Это первая часть нашего любимого принципа: максимальный эффект при минимальных усилиях.
• Составить список функциональностей
Функциональность – это услуга или функция продукта, формулировка которой понятна заинтересованным сторонам. Функциональность способствует воздействию на заинтересованные стороны и состоит из историй.
Исходя из воздействия
Необходимо задать вопрос что. Следующий уровень на карте impact mapping – это функциональности, способствующие ожидаемому воздействию. Выбрав три или четыре значимых способа воздействия на этот сезон, мы получаем первый список из десятка функциональностей (на моей практике, в диапазоне от 7 до 15).
Рисунок 15.6 – Карта воздействия, включающая функциональности
Степень детализации функциональностей на данном этапе не сильно важна. Главное – составить этот первый список.
Функциональности помещаются на impact map в зависимости от своего воздействия.
Другим способом
Impact map размещает функциональности по отношению к их воздействию. Это помогает идентифицировать их и не начинать со списка покупок (функциональностей), которые могут не соответствовать цели.
Но можно получить список функциональностей и без анализа их воздействия.
Каким бы ни был путь, впоследствии нужно их упорядочить и рассортировать в бэклоге, а также разбить на части для рабочего бэклога. Инструмент, который поможет, – это story mapping.
• Упорядочить функциональности
На что обращать внимание при упорядочении функциональностей в бэклоге поставки?
Исходя из критериев
Без карты системы, которая бы показывала упорядоченные взаимосвязи между элементами, классическим способом считается использование критериев.
Чтобы расставить приоритеты между функциональностями, можно использовать те же критерии, что и для историй (бизнес-ценность и ценность знаний, размер, зависимости).
Основываясь на этих критериях, модели могут быть использованы для упорядочения функциональностей:
– БСЦ2: Бизнес-ценность + Сокращение рисков + Ценность знаний / Цена
– Цена задержек, поделенная на время
Нужно всегда принимать во внимание зависимости и восприятие ценности. Коллективное обсуждение этого вопроса очень важно во время сессии доработки функциональностей.
Тем не менее, чрезвычайно сложно провести оценку бизнес-ценности или ценности знаний функциональности (см. главу 18 «Наглядность при помощи индикаторов»).
Исходя из воздействия
Приоритеты, определенные для воздействия, влияют на приоритеты для функциональностей.
И поскольку эти приоритеты основаны на измеримых целях, мы избегаем субъективной оценки концепции ценности для функциональностей. Наличие цели, выполнение которой можно проверить, помогает объективно взглянуть на ситуацию.
Построение «позвоночника»
Первым шагом в технике story mapping является создание позвоночника на первой строке. Функциональности перечисляются в хронологическом порядке, чтобы определить логическую последовательность (цепочку создания ценности) в соответствии с использованием продукта заинтересованными лицами. Это ось последовательности, которая служит для напоминания use cases.
Не нужно тратить слишком много времени на обсуждение порядка в последовательности. Цель состоит в том, чтобы получить первую цепочку функциональностей, сосредоточив внимание на тех, что способствуют достижению цели сезона.
Помимо приоритизации на основе воздействия, story mapping учитывает также зависимости и риски.
• Разделение функциональностей на истории
Затем наиболее приоритетная функциональность разбивается на истории, каждая из которых помещается на Post-it®. Функциональность может насчитывать с десяток историй. Они располагаются в несколько рядов: верхние ряды – для самых необходимых историй. Вопрос о необходимости ставится перед Владельцем продукта: тебе действительно нужна эта история для достижения цели? Если ответ да, она остается на верхних рядах. Если нет, уходит ниже.
Таким же образом нужно рассмотреть все последующие функциональности. Если команда большая, я рекомендую паттерн роение, чтобы разделение на истории шло параллельно. Например, если скелет состоит из восьми функциональностей, а команда – из восьми человек, можно объединиться по парам, чтобы каждая группа взяла по две функциональности в работу. В данном случае стоит разделить задачи внутри команды.
Цель состоит в том, чтобы получить из историй и функциональностей, расположенных на первых рядах, минимальный набор, который позволил бы заинтересованным сторонам использовать продукт.
• Добавить риски
Участники команды помечают истории, которые, как им кажется, несут определенные риски (технические и др.).
Они добавляют Post-it® другого цвета на карту рядом с соответствующими историями. Чтобы минимизировать указанный риск, можно создать новую историю.
Истории, чья цель в сокращении рисков, обычно имеют высокий приоритет. Если так, они помещаются в самый верх карты.
На одной такой встрече команда может определить двадцать-тридцать историй и внести их в бэклог.
Порядок, определенный при story mapping, сохраняется для историй, которые пойдут непосредственно в доработку. Функциональности возвращаются в kanban-таблицу. Участникам нужно распределить их на те, что служат цели сезона, и остальные.
Рисунок 15.7 – Наполнение бэклога
Story mapping позволяет сократить работу над продуктом в двух направлениях:
✓ убирая ненужные функциональности,
✓ убирая ненужные истории среди оставшихся.
Преимущество этого подхода – в быстром получении первоначального бэклога, который учитывает зависимости и риски вкупе с влиянием на бизнес.
• Первая доработка
Первая доработка проходит ближе к концу прелюдии. Вероятно, в первый раз это займет больше времени, чем в последующие разы. Одна из причин: к этому моменту еще непонятно, сколько историй команда может завершить за один спринт.
Как только функциональности определены и упорядочены, действия по доработке, представленные в главе 7, применяются, как правило, в следующей последовательности: наполнить лоток доработки, упорядочить, разбить на истории, оценить и, наконец, переместить истории в колонку готово.
• Появление минимальной функциональности
После определения историй, соответствующих функцинальности, наступает момент их доработки, разделения на части и упорядочения.
Пример Peetic. Команда хочет предложить пользователям возможность онлайн-коучинга от заводчиков.
Участники команды думают, что первый урок можно сделать бесплатным.
Команда определяет следующие истории: клиент запрашивает бесплатное занятие, заводчик проводит его, клиент покупает еще десять занятий, заводчик регулирует запросы.
Владелец продукта считает, что сначала нужно запустить бесплатный сервис для привлечения людей. В первом сезоне есть две истории, соответствующие его пожеланию: запросить бесплатный урок и провести его. Это минимально пригодная для использования функциональность. Другие истории могут подождать до следующего сезона (в ледяном лотке).
Рисунок 15.8 – Разделение функциональности (1) на истории (2) и группирование в минимальную фнкциональность (3).
С одной стороны, команда получает функциональность бесплатный коучинг, которая будет завершена в текущем сезоне, с другой стороны – функциональность платный коучинг, которая станет предметом следующего сезона.
При этом следует убедиться, что ожидаемое воздействие сохраняется.
Это разделение на части может проводиться во время story mapping.
• Разработка, направляемая гипотезами
Цель этого паттерна – в сокращении функциональных рисков. При этом обеспечивается ценность функциональности путем экспериментирования с пользователями.
Мы предполагаем, что <эта функциональность>
Окажет <это воздействие>
Мы убедимся, когда увидим <этот измеряемый сигнал>
Пример Peetic. Мы полагаем, что возможность размещения онлайн-анкет владельцами собак с предложением присмотреть за питомцем
Создаст наплыв предложений о присмотре
Мы убедимся в этом, когда увидим прирост подписок на Peetic в 10 %.
Наша модель состоит из трех уровней: история, функциональность, воздействие. Продукт представлен на трех уровнях элементов. Вот краткий обзор основных пользователей для каждого из трех уровней и способы их оценки.
Таблица 15.1
Пример на трех уровнях:
✓ История: как владелец бассет-хаунда, я могу задать вопрос эксперту.
✓ Функциональность: коучинг породистых собак онлайн.
✓ Воздействие: 10 % прибыль благодаря подписавшимся на новую услугу.
15.5 Нефункциональные требования
В первом издании этой книги я написал параграф о нефункциональных требованиях, который впоследствии, не встретив отклика читателей, удалил.
Ситуация изменилась. Аспекты безопасности и производительности, ранее ассоциировавшиеся разве что с бортовыми системами, сегодня приобретают все большее значение во всех областях.
Создание бэклога – подходящий момент, чтобы задаться вопросом на эту тему.
Техника пользовательские истории позволяет выявить функциональные требования, но для программного продукта есть и другие требования – нефункциональные, технические. Это могут быть: