View
38
Download
0
Category
Preview:
DESCRIPTION
Agile в управлении и разработке ПО
Citation preview
Управление потоком требований в распределенных проектах
Мертвая зона
Сергей Прохоренко
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
Recommended