Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Знакомство с Agile
Василий Савунов
ScrumTrek
http://scrumtrek.ru
Сперва немного статистики
Успешность проектов
http://www.infoq.com/articles/standish-chaos-2015
Лишь около 30%
проектов
по разработке ПО
заканчивают...
Использование функций
http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf
• 45-65% функций ПО
используютс...
ИТОГО
• Лишь 30% проектов по разработке ПО заканчиваются
полным успехом
• При этом, лишь 20% функций разработанного ПО
исп...
Классика жанра
Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
Приемка
пользователем
Пользователь...
Время
Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
• Петли обратной связи
• Отс...
Как это выглядит для заказчика?
Заключили
контракт
ГДЕ?!
Магия
ЧТО ЭТО?!
То есть:
Делаем не то Делаем долго
Недостаток
прямого общения
Не прозрачно
Как это выглядит для подрядчика
- Расскажите, как вы видите
конечный продукт?
- Я в этом ничего не понимаю.
Вы специалист,...
Как это выглядит для подрядчика - 2
- Я ничего в этом не понимаю.
Вы специалист, вот вам
деньги, расскажите как
правильно....
УСЛОВИЯ УСПЕХА
Условия успеха Waterfall
• Заказчик точно знает чего хочет
• Разработчики точно знают как это реализовать технически
• Тре...
Реальность Waterfall
Цель
«Вы сделали то, что я
просил, но это не то, что
мне сейчас нужно»
«Я знаю рынок, Вот
вам деньги,...
Факторы успеха проектов
Вовлеченность
пользователей –
главная причина
успеха проектов.
Затем идут поддержка
менеджмента и
...
ПРИ ЧЕМ ТУТ AGILE?
Еще немного статистики
http://www.infoq.com/articles/standish-chaos-2015
© Standish Group ChaosReport 2015
По итогам 2010-...
Основные особенности Agile-подхода
• Обязательное участие представителя заказчика
• Ориентация на пользователя при проекти...
Итеративный подход
ЦЕЛЬ
Итеративный и инкрементальный
подход
• Клиент постепенно осознает свои
потребности
• Цель может ме...
Валидация
agile
«ложная» загрузка
СУТЬ AGILE
AGILE MANIFESTO
ЛЮДИ И ВЗАИМОДЕЙСТВИЕ
ВАЖНЕЕ процессов и инструментов
РАБОТАЮЩИЙ ПРОДУКТ
ВАЖНЕЕ исчерпывающей документации...
Основные принципы AGILE-разработки
• Наивысшим приоритет - удовлетворение потребностей
заказчика, благодаря регулярной и р...
Waterfall vs Agile: этапность
Waterfall vs Agile: возврат инвестиций и
риски
ОГРАНИЧЕНИЯ ПРИМЕНЕНИЯ
AGILE
Первое ограничение:
стоимость Rework
(технологический фактор)
AGILE AGILE
Модель Кеневин
ХАОТИЧНЫЕ
СЛОЖНЫЕКОМПЛЕКСН.
Дейв Сноуден
ПРОСТЫЕ
УпорядоченныеНеупорядоченные
Второе ограничение
комплексность окружения/системы
(ищем путь к продукту)
Run vs Change
Change the company Run the company
Третий фактор
Деятельность по созданию/изменению
продуктов и процессов
(возможность экспериментов)
AGILE ПРАКТИКИ
Распространенность Agile-практик
http://stateofagile.versionone.com
© 10th State of Agile Report - VersionOne
SCRUM FRAMEWORK
Обзор Scrum
Особенности Scrum
• Список задач по продукту (Product Backlog) со сквозными
приоритетами
• Работа быстрыми итерациями фикс...
FAIL FAST
FAIL
FAST
Роли
Dev Team Product Owner Scrum Master
Мероприятия Scrum
• Sprint Planning
• Daily Scrum
• Sprint Review (Demo)
• Sprint Retrospective
• Backlog Grooming
Артефакты Scrum
• Product Backlog
• Sprint Backlog
• Product Increment
• Definition of Done
• Scrum Board
• Burndown Chart...
PRODUCT OWNER
PRODUCT
OWNER
STAKEHOLDERS
CUSTOMERS
DEV TEAM
BACKLOG
PRODUCT
OWNER
STAKEHOLDERS
CUSTOMERS
VISION
BACKLOG
«Нет!»
DEV TEAM
Product owner с точки зрения руководства
• Владеет продуктом от имени организации
• Несет ответственность перед руководств...
Product owner с точки зрения команды
• Отвечает за ценность
проделываемой командой
работы
• Отвечает за прозрачность и
ясн...
Product Owner в Scrum
PRODUCT
OWNER
Владеет
и Создает
Участвует
Отвечает на
вопросы
команды
Участвует в
демонстрации
Менеджер проекта vs Product owner
Менеджер проекта Product owner
Цель – сдать проект Цель – создать продукт c
максимальной...
SCRUM MASTER
SCRUM
МАСТЕР
ЗАИНТЕРЕСОВАННЫЕ
ЛИЦА
КОМАНДАPRODUCT
OWNER
МЕНЕДЖМЕНТ
• СПОСОБСТВУЕТ
ПОВЫШЕНИЮ
ГИБКОСТИ
• СОВЕТУЕТ И
КОУЧИТ
•...
Менеджер проекта vs Scrum-Мастер
Менеджер проекта Scrum-Мастер
Цель – сдать проект Цель – создать
эффективную команду
Разд...
AGILE КОМАНДА
Пример структуры кроссфункциональной
команды
Бизнес заказчик
Product Owner
Аналитики
Scrum-мастер
Разработчики
Разработчик...
Состав команды
• Частичная занятость
– Эксперты в предметной
области
– Заинтересованные лица
• Полная занятость
– Product ...
Классическая проектная структура
Customer
Вертикальная
коммуникация
Ценность не соответствует колодцам
Задача Agile: соединить колодцы
Трения между
колодцами
Рассад...
Свойства и структура Scrum-команды
• 5-9 человек, стабильная команда
• Кросс-функциональная
(все необходимые компетенции)
...
Принципы самоорганизации
• Коллективное принятие решений
– Обеспечивает ответственность за результат
– Не работает без дов...
Tucman’s Model – Эволюция команды
Эффективность
Время
AGILE В МИРЕ
Agile – виды компаний
http://stateofagile.versionone.com
© 10th State of Agile Report - VersionOne
Agile: некоторые компании и продукты
vsavunov@scrumtrek.ru
babr79
СПАСИБО ЗА ВНИМАНИЕ
Вопросы?
http://scrumtrek.ru
Введение в Agile
Введение в Agile
Введение в Agile
Upcoming SlideShare
Loading in …5
×

