Очень важным этапом работы с Product Backlog является выстраивание задач в порядке их приоритета. Когда мы провели декомпозицию и оценили пользовательские истории необходимо определить, в какой последовательность будет проходить реализация задач, что будет выпущено в первой версии продукта, что может быть включено в последующие поставки, а что может быть оставлено на тот случай, если останется время. Как же определить, что брать за основу при выстраивании приоритезированного списка User Stories?

Провести сортировку бэклога и выстроить тот или иной порядок задач можно базируясь на различных критериях, исходя из разных ценностей. Именно для этого существует множество техник приоритезации, каждая из которых принимает во внимание тот или иной аспект\критерий значимости задачи. Как это свойственно Agile процессу, самым эффективным будет применение и комбинирование различных методов приоритезации. Далее в статье разобраны варианты техник, с помощью которых можно провести сортировку Product Backlog.

Метод 1: Value Based – техника основанная на ценности для бизнеса.

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

Метод 2: Technology Risk Based – техника основанная на технологических рисках.

• В этом методе приоритет требований определяется на основе риска, связанного с его реализацией.
• Высокий риск может быть связан с различными факторами, например:
  • Использованием новой еще «необкатанной» технологии.
  • Большим количеством точек интеграций с внешними системами.
  • Сложной логикой и большим количеством условий.
  • Наличием устаревшего кода (Legacy code), который более не поддерживается и не дорабатывается, но переиспользуется.
• Требование с наибольшим технологическим риском реализуется во время первых итераций и включается в ранние релизы. Это необходимо для того, чтобы:
  • Как можно раньше выявить возможные технические сложности и, при необходимости, принять соответствующие меры.
  • Получить ранний фидбэк от пользователей по работе с новыми технологиями и решениями.

Метод 3: «MoSCoW» - метод «Москва».

• При оценке приоритета методом «MoSCoW» для каждой задачи мы подбираем наиболее соответствующее ей 1 утверждение из 4. Каждое из утверждений является индикатором определенного уровня важности задачи. Какое из утверждений больше соответствует действительности, к такой группе приоритета и принадлежит данная пользовательская история:
  • Must have this – Это обязательно должно быть. «Must» требования не подлежат обсуждению и в любом случае должны быть реализованы. Если они не поставлены пользователю в ближайших релизах, тогда весь проект не имеет смысла.
  • Should have this if at all possible – Следует сделать, если это только возможно. Данные задачи также важны для пользователя и\или заказчика, однако, сроки их поставки не так критичны как для «Must». Без данной функциональности продукт уже можно использовать, ее отсутствие не блокирует базовых возможностей из списка «Must» и она может быть выдана немного позже.
  • Could have this if it does not affect anything else – Можно сделать, если это не повлияет на что-то другое. Эта категория задач допускает максимально гибкий взгляд на такие основные критерии выполнения как скоуп, сроки, качество и ресурсы. Здесь возможна вариативность и компромиссы.
  • Will not have this time but would like in the future – Сейчас на это нет времени, но хотелось бы сделать в будущем. Для этой категории ключевым моментом является то, что данные требования могут быть также важны (также как и «Must»), однако, их можно оставить для более поздних поставок продукта. Категория «Will not» имеет 3 важных эффекта:
    • Пользователям и заказчикам не нужно бороться, чтобы включить какое-либо требование в Product Backlog.
    • Имея возможность видеть список требований для отдаленных релизов, можно оценить как это будет влиять на то, что будет реализовано в первую очередь.
    • На требования из категории «Will not» можно ориентироваться как на долгосрочную тенденцию в развитии продукта, учитывая данные особенности в ранних поставках.
• После выполнения такого упражнения каждое требование будет иметь один из четырех приоритетов, который можно отметить на стикере с пользовательской историей символом M, S, C или W.

Метод 4: Kano model - модель Кано.

• В этом методе требования классифицируются на основе предпочтений клиента по 5 категориям. Каждая категория показывает насколько важна пользователю\заказчику\клиенту та или иная функциональность, качество или характеристика продукта:
  • Must-be Quality - обязательные для пользователя характеристики продукта. Это требования, которые заказчики\пользователи\клиенты ожидают в первую очередь и воспринимаются как должное, они являются необходимыми для выпуска продукта. Когда данные функции реализованы, клиенты воспринимают это как само собой разумеющееся, но когда они не реализованы или сделаны плохо, клиенты очень недовольны.
  • One-dimensional Quality - одномерные характеристики. Это функциональность, которая приводит к удовлетворению пользователей\клиентов, когда она реализована и недовольству, когда ее нет. Это параметры и возможности продукта, на которых строится конкуренция компаний между собой.
  • Attractive Quality – привлекательные для пользователя характеристики. Реализация данных требований обеспечивает удовлетворение пользователей, но при этом когда они не выполняются, это не вызывают неудовлетворенности. Это функционал, который обычно не ожидается и радует пользователя, если он вдруг появился.
  • Indifferent Quality – безразличные для пользователя характеристики. Для пользователя требования из этой категории не являются ни хорошими, ни плохими, они не приводят к удовлетворению или неудовлетворенности клиентов. Примером таких задач могут быть различные технические решения, которые скрыты от пользователя.
  • Reverse Quality – противоположные характеристики. К этой группе относятся требования, реализация которых улучшает, но при этом усложняет продукт. Это могут быть различные дополнительные функции, которые расширяют необходимый и достаточный функционал продукта. Для ряда клиентов и пользователей сложный высокотехнологичный продукт, с большим количеством функций и возможностей может быть скорее минусом.
• Данная модель позволяет характеризовать каждую задачу, выстроить очередность реализации требований и сформировать план поставок базируясь на ожиданиях пользователей, управляя их реакцией на вывод той или иной функциональности.

Метод 5: Validated Learning – «подтвержденное обучение».

• В этом методе в качестве самых приоритетных выбираются функции и задачи с самым высоким рыночным риском. Это могут быть какие-либо фичи\продукты\возможности, которых еще не было на рынке и не понятно как рынок отреагирует на их появление, как примут их пользователи.
• Суть метода сводится к тому, чтобы выпустить задачи с наибольшим рыночным риском как можно раньше, проверить решение экспериментально, получить обратную связь (пройдя тем самым обучение) и далее применить полученные знания в новой итерации.
• Процесс применения Validated Learning обычно состоит из следующих шагов:
  • Выбираются пользовательские истории с наибольшим риском\степенью неопределенности для рынка.
  • Определяются метрики и критерии успешности для выбранных задач.
  • Требования с самым высоким приоритетом реализуются в первых итерациях и включаются в максимально ранние поставки.
  • Проводится анализ достижения установленных метрик.
  • В соответствии с полученными результатами в требования и процесс работы вносятся корректировки и начинается следующая итерация приоритезации.

Метод 6: Walking Skeleton – «ходячий скелет».

• В этом методе задачи приоритезируются таким образом, чтобы наиболее тесно связанные между собой требования, которые составляют сквозной бизнес процесс, были реализованы и выпущены одновременно или в течение короткого промежутка времени.
• Вначале отбираются задачи, реализация которых даст минимальный возможный набор  end-to-end функционала и позволит выпустить первую рабочую версию продукта. Данные задачи будут иметь максимальный приоритет.
• Остальные задачи также при помощи приоритетов объединяются по группам. Каждая группа требований получает свой приоритет и ее реализация позволяет добавить к продукту новый небольшой функционал (сквозной бизнес процесс).
• Важным принципом при разбиении требований на группы приоритетов с использованием Walking Skeleton является то, что в первом релизе, в начальной версии продукта мы не реализуем сразу конечную архитектуру. Архитектура и функциональные задачи реализуются параллельно в последующих итерациях.

Метод 7: Theme scoring – оценка «тем».

• 
  В рамках данного метода приоритеты определяются при сравнении требований («тем») друг с другом по различным критериям. В процессе приоритезации определяется насколько важно включить ту или иную тему в следующий релиз по каждому из таких критериев\условий.
• Основные этапы метода Theme scoring:
  • Определяется порядка 5-9 критериев выбора для сравнения, что важно выпустить в следующем релизе. Критериями для сравнения могут быть, например:
    • Полученная прибыль после выпуска задачи
    • Важность функционала для пользователей\клиентов
    • Необходимость решения для последующих доработок продукта
    • Уровень технического риска при реализации задачи
  • Выбирается базовая «тема», с которой будут сравниваться остальные. Условия для выбора базовой темы:
    • Данная задача вероятнее всего будет включена в следующий релиз
    • Задача понятна и прозрачна для большинства членов команды
  • Каждая тема, которая является кандидатом в релиз оценивается относительно основной темы по каждому критерию. Фактически заполняется матрица с указанием баллов оценки:
    • Если рассматриваемая задача важнее базовой, то для данного критерия выставляется +1 балл, если она менее важна, то -1 балл.
    • Если критерии неравнозначны между собой, то для них можно ввести специальные весовые коэффициенты или проценты (например, прибыль может иметь вес 50%, а технический риск 10%).
    • Для базовой темы по всем критериям сравнения указываем 0 баллов.
  • После того как все темы оценены по всем критериям выполняется подсчет баллов. Сумма баллов для каждой темы и будет ее приоритетом. Чем больше баллов, тем выше приоритет данной задачи.

Смотрите также:

Agile: 8 методов декомпозиции задач

Agile: 7 техник оценки задач