Презентация для доклада на конференции ТЕРН (Business Intelligence)

1. Знакомство с Agile
Василий Савунов
ScrumTrek

2. http://scrumtrek.ru

4. Сперва немного статистики

5. Успешность проектов
http://www.infoq.com/articles/standish-chaos-2015
Лишь около 30%
проектов
по разработке ПО
заканчиваются
успешно (уложились
в срок и бюджет)
© Standish Group ChaosReport 2015

6. Использование функций
http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf
• 45-65% функций ПО
используются редко
или никогда
• Лишь 20% функций
используются
постоянно
Никогда
45%
Редко
19%
Иногда
16%
Постоянно
20%
Никогда
Редко
Иногда
Постоянно
© Standish Group Chaos Manifesto 2013

7. ИТОГО
• Лишь 30% проектов по разработке ПО заканчиваются
полным успехом
• При этом, лишь 20% функций разработанного ПО
используются постоянно
А в чем причина?

8. Классика жанра

9. Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
Приемка
пользователем
Пользователь
рассказывает
Нет взаимодействия с пользователем
• Недостаток
коммуникации
• Нет обратной связи
от пользователя

10. Время
Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
• Петли обратной связи
• Отсутствие прямого
взаимодействия с
пользователем
• Затраты времени на
согласование и уточнение
• Не укладываемся в срок
• Выпускаем то, что успели
• Пользователь не доволен
?
?
?
?
?
??
?
rework
rework
rework
rework
+rework
+rework
+rework
+rework
START
А РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т П
DEADLINE DEADLINE
!?
!?

11. Как это выглядит для заказчика?
Заключили
контракт
ГДЕ?!
Магия
ЧТО ЭТО?!

12. То есть:
Делаем не то Делаем долго
Недостаток
прямого общения
Не прозрачно

13. Как это выглядит для подрядчика
- Расскажите, как вы видите
конечный продукт?
- Я в этом ничего не понимаю.
Вы специалист, сделайте мне
«красиво». Встретимся через
год.
• Надо догадаться,
что нужно
пользователю
• Действуем исходя
из предположений

14. Как это выглядит для подрядчика - 2
- Я ничего в этом не понимаю.
Вы специалист, вот вам
деньги, расскажите как
правильно.
- Вот так будет правильно.
- Я с вами не согласен.
• Не доверяем
экспертному мнению
• «Вы сделали то, что
я просил, но
оказывается, мне
нужно не это»

15. УСЛОВИЯ УСПЕХА

16. Условия успеха Waterfall
• Заказчик точно знает чего хочет
• Разработчики точно знают как это реализовать технически
• Требования не меняются в процессе реализации
• Рынок меняется медленно
Das ist fantastisch! 

17. Реальность Waterfall
Цель
«Вы сделали то, что я
просил, но это не то, что
мне сейчас нужно»
«Я знаю рынок, Вот
вам деньги,
сделайте вот это»

18. Факторы успеха проектов
Вовлеченность
пользователей –
главная причина
успеха проектов.
Затем идут поддержка
менеджмента и
понятные требования
http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf
© Standish Group Chaos Report 2014

19. ПРИ ЧЕМ ТУТ AGILE?

20. Еще немного статистики
http://www.infoq.com/articles/standish-chaos-2015
© Standish Group ChaosReport 2015
По итогам 2010-2015гг видно:
• Общая стагнация в области
разработки ПО
• Чем крупнее проект, тем
больше шансов провала
• Уверенное преимущество
Agile над Waterfall

21. Основные особенности Agile-подхода
• Обязательное участие представителя заказчика
• Ориентация на пользователя при проектировании продукта
• Все необходимые специалисты вместе
• Работа небольшими порциями законченного функционала
• Как можно более ранняя поставка
• Ранняя проверка гипотез (MVP - Minimum Viable Product)

22. Итеративный подход
ЦЕЛЬ
Итеративный и инкрементальный
подход
• Клиент постепенно осознает свои
потребности
• Цель может меняться в процессе
• Разработчики постепенно понимают, как
их удовлетворять
• Итеративно проверяем, то ли мы делаем
• Можем раньше поставить готовый
промежуточный результат

23. Валидация
agile
«ложная» загрузка

24. СУТЬ AGILE

25. AGILE MANIFESTO
ЛЮДИ И ВЗАИМОДЕЙСТВИЕ
ВАЖНЕЕ процессов и инструментов
РАБОТАЮЩИЙ ПРОДУКТ
ВАЖНЕЕ исчерпывающей документации
СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ
ВАЖНЕЕ согласования условий контракта
ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ
ВАЖНЕЕ следования плану
2001
http://agilemanifesto.org

26. Основные принципы AGILE-разработки
• Наивысшим приоритет - удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке.
• Работающий продукт следует выпускать как можно чаще (от пары
недель до пары месяцев).
• На протяжении всего проекта разработчики и бизнес (заказчики)
должны ежедневно работать вместе
• Непосредственное общение как с самой командой, так и внутри
команды есть наилучший способ обмена информацией
• Самые лучшие требования, архитектурные и технические решения
рождаются у самоорганизующихся команд.
• Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
• Работающий продукт — основной показатель прогресса.
http://agilemanifesto.org

27. Waterfall vs Agile: этапность

28. Waterfall vs Agile: возврат инвестиций и
риски

30. ОГРАНИЧЕНИЯ ПРИМЕНЕНИЯ
AGILE

31. Первое ограничение:
стоимость Rework
(технологический фактор)
AGILE AGILE

