Scrum: 5–3–5–3–3

01.09.2021

В начале работы с Agile и Scrum, оказывая помощь коллегам, я обычно использовал комбинацию 3–5–3, где:

первые “3” — три роли Scrum;
“5” — пять событий Scrum;
последние “3” — три артефакта Scrum.

Эта комбинация указана в руководстве по Scrum и известна многим практикам. Я расширил эту концепцию, дополнив ее двумя аспектами:

еще одной “5” для представления пяти ценностей Scrum;
еще одной “3” для определения трех обязательств, которые были официально сформулированы в прошлогодней версии руководства Scrum.

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

5 ценностей Scrum;
3 обязательства Scrum;
5 событий Scrum;
3 артефакта Scrum;
3 роли Scrum.

Ценности Scrum

Пятью ценностями Scrum являются:

приверженность;
нацеленность на успех;
открытость;
уважение;
мужество.

Я недаром поставил пятерку ценностей на первое место в комбинации 5–3–5–3–3. Мой опыт подсказывает: команды, которые не моделируют эти ценности, вряд ли могут рассчитывать на большую пользу от Scrum. Пренебрегая ценностями, они практикуют упрощенный подход к Scrum: пытаются внедрить отдельные методы, особо не меняя стиля работы. Рассмотрим каждую из этих ценностей.

Приверженность

Scrum Команда стремится к достижению своих целей и поддержке друг друга.

Понятие “приверженность” напрямую связано с тремя обязательствами, которые я опишу в следующем разделе. Обратите внимание на то, что поддержка друг друга не менее важна, чем стремление к достижению целей. Кроме того, следуя Scrum, важно проявлять осмотрительность, чтобы избежать ловушек, которые в течение многих лет были связаны с понятием “приверженность”.

Нацеленность на успех

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

Ощутимый, значимый прогресс в решении поставленных задач во многом связан со способностью оставаться в потоковом состоянии (для которого характерны полная вовлеченность в работу и нацеленность на успех). Именно это является одной из причин, по которым Scrum-команды используют методы Канбан, такие как обеспечение наглядности задач и WIP-лимитирование (сокращение незавершенных процессов).

Открытость

Scrum-команда и все заинтересованные стороны открыты для работы и решения задач.

Если бы меня пригласили на Ретроспективу Спринта незнакомой мне Scrum-команды, то в первые же 5 минут я точно определил бы, обладает ли эта команда прозрачностью и доверием — факторами успеха в среднесрочной и долгосрочной перспективе.

Уважение

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

Аретра Франклин выразила это лучше, чем кто-либо другой: все, что нужно людям друг от друга, — это уважение. Чувство уважения должно естественно возникать не только в отношениях членов отдельной команды, но также между различными командами, а также на уровне руководства.

Мужество

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

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

Подводя итог, хочу привести заключительный абзац из раздела руководства по Scrum о ценностях.

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

Обязательства Scrum

— Цель Продукта как обязательство для Бэклога Продукта.

— Цель Спринта как обязательство для Бэклога Спринта.

— Критерии Готовности как обязательство для Инкремента.

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

Цель Продукта

Цель Продукта была точно определена в последней версии руководства по Scrum:

Цель Продукта описывает его будущее состояние, которое может служить целью для Scrum-команды при планировании. Цель Продукта указывается в Бэклоге Продукта. В остальной части Бэклога Продукта определяется, “что” будет соответствовать Цели Продукта… Цель Продукта — это долгосрочная цель Scrum-команды, которая должна выполнить (или оставить) одну цель, прежде чем браться за следующую.

Мне кажется, что добавление в руководство по Scrum понятия Цели Продукта связано с тем, что всегда подразумевалось по умолчанию: для Scrum-команд важно четко выразить видение или цель высшего уровня (то, что называется “путеводной звездой”). Кроме того, понятие Цели Продукта подчеркивает важность для команды кратко сформулировать то, чего она стремится достичь, в идеале включая критерии, которые позволят продемонстрировать, действительно ли достигнута Цель Продукта.

Цель Спринта

Цель Спринта — это обязательство для Бэклога Спринта.

Цель Спринта — это единственная целевая установка для Спринта. Хотя Цель Спринта является обязательством Разработчиков, она обеспечивает гибкость, исходя из точного объема работы, необходимо для ее достижения. Цель Спринта также создает атмосферу согласованности и сосредоточенности, мотивируя Scrum-команду работать сообща, а не над отдельными инициативами.

Цель Спринта формулируется на совещании по Планированию Спринта, а затем добавляется в Бэклог Спринта. В течение всего Спринта Разработчики помнят о Цели Спринта. Если в производственном процессе возникнут непредвиденные моменты, они связываются с Владельцем Продукта, чтобы согласовать объем работ Бэклога Спринта, не влияя на Цель Спринта.

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

