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

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

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

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

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

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

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

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

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

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