Текст книги "Все о SCRUM. Изучение, разработка, интеграция"

6
Структура бэклога

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

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

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

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

Бэклог – это инструмент сбора и распределения задач.

6.1 Бэк что?

Неужели нет французского слова для бэклога?

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

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

Хотя и не без путаницы: кое-кто упорно произносит блэклог. Я даже как-то раз слышал блэкдог.

Рисунок 6.1 – «Я сказал дополнить бэклог, а не исполнить «Black dog»

Scrum-мастер – разработчику и фанату группы «Led Zeppelin»

В литературе о Scrum различают бэклог продукта и бэклог спринта.

✓ В 2008 я решил более не использовать термин бэклог спринта для обозначения плана на спринт. Я объясню свое решение в главе 9.

✓ Начиная с третьего издания этой книги, сокращаю бэклог продукта до бэклога.

Этому есть несколько причин: во-первых, так проще, во-вторых, мы говорим о продукте и, наконец, – это больше соотносится с командой. К слову, в Scrum 3.0 термин продукт почти не встречается.

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

6.2 Необходимый инструмент экосистемы

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

Рисунок 6.2 – Свойства бэклога

6.2.1 Доступный

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

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

6.2.2 Конструктивный

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

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

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

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

6.2.3 Упорядоченный

Элементы бэклога расставлены в предположительном порядке их реализации. У задач должна быть четкая последовательность.

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

Если А приоритетнее, чем Б, то А будет выполнено до Б.

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

6.2.4 Уникальный

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

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

6.2.5 Живой

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

Бэклог живет продолжительное время, претерпевая изменения с каждым сезоном:

✓ одни элементы добавляются,

✓ другие убираются,

✓ какие-то из них разбивают на несколько,

✓ порядок элементов корректируется.

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

6.2.6 Развивающийся

Я ознакомился со многими спецификациями в различных областях разработки ПО. И каждый раз отмечал: невозможно все знать с самого начала проекта. Если вы все обсудите и постараетесь предвосхитить все возможные ситуации – конечно, обнаружите много важных функций. Но всегда будут такие, которые появятся только при общении с конечными пользователями.

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

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

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

6.3 Маленькие и большие части бэклога

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

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

6.3.1 Две точки зрения на бэклог

«Руководство по Scrum» формально не навязывает использование какого-либо термина для элементов бэклога, но употребляет аббревитуру PBI (Product Backlog Item).

Со временем элементы бэклога стали называться историями (stories). Истории становились все меньше и короче по определенным причинам – мы коснемся их позднее. Но в связи с этим проблема: маленькие обособленные части бэклога не понятны заинтересованным сторонам. А разработчик не может свести их в общую картинку и перестает разбираться в процессе.

Джефф Паттон [«Пользовательские истории»] заострил внимание на этой тенденции и использовал метафору астероидов. Он предложил создать карту, чтобы соотнести большие и маленькие части бэклога.

Учитывая размер элементов бэклога, не стоит забывать, что самым важным остается работа с ними.

После десяти лет практики я пришел к выводу, что бэклог состоит из двух частей.

✓ Та, что касается команды и содержит маленькие части, над которыми команда работает или планирует работать в скором времени

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

Бэклог состоит из двух частей, каждая из которых служит своей цели:

– Рабочий бэклог состоит из маленьких частей, называемых историями.

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

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

Рисунок 6.3 – Бэклог и две его части

6.3.2 Функциональность

В литературе по теме можно найти в качестве эквивалентов такие термины, как feature (то, что я использовал в предыдущих изданиях этой книги) или capability. Наиболее близкое мне понятие – Minimal Marketable Feature, MMF (прим. пер.: коммерчески ценная функциональность) [23]23
  Определение MMF: https://www.agilealliance.org/glossary/mmf – Прим. авт.


[Закрыть]. На мой взгляд, функциональность, появившаяся вследствие декомпозиции – это MMF.

Функциональность – это функция продукта, формулировка которой понятна для заинтересованных сторон. Она влияет на пользователя.

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

Ключевая концепция заключается в поиске наименьшей значимой функциональности. Это задача Владельца продукта.

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

Пример функциональности для команды Рeetic.

Изначальная функциональность. Онлайн-тренировки для домашних питомцев.

После разделения на части и анализа каждой функциональность стала выглядеть следующим образом:

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

6.3.3 История

Термин user story – пользовательская история – появился в Экстремальном Программировании, а сейчас широко употребляется в Scrum.

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

Пример истории для команды Peetic.

Пользовательская история. Возможность для хозяина бассет-хаунда записать своего питомца на выставку собак.

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

Как и функциональность, история видна пользователям. Но есть два отличия:

✓ в эксплуатацию вводится сразу несколько историй,

✓ история разрабатывается в течение одного спринта.

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

Epic – это история, которую невозможно закончить за один спринт. Она не может перейти к статусу готово.

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

Epic должен быть разделен на части и хорошо изучен, он нуждается в доработке. После разделения на части он исчезает.

6.4 Изображение бэклога

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

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

6.4.1 Жизненный цикл истории

В 2001 году Рон Джеффрис дал следующее определение истории: мы пишем на карточках то, чего хотим достигнуть. Затем мы проговариваем дальнейшую работу и коллективно подтверждаем. Такой подход называется Три П.

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

1. Однажды у кого-то появляется идея, и он пишет ее на карточке (сейчас для этого чаще используются Post-it®).

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

3. Команда подтверждает, что она готова.

4. Команда реализует историю в рамках спринта, проговаривая весь процесс с Владельцем продукта.

5. Владелец продукта подтверждает, что работа завершена.

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

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

