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

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

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

Набор тестов может быть прислан и заказчиком.

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

В один момент времени может быть до 2х веток кода:

• Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
• Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).

• 0й – разработка
• 1й – тестирование, fix, разработка, сдача этапа (деливери)
• 2й – тестирование, fix, разработка, сдача этапа (деливери)
• 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

• 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
• 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
• 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
• 4. PM планирует объем функционала {Ф} для следующего деливери.
• 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
• ! У дефектов приоритет всегда выше, чем у нового функционала!
• 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
• 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
• ! Деливери собирается и отправляется только после одобрения QA!
  • Деливери отправляется заказчику вместе с сопроводительной документацией.
• 8. PM инициирует слияние двух веток.
• 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
• 10. Процесс повторяется до выпуска финальной версии.

Что входит в управление изменениями проекта:

• Анализ и сбор всех требований Заказчика.
• Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
• Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
• Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
• Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
• После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
• Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

• Все или большинство требований, относящихся к следующему деливери (фазе), реализованы.

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

• Определение готовности деливери к отправке. Критерии готовности:

• все требования, относящиеся к данному деливери (фазе), реализованы;
• открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

Мы рассмотрели пример процесса управления изменениями в ИТ проекте. Одна из распространенных ошибок – одноособное управление требованиями исходящее от руководителя проекта. Залог успеха – групповое обсуждение изменений, достижение компромисса со всеми учасниками.

План-график работ проекта (лучше всего – в MS Project). Должен показывать:

• Объем и дату каждого деливери.
• Объем работ на каждом этапе.
• Основные вехи.

Примеры основных вех:

• MILESTONE- утверждение спецификаций (в план должно быть заложено время на ревю и утверждение спецификаций заказчиком).
• MILESTONE- утверждение плана тестирования деливери Х (QA менеджер составляет план тестирования следующего деливери, который должен быть утвержден менеджером проекта).
• MILESTONE- завершение кодирования по деливери X (разработчики успешно закончили кодирование функционала, предназначенного для сдачи в деливери X).
• MILESTONE- QA приемка деливери (QA тестирует деливери на территории заказчика, если требуется, и дает «добро»).
• MILESTONE- готовность деливери Х к отправке (все фичи реализованы, а дефекты успешно исправлены – деливери можно отправлять заказчику).
• MILESTONE- готовность пользовательской документации (финальная документация, которую необходимо передать заказчику, должна пройти ревю менеджера проекта).
• MILESTONE- приемка деливери заказчиком (используя набор приемочных тестов, PM получает формальное одобрение продукта заказчиком).
• MILESTONE- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

Таким образом и команда и заказчик становятся информированы о запланированном графике предстоящих работ. Тем самым повышая вероятность успешного завершения проекта в срок.