Какие документы использовать и как с ними работать при Scrum-подходе

Наш эксперт Максим Якубович продолжает рассказывать о подходе Sсrum в работе над проектом.

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

Итак, в Scrum используется всего три документа:

• Журнал продукта (Product backlog)
• Журнал спринта (Sprint backlog)
• Диаграмма BurnDown

Журнал продукта

Первый документ – журнал продукта содержит в себе все требования (пожелания) к тому продукту, над которым ведет работу команда проекта. Часто в этот журнал записывают еще и те задачи, которые напрямую не связаны с создаваемым продуктом. Например, задачи по улучшению процессов работы над проектом. Пожелания в Scrum называются историями пользователя и записываются одной строчкой примерно в таком формате:

Будучи <тип пользователя>, я хочу <конкретная цель>, чтобы <конкретная причина>

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

После того как история пользователя поднимается в рейтинге достаточно высоко, чтобы попасть в ближайший спринт, кто-то из команды встречается с владельцем продукта и задает ему уточняющие вопросы по требованиям. Владелец продукта должен быть доступным для команды. Настолько, чтобы запланировать обсуждение по истории в течение 1-2 дней после сообщения от команды о желании встретиться.Майк Кон в книге «Scrum. Гибкая разработка ПО» описывает важнейшие характеристики, которыми должен обладать хороший журнал продукта:

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

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

3. Изменчивость. Журнал продукта не является чем-то статичным. С течением времени он изменяется. По мере получения дополнительной информации, в нем появляются новые пользовательские истории, какие-то из них удаляются, изменяются приоритеты по ним.

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

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

Журнал спринта

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

Для того, чтобы отобрать истории, им нужно:

• Знать приоритет историй в журнале продукта
• Знать скорость, с которой команда выполняет работу в рамках спринта. Ее обычно измеряет скрам-мастер
• Уметь делать оценки сложности по элементам журнала продукта

В The Scrum Guide описана такая метрика измерения скорости работы команды, как velocity, которая по сути отражает скорость работы команды в рамках каждого спринта. Измеряется этот показатель в так называемых story points или идеальных человеко-часах. Мы в команде для измерения скорости нашей работы выбрали идеальные человеко-часы.

Кроме скорости команды, мы измеряем такой показатель как Focus Factor. Он позволяет понять, как команда держит свои обещания относительно выполнения взятого на себя объема работ на спринт. Например, на старте спринта мы взяли на команду 10 задач и оценили их в 160 идеальных человеко-часов. По окончании спринта мы полностью выполнили 7 задач из 10. По плановым оценкам эти 7 задач оценивались в 96 идеальных человеко-часов – это и есть velocity команды на данный спринт. А Focus Factor данного спринта составил 96/160 = 0,6.

В следующий раз при планировании спринта команда, фокус-фактор которой оказался равен 0,6, возьмет работы не на все имеющееся у нее время в 160 часов (к примеру), а на 160*0,6 = 96 часов.

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

Диаграмма BurnDown

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

Что нужно знать команде каждый день, чтобы понимать, успеет ли она реализовать взятые на спринт обязательства? Ей нужно понимать, какой объем работ остался до окончания спринта и какой должен был остаться по плану.

Для этого и используется диаграмма BurnDown. Вот пример такой диаграммы:

У команды на спринт было запланировано работы на 162 идеальных человеко-часа. Зеленая линия на диаграмме показывает, какой объем работ в человеко-часах должен оставаться у команды в идеальной ситуации на каждый день. Красная линия – какой объем работ реально у команды остался.

Таким образом, если красная линия идет выше зеленой – мы отстаем от плана, в обратном случае – мы его опережаем или идем ровно так, как запланировали (если линии совпадают). Если участники команды не ленятся, каждый день оценивают по уже начатым задачам объем оставшихся работ – на диаграмме виден прогноз, успевают ли они в срок выполнить все намеченное на спринт.Вот такие достаточно простые документы ведет Scrum-команда для управления своим проектом. Но простота эта только кажущаяся, ведь создание и поддержание в актуальном состоянии всех этих документов требует от команды серьезной дисциплины. А кто должен убедить команду в важности ведения этих документов? Скрам-мастер.

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

С удовольствием постараюсь ответить на возникшие вопросы в комментариях к статье.

Хотите мгновенно получать уведомления о новых материалах и событиях «Про бизнес.»? Подписывайтесь на наш канал в Telegram!