В шапке
Документы, которые использует команда при работе по  Scrum

Документы, которые использует команда при работе по Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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 для оценок работ рекомендуется использовать так называемое покерное планирование, о котором я напишу в следующих статьях.

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

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

Для этого и используется диаграмма BurnDown,  пример которой представлен ниже:

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

Вот такие достаточно простые документы ведет Scrum-команда для управления своим проектом. Но простота только кажущаяся, ведь создание и поддержание в актуальном состоянии всех этих документов требует от команды серьезной дисциплины. А кто должен убедить команду в важности ведения этих документов? Правильно, скрам-мастер.

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

Удачи Вам в реализации ваших проектов!

 

Комментарии (0)
Войти как