Scrum: революционный метод управления проектами

Самая известная книга, посвящённая теме, в русском переводе известна под названием «Scrum. Революционный метод управления проектами», что содержит определение, которое нередко вызывает критику. В оригинале подзаголовок другой: «Искусство делать в два раза больше работы в два раза быстрее». Здесь Scrum не называется методом, и речь не идёт об управлении проектами. Однако и такой вариант трактовки в более широком контексте тоже оправдан. Особенно если рассматривается не узкая сфера разработки программного обеспечения (ПО), а подход, лежащий в основе фреймворка, который легко распространяется почти на любой вид коллективной деятельности.

Scrum: трудности перевода

Scrum (по-русски произносится «скрам») – термин, который в регби означает фигуру, создаваемую игроками в процессе игры, а в бизнесе придумывался авторами Джеффом Сазерлендом (Jeff Sutherland) и Кеном Швабером (Ken Schwaber) как каркас эффективного процесса разработки ПО. В официальном описании Scrum нет указаний к действию в любой ситуации, и некоторые вопросы остаются без ответов (например, здесь указывается необходимость оценки отводимого на процесс рабочего времени, но не определяется вид оценки). Поэтому говорить о Scrum как об исчерпывающей методологии в классическом понимании слова нужно с осторожностью.

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

Универсальная схема Scrum

Управление продуктом в Scrum складывается из нескольких универсальных для каждого контекста шагов.

1. Выбирается «Владелец продукта» – человек, который становится связующим звеном между рынком (заказчиком продукта или конечным потребителем) и командой исполнителей. Этот человек отвечает за увеличение ценности продукта и со старта видит общий замысел.
2. Собирается команда исполнителей, компетентность которой должна сочетаться с умением согласованно работать.
3. Определяется Scrum-мастер. Здесь мастер – это администратор, следящий за ходом работы в команде, но не командующий, а помогающий в обучении, обеспечивающий плановое проведение собраний и т. д.
4. Создаётся список требований к цели и продукту с расстановкой пунктов по приоритету. Этот список меняется по ходу развития проекта.
5. Участники команды оценивают каждый пункт списка, решая сколько временных и материальных ресурсов потребуется для реализации задачи.
6. Владелец продукта, мастер и участники команды проводят собрание, где в совместном обсуждении планируется спринт – короткий (не больше месяца в практике разработчиков ПО) этап, на который планируется решение определённой части задач. В некоторых контекстах такой этап называют итерацией. Предполагается, что в течение каждого спринта-итерации команда нарабатывает определённое количество баллов, которое в следующем спринте желательно увеличить, чтобы продемонстрировать рост производительности.
7. Для информирования всех участников процесса создаётся информационная доска, заполняемая стикерами, с разделением на то, что нужно сделать, что находится в работе, и что сделано. По мере выполнения задач, стикера перемещаются из одной колонки в другую.
8. Короткие общие собрания проводятся ежедневно. На них озвучиваются препятствия на пути, определяется уже сделанное для пользы проекта и запланированное.
9. Каждый спринт заканчивается детальным обзором результатов работы и, что не менее важно, обсуждением характеристик процесса в прошедшем спринте. Если можно что-то улучшить, то обговариваются направленные на оптимизацию нововведения, которые будут внедрены в следующем спринте.

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

• философии Scrum, которая со временем включила в себя ценности и принципы манифеста Agile (авторы методологии были в числе 17 авторов, подписавших знаменитый манифест),
• требований в заданном формате,
• определённого алгоритма действий с распределением ролей в команде,
• особого типа рабочих отношений,
• специфического понимания отдельного рабочего этапа,
• инструментария, подходящего для этой методологии.

В зависимости от сферы, в которой внедряется методология управления Scrum, характеристики некоторых составляющих могут отличаться. Например, варьируется число исполнителей в команде, некоторые инструменты учёта или система начисления баллов. Но ключевые моменты и рамки структуры Scrum должны оставаться неизменными.

Философская основа Scrum

Управление продуктом в Scrum на идеологическом уровне – это следование определённому образу жизни и образу деятельности. Автор книги о методе Scrum увлекался японскими боевыми искусствами и это увлечение отразилось на отношении к своей работе, которая перестала быть просто зарабатыванием денег. Работа в стиле Scrum (как и айкидо) – это способ постоянного совершенствования через практику стремящихся к единству тела и разума.

Идеологические основы Scrum позднее были более чётко выражены в манифесте Agile. В нём были перечислены 4 ценности и 12 принципов, которым призывали следовать авторы манифеста. На первое место в системе ценностей ставились:

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

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

