Введение в Agile

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

2. http://scrumtrek.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. СУТЬ AGILE

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

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

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

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

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

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

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

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

32. Run vs Change Change the company Run the company

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

34. AGILE ПРАКТИКИ

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

36. SCRUM FRAMEWORK

37. Обзор Scrum

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

39. FAIL FAST FAIL FAST

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

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

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

43. PRODUCT OWNER

44. PRODUCT OWNER STAKEHOLDERS CUSTOMERS DEV TEAM BACKLOG

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

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

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

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

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

50. SCRUM MASTER

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

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

53. AGILE КОМАНДА

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

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

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

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

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

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

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

61. AGILE В МИРЕ

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

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

Введение в Agile

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Введение в Agile

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Введение в Agile (20)

Plus récents (7)