Введение в Agile
0 likes459 views
Документ описывает проблемы традиционного подхода к разработке программного обеспечения, включая низкий уровень успешности проектов и неэффективность в использовании функций. Он выделяет преимущества agile-методов, таких как вовлеченность пользователя, итеративность и гибкость в требованиях. Также обсуждаются роли в agile-командах и основные принципы методологии, включая Daily Scrum и Scrum Master.
Введение в Agile
- 1. Знакомство с Agile Василий Савунов ScrumTrek
- 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% функций разработанного ПО используются постоянно А в чем причина?
- 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. Итеративный подход ЦЕЛЬ Итеративный и инкрементальный подход • Клиент постепенно осознает свои потребности • Цель может меняться в процессе • Разработчики постепенно понимают, как их удовлетворять • Итеративно проверяем, то ли мы делаем • Можем раньше поставить готовый промежуточный результат
- 24. СУТЬ AGILE
- 25. AGILE MANIFESTO ЛЮДИ И ВЗАИМОДЕЙСТВИЕ ВАЖНЕЕ процессов и инструментов РАБОТАЮЩИЙ ПРОДУКТ ВАЖНЕЕ исчерпывающей документации СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ ВАЖНЕЕ согласования условий контракта ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ ВАЖНЕЕ следования плану 2001 http://agilemanifesto.org
- 26. Основные принципы AGILE-разработки • Наивысшим приоритет - удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке. • Работающий продукт следует выпускать как можно чаще (от пары недель до пары месяцев). • На протяжении всего проекта разработчики и бизнес (заказчики) должны ежедневно работать вместе • Непосредственное общение как с самой командой, так и внутри команды есть наилучший способ обмена информацией • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. • Работающий продукт — основной показатель прогресса. http://agilemanifesto.org
- 27. Waterfall vs Agile: этапность
- 28. Waterfall vs Agile: возврат инвестиций и риски
- 31. Первое ограничение: стоимость Rework (технологический фактор) AGILE AGILE
- 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) • Ежедневное статусное собрание • Постоянное улучшение работы команды • Выделенный представитель бизнеса
- 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
- 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 Эксперты + Заинтересованные лица
- 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: некоторые компании и продукты