Agile в управлении и разработке ПО

1. Управление потоком требований в
распределенных проектах
Мертвая зона
Сергей Прохоренко
Luxoft
6 February 2014

2. 2
Agile в Luxoft
23 May 2014
 Проекты с 2005 года
 15+ заказчиков
 90+ текущих проектов
 ~100 Certified Scrum Masters
 ~700 Agile практиков
 17 внутренних Agile/Lean коучей
Практический опыт в Agile Выделенный центр экспертизы
Старт новых
Agile/Lean проектов
Трансформация
существующих
проектов
Аудит и улучшение
процессов в Agile
проектах

3. 3
В поисках «серебряной пули»
23 May 2014
Agile
предлагает
Приоритизация на
основе ценности
для бизнеса
Оплата только
сделанной и
принятой работы
Бесплатное
управление
изменениями
Полная
прозрачность, демо
в конце коротких
итераций
Проблема
клиента
Запаздывание
необходимой
функциональности
«Изобретение
велосипеда» и
фичи, «готовые на
90%»
Слишком высокая
стоимость даже
небольших
изменений
Неизвестно
реальное
состояние продукта
vs
vs
vs
vs
Never
45%
Rarely
19%
Sometimes
16%
Often
13%
Always
7%
Actual use of requested
features
Источник: The CHAOS Manifesto, The Standish Group, 2011

4. 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
289 страниц vs 16 страниц

5. 5
...но сложно научиться играть

6. 6
Product Owner в идеальном мире
 Responsible for maximizing the value of
the product and the work of the
Development Team
 Sole person responsible for managing the
Product Backlog
– Power
– Expertise
– Dedication
 Does Sprint Planning and PBR with the
Development Team
 Tracks total work remaining at least every
Sprint Review

7. 7
...и в реальном

8. 8
ScrumButt (СкрамНо)

9. 9
Следование карго-культу

10. 10
Процесс важнее сотрудничества
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
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
New stories
(no time to
PBR!)
No sprint
commitment! L

11. 11
Визуализация на уровне спринта

12. 12

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

14. 14
Люди и их
взаимодействия

15. 15
«Разделяй и властвуй»
Если вы не живете в «идеальном мире» – это нормально!
В сложных проектах PO – организатор, а не эксперт

16. 16
Proxy PO
Proxy PO: полезен или вреден?
 Со стороны команды
 Часть команды разработки,
разделяет цель спринта
 Глубокий анализ бизнес-
требований
 Организует анализ бэклога
 Отвечает на вопросы
 Общается с экспертами в
предметной области
Product Owner
 Со стороны бизнеса
 Может сам принимать
решения по приоритетам
 Приоритизирует бэклог
продукта
 Принимает бэклог спринта
 Управляет ожиданиями
заказчиков и спонсоров
 Дает доступ к экспертам
The Product Owner may do the […], or have the Development Team
do it. However, the Product Owner remains accountable.
(Scrum Guide, July 2013)

17. 17
Не просто “БА на стероидах”
Командный
игрок
Отслеживает
поток
требований
Организует
анализ
бэклога
Фокус на
бизнес-
ценности, не
документах

18. 18
Пример масштабирования
Компания
 Топ-10 международный инвестбанк
Бизнес-область
 Мидл-офис & бэк-офис & бухгалтерия
Задача
 Перевод системы обработки сделок по
торговле акциями с мэйнфрейма на новую
«облачную» платформу для решения ряда
бизнес-проблем
География
 EMEA, APAC & North America regions
Команда
 13 распределенных команд работают над
одним продуктом
 4 команды в Luxoft (30+ человек)
Scrum Mentor
A Team
Sr. Java
Developer/
SCRUM Master
Sr. Java
Developer
BA / pPO
B Team
Sr. Java
Developer
Sr. Java
Developer/
SCRUM Master
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
Sr. Java
Developer
Sr. Java
Developer
Product Owner
Luxoft Onsite
Coordinator
Onshore Team
Onshore Team
Onshore
Sr. Java
Developer/
SCRUM Master
Sr. Java
Developer
Sr. Java
Developer
C Team
QA
Sr. Java
Developer
QA
Sr. Java
Developer
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
QASr. Java
Developer/
SCRUM Master
Sr. Java
Developer
D Team
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
QA
Luxoft Customer
Streams A/B owner
Stream D owner
Stream C owner
Sr. Java
Developer
Single Product

19. 19
Четкое разграничение ролей
Приоритизация
Коммуникация
Экспертиза

