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

2. 






3. Agile предлагаетТрадиционные проблемы
 Запаздывание необходимой
функциональности
 Оплата сложных решений и
неиспользуемых фич
 Слишком высокая стоимость
даже небольших изменений
 Неизвестно реальное состояние
продукта
 Приоритизация на основе ценности
для бизнеса
 Оплата только сделанной и
принятой работы
 Бесплатное управление
изменениями
 Полная прозрачность, демо в конце
коротких итераций

4. PO
Product Owner
Product
Backlog
(Features)
Sprint
Planning
Part 1
(What?)
2-4 h
Sprint
Planning
Part 2
(How?)
2-4 h
Sprint
Backlog
(Tasks)
Team
SM
Daily Scrum
15 min
Product Backlog
Refinement
5-10% of Sprint
1 Day
2-4 weeks
Sprint
Potentially Shippable
Product Increment
Sprint
Review
2-4 h
Sprint
Retrospective
1,5-3 h
Scrum Master

11. Разработчики
 Какова цель текущего релиза?
 Сможем ли мы закончить все,
чего ждут пользователи в
релизе?
 Чем заняты другие команды?
 Есть ли взаимозависимости на
уровне проекта?
 Достаточно ли у аналитиков
требований для следующего
спринта?
Менеджмент
 Выпустим ли мы релиз
вовремя?
 Какие эпики будут готовы к
релизу и каков их текущий
статус?
 Чем заняты аналитики?
Блокирует ли что-то их
работу?
 Сколько пользовательских
историй готово к следующему
спринту?
 Готовы ли мы спланировать
следующий релиз?

20. Product Owner
(может быть заменен комитетом
бизнес-спонсоров)
Команда
(разработчики, тестировщики,
дизайнеры и т.д.)
Proxy Product Owner
(аналитик, постоянно
работающий с командой)
 Приоритизация
запросов
 Понимание средне- и
долгосрочных целей
продукта
 Не обязательно
глубокая экспертиза во
всех деталях
предметной области
 Определение цели
итерации и приемка
результата
 Знание бэклога
продукта в кратко- и
среднесрочной
перспективе
 Глубокое понимание
требований вплоть до
отдельных user story
 Способность
оперативно отвечать
на вопросы команды
 Ознакомление
команды с
требованиями на
будущие итерации
 Участие в детализации
требований до начала
итерации (хорошая
практика – минимум
два предварительных
обсуждения user story
не позже, чем за
неделю до начала
итерации)
 Ориентация на
решение бизнес-задач
 В течение итерации –
фокус на
своевременную сдачу
всех user story (в
порядке
приоритетности)

24. вместо