Критерии Готовности

Критерии Готовности — это обязательство, связанное с Инкрементом.

Критерии Готовности — это формальное описание состояния Инкремента (готовой к использованию части Продукта), когда оно соответствует критериям качества Продукта.

Критерии Готовности создают атмосферу прозрачности, давая всем общее понимание того, какая работа была выполнена по созданию представленного Инкремента. Если какой-то элемент Бэклога Продукта не соответствует Критериям Готовности, он не может быть выпущен или даже представлен на Обзоре Итогов Спринта. Вместо этого, он возвращается в Бэклог Продукта для дальнейшего рассмотрения.

По предыдущим версиям руководства по Scrum могло сложиться впечатление, что Критерии Готовности, хотя и являются частью Scrum, не играют приоритетной роли. Нынешняя формулировка Критериев Готовности в качестве оценочного фактора Инкремента повысила их значимость. Теперь Критерии Готовности посылают более сильный сигнал команде и заинтересованным сторонам о том, что надо серьезно относиться к принятию рабочих решений, не отстраняясь от проблем с качеством и стараясь довести продукт до базового уровня ожиданий.

События Scrum

Пять событий Scrum:

Спринт;
Планирование Спринта;
Ежедневный Scrum;
Обзор Итогов Спринта;
Ретроспектива Спринта.

Примечание: о событиях, артефактах и ролях Scrum было так много сказано и написано, что мне практически нечего добавить сверх того, что содержится в руководстве по Scrum.

Спринт

Спринт в Scrum — контейнер для всех остальных событий Scrum.

Спринты — это сердце Scrum, в котором идеи превращаются в бизнес-ценности.

Это события фиксированной продолжительности (длиной в один месяц или короче), необходимой для обеспечения системной работы. Новый Спринт начинается сразу после завершения предыдущего Спринта.

Вся работа, необходимая для достижения Цели Продукта, включая Планирование Спринта, Ежедневные Scrum, Обзор Итогов Спринта и Ретроспективу Спринта, выполняется в рамках Спринтов.

Примечание: синонимом Спринта является итерация. Например, в экстремальном программировании используется термин “итерация”, а не “Спринт”, что помогает подчеркнуть итеративный характер планирования и выпуска продукта по методологии Agile.

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

Как следует из названия, Планирование Спринта — это возможность для команды совместно решать, какие высокоприоритетные рабочие процессы необходимо включить в предстоящий Спринт.

Планирование Спринта инициирует Спринт, определяя объем работы, который нужно выполнить во время Спринта. Окончательный план создается в результате совместной работы всей Scrum Команды.

Планирование Спринта фокусируется на трех аспектах.

Почему?
Что?
Как?

Почему = “Тема первая”

Вопрос: почему этот Спринт ценен?

Владелец Продукта высказывает предположение о том, как Продукт может повысить свою ценность и полезность в текущем Спринте. Затем вся Scrum Команда совместно определяет Цель Спринта, которая объясняет, почему Спринт ценен для заинтересованных сторон. Цель Спринта должна быть определена до окончания Планирования Спринта.

Что = “Тема вторая”

Вопрос: что можно сделать в этом Спринте?

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

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

Как = “Тема третья”

Вопрос: как будет выполнена выбранная работа?

Для каждого выбранного элемента Бэклога Продукта разработчики планируют работу, необходимую для создания Инкремента, соответствующего Критериям Готовности. Иногда рабочие элементы Бэклога Продукта разделяются на более мелкие элементы, которые необходимо создать в сроки продолжительностью в один день или короче. То, как это сделать, остается на усмотрение разработчиков. Никто больше не указывает им, как превратить элементы Бэклога Продукта в качественный Инкремент.

Примечание: между совещаниями по Планированию Спринта многие команды используют практику, называемую Уточнением Бэклога Продукта. Чаще всего это происходит примерно в середине Спринта. Типичная причина, по которой команды дополняют Планирование Спринта Уточнением, заключается в необходимости получить большую ясность по деловым или техническим вопросам, которые могут потребовать более глубокого обсуждения или проверки с людьми вне команды.

Ежедневный Scrum

Ежедневный Scrum, иногда заменяемый синонимичным термином “Ежедневный Стендап”, — это возможность для разработчиков определить методы, с помощью которых они смогут наиболее эффективно сотрудничать в команде в течение следующего 24-часового периода.

Цель Ежедневного Scrum — убедиться в прогрессе в достижении Цели Спринта и при необходимости внести изменения в Бэклог Спринта, скорректировав запланированную работу.

Ежедневный Scrum — это 15-минутное мероприятие для разработчиков Scrum-команды. В целях упрощения регламента оно проводится в одно и то же время и в одном и том же месте каждый рабочий день Спринта. Если Владелец Продукта или Scrum-мастер активно работают над элементами Бэклога Спринта, они участвуют в качестве разработчиков.

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

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

