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

Пример Peetic. Команда хочет предложить пользователям возможность онлайн-коучинга от заводчиков.

Участники команды думают, что первый урок можно сделать бесплатным.

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

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

Рисунок 15.8 – Разделение функциональности (1) на истории (2) и группирование в минимальную фнкциональность (3).

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

При этом следует убедиться, что ожидаемое воздействие сохраняется.

Это разделение на части может проводиться во время story mapping.

• Разработка, направляемая гипотезами

Цель этого паттерна – в сокращении функциональных рисков. При этом обеспечивается ценность функциональности путем экспериментирования с пользователями.

Мы предполагаем, что <эта функциональность>

Окажет <это воздействие>

Мы убедимся, когда увидим <этот измеряемый сигнал>

Пример Peetic. Мы полагаем, что возможность размещения онлайн-анкет владельцами собак с предложением присмотреть за питомцем

Создаст наплыв предложений о присмотре

Мы убедимся в этом, когда увидим прирост подписок на Peetic в 10 %.

15.4.6 Структура рабочих элементов

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

Таблица 15.1

Пример на трех уровнях:

✓ История: как владелец бассет-хаунда, я могу задать вопрос эксперту.

✓ Функциональность: коучинг породистых собак онлайн.

✓ Воздействие: 10 % прибыль благодаря подписавшимся на новую услугу.

15.5 Нефункциональные требования

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

Ситуация изменилась. Аспекты безопасности и производительности, ранее ассоциировавшиеся разве что с бортовыми системами, сегодня приобретают все большее значение во всех областях.

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

15.5.1 Что это?

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

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

✓ качество развития: ремонтопригодность, портативность,

✓ ограничения проектирования, развертывания, соответствие стандартам.

В зависимости от этого меняется и влияние на элементы Scrum.

Если нефункциональное требование оказывает сильное влияние на продукт, его можно использовать для контекстуализации Scrum (см. главу 14).

Примеры: ограничения – такие, как соответствие стандартам в данной области (например, DO178B для аэронавтики), или выбор программного пакета, или тип лицензии.

15.5.2 Поместить их в бэклог

Бэклог содержит все, что требует работа команды: как функциональные, так и нефункциональные требования.

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

✓ реализовать за один спринт, следуя определению завершенности,

✓ протестировать.

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