Гибкое управление проектами и продуктами

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

Более важные элементы журнала пожеланий определены точнее

Как видите, чем позднее планируется реализация того или иного функционала, тем более крупные фрагменты функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS (Keep it simple, stupid – «Не усложняй, тупица») и YAGNI (You аin’t gonna need it – «Вам это не понадобится»).

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

• рефакторинг модуля;

• оптимизация производительности;

• исправления сложного дефекта;

• настройка инфраструктуры.

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

Определение приоритетов историй пользователя

I can’t get no satisfaction,

I can’t get no satisfaction.
‘Cause I try, and I try, and I try, and I try.
I can’t get no, I can’t get no.

The Rolling Stones

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

Рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано (Noriaki Kano) предложил ее в работе «Привлекательное качество и необходимое качество» (Attractive Quality and Must-Be Quality) еще в 1984 году.

Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта.

Типы функций продукта

Таким образом, можно выделить три типа функций продукта.

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

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

3. Привлекательные функции – функции, которые придают вашему продукту wow-эффект. В качестве примера можно рассмотреть эргономику и удобство использования (юзабилити) Apple IPhone.

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

1. Как вы отнесетесь к наличию данной функциональности в продукте?

2. Как вы отнесетесь к отсутствию данной функциональности в продукте?

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

В качестве ответов опрашиваемому пользователю предлагаются следующие варианты ответов:

• нравится;

• ожидаю этого;

• все равно;

• могу смириться с этим;

• не нравится это.

После такого опроса можно проводить анализ результатов с помощью следующей таблицы (табл. 3.2).

Таблица 3.2.

Анализ результатов

В результате функции продукта разобьются на шесть категорий:

• A (attractive) – привлекательные;

• O (one-dimensional) – линейные;

• M (must-be) – обязательные;

• R (reverse) – обратные (ненужные);

• Q (questionable result) – сомнительный/противоречивый результат;

• I (indifferent) – безразлично.

Первые три категории для нашего анализа являются самыми интересными и дают более глубокое понимание требований по нашему продукту: