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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3.3 История

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