Agile-артефакты в Scrum: зачем нужны и как использовать

Scrum и daily stand-ups — не загадочные слова в разработке, а повседневность. Но команда может применять фреймворк и одновременно — неправильно работать с его отдельными элементами.

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

Зачем артефактам отдельное место в Scrum-гайде

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

Если команда работает по Scrum, то понимает, что требования клиентов могут меняться. Поэтому разработка ведется инкрементально и адаптивно, с опорой на 3 столпа процесса управления:

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

Базовые элементы фреймворка — артефакты в Scrum, на использовании которых строится эффективная работа. Им нужно отдельное место в гайде, а к ним — особо внимательное отношение. Что относят к артефактам:

• Product Backlog. Список всего, что должно появиться у продукта: функции, требования, улучшения. Для удобства обращения с ним все пункты списка упорядочивают по приоритету.
• Sprint Backlog. Список элементов, которые команда планирует реализовать в этом спринте. 
• Инкремент. Рабочая версия продукта, которую потенциально можно представить пользователям. 
• Definition of Done (DoD). Список критериев, которым инкремент должен соответствовать на момент завершения спринта.

Если команда хорошо понимает значение Scrum артефактов, то ей будет проще внедрить и использовать методику. Нарушение структуры, отказ от использования или неправильный выбор артефактов может привести к тому, что профессионалы в шутку называют «ScrumBut(t)» или по-русски «Скрам, но…» — ситуации, когда команда использует Scrum только на словах, на деле игнорируя целостность подхода. Так есть вероятность, что разработка будет стоять на месте, команда потеряет фокус, а работа перестанет быть прозрачной и прогнозируемой. 

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

Денис Бартоломе, бизнес-тренер

Стратегический список ценности: Product Backlog + Product Goal

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

Владелец продукта расставляет приоритеты в бэклоге в зависимости от того, насколько это:

• важно для клиента;
• сложно в реализации;
• нуждается в обратной связи;
• связано с другими рабочими задачами. 

Правильно расставленные приоритеты помогают решать важные задачи в первую очередь и следить за балансом между автономностью команды и требованиями к продукту.

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

Сверху в бэклоге должно лежать то, что поможет максимально сфокусироваться на достижении цели продукта. 

Денис Бартоломе, бизнес-тренер

Владелец продукта формирует бэклог в несколько шагов:

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

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

Цель продукта — это направление или «фильтр», через который нужно пропускать все решения. Этот инструмент не дает потерять фокус и забыть, зачем ведется работа. 

Денис Бартоломе, бизнес-тренер

Работа с бэклогом должна включать в себя процесс приоритизации для определения самых важных элементов — Product Backlog Refinement (PBR) или, как это еще иногда называют, груминг бэклога. Это регулярный процесс, во время которого задачи в бэклоге:

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

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

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

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

Во время PBR можно декомпозировать крупные задачи, сделать их более управляемыми и понятными для участников.

План команды на текущий спринт: Sprint Backlog + Sprint Goal 

Когда все элементы находят свое место в списке, Владелец продукта вместе с командой отбирают из множества основных задач несколько в Sprint Backlog — бэклог спринта. Это «контейнер» для детального планирования работы на ближайшую итерацию — спринт. С помощью бэклога спринта команда не отвлекается на долгосрочные планы и может сосредоточиться на текущих потребностях проекта. 

Чтобы отобрать задачи из Product Backlog в бэклог спринта, нужно:

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

👉 Во время составления Sprint Backlog важно убедиться, что запланированные задачи реально выполнить за спринт.

Бэклог спринта — «контейнер», в котором лежат потенциально ценные фичи и обновления, которые помогают добиться цели. Если необходимо — можно динамически управлять бэклогом спринта, если это помогает эффективнее достигать поставленной цели. 

Денис Бартоломе, бизнес-тренер

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

Есть разные методы, которыми пользуются команды для  отбора задач в спринт. Один из таких методов — MoSCoW, в котором задачи разделяют на 4 категории:

• Must have (обязательно); 
• Should have (желательно); 
• Could have (возможно); 
• Won’t have (не нужно).