Рисунок 6.4 – Жизненный цикл истории

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

В главе 2 мы обсудили двухфазный подход (исследовать, затем использовать) к продукту, который, по сути, очень похож: общая идея – снизить риски и оценить все возможные варианты на первом этапе и приступить к реализации на втором.

Двухфазный паттерн – фрактальный: он применим к жизненному циклу и истории, и функциональности.

6.4.2 Бэклог поставки

• Жизненный цикл функциональности

Жизненный цикл функциональности зависит от контекста. На него влияет позиция Scrum в цепочке создания ценности. На начальном этапе – это принятие решения о начале разработки, на последнем – развертывание и ввод в эксплуатацию.

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

Функциональность готова, когда:

– подтверждается гипотеза о ее воздействии на пользователей,

– усилия по достижению этого воздействия сводятся к минимуму.

Она завершена, когда добавляет продукту ценность.

Владелец продукта придерживается принципа максимальный эффект при минимальных усилиях [24]24
  На английском: «Minimize output, maximize outcome». – Прим. авт.


[Закрыть].

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

• Изображение при помощи kanban-таблицы

Бэклог поставки, содержащий функциональности, обычно изображается при помощи таблицы. Каждая колонка означает определенный этап. Визуальный менеджмент позволяет отслеживать работу над элементами (в данном случае, это функциональности) в течение времени.

Такая таблица называется kanban (не следует путать с методом Kanban, о котором мы поговорим в главе 20).

Рисунок 6.5 – kanban-таблица для работы с функциональностями

Бэклог поставки является основным инструментом коммуникации с заинтересованными сторонами.

6.4.3 Рабочий бэклог

• Жизненный цикл истории

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

Далее в контексте рабочего бэклога может применяться двухфазный паттерн. Команда может столкнуться с большим списком историй на стадии доработки. Чтобы уменьшить его, существует паттерн лотков[25]25
  Под лотками у автора подразумеваются столбцы. – Прим. ред.


[Закрыть]: наглядно изображаются пять этапов жизни истории (два действия, период ожидания между ними, до и после).

Суть этого паттерна – в распределении историй в соответствии с их текущим состоянием.

Во французском употребляется слово bacs (лотки) – как бы фонетическая отсылка к бэклогу.

• Изображение при помощи лотков

Песочница идей

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

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

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

Обратная связь имеет большое значение в Аgile-методах, и первоначальным хранилищем для нее является песочница.

Лоток доработки

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

Этот лоток выглядит, как обычная воронка.

✓ Приоритетная история уже почти готова. Она небольшого размера.

✓ В середине воронки то, что перейдет к этапу разработки через несколько спринтов. Здесь находятся epics среднего размера.

✓ Наименее приоритетные истории будут разрабатываться еще позднее. Это большие, громоздкие epics, которые впоследствии будут разложены на части.

Рисунок 6.6 – Воронка

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

Стартовый лоток для готовых историй

Scrum использует метафору гонки (спринт), и я предлагаю ее развить.

До спринтерских забегов готовые истории находятся в стартовых блоках. Назовем их стартовым лотком.

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

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

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

Финишный лоток для завершенных историй

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

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

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

Преимущества паттерна лотков

Применение этого паттерна означает для команды (и особенно для Владельца продукта) следующее:

✓ четко видеть, что у каждой части в изображении своя цель, отличная от других;

✓ работать над каждой частью в соответствии с этапом, на котором она находится;

✓ не быть заваленными огромным количеством историй.

Рисунок 6.7 – Структура рабочего бэклога на основе этапов жизни

В этой главе мы рассмотрели бэклог в статике. Следующая будет посвящена бэклогу в динамике и процессу циркулирования историй и функциональностей в потоке.

6.5 Типология историй

Какую работу заносить в бэклог? Бывает, команда тратит время на технические аспекты или на исправление ошибок. Паттерн сториотип [26]26
  Характеристики, свойственные нескольким историям. – Прим. ред.


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

Этот паттерн основан на идее Филиппа Крухтена: визуализация элемента бэклога по двум основным направлениям [27]27
  http://www.infoq.com/news/2010/05/what-color-backlog – Прим. авт.


[Закрыть]:

✓ Ценность – в зависимости от того, добавляет элемент новую или восполняет отсутствующую;

✓ Значимость – в зависимости от того, кому продукт предназначен.

Рисунок 6.8 – Четыре основных типа историй

Эта классификация помогает не забыть внести работу в бэклог. Она будет полезна вкупе с более детальной классификацией критериев завершенности (Definition of Done, DoD).

6.5.1 Пользовательская история

Это история, которая имеет значение и ценность для заинтересованных сторон.

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

Пример пользовательской истории для команды Peetic.

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

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

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

6.5.2 Исправление ошибок

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

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

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

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

6.5.3 Техническая работа

Это работа, которая приносит ценность команде, но не видна заинтересованным сторонам.

Внимание

В пользовательских историях всегда есть техническая работа (дизайн, код), и это очень хорошо. Речь идет о работе, которая не связана с пользовательскими историями, но настолько значительна, что хотелось бы, чтобы она была более видима заинтересованным сторонам.

Внесение технической работы в бэклог оправдано в следующих ситуациях:

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

✓ есть технические риски, которые надо устранить до реализации пользовательской истории;

✓ необходимо улучшить качество или способ работы команды: инфраструктуру, логистику, новые инструменты, обучение, и т. д.

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

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

6.5.4 Погашение технического долга

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

Рисунок 6.9 – Попытка объяснить Владельцу продукта, что нужно сократить задолженность

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

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

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

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

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