На прошедшей недавно конференции Agile Base Camp Value Driven Development я затронул тему Agile требований.

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

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

Для начала стоит помнить, что «работа с требованиями в стиле Agile – это совместные сессии между Бизнесом и ИТ», ведь мы говорим про Agile Collaboration, а не про бюрократию и долгую и болезненную передачу информации от бизнес-представителей к команде разработки. Только работая совместно, можно добиться большего, и, по моему мнению, командам разработки проще выучить язык бизнеса, чем наоборот :-).

Чтобы упростить и ускорить общение, нужны простые инструменты, нужна наглядность того к чему мы идем и где мы находимся и правильное использование самого подхода «Последний Ответственный Момент» (Last Responsible Moment).

В докладе я объяснил такие инструменты контекста как:

• Видение Продукта
• Персоны
• Возможные другие способы добавления информации о бизнес-домене

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

• физические карточки (post-it) – они хорошо помогают при дискуссиях и совместных сессиях
• Все возможные карты: карты историй (story map), карты влияния (Impact map)
• Легковесные прототипы – рисованные от руки или с помощью простых инструментов

Только получив контекст и поняв, о чем же мы говорим, сами требования можно описывать в простых форматах типа Историй Пользователя (User Story) или Вариантов Использования (Use Case). Зачастую, как раз эти простые форматы и не работают из-за того, что не хватает контекста – это, на моем опыте, является большой проблемой для команд, которые  узнали только про формат Историй и решили его использовать. Ну и, конечно, детали можно добавлять на разных уровнях по мере необходимости.

Вот сами слайды со звуком, для тех, кто хочет знать больше.

[slideshare id=16348272&doc=random-130204151348-phpapp02]

Оставайтесь с нами, будут еще статьи про процессы, команды, саморазвитие и другие темы.