Пользовательские истории. Искусство гибкой разработки ПО

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

С чего все началось?

Устоявшийся подход к письменным спецификациям не стали отменять в одночасье. Концепцию написания требований на обратной стороне карточки внедрить было нелегко. Как Никола могла ожидать, что разработчики и тестировщики внедрят необходимую функциональность, за которую она несла ответственность, если у них нет необходимой информации? Фокус просто переместился на создание последовательностей действий пользователя, почти ничем не отличающихся от традиционных функциональных требований, за исключением размера; схема коммуникации не изменилась.

Чтобы передать требования команде на сессиях разработки, Никола:

• собирала требования партнеров по бизнесу;

• глубоко анализировала требования и данные;

• создавала последовательности действий пользователя (каждая занимала от одной до пяти страниц), где описывались требования, дизайн решения и критерии приемки;

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

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

После одной из сессий Сэм, эксперт в предметной области, одновременно играющий роль владельца продукта, заметил: «Если это и есть проект Agile, я не желаю в этом участвовать!»

Нужно было что-то делать.

Что поменялось?

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

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