Не думаю, что когда-либо буду собирать требования по проекту или планировать релизы ПО каким-нибудь другим способом. Всякий раз, как я упоминаю «сбор требований», профессионалы IT представляют себе перспективу написания доисторического документа в Word. За долгие годы IT-индустрия была завалена всевозможными шаблонами требований и документами в Word. Подписание технического задания было сопряжено со всевозможными тревогами: все ли требования идеально изложены, согласованы с бизнесом, а впоследствии реализованы? А что будет, если требования изменятся? Ох, батюшки… Надо бы завести себе контроль изменений и список согласований!

Заглянем в реальность

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

• группы задач (желтые карточки)
• главные задачи (голубые карточки)
• подчиненные функции (оранжевые карточки).

Я обнаружил, что очень полезно комбинировать пользовательские истории с картами историй для управления требованиями и планирования релизов ПО. Вот 5 преимуществ, которые карты историй принесут вашему следующему проекту.

1. Реализуем первым то, что действительно важно

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

2. Дробим большие требования на маленькие куски

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

3. Откладываем менее важное на другой релиз

Поскольку требования определяются малыми порциями, становится легче отложить менее важные на будущие релизы. Выделяя самые важные требования и откладывая менее важные на потом, команда может намного успешнее реализовывать продукт, отвечающий нуждам заказчика, нежели выпуская частичный продукт, напичканный «бантиками». Если же финансирование проекта внезапно урежут или отменят, то у конечного пользователя останется бонус в виде рабочего ПО, разработанного по приоритезированным требованиям. В том же примере с почтовой системой, если финансирование прикроют, и я не смогу выпустить релиз С, то у меня все равно останется рабочий продукт. Это было бы довольно сложно осуществить при традиционном каскадном управлении проектом. В процессе на основе карты историй куда проще выделить приоритеты, чем в традиционном графике проекта.

4. Улучшаем коммуникацию с заказчиком

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

5. Визуализируем сценарий разработки продукта или системы

Если вы передали мне 100-страничное техзадание и попросили его утвердить, какова вероятность успеха? Где-то странице к десятой я начну читать по диагонали и, скорее всего, пропущу важное требование, за что понесу ответ на стадии разработки. Этот подход вообще не имеет смысла, потому что в текстовом виде трудно соотнести требования с системой. С картой историй, однако, фокус уменьшается, и заказчик может визуально понять, какие требования войдут в первый релиз, какие - во второй и последующие. Фокусируясь на релизах, заказчик может уделить больше внимания соответствующим требованиям. В примере с почтой во время релиза А заказчик может сосредоточиться на высокоприоритетных особенностях, которые войдут в начальный релиз.

Как только эти требования реализованы в виде работающего ПО, заказчик и команда проекта могут лучше понять, как улучшить сценарий продукта или системы. После этого функции с меньшим приоритетом могут быть пересмотрены и передвинуты на более ранние релизы, поскольку с каждым релизом у команды все лучше понимание, как что должно работать. Попробуйте сделать такое с документом в Word!

Об авторе: Доктор Эндрю Макар - руководитель IT-проектов и автор книги «Легкий способ пройти интервью на руоводителя проекта (Project Management Interview Questions Made Easy)».

Источник: http://www.liquidplanner.com/blog/5-reas[...]to-use-story-maps-for-your-next-project/

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• Оценка трудоемкости при планировании релиза в Agile
• Подгруппы Agile раскрывают потенциал команды