Атрибуты Scrum

8.4. Доска задач

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

Каждый рабочий день все члены команды собираются на 15-минутное daily, на котором они обмениваются информацией по состоянию текущих дел ("Что сделано с момента предыдущей встречи?", "Чем планирую заниматься сегодня?", "Какие есть препятствия?").

На доске команды развешены задачи, каждой из которых выделен бумажный стикер, на котором написано, в чем состоит суть задачи ( рис. 8.3).

Рис. 8.3. Доска задач

Доска задач должна минимум делиться на три колонки:

• запланировано (To Do);
• в работе (In Progress);
• завершено (Done).

На момент планирования задач, которые предстоит взять в спринт, все карточки помещаются в колонку "Запланировано". Каждый день, когда член команды берет в работу определенную задачу, он говорит: "Я начал работать над…" и перемещает карточку в столбец "In Progress". После того как задача выполнена, исполнитель говорит о том, что работа над задачей закончена, и карточка перемещается в соответствующую колонку "Завершено".

Использование доски задач полностью соответствует принципам прозрачности работ, которые являются одним из главных преимуществ Agile в сравнении с альтернативными подходами к разработке программного обеспечения. Участники daily каждый день собственными глазами видят, как идет прогресс в работе над тем или иным типом задачи. Они не только погружаются в значимые детали работ, но и получают ценный опыт. Неоспоримыми выгодами, которые получает команда от использования доски задач, являются:

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

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

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

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

8.5. Бэклог продукта

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

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

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

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

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

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

Техники сбора требований схожи при традиционной и гибкой работе, как можно увидеть на следующих примерах:

• Задача --> Решение.
• Общее --> Частное.
• Учет влияния различных факторов --> Улучшение качества продукта.
• Прочее.

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

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

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

Это ведет к лучшему пониманию всеми вовлеченными сторонами, выявлению новых деталей.

После того как необходимые требования к продукту собраны, их необходимо зафиксировать и "взять на учет" для дальнейшей реализации. Для этого в Scrum есть артефакт, который называется бэклог продукта (Product Backlog, PB).

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

PB никогда не является полным. В начале (сверху) - только первоначально известные и наиболее понятные требования. Бэклог постоянно обновляется по мере обновления самого продукта и окружающей его среды, поэтому PB "живет" вместе с продуктом. PB является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. PB существует ровно до тех пор, пока существует и сам продукт:

1. PB содержит все "фичи", функции, требования, усовершенствования и информацию по исправлению дефектов, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому элементу PB присваивается описание, порядковый номер, оценка объема работы и ценность.
2. Элементы бэклога продукта, расположенные сверху, должны быть более понятными и содержать больше деталей, чем те, которые расположены ниже. Более точные оценки даются требованиям, которые являются более четкими и содержат больше дополнительной информации.
3. Чем ниже находятся требования, тем меньше деталей. Бэклог спринта представляет собой репозиторий задач, реализация которых позволит инкрементально двигаться к достижению желаемого конечного результата от разработки конкретного программного продукта.