Уникальность бэклога концентрирует усилия команды и помогает избежать негативных последствий мультизадачности.
Бэклог следует жизни продукта и развивается вместе с ним. В современном мире продукты не статичны, они создаются и развиваются постепенно и постоянно.
Бэклог живет продолжительное время, претерпевая изменения с каждым сезоном:
✓ одни элементы добавляются,
✓ другие убираются,
✓ какие-то из них разбивают на несколько,
✓ порядок элементов корректируется.
Бэклог живой, потому что продукт постоянно развивается. Иначе он умирает вместе с продуктом.
Я ознакомился со многими спецификациями в различных областях разработки ПО. И каждый раз отмечал: невозможно все знать с самого начала проекта. Если вы все обсудите и постараетесь предвосхитить все возможные ситуации – конечно, обнаружите много важных функций. Но всегда будут такие, которые появятся только при общении с конечными пользователями.
Бэклог доступен для всех членов экосистемы. Каждый может привнести свой вклад в его развитие.
Только обратная связь от пользователей позволяет узнать, что они действительно ожидают от продукта.
Бэклог допускает внесение новых элементов, потому что невозможно все знать заранее.
6.3 Маленькие и большие части бэклога
Существует множество паттернов, чтобы адаптировать бэклог к контексту.
В этой главе мы рассмотрим те, что позволят структурировать бэклог, в следующей – те, что пригодятся при его доработке.
«Руководство по Scrum» формально не навязывает использование какого-либо термина для элементов бэклога, но употребляет аббревитуру PBI (Product Backlog Item).
Со временем элементы бэклога стали называться историями (stories). Истории становились все меньше и короче по определенным причинам – мы коснемся их позднее. Но в связи с этим проблема: маленькие обособленные части бэклога не понятны заинтересованным сторонам. А разработчик не может свести их в общую картинку и перестает разбираться в процессе.
Джефф Паттон [«Пользовательские истории»] заострил внимание на этой тенденции и использовал метафору астероидов. Он предложил создать карту, чтобы соотнести большие и маленькие части бэклога.
Учитывая размер элементов бэклога, не стоит забывать, что самым важным остается работа с ними.
После десяти лет практики я пришел к выводу, что бэклог состоит из двух частей.
✓ Та, что касается команды и содержит маленькие части, над которыми команда работает или планирует работать в скором времени
✓ Та, что служит для общения с заинтересованными сторонами и содержит большие части. Конечно, она также полезна и для команды.
Бэклог состоит из двух частей, каждая из которых служит своей цели:
– Рабочий бэклог состоит из маленьких частей, называемых историями.
– Бэклог поставки состоит из больших частей, называемых функциональностями.
В экосистеме продукта истории соотносятся с функциональностями, поскольку большая часть продолжает существовать даже после того, как ее разбили на более маленькие (что отлично от любимых астероидов Джеффа).
Рисунок 6.3 – Бэклог и две его части
В литературе по теме можно найти в качестве эквивалентов такие термины, как feature (то, что я использовал в предыдущих изданиях этой книги) или capability. Наиболее близкое мне понятие – Minimal Marketable Feature, MMF (прим. пер.: коммерчески ценная функциональность) [23]. На мой взгляд, функциональность, появившаяся вследствие декомпозиции – это MMF.
Функциональность – это функция продукта, формулировка которой понятна для заинтересованных сторон. Она влияет на пользователя.
Она живет и преображается. Команда разбивает ее на истории. А иногда из этих историй получается новая функциональность, которая будет меньше изначальной.
Ключевая концепция заключается в поиске наименьшей значимой функциональности. Это задача Владельца продукта.
Функциональность больше, чем сумма историй, которые ее составляют. У нее своя жизнь. Это элемент, который может быть введен в эксплуатацию конечными пользователями.
Пример функциональности для команды Рeetic.
Изначальная функциональность. Онлайн-тренировки для домашних питомцев.
После разделения на части и анализа каждой функциональность стала выглядеть следующим образом:
Окончательная функциональность, введенная в эксплуатацию: бесплатные онлайн-тренировки для собак-компаньонов.
Термин user story – пользовательская история – появился в Экстремальном Программировании, а сейчас широко употребляется в Scrum.
Пользовательская история – это небольшая часть функциональности, видимая пользователю. Она может быть разработана в течение одного спринта.
Пример истории для команды Peetic.
Пользовательская история. Возможность для хозяина бассет-хаунда записать своего питомца на выставку собак.
Название едва созданной истории обычно состоит из глагола и дополнения. Уже потом, в процессе работы, разработчики добавляют в него все, что сочтут важным.
Как и функциональность, история видна пользователям. Но есть два отличия:
✓ в эксплуатацию вводится сразу несколько историй,
✓ история разрабатывается в течение одного спринта.
Не все истории в бэклоге относятся к пользователям. Вот почему я чаще использую общий термин история, говоря об элементах бэклога. Некоторые также употребляют термин epic.
Epic – это история, которую невозможно закончить за один спринт. Она не может перейти к статусу готово.
Причина этому – масштаб этой истории. Она гораздо больше. Иногда это бывает история, о которой команда мало знает в начале работы. Но впоследствии оказывается, что она включает в себя множество задач.
Epic должен быть разделен на части и хорошо изучен, он нуждается в доработке. После разделения на части он исчезает.
6.4 Изображение бэклога
Из одного простого списка бэклог превращается в хранилище двух списков, к которому мы применяем структурный паттерн поставки/работы для большей наглядности.
Чтобы упростить управление бэклогом и мониторинг, существует еще один паттерн – двухфазный. Он основывается на изображении значимых этапов жизненного цикла элементов бэклога.
В 2001 году Рон Джеффрис дал следующее определение истории: мы пишем на карточках то, чего хотим достигнуть. Затем мы проговариваем дальнейшую работу и коллективно подтверждаем. Такой подход называется Три П.
В Scrum команда дважды повторяет этапы проговаривания и подтверждения. Первый раз, чтобы подготовить работу над историей, и второй – чтобы ее закончить.
1. Однажды у кого-то появляется идея, и он пишет ее на карточке (сейчас для этого чаще используются Post-it®).
2. Владелец продукта и команда дорабатывают ее, коллективно и всесторонне проговаривая, пока она не становится историей, которую можно реализовать за один спринт.
3. Команда подтверждает, что она готова.
4. Команда реализует историю в рамках спринта, проговаривая весь процесс с Владельцем продукта.
5. Владелец продукта подтверждает, что работа завершена.
Получается Пять Пв жизненном цикле истории. Коллективная работа основана на обсуждении: реализации в рамках текущего спринта, что общеизвестно, и доработки в рамках предыдущих спринтов, что известно не так хорошо.
Между этими двумя непоследовательными этапами история уже готова – в том смысле, что она может быть реализована во время следующего спринта.
Рисунок 6.4 – Жизненный цикл истории
Эта модель помогает структурировать и дорабатывать бэклог, не забывая о том, что идея не приравнивается к готовой истории.
В главе 2 мы обсудили двухфазный подход (исследовать, затем использовать) к продукту, который, по сути, очень похож: общая идея – снизить риски и оценить все возможные варианты на первом этапе и приступить к реализации на втором.
Двухфазный паттерн – фрактальный: он применим к жизненному циклу и истории, и функциональности.
• Жизненный цикл функциональности
Жизненный цикл функциональности зависит от контекста. На него влияет позиция Scrum в цепочке создания ценности. На начальном этапе – это принятие решения о начале разработки, на последнем – развертывание и ввод в эксплуатацию.
Под контекстом в данном случае понимаются тип развертывания, размер продукта, темп спринтов и сезонов. В жизни функциональности ярче остальных выделяются два этапа: готово и завершено.
Функциональность готова, когда:
– подтверждается гипотеза о ее воздействии на пользователей,
– усилия по достижению этого воздействия сводятся к минимуму.
Она завершена, когда добавляет продукту ценность.
Владелец продукта придерживается принципа максимальный эффект при минимальных усилиях [24].
Таким образом, жизненный цикл функциональности проходит через два важных этапа: готово и завершено, остальные этапы (почти готово, почти завершено) зависят от контекста.
•