Процессы разработки требований

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

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

Пользовательские истории и Scrum

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

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

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

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

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

Scrumban и разработка требований

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

1. Перед планированием спринта команде выделяется дополнительное время на проработку UX, дизайна и архитектуры. В результате этой работы для каждой истории создавайте системные требования, с использованием языка UML, макетов форм и вариантов использования.

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

3. Ограничения незавершенной работы (WIP) позволяют видеть реальные возможности команды, обнаруживать узкие места и улучшать процесс разработки.

Разработка по требованиям в Kanban

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

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

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

3. Передавайте требования в разработку целиком или частями, создавая на их основе доработки. Используйте бейзлайны и версии, чтобы разработчикам и тестировщикам было проще увидеть изменения в требованиях по сравнению с предыдущим вариантом.

4. Контролируйте качество и полноту реализации системных требований, покрытие тестовой и эксплуатационной документацией, при помощи матриц трассировок.

Поделитесь вашим процессом разработки требований с сообществом профессионалов ALM и улучшите ваш процесс с использованием идей единомышленников.


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