Связь версий продукта с этапами разработки

30.03.2010 15:18

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

 

Мы часто слышим подобные вопросы:

  • Когда выйдет очередная версия с такой-то функциональностью?
  • В какой версии исправлены такие-то ошибки?
  • Какую версию продукта использовать для тестирования очередного релиза?
  • Какой версией продукта вы пользуетесь? Какая версия установлена у заказчика?

 

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

 

Вот несколько подходов к связыванию этапов разработки и нумерации версий продукта:

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

 

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

 

img1 На закладке "Релизы" осуществляется управление версиями и этапами разработки продукта. Команда и заказчик видят план выпуска версий продукта и сроки разработки каждой версии. Устаревшие или "плохие" версии (например, сборки, в которых не прошли автоматические тесты) можно переносить в архив, чтобы они не мешались в списках версий продукта.

img2

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

img3

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

 

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

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