Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Мертвая зона - Как визуализировать поток требований в распределенном проекте

0 views

Published on

Сергей Прохоренко, Luxoft (Киев)

Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?

Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.

Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.

Published in: Technology
  • Be the first to comment

Мертвая зона - Как визуализировать поток требований в распределенном проекте

  1. 1. 
  2. 2. Agile предлагаетТрадиционные проблемы Запаздывание необходимойфункциональности Оплата сложных решений инеиспользуемых фич Слишком высокая стоимостьдаже небольших изменений Неизвестно реальное состояниепродукта Приоритизация на основе ценностидля бизнеса Оплата только сделанной ипринятой работы Бесплатное управлениеизменениями Полная прозрачность, демо в концекоротких итераций
  3. 3. POProduct OwnerProductBacklog(Features)SprintPlanningPart 1(What?)2-4 hSprintPlanningPart 2(How?)2-4 hSprintBacklog(Tasks)TeamSMDaily Scrum15 minProduct BacklogRefinement5-10% of Sprint1 Day2-4 weeksSprintPotentially ShippableProduct IncrementSprintReview2-4 hSprintRetrospective1,5-3 hScrum Master
  4. 4. Разработчики Какова цель текущего релиза? Сможем ли мы закончить все,чего ждут пользователи врелизе? Чем заняты другие команды? Есть ли взаимозависимости науровне проекта? Достаточно ли у аналитиковтребований для следующегоспринта?Менеджмент Выпустим ли мы релизвовремя? Какие эпики будут готовы крелизу и каков их текущийстатус? Чем заняты аналитики?Блокирует ли что-то ихработу? Сколько пользовательскихисторий готово к следующемуспринту? Готовы ли мы спланироватьследующий релиз?
  5. 5. Product Owner(может быть заменен комитетомбизнес-спонсоров)Команда(разработчики, тестировщики,дизайнеры и т.д.)Proxy Product Owner(аналитик, постоянноработающий с командой) Приоритизациязапросов Понимание средне- идолгосрочных целейпродукта Не обязательноглубокая экспертиза вовсех деталяхпредметной области Определение целиитерации и приемкарезультата Знание бэклогапродукта в кратко- исреднесрочнойперспективе Глубокое пониманиетребований вплоть доотдельных user story Способностьоперативно отвечатьна вопросы команды Ознакомлениекоманды стребованиями набудущие итерации Участие в детализациитребований до началаитерации (хорошаяпрактика – минимумдва предварительныхобсуждения user storyне позже, чем занеделю до началаитерации) Ориентация нарешение бизнес-задач В течение итерации –фокус насвоевременную сдачувсех user story (впорядкеприоритетности)
  6. 6. вместо

×