Борис Вольфсон - Гибкое управление проектами и продуктами

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

Владелец продукта(Product Оwner, менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и управление его журналом пожеланий.

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

Команда разработки(Development Team) – это многофункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта.

Основной задачей владельца продукта является максимизация его ценности через управление его журналом пожеланий, включая:

• создание и обработку элементов журнала пожеланий;

• приоритизацию элементов журнала пожеланий;

• выработку понимания элементов журнала пожеланий у команды.

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

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

Важным свойством команды является ее самоорганизация: она сама определяет способ, которым сделает из элементов журнала пожеланий инкремент продукта.

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

Скрам-мастер – это член команды, который ответствен за понимание и реализацию Scrum и помогает в этом следующим субъектам.

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

Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях. Все встречи жестко ограничены по времени (time-boxed).

Спринт – это ограниченная по времени итерация, которая является контейнером для других процессов в Scrum. В конце спринта создается потенциально готовый к поставке продукт и начинается следующий спринт. Спринт длится от одной до четырех недель.

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

Спринт может быть отменен владельцем продукта в случае, если цели спринта устарели.

У планирования спринта две основные задачи: выбор элементов журнала пожеланий для реализации и их декомпозиция. Планирование проводится в самом начале спринта и обычно занимает не более дня для спринта длиной в месяц.

Хорошей практикой будет на основе выбранных элементов журнала пожеланий сформулировать цели для спринта, чтобы команда могла работать более сфокусированно. Подробнее о целях спринта можно прочитать в разделе «Умные цели для спринта» гл. 3.

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

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

2. Какие есть проблемы?

3. Что будет сделано к следующему скрам-митингу?

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

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

Получение обратной связи в рамках Scrum

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

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

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

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

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

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

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