Примечание: одна из наиболее распространенных ошибок, которые совершают команды, заключается в отношении к Ежедневному Scrum как к отчетному собранию. Другая допускаемая иногда ошибка — появление на совещании человека, который не является членом команды.

Обзор Итогов Спринта

Нет более убедительного доказательства тезиса “обратная связь — бесценный подарок”, чем Обзор Итогов Спринта.

Цель Обзора Итогов Спринта — изучить результаты Спринта и определить будущие условия адаптации. Scrum-команда представляет результаты своей работы ключевым заинтересованным сторонам и обсуждает прогресс в достижении Цели Продукта.

Во время мероприятия Scrum Команда и заинтересованные стороны анализируют, что было достигнуто в ходе Спринта и что изменилось в производственной среде. Основываясь на этой информации, участники совместно решают, что делать дальше. Бэклог Продукта также может быть скорректирован в соответствии с новыми возможностями. Обзор Итогов Спринта — это рабочее собрание, и Scrum-команде не следует ограничиваться презентацией достижений.

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

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

Я один из многих практиков Agile, которые считают Ретроспективу Спринта наиболее важным аспектом Scrum, потому что это драйвер непрерывного совершенствования.

Цель Ретроспективы Спринта — наметить пути повышения качества и эффективности.

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

Scrum-команда отмечает наиболее полезные изменения для повышения своей результативности. Наиболее эффективные предложения по оптимизации рабочего процесса рассматриваются в оперативном порядке. Они даже могут быть добавлены в список Бэклога Спринта для следующего Спринта.

Примечание: когда речь заходит о непрерывном совершенствовании Agile, нет лучшего руководства и источника вдохновения, чем книга “Ретроспективы Agile: как сделать хорошие команды отличными” Эстер Дерби и Дианы Ларсен.

Артефакты Scrum

Три Артефакта Scrum:

Бэклог Продукта;
Бэклог Спринта;
Инкремент.

Бэклог Продукта

Бэклог Продукта включает в себя потенциальные рабочие элементы (истории пользователей) с различным уровнем детализации и уточнения. Элементы, находящиеся в верхней части Бэклога Продукта или близкие к ней, имеют наибольшую бизнес-ценность и, следовательно, наивысший приоритет. Именно на этих элементах команда сосредотачивается до и во время планирования Спринта.

Бэклог Продукта — это эмерджентный упорядоченный список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum-командой.

Элементы Бэклога Продукта, которые могут быть выполнены Scrum-командой в течение одного Спринта, выбираются в ходе мероприятия по Планированию Спринта. Обычно они приобретают такую степень прозрачности после уточнения видов деятельности. Уточнение Бэклога Продукта — это процесс разбивки и дальнейшего определения элементов Бэклога Продукта на более мелкие и точные элементы. Это постоянный процесс добавления деталей, таких как описание, заказ и размер. Подобные атрибуты часто варьируются в зависимости от области работы.

Примечание: Бэклог Продукта — это не шведский стол (“ешьте, сколько влезет”). Скорее, это выбор наиболее желательных блюд, которые попадают в меню благодаря отзывам клиентов. Когда Бэклог Продукта достигает сотен позиций, это увеличивает вероятность того, что мы не сможем увидеть лес за деревьями.

Бэклог Спринта

Пользовательские истории, включенные в список Бэклога Спринта, — результат совместной работы команды по определению объема работы, который она может выполнить для достижения Цели Спринта и который реалистично отражает ее возможности.

Бэклог Спринта — это план для разработчиков, составленный ими самими. Это четкая визуализация рабочего сценария в режиме реального времени, который разработчики планируют воплотить во время Спринта, чтобы достичь Цели Спринта. Следовательно, Бэклог Спринта обновляется на протяжении всего Спринта по мере получения дополнительной информации. В нем должно быть достаточно деталей, чтобы разработчики могли проверять свой прогресс в ежедневных Scrum.

Примечание: одна из наиболее распространенных ошибок, которые совершают команды, — стремление выполнить слишком большой объем работы в Спринте. Это чревато массой возможных негативных последствий, включая накопление множества незавершенных процессов, риск того, что в конце Спринта останется незавершенная работа, подрыв морального духа команды. Однако нельзя переоценить предоставленное командам право выбора высокоприоритетных рабочих задач, позволяющее им ответственно подходить к выполнению взятых обязательств.

Инкремент

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

Инкремент — это конкретный шаг на пути к Цели Продукта. Каждый Инкремент является дополнением ко всем предыдущим Инкрементам и тщательно проверяется, гарантируя работу всех Инкрементов вместе. Чтобы подтвердить свою ценность, Инкремент должен быть пригодным для использования.

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

Работа не может считаться частью Инкремента, если ее результат не соответствует Критериям Готовности.

