Гибкие методологии разработки - Часть 2
Гибкие методологии разработки - Часть 2. Сегодня самой популярной гибкой методологией разработки ПО является Scrum. Если вы спросите любого практика Agile, он обязательно подтвердит это, хотя каждое слово в предыдущей фразе неправда.Scrum – гибкий управленческий фреймворк
Сегодня самой популярной гибкой методологией разработки ПО является Scrum. Если вы спросите любого практика Agile, он обязательно подтвердит это, хотя каждое слово в предыдущей фразе неправда.
Начнем с конца – Scrum используют не только для разработки ПО, он отлично подходит для многих процессов по созданию продукта: от венчурных до маркетинговых продуктов. И соответственно подбираемся ко второму пункту – Scrum вовсе не методология, это гибкий управленческий фреймворк.
Откуда следует и третий пункт – Scrum обычно дополняют инженерными практиками из других гибких методологий (например, практики разработки из экстремального программирования, или практики анализа и сбора требований из ICONIX). Так что в дальнейшем, если не оговорено иное, под Agile будем подразумевать семейство гибких методологий, а Scrum будем рассматривать в качестве управленческого фреймворка, дополненного практиками из других гибких методологий. Но довольно буквоедствовать, давайте начнем знакомиться со Scrum.
Классический Scrum состоит из следующих элементов:
Роли
В Scrum принято выделять три основных роли: владелец продукта, скрам-мастер и команда.
Владелец продукта (Продукт оунер, Product owner, Менеджер продукта) – это человек, ответственный приоритезацию требований и часто за их создание.
Скрам-мастер – член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде.
Команда – 7±2 человек, которые реализуют требования владельца продукта.
Обязанности скрам-мастера
Скрам-мастер должен ежедневно следить за тем, чтобы скрам-митинг начинался и заканчивался вовремя. Рекомендуется выделять определенное время каждому участнику, чтобы общая протяженность скрама-митинга не превышала заранее оговоренного времени (например, 15 минут).
Скрам-мастер в начале спринта помогает команде проводить планирование спринта и запуск спринта.
В конце спринта скрам-мастер организует демонстрацию результатов спринта при участии всех заинтересованных лиц и проводит ретроспективу при участии всех членов проектной команды.
Также в обязанности скрам-мастера входит мониторинг социальных аспектов команды и поддержание командного духа.
Артефакты
Беклог продукта (Product Backlog) – приоритезированный список требований с оценкой трудозатрат. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-ценность и называются элементы беклога.
Беклог спринта (Sprint Backlog) – часть беклога продукта, с самой высокой важностью и суммарной оценкой, не превышающей скорость команды, отобранная для спринта.
Инкремент продукта – новая функциональность продукта, созданная во время спринта спринта.
Процессы
Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях.
Скрам-митинг
Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка) – собрание членов команды (с возможностью приглашения владельца продукта) для синхронизации деятельности команды и обозначения проблем. Каждый член команды отвечает на три вопроса:
- Что было сделано с предыдущего скрам-митинга?
- Какие есть проблемы?
- Что будет сделано к следующему скрам митингу?
Если первый и третий пункт служат для синхронизации деятельности команд, то второй пункт очень важен для выработки решений проблем: если проблема действительно небольшая, ее можно решить или выработать решение прямо на скрам-митинге, если серьезная и требует обсуждения, ее решить после скрам-митинга.
Планирование спринта
Для планирования спринта необходимо иметь качественный беклог, что означает следующее:
- все элементы бэклога должны иметь уникальную числовую важность;
- самые важные элементы бэклога должны быть уточнены и понятны всей команде и владельцу продукта;
- владелец продукта должен четко представлять, что будет реализовано в рамках каждого элемента бэклога.
Основным результатом планирования спринта является беклог спринта – список задач, которые команда планирует реализовать в рамках спринта. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов беклога (объем работ), которые она может реализовать. Можно данную ситуацию отобразить на классическом «треугольнике управления проектами»:
Обзор спринта (также часто используется термин «демонстрация» или сокращенно «демо») – показ владельцу продукта (и заинтересованным лицам) работающего функционала продукта, сделанного за спринт. Основная задача проведения обзора спринта заключается в получении обратной связи, а общий цикл ее получения выглядит следующим образом:
Демонстрация результатов работы не только мотивирует команду, но и подталкивает реализовывать задачи полностью.
Если взглянуть еще раз на манифест Agile, то там есть пункт, который непосредственно касается демонстраций: «Готовый продукт важнее документации по нему». И действительно основной мерой прогресса является функционал нашего продукта, поэтому показывать на демонстрации надо именно программу. Если ваш заказчик находится не в одном помещении с вами, используйте специальные средства демонстрации. Гораздо хуже будет отправить заказчику презентацию или отчет по сделанному функционалу, ведь мы хотим получить качественную обратную связь.
В обзоре спринта обязательно должна принимать участие вся команда, при этом возможны разные стратегии показа. Антипаттерном можно назвать демонстрацию функционала одним человеком, например, скрам-мастером.
К паттернам можно отнести демонстрацию «чужих» реализованных элементов беклога и привлечение к демонстрации аналитиков, тестировщиков, верстальщиков, UI- специалистов и так далее. Такой подход позволяет выработать командную ответственность за результат.
Ретроспектива
В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.
Ретроспективу традиционно проводят после обзора спринта спустя небольшое количество времени, чтобы оперативно получить фидбек. Скрам-мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи.
Структура ретроспективы
Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:
- Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
- Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
- Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
В процентном соотношении принято выделять такую структуру:
- Открытие – 5%
- Сбор данных – 30%-50%
- Проникновение в суть – 20%-30%
- Принятие решение – 10%
- Закрытие – 5%-10%
Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса:
- Что было сделано хорошо?
- Что можно улучшить?
- Какие улучшения будем делать?
Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения.
Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:
«В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»
Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудить на ретроспективе:
- скорость команды и ее изменение по сравнению с предыдущими спринтами;
- нереализованные истории пользователей и причины опоздания; -
- дефекты и их причины;
- качество процессов (нарушения, отступления).
К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта и позволяет контролировать уровень сделанных улучшений.
Первая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 1
Третья часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 3
