Scrum – гибкий управленческий фреймворк

Сегодня самой популярной гибкой методологией разработки ПО является Scrum. Если вы спросите любого практика Agile, он обязательно подтвердит это, хотя каждое слово в предыдущей фразе неправда.

Начнем с конца – Scrum используют не только для разработки ПО, он отлично подходит для многих процессов по созданию продукта: от венчурных до маркетинговых продуктов. И соответственно подбираемся ко второму пункту – Scrum вовсе не методология, это гибкий управленческий фреймворк.

Откуда следует и третий пункт – Scrum обычно дополняют инженерными практиками из других гибких методологий (например, практики разработки из экстремального программирования, или практики анализа и сбора требований из ICONIX). Так что в дальнейшем, если не оговорено иное, под Agile будем подразумевать семейство гибких методологий, а Scrum будем рассматривать в качестве управленческого фреймворка, дополненного практиками из других гибких методологий. Но довольно буквоедствовать, давайте начнем знакомиться со Scrum.

Классический Scrum состоит из следующих элементов:

Роли

В Scrum принято выделять три основных роли: владелец продукта, скрам-мастер и команда.

Владелец продукта (Продукт оунер, Product owner, Менеджер продукта) – это человек, ответственный приоритезацию требований и часто за их создание.

Скрам-мастер – член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде.

Команда – 7±2 человек, которые реализуют требования владельца продукта.

Обязанности скрам-мастера

Скрам-мастер должен ежедневно следить за тем, чтобы скрам-митинг начинался и заканчивался вовремя. Рекомендуется выделять определенное время каждому участнику, чтобы общая протяженность скрама-митинга не превышала заранее оговоренного времени (например, 15 минут).

Скрам-мастер в начале спринта помогает команде проводить планирование спринта и запуск спринта.

В конце спринта скрам-мастер организует демонстрацию результатов спринта при участии всех заинтересованных лиц и проводит ретроспективу при участии всех членов проектной команды.

Также в обязанности скрам-мастера входит мониторинг социальных аспектов команды и поддержание командного духа.

Артефакты

Беклог продукта (Product Backlog) – приоритезированный список требований с оценкой трудозатрат. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-ценность и называются элементы беклога.

Беклог спринта (Sprint Backlog) – часть беклога продукта, с самой высокой важностью и суммарной оценкой, не превышающей скорость команды, отобранная для спринта.

Инкремент продукта – новая функциональность продукта, созданная во время спринта спринта.

Процессы

Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях.

Скрам-митинг

Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка) – собрание членов команды (с возможностью приглашения владельца продукта) для синхронизации деятельности команды и обозначения проблем. Каждый член команды отвечает на три вопроса:

1. Что было сделано с предыдущего скрам-митинга?
2. Какие есть проблемы?
3. Что будет сделано к следующему скрам митингу?

 

Если первый и третий пункт служат для синхронизации деятельности команд, то второй пункт очень важен для выработки решений проблем: если проблема действительно небольшая, ее можно решить или выработать решение прямо на скрам-митинге, если серьезная и требует обсуждения, ее решить после скрам-митинга.

Планирование спринта

Для планирования спринта необходимо иметь качественный беклог, что означает следующее:

• все элементы бэклога должны иметь уникальную числовую важность;
• самые важные элементы бэклога должны быть уточнены и понятны всей команде и владельцу продукта;
• владелец продукта должен четко представлять, что будет реализовано в рамках каждого элемента бэклога.

Основным результатом планирования спринта является беклог спринта – список задач, которые команда планирует реализовать в рамках спринта. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов беклога (объем работ), которые она может реализовать. Можно данную ситуацию отобразить на классическом «треугольнике управления проектами»:

Обзор спринта (также часто используется термин «демонстрация» или сокращенно «демо») – показ владельцу продукта (и заинтересованным лицам) работающего функционала продукта, сделанного за спринт. Основная задача проведения обзора спринта заключается в получении обратной связи, а общий цикл ее получения выглядит следующим образом:

Демонстрация результатов работы не только мотивирует команду, но и подталкивает реализовывать задачи полностью.

Если взглянуть еще раз на манифест Agile, то там есть пункт, который непосредственно касается демонстраций: «Готовый продукт важнее документации по нему». И действительно основной мерой прогресса является функционал нашего продукта, поэтому показывать на демонстрации надо именно программу. Если ваш заказчик находится не в одном помещении с вами, используйте специальные средства демонстрации. Гораздо хуже будет отправить заказчику презентацию или отчет по сделанному функционалу, ведь мы хотим получить качественную обратную связь.

В обзоре спринта обязательно должна принимать участие вся команда, при этом возможны разные стратегии показа. Антипаттерном можно назвать демонстрацию функционала одним человеком, например, скрам-мастером.

К паттернам можно отнести демонстрацию «чужих» реализованных элементов беклога и привлечение к демонстрации аналитиков, тестировщиков, верстальщиков, UI- специалистов и так далее. Такой подход позволяет выработать командную ответственность за результат.

Ретроспектива

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.

Ретроспективу традиционно проводят после обзора спринта спустя небольшое количество времени, чтобы оперативно получить фидбек. Скрам-мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи.

Структура ретроспективы

Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:

• Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
• Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
• Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.

В процентном соотношении принято выделять такую структуру:

1. Открытие – 5%
2. Сбор данных – 30%-50%
3. Проникновение в суть – 20%-30%
4. Принятие решение – 10%
5. Закрытие – 5%-10%

Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса:

1. Что было сделано хорошо?
2. Что можно улучшить? 
3. Какие улучшения будем делать?

Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения.

Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:

«В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»

Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудить на ретроспективе:

• скорость команды и ее изменение по сравнению с предыдущими спринтами;
• нереализованные истории пользователей и причины опоздания; -
• дефекты и их причины;
• качество процессов (нарушения, отступления).

К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта и позволяет контролировать уровень сделанных улучшений.

Первая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 1

Третья часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 3