Роли, процессы и артефакты в Scrum: дьявол в деталях

Всем привет!

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

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

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

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

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

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

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

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

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

Скрам-мастер – это эксперт в области Agile-практик, который помогает Команде разработки выстроить правильные процессы. На начальных этапах Скрам-мастер проводит встречи (Планирование спринта, Ежедневные летучки, Обзор спринта, Ретроспективу), поддерживает в актуальном состоянии артефакты процесса, защищает команду от внешних вмешательств: срочных поручений, не относящихся к разрабатываемому продукту, попыток изменить требования в ходе спринта и т.п.

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

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

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

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

Чтобы сплотить команду, рекомендуют разместить всех участников в одном помещении. По мнению Филиппа Мисслера, CTO немецкой компании «mobile.de», это влияет не только на эффективность выполнения задач, но и на боевой дух команды. Для создания атмосферы в рабочем помещении повесьте на видном месте плакаты с ключевой информацией о продукте: формулировку концепции, наиболее приоритетные элементы Бэклога продукта, задачи текущего спринта. Если нескольким участникам команды нужно часто обсуждать результаты в рабочем режиме, лучше предусмотреть для таких встреч отдельное помещение, чтобы не мешать остальным.

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

Бэклог продукта есть практически в любом Agile-проекте: это удобное средство для фиксации требований, задач и элементов продукта. Для оценки качества Бэклога применяется инструмент DEEP (от англ. detailed, estimated, emergent, prioritized): хороший Бэклог должен содержать детализированные, оцененные, независимые и приоритизированные элементы. Максимальную степень детализации должны иметь наиболее приоритетные элементы. Оценка элементов Бэклога помогает спланировать, что мы запланируем на следующий спринт, а что сделать не успеем. По мере создания продукта в Бэклог могут добавляться новые требования.

Для оценки элементов Бэклога применяются относительные величины, которые показывают совокупную величину элемента по сложности, трудоемкости или размеру. Распространены техники оценки в стори-поинтах (от англ. «story points», очки, баллы) – 0, 1, 2, 3, 5, 8, 13 или 20 стори-поинтов, или в размерах футболок – S – маленький элемент, M – средний, L – большой.

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

Бэклог спринта – это набор элементов Бэклога продукта, который Команда принимает в разработку на ближайший спринт. В Бэклоге спринта также формулируется Цель спринта (Зачем мы работаем в этом спринте? Чего хотим достичь именно за эту итерацию?) и план по достижению этой цели.

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

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

Инкремент продукта – это сумма завершенных во время спринта Элементов Бэклога продукта и всех инкрементов предыдущих спринтов. То есть, это текущее состояние разрабатываемого продукта, включая доработки последнего спринта.

Планирование спринта проходит перед началом каждого спринта. Цель этого процесса – определить объем работ, который Команда возьмет в ближайший спринт. В ходе Планирования спринта Команда выбирает из Бэклога продукта самые приоритетные элементы (требования к продукту), детализирует их до уровня задач, оценивает трудоемкость и взаимосвязи между задачами.

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

Ежедневная летучка проводится каждый день в ходе Разработки, в одно и то же время. На этой встрече Команда обсуждает, что каждый из участников сделал за прошлый день, что планирует делать в следующий и в чем нужна помощь. Летучка длится не более 15 минут. Важно не отвлекаться на решение проблем в ходе встречи, а только обозначить их, и вернуться к решению после окончания, не отвлекая внимание других участников.

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

Разработка – процесс, в ходе которого Команда выполняет задачи и реализует требования из Бэклога спринта. Основное правило разработки – запрет на изменение состава спринта. В ходе спринта нельзя добавлять к работе команды новые требования или отказываться от уже включенных в Бэклог спринта. Остановить выполнение спринта можно лишь в одном случае: если Цель спринта теряет свою актуальность. В этом случае проводится Ретроспектива для анализа причин возникшей ситуации и заново запускается Планирование спринта.

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

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

Ретроспектива – это закрытая встреча Команды, на которой оценивается прошедший спринт с точки зрения организации процессов. На Ретроспективе формулируются ответы на вопросы:

• Что было сделано хорошо?
• Как можно улучшить процесс?
• Какие улучшения будем делать в следующем спринте?

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

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

Тогда приходите к нам на тренинг Agile Certified Professional и научитесь правильно применять Scrum и Kanban на практике, чтобы сделать рывок в карьере или бизнесе!