Любой программный продукт не создается мгновенно, во внешний мир выпускается несколько версий продукта, а в процессе разработки команда создает несколько промежуточных версий продукта, которые проходят все необходимые этапы тестирования, стабилизации, приемки и т.п. Версия является своеобразной метрикой для измерения функциональности, реализованной в продукте к моменту выхода данной версии.
Мы часто слышим подобные вопросы:
- Когда выйдет очередная версия с такой-то функциональностью?
- В какой версии исправлены такие-то ошибки?
- Какую версию продукта использовать для тестирования очередного релиза?
- Какой версией продукта вы пользуетесь? Какая версия установлена у заказчика?
И это только малая часть вопросов, ссылающихся на определенную версию продукта. Однако, где здесь слова релиз, итерация и сборка, которыми оперирует команда в процессе планирования, реализации и тестирования функциональности? Очевидно, нужен некоторый способ связать временные отрезки процесса разработки и нумерацию версий реализуемого продукта.
Вот несколько подходов к связыванию этапов разработки и нумерации версий продукта:
- Процесс сам по себе, номера версий сами по себе. Этот вариант чаще используется в "водопадных" проектах, когда всех участников интересует только финальный вариант продукта, которому присваивается некоторый номер. При использовании этого варианта в итерационной разработке образуется жуткая неразбериха, поскольку нет связи между планами и результатами работ. Сведения о том, какой функционал реализован в той или иной версии, хранятся только в головах разработчиков и быстро устаревают, особенно, когда начинают работать тестировщики.
- Задание номеров версий и сборок в качестве атрибутов пожеланий и дефектов. Это классический вариант, реализованный в существующих баг-трекерах. На этапе планирования состава очередной версии вы указываете к какой версии будет принадлежать некоторое пожелание, а при его исправлении - в какой сборке оно реализовано. Недостаток такого подхода заключается в отсутствии связи с планом работ, то есть релизами и итерациями (спринтами), в рамках которых будут реализованы пожелания, у команды нет возможности связать номер версии с датами этапов разработки.
Оба описанных подхода обязуют проектную команду изобретать нумерацию версий, чего не скажешь о DEVPROM, где управление версиями продукта неразрывно связано с процессом разработки: на основании нумерации релизов, итераций и сборок автоматически формируется номер версии продукта. Таким образом, проектная команда, заказчик или пользователи общаются на одном языке номеров версий и этапов разработки.
|
| | img2 | | | | При сообщении об ошибке можно указать номер версии, в которой она обнаружена с детализацией на уровне релиза, итерации или сборки. Вы всегда можете получить список пожеланий заведенных в версии или исправленных в версии | | | img3 | | | | Участники проекта могут фильтровать пожелания, задачи, результаты тестирования и другие артефакты на основании интересующей их версии продукта. |
При необходимости вы можете настроить правила соответствия номеров версий этапам разработки в настройках проекта, например, чтобы исключить номер итерации из полного номера версии. |
