Управление потоком требований в распределенных проектах

Мертвая зона

Сергей Прохоренко

Luxoft

6 February 2014

2

Agile в Luxoft

23 May 2014

Проекты с 2005 года

15+ заказчиков

90+ текущих проектов

~100 Certified Scrum Masters

~700 Agile практиков

17 внутренних Agile/Lean коучей

Практический опыт в Agile Выделенный центр экспертизы

Старт новых

Agile/Lean проектов

Трансформация

существующих

проектов

Аудит и улучшение

процессов в Agile

проектах

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

Простые правила

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

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

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

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

8

ScrumButt (СкрамНо)

9

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

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

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

12

13

«Мертвая зона» требований

Разработчики

Какова цель текущего релиза?

Сможем ли мы закончить все,

чего ждут пользователи в

релизе?

Чем заняты другие команды?

Есть ли взаимозависимости на

уровне проекта?

Достаточно ли у аналитиков

требований для следующего

спринта?

Менеджмент

Выпустим ли мы релиз

вовремя?

Какие эпики будут готовы к

релизу и каков их текущий

статус?

Чем занят PO, аналитики?

Блокирует ли что-то их

работу?

Сколько пользовательских

историй готово к следующему

спринту?

Готовы ли мы спланировать

следующий релиз?

14

Люди и их

взаимодействия

15

«Разделяй и властвуй»

Если вы не живете в «идеальном мире» – это нормально!

В сложных проектах PO – организатор, а не эксперт

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

Не просто “БА на стероидах”

Командный игрок

Отслеживает поток

требований

Организует анализ бэклога

Фокус на бизнес-

ценности, не документах

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

Четкое разграничение ролей

Приоритизация

Коммуникация

Экспертиза

20

Процессы и

инструменты

21

Kanban на уровне проекта (программы)

23 May 2014

22

Поток ценностей

Request from stakeholders

Backlog prioritization

Backlog refinement

Ready for development

Sprint Ready for release

23

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

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

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

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

27

Четкие правила PBR

23 May 2014

• Минимум раз в неделю, есть в календаре у PO

• Начинается заранее (минимум за неделю до спринта)

Регулярный

• 15-20 минут на user story

• Если не хватило времени –вопросы/ответы оффлайн и обсуждаем на следующем PBR

Ограничен по времени

• Все члены команды вопросы до разработки

• Члены команды (не только PO/pPO) объясняют историю, сценарии и дизайн

Участвует вся команда

• Если артефакт не соответствует DoD, он не идет дальше

Следование DoD

28

Эффективное взаимодействие

Feature Team US 1

Feature Team UA 2 Feature Team US 2

Feature Team UA 1

Scrum of Scrums

Scrum of Scrums

Кросс-функциональные

команды

Единый бэклог с едиными

оценками

Один Product Owner

Proxy Product Owners для

каждой локации

Совместное релизное

планирование

29

Создание

бэклога

30

Видение и цели продукта

Зачем нам продукт/проекта

Долгосрочные цели

Общее понимание бизнеса

31

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

32

Story Mapping

Высокоуровневые фичи

Отсортированы с позиции

пользователя

Включают маркировку скиллов

Выполняемые действия

Формируем поток

Приоритизируем по ценности для

бизнеса

33

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

34

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

35

Рабочие соглашения

Definition of Done

Definition of Ready

Ограничение WIP

График встреч

Все остальное

36

Результаты

Числа:

– Разные клиенты: от стартапа до топ-10 инвестбанка

– Разные размеры проектов: до 3 команд на одном воркшопе

– Средний цикл: повтор каждые 3-6 месяцев

– Продолжительность: до 2 недель в первый раз, 3-5 дней потом

Достижения:

– Гораздо более открытое общение между PO и разработчиками

– Лучшее понимание бизнес-области, целей и задач проекта

– Более надежное средне- и долгосрочное планирование

– Разработчики вовлечены в создание продукта

37

Что дальше?

38

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

39

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

vs

40

Действуйте!

41

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

Your

QR Code Спасибо!

6 February 2014

Sergey Prokhorenko

Luxoft

sprokhorenko@luxoft.com

ua.linkedin.com/in/sergeyprokhorenko