Это семейство процессов характеризуется тем, что все участники работают с первичными требованиями, поступившими непосредственно от пользователей продукта, заказчика или его представителей. Такие требования могут быть сформулированы в формате заявки, хотелки, пользовательской истории или еще каким-то способом, удобным для пользователя.
Системные требования, такие как информационные модели, модели данных, поведенческие диаграммы, макеты пользовательского интерфейса и т.п., являются второстепенными и уточняют первичные требования. Одновременно с этим, системные требования позволяют накапливать знания о внутреннем устройстве продукта, что крайне полезно при обновлении коллектива, а также при анализе влияния потенциальных изменений.
При создании нового продукта на первый план выходит выявление и уточнение требований, которые в такой ситуации обычно неполны, неточны и могут часто меняться. Нет более лучшего способа уточнения требований, чем работа с прототипом (или работающим продуктом, хоть и с минимальной функциональностью). Таким образом, частая поставка промежуточного продукта - основная цель в этом случае.
Для достижения этой цели участники проекта сокращают лишние расходы на производство документации, которая устаревает очень быстро. А также используют короткие итерации длительностью одну или две недели. В течение итерации реализуют несколько наиболее важных пользовательских требований. Проектирование, программирование, тестирование и все остальные технологические этапы производства осуществляются внутри итерации. В конце итерации получается готовая к использованию промежуточная версия продукта, которая передается пользователям для сбора обратной связи.
Управление проектом на стадии поиска и создания продукта осуществляется на основе Scrum.
| Плюсы |
Поскольку трбования меняются часто, мы не тратим силы на документацию, которую придется выбросить уже на следующей итерации. Пользователи получают работающий продукт часто (в конце итерации) и могут применять его в работе, формируя новые и уточняя текущие требования, с целью создания правильного продукта. |
| Минусы |
Из-за меняющихся требований приходится переделывать то, что было реализовано на предыдущих итерациях - это потеря времени. Поскольку требования до конца не понятны, то высоки технические риски. Есть опасность заложить неверную архитектуру и дизайн, которые затем придется переделывать. В условиях постоянно меняющихся требований нет возможности заранее договориться о четком бюджете на проект. |
| Требования |
Необходимы условия для обильной коммуникации пользователей (представителя) и членов команды. Поскольку нет четких формализованных требований, уровень профессионализма команды должен быть высоким, чтобы быстро принимать серьезные технические решения и реализовывать качественный продукт со слов пользователя. |
Когда продуктом уже пользуются, то становится неприемлемо ждать целых две недели (длительность одной итерации), ради исправления ошибки или реализации мелкой (но важной) доработки. С другой стороны, появляются новые требования (фичи), реализация которых занимает продолжительное время. На этой стадии жизненного цикла продукта необходим процесс, который будет позволять планомерно реализовывать новые фичи (как при поиске продукта) и, одновременно, решать срочные запросы от пользователей.
Бэклог продукта делится на две части: бэклог текущего релиза и бэклог будущего релиза. На стадии уточнения пользовательских требований мы решаем, в какой из бэклогов поместить требование. Срочные и простые запросы идут в текущий релиз. Сложные запросы идут в будущий релиз. На стадии уточнения можно дополнить пользовательские требования важными техническими решениями, например, макетами пользовательского интерфейса, моделями данных и другими системными требованиями, чтобы на этапе разработки этим уже не заниматься.
Пользовательские требования для текущего релиза управляются процессом на основе Kanban. Ключевая метрика здесь скорость исправления ошибки или реализации несложной доработки. Как правило, это небольшие изменения и их можно реализовать по упрощенному процессу, например, без привлечения всех участников проектной команды.
Пользовательские требования будущего релиза управляются процессом на основе Scrum. Здесь, как и в процессе "Поиск и создание продукта", осуществляется планирование спринтов, декомпозиция требований на задачи, демонстрация и приемка реализованной функциональности. Из-за того, что часть усилий команды будет оттягивать текущий релиз, требования к срокам (или составу) спринтов смягчаются.
| Плюсы |
Те же, что у процесса "Поиск и создание продукта" Есть выделенная стадия уточнения историй, которая позволяет подготовить часть системных требований заранее, до начала планирования и декомпозиции пользовательских требований на задачи. Ошибки и мелкие доработки решаются значительно быстрее, чем частота выпуск фичей. |
| Минусы |
Те же, что у процесса "Поиск и создание продукта" Поскольку часть усилий команды уходит на сопровождение, то могут сорваться сроки спринтов или уменьшен объем функциональности. В условиях постоянно меняющихся требований нет возможности заранее договориться о четком бюджете на проект. |
| Требования |
Необходимы условия для обильной коммуникации пользователей (представителя) и членов команды. Упрощенный процесс реализации ошибок и мелких доработок (текущий релиз) требует от исполнителей большей квалификации и кросс-функциональности, чтобы не ухудшить качество продукта. |
Стадия сопровождения - финальная стадия жизненного цикла продукта, на которой команда исправляет дефекты и реализует небольшие доработки. Поскольку программная система используется заказчиком или пользователями, то критичной становится именно скорость исправления дефектов и реализации мелких но важных доработок, мешающих качественному решению пользовательских задач.
В этом процессе нет спринтов (итераций) и отсутствует пакетная реализация. При использовании современных технологических решений, выпуск новых версий, обновлений или патчей, может осуществляться буквально под каждое пользовательское требование (подробнее об этом можно узнать в подходе Continuous Delivery).
Доска историй (или пожеланий) отражает всю технологическую цепочку. Каждый статус (столбец на доске) соответствует одному из этапов технологии разработки: анализу, проектированию, разработке, тестированию и т.п. За каждым этапом закреплен один или несколько членов команды. Каждое пользовательское требование последовательно проходит все этапы, начиная от анализа и заканчивая документированием. Это напоминает традиционный водопадный процесс, с тем отличием, что скоуп каждого этапа сокращен до одного пользовательского требования.
С точки зрения управления проектом, в данном процессе используется подход Software Kanban. Это простой процесс из бережливого производства (Lean Management). Есть суть заключается в следующем:
Эти несколько принципов позволяют максимизировать скорость реализации пользовательских требований, что и ожидается заказчиком на данной стадии жизненного цикла продукта.
| Плюсы |
Пользовательские требования реализуются гораздо быстрее, из-за того, что выпуск очередного обновления не блокируется реализацией всех нужных доработок. Поскольку скорость решения запросов примерно одинакова (или может быть сегментирована по классам задач: срочные, доработки, ошибки), можно эффективно оценивать сроки и стоимость оставшегося объема работ. |
| Минусы |
Сложные задачи могут блокировать реализацию более простых, но не менее важных задач. Увеличение хвоста очереди приводит к задержкам при выпуске обновлений. |
| Требования |
Необходимы условия для обильной коммуникации пользователей (представителя) и членов команды, чтобы сократить число возвратов задач на предыдущие стадии. Задачи не должны сильно различаться в размере. Если это происходит, скорее всего вы имеете дело со стадией "Развитие продукта" и процесс нужно менять. |