Введение в Agile

313 views

Published on

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

Published in: Leadership & Management
  • Be the first to comment

  • Be the first to like this

Введение в Agile

  1. 1. Знакомство с Agile Василий Савунов ScrumTrek
  2. 2. http://scrumtrek.ru
  3. 3. Сперва немного статистики
  4. 4. Успешность проектов http://www.infoq.com/articles/standish-chaos-2015 Лишь около 30% проектов по разработке ПО заканчиваются успешно (уложились в срок и бюджет) © Standish Group ChaosReport 2015
  5. 5. Использование функций http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf • 45-65% функций ПО используются редко или никогда • Лишь 20% функций используются постоянно Никогда 45% Редко 19% Иногда 16% Постоянно 20% Никогда Редко Иногда Постоянно © Standish Group Chaos Manifesto 2013
  6. 6. ИТОГО • Лишь 30% проектов по разработке ПО заканчиваются полным успехом • При этом, лишь 20% функций разработанного ПО используются постоянно А в чем причина?
  7. 7. Классика жанра
  8. 8. Обычный подход к разработке ПО ТРЕБОВАНИЯ АНАЛИЗ ДИЗАЙН РАЗРАБОТКА ТЕСТИРОВАНИЕ ПРИЕМКА Приемка пользователем Пользователь рассказывает Нет взаимодействия с пользователем • Недостаток коммуникации • Нет обратной связи от пользователя
  9. 9. Время Обычный подход к разработке ПО ТРЕБОВАНИЯ АНАЛИЗ ДИЗАЙН РАЗРАБОТКА ТЕСТИРОВАНИЕ ПРИЕМКА • Петли обратной связи • Отсутствие прямого взаимодействия с пользователем • Затраты времени на согласование и уточнение • Не укладываемся в срок • Выпускаем то, что успели • Пользователь не доволен ? ? ? ? ? ?? ? rework rework rework rework +rework +rework +rework +rework START А РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т П DEADLINE DEADLINE !? !?
  10. 10. Как это выглядит для заказчика? Заключили контракт ГДЕ?! Магия ЧТО ЭТО?!
  11. 11. То есть: Делаем не то Делаем долго Недостаток прямого общения Не прозрачно
  12. 12. Как это выглядит для подрядчика - Расскажите, как вы видите конечный продукт? - Я в этом ничего не понимаю. Вы специалист, сделайте мне «красиво». Встретимся через год. • Надо догадаться, что нужно пользователю • Действуем исходя из предположений
  13. 13. Как это выглядит для подрядчика - 2 - Я ничего в этом не понимаю. Вы специалист, вот вам деньги, расскажите как правильно. - Вот так будет правильно. - Я с вами не согласен. • Не доверяем экспертному мнению • «Вы сделали то, что я просил, но оказывается, мне нужно не это»
  14. 14. УСЛОВИЯ УСПЕХА
  15. 15. Условия успеха Waterfall • Заказчик точно знает чего хочет • Разработчики точно знают как это реализовать технически • Требования не меняются в процессе реализации • Рынок меняется медленно Das ist fantastisch! 
  16. 16. Реальность Waterfall Цель «Вы сделали то, что я просил, но это не то, что мне сейчас нужно» «Я знаю рынок, Вот вам деньги, сделайте вот это»
  17. 17. Факторы успеха проектов Вовлеченность пользователей – главная причина успеха проектов. Затем идут поддержка менеджмента и понятные требования http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf © Standish Group Chaos Report 2014
  18. 18. ПРИ ЧЕМ ТУТ AGILE?
  19. 19. Еще немного статистики http://www.infoq.com/articles/standish-chaos-2015 © Standish Group ChaosReport 2015 По итогам 2010-2015гг видно: • Общая стагнация в области разработки ПО • Чем крупнее проект, тем больше шансов провала • Уверенное преимущество Agile над Waterfall
  20. 20. Основные особенности Agile-подхода • Обязательное участие представителя заказчика • Ориентация на пользователя при проектировании продукта • Все необходимые специалисты вместе • Работа небольшими порциями законченного функционала • Как можно более ранняя поставка • Ранняя проверка гипотез (MVP - Minimum Viable Product)
  21. 21. Итеративный подход ЦЕЛЬ Итеративный и инкрементальный подход • Клиент постепенно осознает свои потребности • Цель может меняться в процессе • Разработчики постепенно понимают, как их удовлетворять • Итеративно проверяем, то ли мы делаем • Можем раньше поставить готовый промежуточный результат
  22. 22. Валидация agile «ложная» загрузка
  23. 23. СУТЬ AGILE
  24. 24. AGILE MANIFESTO ЛЮДИ И ВЗАИМОДЕЙСТВИЕ ВАЖНЕЕ процессов и инструментов РАБОТАЮЩИЙ ПРОДУКТ ВАЖНЕЕ исчерпывающей документации СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ ВАЖНЕЕ согласования условий контракта ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ ВАЖНЕЕ следования плану 2001 http://agilemanifesto.org
  25. 25. Основные принципы AGILE-разработки • Наивысшим приоритет - удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке. • Работающий продукт следует выпускать как можно чаще (от пары недель до пары месяцев). • На протяжении всего проекта разработчики и бизнес (заказчики) должны ежедневно работать вместе • Непосредственное общение как с самой командой, так и внутри команды есть наилучший способ обмена информацией • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. • Работающий продукт — основной показатель прогресса. http://agilemanifesto.org
  26. 26. Waterfall vs Agile: этапность
  27. 27. Waterfall vs Agile: возврат инвестиций и риски
  28. 28. ОГРАНИЧЕНИЯ ПРИМЕНЕНИЯ AGILE
  29. 29. Первое ограничение: стоимость Rework (технологический фактор) AGILE AGILE
  30. 30. Модель Кеневин ХАОТИЧНЫЕ СЛОЖНЫЕКОМПЛЕКСН. Дейв Сноуден ПРОСТЫЕ УпорядоченныеНеупорядоченные
  31. 31. Второе ограничение комплексность окружения/системы (ищем путь к продукту)
  32. 32. Run vs Change Change the company Run the company
  33. 33. Третий фактор Деятельность по созданию/изменению продуктов и процессов (возможность экспериментов)
  34. 34. AGILE ПРАКТИКИ
  35. 35. Распространенность Agile-практик http://stateofagile.versionone.com © 10th State of Agile Report - VersionOne
  36. 36. SCRUM FRAMEWORK
  37. 37. Обзор Scrum
  38. 38. Особенности Scrum • Список задач по продукту (Product Backlog) со сквозными приоритетами • Работа быстрыми итерациями фиксированной длительности (Sprint) • Фиксация списка задач на итерацию (Sprint Backlog) • Регулярная демонстрация сделанного за итерацию (Product Increment) • Ежедневное статусное собрание • Постоянное улучшение работы команды • Выделенный представитель бизнеса
  39. 39. FAIL FAST FAIL FAST
  40. 40. Роли Dev Team Product Owner Scrum Master
  41. 41. Мероприятия Scrum • Sprint Planning • Daily Scrum • Sprint Review (Demo) • Sprint Retrospective • Backlog Grooming
  42. 42. Артефакты Scrum • Product Backlog • Sprint Backlog • Product Increment • Definition of Done • Scrum Board • Burndown Chart Product Backlog Scrum Board Burndown Chart
  43. 43. PRODUCT OWNER
  44. 44. PRODUCT OWNER STAKEHOLDERS CUSTOMERS DEV TEAM BACKLOG
  45. 45. PRODUCT OWNER STAKEHOLDERS CUSTOMERS VISION BACKLOG «Нет!» DEV TEAM
  46. 46. Product owner с точки зрения руководства • Владеет продуктом от имени организации • Несет ответственность перед руководством • Принимает любую обратную связь, но… • Самостоятельно принимает решения
  47. 47. Product owner с точки зрения команды • Отвечает за ценность проделываемой командой работы • Отвечает за прозрачность и ясность баклога для команды • Несет ответственность перед заинтересованными лицами
  48. 48. Product Owner в Scrum PRODUCT OWNER Владеет и Создает Участвует Отвечает на вопросы команды Участвует в демонстрации
  49. 49. Менеджер проекта vs Product owner Менеджер проекта Product owner Цель – сдать проект Цель – создать продукт c максимальной ценностью Управляет людьми, расписанием, рисками Управляет требованиями к продукту Оптимизация сроков, стоимости и бюджета Оптимизация поставки бизнес-ценности
  50. 50. SCRUM MASTER
  51. 51. SCRUM МАСТЕР ЗАИНТЕРЕСОВАННЫЕ ЛИЦА КОМАНДАPRODUCT OWNER МЕНЕДЖМЕНТ • СПОСОБСТВУЕТ ПОВЫШЕНИЮ ГИБКОСТИ • СОВЕТУЕТ И КОУЧИТ • ОБЪЯСНЯЕТ AGILE • КОУЧИТ • ОРГАНИЗУЕТ МЕРОПРИЯТИЯ • УСТРАНЯЕТ ВНЕШНИЕ ПРЕПЯТСТВИЯ
  52. 52. Менеджер проекта vs Scrum-Мастер Менеджер проекта Scrum-Мастер Цель – сдать проект Цель – создать эффективную команду Раздает задачи Координирует людей Управляет планами Управляет процессом Управляет рисками Устраняет препятствия
  53. 53. AGILE КОМАНДА
  54. 54. Пример структуры кроссфункциональной команды Бизнес заказчик Product Owner Аналитики Scrum-мастер Разработчики Разработчики, тестировщики Product Discovery Product Delivery
  55. 55. Состав команды • Частичная занятость – Эксперты в предметной области – Заинтересованные лица • Полная занятость – Product owner – Scrum-мастер – Все специалисты, нужные для достижения цели PO SM Эксперты + Заинтересованные лица
  56. 56. Классическая проектная структура Customer
  57. 57. Вертикальная коммуникация Ценность не соответствует колодцам Задача Agile: соединить колодцы Трения между колодцами Рассадка по функциям Политические барьеры
  58. 58. Свойства и структура Scrum-команды • 5-9 человек, стабильная команда • Кросс-функциональная (все необходимые компетенции) • PO отвечает за продукт • Способен сбалансировать интересы всех заказчиков • Отвечает за бизнес-показатели • SM растит команду • Командная ответственность • В команде все равны • Плоская команда (нет подкоманд) • Самоорганизация в команде
  59. 59. Принципы самоорганизации • Коллективное принятие решений – Обеспечивает ответственность за результат – Не работает без доверия и общей цели • Общая цель • Доверие – Для доверия нужна взаимная ответственность • Взаимная ответственность – Не работает без прозрачности • Прозрачность
  60. 60. Tucman’s Model – Эволюция команды Эффективность Время
  61. 61. AGILE В МИРЕ
  62. 62. Agile – виды компаний http://stateofagile.versionone.com © 10th State of Agile Report - VersionOne
  63. 63. Agile: некоторые компании и продукты
  64. 64. vsavunov@scrumtrek.ru babr79 СПАСИБО ЗА ВНИМАНИЕ Вопросы? http://scrumtrek.ru

×