20. 20
Процессы и
инструменты

21. 21
Kanban на уровне проекта (программы)
23 May 2014

22. 22
Поток ценностей
Request from
stakeholders
Backlog
prioritization
Backlog
refinement
Ready for
development
Sprint
Ready for
release

23. 23
Начните с имеющегося

24. 24
Используйте Value Stream Mapping
Request from
business
sponsors
Program
initiation
Project
chartering
Epics
breakdown
User story
drafting
User story
grooming
Ready for
sprint
In
development
Ready for
demo
Ready for
UAT
In UAT
Ready for
release

25. 25
Definition of Done для фаз анализа
23 May 2014
Program
initiation
• PID is shared with
BAs
• Project charter is
drafted and
shared with
business sponsors
and BAs
Project
chartering
• Charter is
approved by
business sponsors
• Final charter is
reviewed with BAs
in a meeting
Epics
breakdown
• Charter
breakdown into
epics is approved
by PO
• All epics are
described in
Confluence with:
• Business context
• Problem
statement
• High-level
acceptance
criteria
• All epics are
presented to the
team(s)
• Epics are included
into backlog and
prioritized
• Business contacts
identified
User story
drafting
• User story is well-
analyzed by BA
and conform to
INVEST criteria
• Detailed BDD
scenarios are
created
• Mockups are
created (where
applicable)
• Data requirements
specified (if any)
• Business logic is
specified (if any)
• US reviewed with
business SME
• Acceptance
criteria are
reviewed by
business SME
• US is prioritized in
backlog and
priority approved
by PO
User story
grooming
• Team reviewed
and agreed that
US conforms to
INVEST criteria
• BDD acceptance
scenarios are well
understood by
team and
approved by
business
• All research
spikes identified
and completed
• US breakdown is
approved by team
(and re-approved
by business if any
changes)
• Business contacts
are shared with
the team
• Design is
approved
DoD for last analysis phase = DoR for sprint

26. 26
Ограничивайте WIP

27. 27
Четкие правила PBR
23 May 2014
• Минимум раз в неделю, есть в календаре у PO
• Начинается заранее (минимум за неделю до спринта)
Регулярный
• 15-20 минут на user story
• Если не хватило времени –вопросы/ответы оффлайн и обсуждаем
на следующем PBR
Ограничен по времени
• Все члены команды вопросы до разработки
• Члены команды (не только PO/pPO) объясняют историю, сценарии
и дизайн
Участвует вся команда
• Если артефакт не соответствует DoD, он не идет дальше
Следование DoD

28. 28
Эффективное взаимодействие
Feature Team US 1
Feature Team UA 2Feature Team US 2
Feature Team UA 1
Scrum of Scrums
 Scrum of Scrums
 Кросс-функциональные
команды
 Единый бэклог с едиными
оценками
 Один Product Owner
 Proxy Product Owners для
каждой локации
 Совместное релизное
планирование

29. 29
Создание
бэклога

30. 30
Видение и цели продукта
 Зачем нам продукт/проекта
 Долгосрочные цели
 Общее понимание бизнеса

31. 31
Используйте Business Model Canvas

32. 32
Story Mapping
 Высокоуровневые фичи
 Отсортированы с позиции
пользователя
 Включают маркировку скиллов
 Выполняемые действия
 Формируем поток
 Приоритизируем по ценности для
бизнеса

33. 33
Начальный бэклог

34. 34
Формируем оценочную сетку

35. 35
Рабочие соглашения
 Definition of Done
 Definition of Ready
 Ограничение WIP
 График встреч
 Все остальное

36. 36
Результаты
 Числа:
– Разные клиенты: от стартапа до топ-10 инвестбанка
– Разные размеры проектов: до 3 команд на одном воркшопе
– Средний цикл: повтор каждые 3-6 месяцев
– Продолжительность: до 2 недель в первый раз, 3-5 дней потом
 Достижения:
– Гораздо более открытое общение между PO и разработчиками
– Лучшее понимание бизнес-области, целей и задач проекта
– Более надежное средне- и долгосрочное планирование
– Разработчики вовлечены в создание продукта

37. 37
Что дальше?

38. 38
Общая картина

39. 39
Нет хороших практик, подходящих всем
vs

40. 40
Действуйте!

41. 41
Что еще почитать

42. Your
QR Code
Спасибо!
6 February 2014
Sergey Prokhorenko
Luxoft
sprokhorenko@luxoft.com
ua.linkedin.com/in/sergeyprokhorenko