Важнейшая часть фазы Execution — разработка и реализация поставок. На этом шаге производится непосредственная разработка проекта по планам и этапам, уставу и концепции, подготовленными в рамках фаз Initiation и Elaboration. Проектная команда регулярно предоставляет заказчику прототипы, готовые к тестированию, получает обратную связь по результатам тестирования, вносит изменения. Процедура повторяется до тех пор, пока не завершится адаптация системы согласно разработанной концепции.
Бизнес-процесс реализации поставок состоит из нескольких стадий (Рис. 22).
Рис. 22 — Цикл процессов реализации поставок
Составление детального плана поставки
Цель шага — подготовка детального плана разработки, передачи и тестирования пакетов новой функциональности. План разрабатывает руководитель проекта. На этом шаге:
1.Подготовьте черновик детального плана поставки, проработайте и обозначьте контрольные точки поставки:
•презентацию заказчику технического дизайна;
•согласование технического дизайна с заказчиком;
•готовность системы к сдаче-приемке;
•завершение тестирования заказчиком.
2.Закладывайте в детальный план работы по поставке реальные оценки задач, которые включают:
•идеальное время выполнения задачи, то есть время непрерывной работы сотрудника без отвлекающих факторов;
•время, необходимое на технологические перерывы;
•время, необходимое для взаимодействия команды;
•коэффициент опыта команды, то есть опыт проектной работы и сработанность сотрудников.
На заметку
Длительность одной поставки в среднем составляет от 4 до 6 недель, задержка между стадиями сдачи-приемки двух последовательных поставок — от 2 до 4 недель.
Важно
В оценку контрольных точек необходимо включить буфер рисковых и недооцененных задач в размере 25% от реальной оценки задач, запланированных до контрольной точки. При помощи такого показателя влияния риска руководитель портфеля проектов сможет оценить реальность выполнения сроков.
3.Организуйте и проведите встречу-планирование по проработке детального плана поставки со всей проектной командой исполнителя.
4.Оформите результаты встречи в виде детального плана поставки.
5.Презентуйте заказчику детальный план поставки.
6.В случае корректировки со стороны заказчика внесите изменения в детальный план и повторно презентуйте его заказчику. Действует правило двух итераций.
7.После утверждения детального плана поставки разместите его на общедоступном ресурсе и передайте аналитикам и разработчикам.
Технический дизайн
После проработки и утверждения детального плана поставки аналитик или группа аналитиков составляет технический дизайн поставки, который описывает требования к системе для реализации в рамках поставки. Технический дизайн содержит:
•требования к полям и интерфейсу объектов;
•детальные требования к скриптам;
•детальные требования к аналитическим отчетам;
•детальные требования к интеграциям;
•тест-кейсы для проверки требований.
Тест-кейсы — это примеры использования системы, с помощью которых на этапе сдачи-приемки в рамках одной поставки и тестовой эксплуатации можно определить, насколько полно система удовлетворяет предъявленным требованиям. Тест-кейсы создаются на основании предоставленных заказчиком бизнес-примеров использования системы. Они описывают исходные данные, действия, которые выполняются в системе, и ожидаемые результаты этих действий. Шаблоны документов доступны по ссылке.
Готовый технический дизайн передается на согласование с заказчиком. Если документ еще находится на утверждении, а аналитик уже выполнил все запланированные работы, то он может перейти к описанию блоков следующей поставки, которые не зависят от текущей поставки (Рис. 22, процесс подготовки технического дизайна независимых блоков из следующей поставки).
Стадия технического дизайна для текущей поставки считается завершенной после утверждения заказчиком документа “Технический дизайн”.
На заметку
В отдельных случаях адаптация и тестирование поставки могут стартовать до подписания технического дизайна заказчиком. Например, если необходимо настроить объектную модель, которая бы соответствовала заменяемой в рамках проекта системе. Мы не рекомендуем разрабатывать скриптовую логику до утверждения технического дизайна.
Адаптация и тестирование
На этапе адаптации и тестирования выполняется непосредственная разработка продукта в соответствии с потребностями заказчика и техническим дизайном. Основную часть работ выполняет отдел разработки.
Роль аналитиков — консультация разработчиков по созданным постановкам, тестирование реализованной функциональности. В некоторых случаях аналитики также проводят настройку конфигурации при помощи доступных пользовательских инструментов.
Сдача-приемка поставки
После того как функциональность, включенная в текущую поставку, разработана и протестирована, аналитики или руководитель группы аналитиков презентуют поставку заказчику. По возможности презентацию лучше проводить в формате личной встречи для лучшего вовлечения заказчика.
Сдача-приемка поставки проходит по тест-кейсам и только по успешному сценарию (happy path). Остальные кейсы заказчик тестирует самостоятельно и передает рабочей группе разработки первую обратную связь. Предоставьте заказчику регламент получения обратной связи:
•акцентируйте внимание на отличии ошибок от доработок;
•обсудите и согласуйте приоритеты задач;
•определите сроки исправления для ошибок и доработок в соответствии с приоритетом;
•утвердите стадии согласования и объемы реализации доработок.
Тестирование поставки заказчиком
На завершающей стадии текущей поставки рабочая группа заказчика тестирует разработанную функциональность по тест-кейсам и передает обратную связь аналитикам или руководителю группы аналитиков. Замечания разделите на два типа:
•Ошибка — некорректная работа или отсутствие функциональности, включенной в технический дизайн.
•Доработка — пожелания и дополнения к разрабатываемой функциональности, которые не были учтены в техническом дизайне.
Ошибки исправляются в рамках текущей поставки, тогда как доработки, если согласована их реализация, включаются в следующую поставку.
Процедура работы с ошибками и доработками
Аналитик или руководитель группы аналитиков получает обратную связь от рабочей группы заказчика, обрабатывает ее и выделяет ошибки, которые необходимо исправить, и пожелания по доработкам от заказчика.
Ошибки передаются команде разработчиков, а доработки — руководителю проекта или руководителю портфеля проектов. Если доработки требуют дополнительного финансирования, то менеджер по работе с клиентами, ответственный за проект, согласовывает с заказчиком план и дополнительное финансирование доработок.
Смотрите также
Смотрите далее
