Uploaded byВасилий Савунов
Введение в Agile
Документ описывает проблемы традиционного подхода к разработке программного обеспечения, включая низкий уровень успешности проектов и неэффективность в использовании функций. Он выделяет преимущества agile-методов, таких как вовлеченность пользователя, итеративность и гибкость в требованиях. Также обсуждаются роли в agile-командах и основные принципы методологии, включая Daily Scrum и Scrum Master.
Введение в Agile
- 1. Знакомство с Agile ВасилийСавунов ScrumTrek
- 2.
- 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.
- 24.
- 25. AGILE MANIFESTO ЛЮДИ ИВЗАИМОДЕЙСТВИЕ ВАЖНЕЕ процессов и инструментов РАБОТАЮЩИЙ ПРОДУКТ ВАЖНЕЕ исчерпывающей документации СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ ВАЖНЕЕ согласования условий контракта ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ ВАЖНЕЕ следования плану 2001 http://agilemanifesto.org
- 26. Основные принципы AGILE-разработки •Наивысшим приоритет - удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке. • Работающий продукт следует выпускать как можно чаще (от пары недель до пары месяцев). • На протяжении всего проекта разработчики и бизнес (заказчики) должны ежедневно работать вместе • Непосредственное общение как с самой командой, так и внутри команды есть наилучший способ обмена информацией • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. • Работающий продукт — основной показатель прогресса. http://agilemanifesto.org
- 27. Waterfall vs Agile:этапность
- 28. Waterfall vs Agile:возврат инвестиций и риски
- 30.
- 31. Первое ограничение: стоимость Rework (технологическийфактор) AGILE AGILE
- 32.
- 33. Второе ограничение комплексность окружения/системы (ищемпуть к продукту)
- 34. Run vs Change Changethe company Run the company
- 35. Третий фактор Деятельность посозданию/изменению продуктов и процессов (возможность экспериментов)
- 36.
- 38. Распространенность Agile-практик http://stateofagile.versionone.com © 10thState of Agile Report - VersionOne
- 39.
- 40.
- 41. Особенности Scrum • Списокзадач по продукту (Product Backlog) со сквозными приоритетами • Работа быстрыми итерациями фиксированной длительности (Sprint) • Фиксация списка задач на итерацию (Sprint Backlog) • Регулярная демонстрация сделанного за итерацию (Product Increment) • Ежедневное статусное собрание • Постоянное улучшение работы команды • Выделенный представитель бизнеса
- 42.
- 43. Роли Dev Team ProductOwner Scrum Master
- 44. Мероприятия Scrum • SprintPlanning • Daily Scrum • Sprint Review (Demo) • Sprint Retrospective • Backlog Grooming
- 45. Артефакты Scrum • ProductBacklog • Sprint Backlog • Product Increment • Definition of Done • Scrum Board • Burndown Chart Product Backlog Scrum Board Burndown Chart
- 46.
- 47.
- 48.
- 49. Product owner сточки зрения руководства • Владеет продуктом от имени организации • Несет ответственность перед руководством • Принимает любую обратную связь, но… • Самостоятельно принимает решения
- 50. Product owner сточки зрения команды • Отвечает за ценность проделываемой командой работы • Отвечает за прозрачность и ясность баклога для команды • Несет ответственность перед заинтересованными лицами
- 51. Product Owner вScrum PRODUCT OWNER Владеет и Создает Участвует Отвечает на вопросы команды Участвует в демонстрации
- 52. Менеджер проекта vsProduct owner Менеджер проекта Product owner Цель – сдать проект Цель – создать продукт c максимальной ценностью Управляет людьми, расписанием, рисками Управляет требованиями к продукту Оптимизация сроков, стоимости и бюджета Оптимизация поставки бизнес-ценности
- 53.
- 54. SCRUM МАСТЕР ЗАИНТЕРЕСОВАННЫЕ ЛИЦА КОМАНДАPRODUCT OWNER МЕНЕДЖМЕНТ • СПОСОБСТВУЕТ ПОВЫШЕНИЮ ГИБКОСТИ • СОВЕТУЕТИ КОУЧИТ • ОБЪЯСНЯЕТ AGILE • КОУЧИТ • ОРГАНИЗУЕТ МЕРОПРИЯТИЯ • УСТРАНЯЕТ ВНЕШНИЕ ПРЕПЯТСТВИЯ
- 55. Менеджер проекта vsScrum-Мастер Менеджер проекта Scrum-Мастер Цель – сдать проект Цель – создать эффективную команду Раздает задачи Координирует людей Управляет планами Управляет процессом Управляет рисками Устраняет препятствия
- 56.
- 57. Пример структуры кроссфункциональной команды Бизнесзаказчик Product Owner Аналитики Scrum-мастер Разработчики Разработчики, тестировщики Product Discovery Product Delivery
- 58. Состав команды • Частичнаязанятость – Эксперты в предметной области – Заинтересованные лица • Полная занятость – Product owner – Scrum-мастер – Все специалисты, нужные для достижения цели PO SM Эксперты + Заинтересованные лица
- 59.
- 60. Вертикальная коммуникация Ценность не соответствуетколодцам Задача Agile: соединить колодцы Трения между колодцами Рассадка по функциям Политические барьеры
- 61. Свойства и структураScrum-команды • 5-9 человек, стабильная команда • Кросс-функциональная (все необходимые компетенции) • PO отвечает за продукт • Способен сбалансировать интересы всех заказчиков • Отвечает за бизнес-показатели • SM растит команду • Командная ответственность • В команде все равны • Плоская команда (нет подкоманд) • Самоорганизация в команде
- 62. Принципы самоорганизации • Коллективноепринятие решений – Обеспечивает ответственность за результат – Не работает без доверия и общей цели • Общая цель • Доверие – Для доверия нужна взаимная ответственность • Взаимная ответственность – Не работает без прозрачности • Прозрачность
- 63. Tucman’s Model –Эволюция команды Эффективность Время
- 64.
- 65. Agile – видыкомпаний http://stateofagile.versionone.com © 10th State of Agile Report - VersionOne
- 66. Agile: некоторые компаниии продукты
- 67.