PMsoop: Глава №29: Сдача финальной версии

В ролях – Менеджер Проекта, команда проекта, Заказчик

Артефакты – все

Суть – Готовимся и сдаём финальную версию проекта

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

1. Регрессионное тестирование – для финальной версии является обязательным. Даже если вы не «забивали» на него при сдаче всех промежуточных версий. Причина – в финальной версии весьма желательно исправить _все_ известные дефекты приложения. Обнаружение уже известного ранее дефекта после сдачи финальной версии может сильно испортить отношения с Заказчиком. Так что, уделяем регрессионному тестированию особое внимание

2. Нагрузочное тестирование – обязательно должно быть успешно пройдено. Даже если все предыдущие версии прошли его успешно. Выпущенное приложение должно нормально работать при запланированной нагрузке. В противном случае – снова рискуем репутацией. А потеря репутации = уменьшение шансов на повторные проекты от этого Заказчика.

3. Тестирование безопасности – если есть – тоже обязательно для финальной версии.

4. В целом, предыдущие 3 правила сводятся к максимальному «вылизыванию» финальной версии перед сдачей. В идеале, дефектов быть не должно. В реальности – допускается сдача финальной версии с наличием незначительных дефектов, которые могут быть исправлены в течение срока бесплатной поддержки приложения (согласуется с Заказчиком отдельно).

5. Необходимо выполнить все ченджи, и не забыть их протестировать. Собственно, ченджи – это часть общего скоупа проекта (выпускаемой версии), и логично что весь скоуп должен быть реализован и протестирован. В некоторых случаях часть ченджей оставляют на следующую версию приложения. Однако, разработка следующей версии – это отдельный проект, и такие ченджи уже не входят в скоуп версии которую сдаём сейчас.

6. Необходимо проконтролировать готовность среды запуска приложения. Для случая когда среда запуска подготавливается силами проектной команды – подготовить и проверить готовность. Для случая когда среда запуска предоставляется Заказчиком – проверить доступность и соответствие требованиям приложение. Сделать это нужно до сдачи версии.

Всё это касается этапа подготовки финальной версии к сдаче Заказчику. По завершению подготовки финальная версия должна соответствовать следующим критериям:

1. Реализован весь функционал согласно скоупа проекта. Нет нереализованных требований или ченджей

2. Весь реализованный функционал протестирован на соответствие требованиям и отсутствие ошибок

3. Выполнены все необходимые (запланированные) виды тестирования

4. Подготовлена среда в которую будет установлена финальная версия (среда запуска)

Когда всё готово – начинаем процедуру сдачи версии. Как обычно, «заливаем» приложение в среду показа Заказчику, ждём окончания проверки и подтверждения приёмки. После получения от Заказчика подтверждения приёмки версии в среде показа – «заливаем» приложение в среду запуска и проверяем вместе с Заказчиком как она себя там чувствует. Если всё ОК и претензий нет – просим Заказчика подтвердить данный факт в письменном виде, причём именно в такой форме – «всё работает, претензий нет». Важно зафиксировать отсутствие претензий. Форма, в которой получаем подтверждение – зависит от условий Контракта (или заменяющих его договорённостей).

Если установка приложения в среду запуска выполняется на стороне Заказчика – делаем то же самое. То есть, помогаем при необходимости (консультируем) с установкой, затем проверяем работу приложения и если всё ОК – просим подтверждение приёмки и отсутствия претензий к работе версии.

Далее, после установки приложения в среде запуска, следует зафиксировать вместе с Заказчиком дату начала срока бесплатной поддержки приложения. На всякий случай напомню, что это такое – общепринятой практикой является бесплатное устранение дефектов (и консультации) в течение некоторого времени после сдачи финальной версии. Срок такой поддержки варьируется в зависимости от сложности и длительности разработки и оговаривается в Контракте (или другим образом) до начала проекта. В общем, фиксируем дату старта срока поддержки и, вместе с тем, указываем дату его окончания. Важно чтобы Заказчик понимал, что бесплатная поддержка ограничена по срокам, и, соответственно, постарался максимально интенсивно его использовать («обкатать» на тестовых пользователях).

Следующим делом является получение всех платежей по проекту. Если Заказчик платил всегда вовремя – скорее всего всё уже ОК (нормальным является проведение последнего платежа после установки финальной версии в среду запуска). Если есть «висящие платежи» – настоятельно рекомендую получить их до передачи исходного кода проекта и технической (сопроводительной) документации, которая является следующим шагом.

Наконец, после того как приложение запущено, приёмка подтверждена Заказчиком, получены все платежи и зафиксирован период поддержки – отдаём Заказчику исходный код проекта и сопроводительную техническую документацию. Finita. Проект сдан!