Примечание: технические методы, такие как непрерывная интеграция и непрерывное развертывание приложений (CI/CD), являются обязательными, когда речь заходит о том, чтобы позволить командам выпускать функциональные продукты как можно раньше и чаще. Книга Джез Хамбл, Джин Ким и Николь Форсгрен “Ускорение — наука об упрощенном ПО и DevOps: создание и масштабирование высокопроизводительных технологических организаций” предлагает широкий взгляд на типы атрибутов и методов, которые выделяют высокопроизводительные организации на фоне всех остальных участников отрасли.

Роли в Scrum

Три роли в Scrum следующие:

Разработчики;
Владелец Продукта;
Scrum Мастер.

Разработчики, Владелец Продукта и Scrum-мастер составляют единую Scrum Команду.

Разработчики

Группа разработчиков включает в себя всех членов команды, которые активно участвуют в создании бизнес-ценности:

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

Конкретные навыки, необходимые разработчикам, варьируются в зависимости от области работы. Однако они всегда несут ответственность за:

— создание плана для Спринта и Бэклога Спринта;

— достижение качества, соответствующего Критериям Готовности;

— ежедневную адаптацию своего плана к Цели Спринта;

— привлечение друг друга к профессиональной ответственности.

Примечание: навыки разработчиков в команде так же разнообразны, как и ассортимент продуктов, над созданием которых им приходится трудиться. Возможно, самый простой способ концептуализировать роль разработчика, — это уяснить следующее: чтобы команда была жизнеспособной, в ней должны быть “все специалисты и все, что им нужно”. Такие разработчики смогут создавать бизнес-ценности, не полагаясь в значительной степени на людей, внешних по отношению к команде.

Владелец Продукта

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

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

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

— разработку и четкое представление Цели Продукта;

— создание и четкое представление элементов Бэклога Продукта;

— заказ элементов Бэклога продукта;

— обеспечение прозрачности, наглядности и понятности Инкремента Продукта.

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

Чтобы Владельцы Продуктов добились успеха, вся организация должна уважать их решения. Эти решения отражаются в содержании и структуре Бэклога Продукта, а также в Инкременте, проверяемом во время Обзора Итогов Спринта.

Владелец Продукта — это один человек, а не комитет. Владелец Продукта может представлять потребности многих заинтересованных сторон в Бэклоге Продукта. Те, кто хотят изменить Бэклог Продукта, могут сделать это, попытавшись убедить своими доводами Владельца Продукта.

Примечание: предполагается, что Владелец Продукта и/или другое лицо, имеющее четкое представление о заинтересованных сторонах и связи с ними, работает в Scrum-команде на регулярной основе. В отсутствие человека с полной осведомленностью о продукте возрастает вероятность совершения смертного греха — “создания совсем не того, что надо”.

Scrum Мастер

Scrum Мастер обычно выполняет различные роли, и, пожалуй, самая важная из них — роль тренера или куратора.

Scrum Мастер отвечает за выполнение Scrum, как определено в руководстве по Scrum. Он делает это как в Scrum-команде, так и в организации, помогая всем понять теорию и практику Scrum.

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

Scrum Мастера — это настоящие лидеры, которые служат Scrum-команде и более крупной организации.

Scrum Мастер помогает Scrum-команде несколькими способами, а именно:

— обучает членов команды навыкам самоуправления и кросс-функциональности;

— помогает сосредоточиться на создании высокоценных Инкрементов, которые соответствуют Критериям Готовности;

— устраняет препятствия на пути прогресса;

— обеспечивает позитивное и продуктивное проведение всех событий Scrum, следит за тем, чтобы они укладывались в установленные временные рамки.

Еще одна тенденция, которая, как правило, наблюдается в успешных Scrum-командах, свидетельствует об эффективном партнерстве между Владельцем Продукта и Scrum Мастером.

Scrum Мастер оказывает поддержку Владельцу Продукта несколькими способами.

— Содействует в поиске методов эффективного определения Цели Продукта и управления Бэклогом Продукта.

— Помогает Scrum Команде уяснить необходимость четких и лаконичных элементов Бэклога Продукта.

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

— Содействует сотрудничеству заинтересованных сторон по запросу или необходимости.

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

Scrum Мастер действует в интересах организации несколькими способами.

— Осуществляет руководство, обучение и коучинг организации в процессе внедрения Scrum.

— Ведет планирование и консультирование по внедрению Scrum в организации.

— Оказывает помощь сотрудникам и заинтересованным сторонам в понимании и применении эмпирического подхода к комплексной работе.

— Устраняет барьеры между заинтересованными сторонами и Scrum Командами.

Примечание: степень, в которой отдельный Scrum Мастер может быть полезен организации, во многом зависит от таких факторов, как масштаб организации и объем опыта, которым он обладает.