32. Модель Кеневин
ХАОТИЧНЫЕ
СЛОЖНЫЕКОМПЛЕКСН.
Дейв Сноуден
ПРОСТЫЕ
УпорядоченныеНеупорядоченные

33. Второе ограничение
комплексность окружения/системы
(ищем путь к продукту)

34. Run vs Change
Change the company Run the company

35. Третий фактор
Деятельность по созданию/изменению
продуктов и процессов
(возможность экспериментов)

36. AGILE ПРАКТИКИ

38. Распространенность Agile-практик
http://stateofagile.versionone.com
© 10th State of Agile Report - VersionOne

39. SCRUM FRAMEWORK

40. Обзор Scrum

41. Особенности Scrum
• Список задач по продукту (Product Backlog) со сквозными
приоритетами
• Работа быстрыми итерациями фиксированной длительности
(Sprint)
• Фиксация списка задач на итерацию (Sprint Backlog)
• Регулярная демонстрация сделанного за итерацию (Product
Increment)
• Ежедневное статусное собрание
• Постоянное улучшение работы команды
• Выделенный представитель бизнеса

42. FAIL FAST
FAIL
FAST

43. Роли
Dev Team Product Owner Scrum Master

44. Мероприятия Scrum
• Sprint Planning
• Daily Scrum
• Sprint Review (Demo)
• Sprint Retrospective
• Backlog Grooming

45. Артефакты Scrum
• Product Backlog
• Sprint Backlog
• Product Increment
• Definition of Done
• Scrum Board
• Burndown Chart
Product
Backlog
Scrum Board
Burndown Chart

46. PRODUCT OWNER

47. PRODUCT
OWNER
STAKEHOLDERS
CUSTOMERS
DEV TEAM
BACKLOG

48. PRODUCT
OWNER
STAKEHOLDERS
CUSTOMERS
VISION
BACKLOG
«Нет!»
DEV TEAM

49. Product owner с точки зрения руководства
• Владеет продуктом от имени организации
• Несет ответственность перед руководством
• Принимает любую обратную связь, но…
• Самостоятельно принимает решения

50. Product owner с точки зрения команды
• Отвечает за ценность
проделываемой командой
работы
• Отвечает за прозрачность и
ясность баклога для команды
• Несет ответственность перед
заинтересованными лицами

51. Product Owner в Scrum
PRODUCT
OWNER
Владеет
и Создает
Участвует
Отвечает на
вопросы
команды
Участвует в
демонстрации

52. Менеджер проекта vs Product owner
Менеджер проекта Product owner
Цель – сдать проект Цель – создать продукт c
максимальной ценностью
Управляет людьми,
расписанием, рисками
Управляет требованиями к
продукту
Оптимизация сроков,
стоимости и бюджета
Оптимизация поставки
бизнес-ценности

53. SCRUM MASTER

54. SCRUM
МАСТЕР
ЗАИНТЕРЕСОВАННЫЕ
ЛИЦА
КОМАНДАPRODUCT
OWNER
МЕНЕДЖМЕНТ
• СПОСОБСТВУЕТ
ПОВЫШЕНИЮ
ГИБКОСТИ
• СОВЕТУЕТ И
КОУЧИТ
• ОБЪЯСНЯЕТ
AGILE
• КОУЧИТ
• ОРГАНИЗУЕТ
МЕРОПРИЯТИЯ
• УСТРАНЯЕТ
ВНЕШНИЕ
ПРЕПЯТСТВИЯ

55. Менеджер проекта vs Scrum-Мастер
Менеджер проекта Scrum-Мастер
Цель – сдать проект Цель – создать
эффективную команду
Раздает задачи Координирует людей
Управляет планами Управляет процессом
Управляет рисками Устраняет препятствия

56. AGILE КОМАНДА

57. Пример структуры кроссфункциональной
команды
Бизнес заказчик
Product Owner
Аналитики
Scrum-мастер
Разработчики
Разработчики,
тестировщики
Product Discovery
Product Delivery

58. Состав команды
• Частичная занятость
– Эксперты в предметной
области
– Заинтересованные лица
• Полная занятость
– Product owner
– Scrum-мастер
– Все специалисты, нужные
для достижения цели
PO
SM
Эксперты
+
Заинтересованные
лица

59. Классическая проектная структура
Customer

60. Вертикальная
коммуникация
Ценность не соответствует колодцам
Задача Agile: соединить колодцы
Трения между
колодцами
Рассадка по
функциям
Политические
барьеры

61. Свойства и структура Scrum-команды
• 5-9 человек, стабильная команда
• Кросс-функциональная
(все необходимые компетенции)
• PO отвечает за продукт
• Способен сбалансировать интересы всех
заказчиков
• Отвечает за бизнес-показатели
• SM растит команду
• Командная ответственность
• В команде все равны
• Плоская команда (нет подкоманд)
• Самоорганизация в команде

62. Принципы самоорганизации
• Коллективное принятие решений
– Обеспечивает ответственность за результат
– Не работает без доверия и общей цели
• Общая цель
• Доверие
– Для доверия нужна взаимная ответственность
• Взаимная ответственность
– Не работает без прозрачности
• Прозрачность

63. Tucman’s Model – Эволюция команды
Эффективность
Время

64. AGILE В МИРЕ

65. Agile – виды компаний
http://stateofagile.versionone.com
© 10th State of Agile Report - VersionOne

66. Agile: некоторые компании и продукты

67. vsavunov@scrumtrek.ru
babr79
СПАСИБО ЗА ВНИМАНИЕ
Вопросы?
http://scrumtrek.ru