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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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