Подробно о том, как метод помогает расставить приоритеты и не провалить проект — читайте в статье «MoSCoW против хаоса: как расставить приоритеты и не сойти с ума».

Для каждого спринта важно определить Sprint Goal. Это краткая формулировка ценности, которую команда должна получить к концу итерации. 

Любая хорошая цель:

• мотивирует команду;
• создает фокус;
• может стать критерием при принятии решений;
• конкретная;
• измеримая.

Также, хорошая цель должна быть сформирована, как бизнес-результат, а не как набор технических задач. Например: «Увеличить конверсию в регистрацию на 15% с помощью оптимизации посадочной страницы».

Цель спринта — образ того, что нужно получить в конце итерации, и команда должна быть способна это продемонстрировать.

Денис Бартоломе, бизнес-тренер

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

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

• визуализировать текущие статусы задач и прогресс команды;
• упростить коммуникацию внутри команды и с заинтересованными сторонами;
• выявить узкие места и исправить их.

👉 Доска таск-трекера помогает отслеживать прогресс и видеть, насколько команда близка к достижению Sprint Goal в реальном времени.

Грамотный владелец продукта всегда имеет план, как он будет «продавать» свой продукт инвесторам и поддерживать интерес к нему. Набор целей спринта — своеобразная декомпозиция этого плана. 

Денис Бартоломе, бизнес-тренер

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

Что значит «реально готово»: Increment + Definition of Done

В конце каждого спринта команда должна представить инкремент в состоянии Definition of Done. 

Инкремент — конкретное обновление, фича или фрагмент продукта, которое потенциально можно протестировать и использовать. Каждый инкремент должен соответствовать «Критериям готовности».

Definition of Done (DoD) или «Критерии готовности»— набор критериев, которые должны быть выполнены для того, чтобы элемент считался завершенным. 

Критерии готовности инкремента зависят от корпоративных требований к процессу поставки и отражают требования среды по качеству.

Денис Бартоломе, бизнес-тренер

Если в команде не установлены критерии DoD, то каждый сотрудник может считать инкремент завершенным по-своему — до тестов или после, до код-ревью или вне зависимости от него.

Если команда поставляет только завершенные инкременты, то минимизирует риски, связанные с доверием аудитории и незавершенной работой. Критерии DoD позволяют быстрее находить и устранять проблемы, минимизировать технический долг, делают инкремент понятным для всех сторон.

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

DoD позволяет снизить технический долг, потому что команда:

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

Также DoD может включать требования к тестированию и рефакторингу. Если команда регулярно проверяет соблюдение критериев, то им легче поддерживать кодовую базу в хорошем состоянии.

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

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

Денис Бартоломе, бизнес-тренер

Радиаторы прогресса: Burn-charts, CFD, velocity-trend

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

Burndown Chart

Отчет «Диаграмма сгорания» показывает, сколько работы осталось выполнить до конца спринта или релиза. Часто его используют для инспекции спринта. По оси X в графике можно отследить время, а по оси Y — оставшийся объем задач в Story Points, часах или количестве задач.

Какие отклонения можно заметить в вашем графике:

• фактическая линия выше идеальной — команда отстает от графика;
• плато (горизонтальная линия) — работа не двигается из-за блокировки или других проблем;
• линия резко поднимается вверх — в спринт добавили новые задачи или их вернули в статус «не готово»;
• линия резко падает вниз — команда разом закрыла много задач или их переоценили;
• линия все время значительно ниже идеальной — команда взяла на себя слишком много задач или недооценила их.

CFD

Отчет «Кумулятивная диаграмма потока», дополнительный аналитический инструмент, показывает, как задачи распределяются по стадиям рабочего процесса, если мы используем более сложную визуализацию — например: «Сделать», «На аналитике», «Разрабатываем», «На тесте», «Готово». Каждая стадия — очередная цветная полоса шириной в количество задач. Отчет подходит как для инспекции процесса работы в спринте, так и для наблюдения за реализацией продукта на более широком временном диапазоне.

Какие отклонения можно заметить в вашем графике:

• Расширение полосы во времени. Если это не колонки «Сделать» или «Готово», то график указывает на «узкое место». Например, если колонка этапа  «Тестирование» постоянно расширяется, то тестировщики не успевают за разработчиками.
• Слишком широкая полоса говорит о большом количестве незавершенной работы. Из-за этого увеличивается время выполнения задач и снижается эффективность работы команды.
• Все полосы идут горизонтально. Поток работы остановился. 

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

Денис Бартоломе, бизнес-тренер

Velocity-trend

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

Какие отклонения можно заметить в вашем графике:

• Скорость от одного спринта к другому сильно меняется. Работа нестабильна — возможно, меняются сотрудники, некорректно оценивают объемы работы или требования плохо проработаны на PBR. 
• Устойчивый нисходящий тренд. Производительность команды падает. Это серьезный сигнал для анализа причин: например, большой технический долг, выгорание сотрудников, проблемы в процессах или конфликты.
• Устойчивый восходящий тренд. Производительность команды растет. Это хорошо, если нет ошибок в расчетах.

Резкое падение или взлет скорости в рамках одного спринта. Нужно анализировать причины — праздники, больничные, трудоустройство нового сильного специалиста.

Диаграмма сгорания и Velocity-trend — показатели, которые помогают команде оценить свой потенциал и понять, смогут ли они осилить следующий рывок.

Денис Бартоломе, бизнес-тренер

Как использовать артефакты в Kaiten

Таск-трекер помогает команде организовать рабочие процессы и отслеживать их прогресс. В сервисе можно создать отдельную доску Product Backlog и сформировать из него Sprint Backlog в пару кликов.

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

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

Затем владелец продукта формирует список задач и целей, собирает их в бэклоге продукта:

После этого совместно с командой решает, на чем нужно сфокусировать внимание в этом спринте, и расставляет приоритеты. 

В полях доски перед запуском спринта можно зафиксировать Product Goal и Sprint Goal, Цель будет всегда видна вместе со сроками спринта. Это обеспечит фокус команды на протяжении всего спринта и поможет принимать решения, если возникнут непредвиденные обстоятельства.

В Kaiten можно сформулировать критерии DoD и добавлять их в виде чек-листа. Пункты будут автоматически добавляться в карточку при ее создании или перемещении в новую колонку. 

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

Для новой фичи пункты чек-листа DoD могут быть, например, такими:

• Код написан;
• Unit-тесты пройдены;
• Интеграционные тесты пройдены;
• Документация обновлена;
• Проверено: Product Owner.

Руководитель или ответственный за фичу сотрудник будет отмечать пункты по мере выполнения. Инкремент будет считаться готовым только тогда, когда все пункты DoD выполнены. 

Еще одно преимущество использования Kaiten — автоматические отчеты:

• Разработка становится прозрачным и предсказуемым процессом.
• Команда, Скрам-мастер, Владелец продукта, команда и другие стейкхолдеры могут в любой момент увидеть актуальный статус спринта и состояние потока работы. 
• На Daily Scrum команда может быстро взглянуть на Диаграмму сгорания, чтобы понять, успевают ли к завершению спринта.
• Kaiten может показывать данные за несколько спринтов, что важно для планирования релизов.

Заключение

Скрам может значительно повысить эффективность команды, а для настройки системы управления можно использовать готовый Scrum-шаблон в Kaiten и его встроенные инструменты аналитики. Также, в нем удобно централизованно вести артефакты проекта, фиксировать и отслеживать цели. Команда больше сможет сфокусироваться на создании ценности для продукта, а не на администрировании процесса. 

Чтобы успешно подготовиться к созданию качественного продукта, вы можете двигаться по шагам:

• активируйте шаблон Scrum в Kaiten и настройте его под себя;
• создайте Product Backlog и добавьте в него все задачи, которые нужно выполнить для завершения работы над продуктом;
• создайте Product Goal, чтобы команде было проще ориентироваться;
• спланируйте первый спринт в соответствии со Sprint Goal, добавьте задачи в Sprint Backlog;
• включите и регулярно изучайте отчеты радиаторов прогресса: Burn-charts, CFD, velocity-trend.

Успешные компании уже используют Kaiten Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать