Промежуточные версии для внутреннего пользования

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

Внутренние версии создаются в течение всей стадии «Разработка». Каждый следующий выпуск должен расширять функциональные возможности предыдущего, как показано на рис. 3. Это способ позволяет рассматривать отдельные выпуски как независимые продукты, ориентируя группу на достижение поставленных целей. Анализ промежуточных выпусков — обязательный элемент самообучения проектной группы, позволяющий ей расширять арсенал удачных решений и избегать повторения ошибок.

Рис.3. Внутренние версии продукта

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

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

Промежуточные версии для внешнего пользования

Рекомендуется на стадии «Разработка» создавать и промежуточные версии для внешнего пользования. Они помогают синхронизировать процесс кодирования и усилия разных подгрупп. Кроме того, их появление демонстрирует заказчику, пользователям и другим участникам проекта, что работа движется к поставленной цели.

Как правило, альфа-выпуск (или выпуски) продукта не содержат всех функциональных возможностей. Его цель в другом — отработать выпуск продукта и проверку других материалов, которые должны быть подготовлены на стадии «Разработка» (например, справочные и учебные материалы).

Бета-версия по своим функциональным возможностям очень близка к окончательному варианту продукта, однако, как правило, не оптимизирована.

Пересмотренные функциональные спецификации

Функциональные спецификации считаются основным результатом фазы «Планирование» и являются основой стадии «Разработка». Это своего рода компас, определяющий направление разработки проекта. Продолжая метафору, скажем, что проектная группа не может «точно проложить курс» до самого пункта назначения, однако функциональные спецификации служат ей ориентиром. Промежуточные этапы фазы «Разработка» — те инструменты, которые помогут вам воплотить функциональные спецификации в жизнь.

Анализ и пересмотр функциональных спецификаций

Пересмотренные функциональные спецификации не обязательно должны быть полностью взаимосвязаны с промежуточными этапами фазы «Разработка». Тем не менее, в них необходимо отразить все различия между проектом приложения, описанным в исходных спецификациях, и состоянием продукта на этапе «Завершение разработки».

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

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

Табл. 1. Причина пересмотра функциональных спецификаций

Роль	Причина
Заказчик	Функциональные возможности промежуточной версии продукта не соответствуют бизнес-целям
Менеджер продукта	Несоответствие продукта существующим требованиям; в этом случае менеджер продукта должен настоять на пересмотре функциональных спецификаций, чтобы привести в соответствие требования и готовый продукт
Менеджер программы	Невозможно выполнить обязательства в установленные сроки
Разработчик	Невозможно реализовать функциональные возможности, зафиксированные в спецификациях; возникновение новых факторов риска, препятствующих реализации; несоответствие трафика разработки поставленным задачам
Тестер	Невозможно выполнить тестирование всех функциональных возможностей в полном объеме. На стадии «Разработка» группа тестирования должна руководствоваться графиком труппы разработки и, в частности, датами промежуточных выпусков — тестировать можно лишь то, что уже готово.
Инструктор	Несоответствие функциональных возможностей альфа- и бета-версий нуждам пользователей (наличие ошибок при этом не считается решающим фактором)
Логистик	Невозможно развернуть альфа- и бета-версии; по мере выпуска последующих версий труппа логистики должна внести в функциональные спецификации поправки, гарантирующие гладкое развертывание продукта