Scrum: сила простоты или сложность совершенства в Agile?

Всем привет!

Это пятая статья из серии «Введение в Agile». В ней мы расскажем о самом популярном подходе в области Agile – фреймворке Scrum, который широко применяется для гибкого управления проектами.

До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile. В рамках этой статьи подробнее остановимся на ключевых ролях и артефактах Scrum, таких как scrum-команда, product owner (владелец продукта), scrum-мастер, а также на элементах эффективного рабочего процесса.

Вы узнаете, как product owner формирует и управляет бэклогом продукта, как scrum-мастер помогает команде соблюдать принципы Scrum и устраняет препятствия, мешающие прогрессу, и какую роль играет регулярная обратная связь в повышении эффективности и адаптивности команды. Мы также рассмотрим, как правильно организовать рабочий процесс, чтобы обеспечить прозрачность, устойчивую скорость разработки и быструю доставку ценности пользователю.

• Часть 1. Agile и классическое проектное управление: в чем разница?
• Часть 2. Как определить, что вашему проекту нужен Agile?
• Часть 3. Почему Agile не «внедряют», или как «вырастить» Agile?
• Часть 4. Хочу быть Agile! Но как?

Первый вопрос, который возникает при виде словосочетания «фреймворк Scrum»: а что такое фреймворк и чем он отличается от стандарта или методологии?

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

Методология Scrum (Скрам) была разработана в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании «Easel Corporation». Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.

Название «Скрам» Сазерленд позаимствовал из регби. Так называется момент в игре, когда участники, обхватив друг друга руками, образуют тоннель, в который вбрасывается мяч. По аналогии, предложенной Сазерлендом, команда разработки объединяется, чтобы сконцентрировать усилия на продукте.

Этот метод известен, так как его применяет большинство команд, работающих по Agile. По результатам 13-го ежегодного исследования State of Agile – 2019, Scrum остается самым популярным фреймворком. Однако следует понимать, что, как у любого подхода, у Скрама помимо сильных сторон есть и ограничения.

Среди принципов Скрама – четкость, простота и наличие единого официального источника информации. Все требования изложены в официальном Руководстве по Скраму (Scrum Guide) .

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

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

Скрам состоит из 3 ролей, 5 событий и 3 артефактов (носителей информации о продукте). Каждый элемент Скрама взаимосвязан с другими и обязателен для применения. Общая схема фреймворка представлена на рисунке ниже. Мы кратко опишем весь процесс, а затем подробнее остановимся на каждом элементе.

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

Работа команды разработки делится на равные промежутки времени – спринты. Рекомендуемая длина спринта – от 1 до 4 недель. Количество спринтов не ограничивается. Проект может быть завершен когда Владелец продукта получил требуемый функционал, когда дальнейшая работа над продуктом не требуется или экономически не востребована.

При планировании очередного спринта Команда разработки формирует Бэклог спринта – фрагмент общего Бэклога продукта, содержащего по возможности самые приоритетные требования. Включая требование в Бэклог спринта, Команда разработки берет на себя обязательство реализовать это требование в ходе спринта.

Объем или количество требований, которые Команда может выполнить за спринт, определяется на основе опыта: в течение нескольких спринтов анализируются обязательства, которые взяла на себя Команда разработки при Планировании спринта, и фактический объем выполненных требований. Такой подход называется эмпирическим. В результате устанавливается условно-постоянный объем, который Командная работа адаптирует Спринт – производительность Команды.

После Планирования спринта запускается процесс Разработки, в ходе которого Команда разработки работает над требованиями из Бэклога спринта.

Для оперативного планирования и решения проблем ежедневно проводятся Скрам-встречи, или «летучки». На них участники Команды разработки обсуждают, что удалось сделать за прошедший день, что планируется на следующий, и какие возникли проблемы. Важная характеристика Скрам-встречи – ее жесткая ограниченность по времени. «Летучка» не должна занимать более 15 минут.

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

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

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

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