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

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

В период развития продукта мы имеем дело с реализацией новых требований. Данная стадия содержит специфику как конструирования, так и поддержки. Вероятно, подход в управлении продуктом на данной стадии должен иметь объединяющее название, например, Скрамбан (Scrumban).

Ключевые особенности Scrumban:

• Некоторые этапы процесса могут предшествовать разработке продукта, а значит – нет необходимости в кросс-функциональности команды. В случае неоперативного исполнения роли владельца продукта, вам потребуется дополнительная стадия «уточнение истории». Во время данной стадии будут разработаны макеты UI, уточнены истории и, возможно, подготовлены технические требования и UML-модели.
• Согласование сроков завершения спринта отсутствует, в связи с неизвестностью объемов незапланированной работы. Не сложно догадаться – срок поставки инкрементов продукта может изменяться.
• Понимание реальных возможностей команды, исключение неоправданных ожиданий, обнаружение узких мест процесса разработки: все это позволяет увидеть ограничение незавершенной работы (Work In Progress Limit).
• Вытягивающая модель работы даёт возможность балансировать нагрузку в условиях незапланированной работы.

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

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

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

• Учимся подбирать методологию к проекту
• Ставим процесс внедрения типовых решений
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Постоянные улучшения и ретроспективы в Agile
• Как часто должно меняться ограничение количества незавершенной работы в Kanban?