Devprom ALM: Руководство пользователя

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

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

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

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

Управление проектом на стадии поиска и создания продукта осуществляется на основе Scrum.

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

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

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

Пользовательские требования будущего релиза управляются процессом на основе Scrum. Здесь, как и в процессе "Поиск и создание продукта", осуществляется планирование спринтов, декомпозиция требований на задачи, демонстрация и приемка реализованной функциональности. Из-за того, что часть усилий команды будет оттягивать текущий релиз, требования к срокам (или составу) спринтов смягчаются.

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

В этом процессе нет спринтов (итераций) и отсутствует пакетная реализация. При использовании современых технологических решений, выпуск новых версий, обновлений или патчей, может осуществляться буквально под каждое пользовательское требование (подробнее об этом можно узнать в подходе Continuous Delivery).

Доска историй (или пожеланий) отражает всю технологическую цепочку. Каждый статус (столбец на доске) соответствует одному из этапов технологии разработки: анализу, проектированию, разработке, тестированию и т.п. За каждым этапом закреплен один или несколько членов команды. Каждое пользовательское требование последовательно проходит все этапы, начиная от анализа и заканчивая документированием. Это напоминает традиционный водопадный процесс, с тем отличием, что скоуп каждого этапа сокращен до одного пользовательского требования.

С точки зрения управления проектом, в данном процессе используется подход Software Kanban. Это простой процесс из бережливого производства (Lean Management). Есть суть заключается в следующем:

• визуализируем все этапы производства;
• фиксируем число задач (пользовательских требованиий), которые могут находиться одновременно на одной стадии;
• улучшаем процесс для того, чтобы на каждом этапе не выстраивались очереди, измеряем метрики и опять улучшаем процесс.

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