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

Я хочу рассказать о еще одном способе контроля за результатами проекта и качеством создаваемого продукта, который в полной мере реализуется в системе управления проектами DEVPROM. Для краткости назову этот метод "Управление проектом через артефакты".

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

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

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

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

С точки зрения идентификации рисков, связанных с успешным выпуском очередного релиза продукта, трассировка позволяет увидеть много "подводных камней" текущего релиза:

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

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

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

• Как просто оценить историю или задачу
• Планирование на перспективу в Agile
• Планирование релиза и итераций в Agile
• Планирование в Agile - общее видение
• А как вы планируете релизы?