Атрибуты Scrum

8.6. Бэклог спринта

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

Бэклог спринта (Sprint Backlog SB) - это набор элементов Product Backlog, выбранных для выполнения в текущем спринте.

Бэклог спринта:

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

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

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

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

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

После того как они выполнены, оценки оставшегося объема работ обновляются.

Если некоторые задачи считаются уже неактуальными, то их удаляют.

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

8.7. Инкремент продукта

Цель команды Scrum в отдельно взятом спринте - предоставлять работающий инкремент продукта.

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

Инкремент по своей сути - это продукт, который будет приносить бизнес-пользу ( рис. 8.4) в момент своей разработки после того, как результаты определенного спринта реализованы Scrum-командой и приняты заказчиком.

Рис. 8.4. Наглядное изображение инкремента в строительстве

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

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

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

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

8.8. Принцип прототипирования

Scrum основывается на "итерационно-инкрементальной" разработке программных продуктов, которые будут с момента своего "зачатия" приносить компании прибыль. Шаг за шагом.

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

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

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

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

8.9. Краткие выводы

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

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