Требования в гибких проектах · Конспекты по бизнес-анализу

Главные идеи#

Чем отличаются такие проекты#

Вигерс и Битти противопоставляют два подхода. Прогнозный (каскадный) подход снижает риски за счёт основательного планирования до начала разработки и работает, когда требования ясны и стабильны. Адаптивный (гибкий) подход исходит из того, что изменения неизбежны, и планирует короткими циклами. Авторы отмечают, что ещё в исходной статье Ройса 1970 года о каскадной модели строгий однократный проход назван рискованным и рекомендована итеративность. Их главный тезис: «гибких требований» не бывает, есть лишь смещение акцентов: - Участие заказчика продолжается весь проект, а не только в начале. - Документация — это минимум, который даёт разработчикам и тестировщикам точные ориентиры; всё сверх него — потери. - Сроки: высокоуровневые истории наполняют бэклог рано; детали добавляют непосредственно перед тем, как история попадает в итерацию, в небольшом цикле выявления, анализа, спецификации и валидации. - Изменений ждут, а не сопротивляются им.

Один бэклог#

Ссылаясь на Майка Кона, авторы советуют вести один бэклог (backlog) на проект, в котором лежат и истории, и дефекты: если списков несколько, приоритеты нельзя сравнить. Приоритеты в бэклоге никогда не фиксируются окончательно.

Атрибуты качества — с самого начала#

Производительность, доступность и другие атрибуты качества определяют архитектуру. Ждать «их» итерации, как с обычной функциональностью, нельзя; выявляйте их заранее.

Историям нужен редактор#

Истории, которые пишут люди без опыта анализа, в том числе сами заказчики, часто неточны. Кто-то с навыками бизнес-анализа должен доработать их до реализации.

Эпики, функции и истории#

Пользовательская история (user story): по размеру помещается в одну итерацию.
Эпик (epic): авторы приписывают этот термин Майку Кону; это история, слишком большая для одной итерации. Разбейте её на истории поменьше, при необходимости через эпики поменьше.
Функция (feature): набор возможностей, ценный для пользователей; может охватывать одну историю, несколько историй или несколько эпиков.

Минимальная продаваемая функциональность (minimum marketable feature, MMF) — понятие, которое ввели Денн и Клеланд-Хуанг (Denne, Cleland-Huang), — это наименьший набор историй, который команда может поставить разом и который всё ещё даёт заказчику реальную ценность. Не зацикливайтесь на ярлыках: важнее качество требований.

Ждите изменений, но смотрите вперёд#

Рефлекс бизнес-аналитика меняется с «это за границами проекта» на «давайте обсудим». Ожидать изменений не значит игнорировать будущее: взгляд вперёд позволяет команде выбрать более расширяемую архитектуру, не проектируя под каждый гипотетический случай. Удалять элементы из бэклога тоже нормально — из-за проблем с реализацией, находок владельца продукта или тестировщиков или более ценной работы.

Без пуризма#

Авторы описывают организацию, где попытка внедрить agile «по учебнику» везде и сразу провалилась. Одна команда остановилась на гибриде (бэклог, трёхнедельные итерации, детальные требования на каждую итерацию), и большинство гибких практик прижилось только после того, как их перестали навязывать. Совет авторов: выбирайте практики под свой контекст, начинайте с пилотного проекта и на первые несколько итераций пригласите опытного коуча.

Как применять#

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

Пример#

В «Мастерской», вымышленной сети веломастерских, бэклог начинается с эпика «Онлайн-запись». Аналитик разбивает его на истории, например «Как клиент, я хочу видеть свободное время в ближайшей мастерской, чтобы выбрать удобное» и «Как сотрудник стойки приёма, я хочу видеть сегодняшние онлайн-записи, чтобы планировать приём велосипедов». Функция «Обновления статуса ремонта» охватывает истории для механиков (установить статус) и для клиентов (получить SMS). Первая MMF — запись в одну пилотную мастерскую с подтверждением по электронной почте. Перед итерацией 1 команда согласует атрибут качества, который определит архитектуру: календарь записи должен быстро откликаться в субботний утренний пик.

Подводные камни#

«Agile — значит без документации» → пишите минимум, который позволяет разработчикам и тестировщикам работать точно.
Истории принимают ровно в том виде, как их написали заинтересованные стороны → сначала доработайте их.
Отдельные бэклоги для функций и дефектов → один список, один набор приоритетов.
Производительность и безопасность откладывают на потом → выявляйте их до того, как определена архитектура.

Чек-лист#

В одном бэклоге лежат истории, дефекты и другая работа.
Ключевые атрибуты качества известны до архитектурных решений.
Аналитик дорабатывает каждую историю, прежде чем она попадёт в итерацию.
Эпики разбиты до планирования итерации.
Первый релиз поставляет минимальную продаваемую функциональность.
Приоритеты пересматривают в каждой итерации.
Изменения общих границ, бюджета или сроков решают за пределами команды.

Источники и что почитать#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 20 (включая ссылки авторов на Ройса, Кона, Денна и Клеланд-Хуанг).