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

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

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

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- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

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

Роли в команде разработчиков ПО:

Менеджер Проекта (PM) ответственный за:

• организацию процесса разработки;
• координацию и контроль всех видов деятельности в проекте;
• разработку плана проекта (Project Plan);
• проведение регулярных статус митингов в проектной группе;
• контроль готовности деливери и нового билда для QA;
• предоставление заказчику документации и промежуточных версий для просмотра и утверждения или комментирования;
• регулярное общение с заказчиком, выяснение требований;
• предоставление отчетов о статусе проекта.

Бизнес аналитик (Business Analyst) ответственный за:

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

Системный аналитик (Technical Leader) ответственный за:

• координацию и контроль деятельности по дизайну, архитектуре и кодированию;
• поддержку контроля версий;
• настройку скрипта для авто-билдера и своевременную сборку версий.

QA менеджер (QA manager) ответственный за:

• организацию и контроль процесса тестирования в проекте;
• планирование тестирования;
• участие в адаптации процесса разработки под проект, анализ его качества;
• анализ результатов тестирования и качества продукта;
• участие в управлении требованиями;
• участие в настройке багтрекинговой системы, полное прослеживание багов;
• контроль готовности деливери и нового билда для QA.

QA аналитик (QA Analyst) ответственный за:

• подготовку тест дизайна;
• написание тест кейс спецификаций;
• проведение тестирования;
• регистрацию багов;
• прослеживание и проверку багов;
• написание документации пользователя.

Разработчик (Developer) ответственный за:

• разработку качественного кода;
• проведение модульного тестирования;
• поддержку контроля версий;
• написание пользовательской документации, относящейся к инсталляции и администрированию.

Заказчик (Customer) ответственный за:

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

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

Документ дает полное представление:

• о будущем проекте (цели, приоритеты, необходимые артефакты и те из них, которые подлежат сдаче заказчику);
• об участниках проекта, роли каждого, а также их взаимодействии;
• о плане проекта (WBS, графике, планируемых затратах);
• о подходе к управлению требованиями;
• о процессе разработки и тестирования;
• о плане тестирования и плане управления конфигурацией;
• о процедуре завершения проекта;
• о подходе к сдаче-приемке проекта или этапа;
• о плане обучения заказчика.

План разработки сайта описывает:

• Цель, содержание и функции проекта
• Объекты, подлежащие сдаче
• Приоритеты проекта

• Организация проекта

• Проектная группа
• Артефакты проекта
• Роли и ответственности
• Взаимодействие участников

• Управление разработкой

• План-график проекта
• Контроль качества
• Управление требованиями и изменениями
• Управление конфигурацией

• Инструменты, инфраструктура
• Контроль версий
• Процесс сборок и релиза
• Работа с дефектами

• Параметр бага «Fix in»
• Фильтры
• Зависимость полей
• Значения поля «Version»
• Действия QA после сборки внутреннего билда
• Действия QA после сборки деливери
• Действия PM после сборки деливери

• Предоставление отчетов
• Почта

• Проектный цикл

• Разработка
• Тестирование
• Приемо-сдаточные испытания

• Участие клиента в процессе

• Ревю и утверждение проектной документации
• Обсуждение изменений в требованиях, сроках, бюджете
• Просмотр промежуточных версий ПО
• Фиксирование замечаний и дефектов
• Приемо-сдаточные испытания

• Дополнительные планы

• План обучения пользователей
• План решения проблем