Предполагалось, что если практика на каждом этапе вносит свои коррективы, и это делает продукт лучше и ценнее, а потребителей – счастливее, то эта практика лучше жёсткого планирования. Подход Agile объединил в одно семейство модели, в основе которых лежали сформулированные ценности. Частью такого семейства моделей был и остаётся Scrum.

Роли в Scrum

Scrum подход предполагает распределение трёх ролей между участниками проекта.

1. Product owner. Этого человека называют «владельцем продукта» поскольку он становится единственным, кто принимает окончательное решение (поэтому эта роль, как правило, не перепоручается группе лиц). Он же ведёт проект в целом и занимается увеличением ценности продукта для рынка (заказчика), которого представляет. Исполнитель этой роли должен поставить задачи команде на спринт, но не ставит задачи конкретному исполнителю. То есть, Product owner – руководит продуктом, а не командой.
2. Scrum Master. Роль мастера тоже не предполагает возможность постановки задач конкретному исполнителю, поскольку команда, следуя принципам подхода, должна проявлять себя как самоорганизующийся и самоуправляемый организм. Его роль в работе ближе к роли администратора:
3. Team. Scrum команда в такой модели кроссфункциональна и самоуправляема. Нет специального человека, который бы организовывал её работу. Применительно к сфере разработки ПО, команды, как правило, складываются из 5-9 человек (в среднем – семи) специалистов разного профиля (аналитиков, разработчиков, тестировщиков). Несмотря на разнообразие специалистов внутри команды, Team действует как единой целое, и результаты её деятельности тоже оцениваются как результат общей работы.

В других сферах бизнес-деятельности, перенявших модель Скрам, стараются сохранить этот количественных стандарт, поскольку большему коллективу сложно самоорганизоваться и функционировать эффективно. Недаром в знаменитой игре Что? Где? Когда? её автор, В. Ворошилов, придумывая правила, остановился на шестёрке знатоков, как на самой эффективной функциональной коллективной единице.

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

Характеристика этапов работы

Работа над проектом и распределение времени предполагает фазы планирования, спринтов и подведения итогов спринта.

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

Список скрам-артефактов включает 4 инструмента:

Все этапы, процессы (ритуалы) и технология применения инструментов важны для жизнеспособности модели. Управление проектами Scrum даёт максимальный эффект при комплексном и системном внедрении всех составляющих.

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

1. • Планирование. Пункты списка задач, от которых зависит достижение цели, расставляются по приоритетности. Каждый пункт участниками команды оценивается для определения объёма временных, интеллектуальных, материальных и др. ресурсов.
   • Оценка объёма энергозатрат. Для введения оценочной шкалы предлагают различные условные единицы с неравномерным распределением «веса». Например, сравнивать энергообъём задач можно в «собаках», где «задача-бульдог» больше «задачи-таксы» и меньше «задачи-мастиффа». На практике удобнее каждой такой величине присвоить ещё и числовое значение.
   • Требования в классической модели представляются в виде пользовательских историй. Они должны быть завершёнными, независящими от обстоятельств, практически реализуемыми. Например, работа интернет-магазина в одной истории может описываться с точки зрения потребителя, который рассказывает, как ему удобно сортировать товар, и как хотелось бы, чтобы в корзине было не очень много полей для заполнения. В другой истории этот же проект описывается с точки зрения маркетолога, сообщающего, что ему нужно видеть, как покупатель вёл себя на сайте, сколько целевых действий сделал, прежде чем совершить покупку. Третья история рассказывается с точки зрения менеджера, обрабатывающего заказ, и т.д..
   • Спринты тоже планируются. Весь коллектив собирается вместе и рассматривают пользовательские истории, оценивая свои возможности с тем условием, что к концу спринта будет закончен запланированный объём задач, который можно будет в виде готового функционала представить заказчику. Команда ставит себя на место потребителя и «проживает» в своём исполнении работы его пользовательскую историю вместе с ним.
   • Собрания, которые проводятся ежедневно, длятся не дольше четверти часа и проходят по одной схеме, определяющей настрой рабочего дня. По сути, собрание состоит из ответов на три ежедневно повторяющиеся вопроса: Что ты сделал накануне, чтобы команда успешно завершила спринт? Что для этого будешь делать сегодня? Что мешает команде?
   • Product backlog. Представляет собой список требований по проекту в виде пользовательских историй, расставленных по приоритету. Отсутствие в этом списке требований означает, что проект завершён.
   • Sprint backlog. Список разделённых на задачи и оценённых требований для ближайшего спринта. Этот список в течение спринта не может пополняться.
   • Sprint Goal. Описание целей, ради которых выполняется спринт.
   • Sprint Burndown Chart. Исполняется в виде диаграммы, отражающей продвижение команды вперёд, и иллюстрирует, как ежедневно, по мере продвижения, «сгорают» человеко-часы.