Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1102 / 167 | Длительность: 10:06:00
Лекция 8:

Атрибуты Scrum

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >

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 является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. PB существует ровно до тех пор, пока существует и сам продукт:

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

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Дмитрий Марушко
Дмитрий Марушко
Беларусь, Минск
Александр Юрченко
Александр Юрченко
Россия, г. Москва