PMsoop: Глава №15: Детальное планирование разработки итерации

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

Артефакты – ТЗ, План Проекта -> детализированный ПП для первой версии

Суть – Менеджер Проекта совместно с разработчиками уточняет план разработки первой версии

Детальное планирование разработки выполняется перед стартом каждой новой итерации проекта. Задача – разделить длительные задачи на более «мелкие». Основной смысл – увеличить количество «точек контроля» в проекте за счёт проверки выполнения выполненных задач.

Рассмотрим на примере. В проекте есть выделенная задача разработки под названием «форма регистрации пользователя», оцененная в 4 рабочих дня. Эту задачу Менеджер Проекта совместно с ответственными разработчиками разбивает на следующие подзадачи:

- блок login & password + capcha, с проверкой на уникальность имени

- блок ввода контактной информации

- блок подгрузки аватары

- блок дополнительных данных

Каждая из выделенных подзадач может быть выполнена за 1 рабочий день. Все задачи делает один и тот же разработчик – тот, кто был ответственный за общую задачу «форма регистрации пользователя». По выполнению всех подзадач автоматически выполняется общая задача. При этом выполнение каждой подзадачи можно проверить отдельно. В случае, если с выполнением подзадачи возникнут трудности – информация поступит Менеджеру Проекта с большей вероятностью чем при выполнении общей задачи целиком, без дополнительных контрольных точек.

Напомню, что критериями для определения задач разработки на подготовительном этапе являются:

- «элементарность» – задача может быть выполнена одним и тем же разработчиком (имеется ввиду роль, а не человек, т.е. задача «привязана» к одной технологии)

- «несвязанность» – в процессе выполнения этой задачи не требуются результаты других задач

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

Хорошей практикой является детализация задач до такого уровня, когда большинство подзадач могут быть выполнены за один рабочий день. В таком случае Менеджер Проекта может получать актуальную информацию о ходе разработки ежедневно и оперативно реагировать на проблемы в случае их возникновения. Как реагировать на проблемы – про это будет написано в следующих главах. Что касается проверки выполненных подзадач – она должна выполняться самими разработчиками, а также (по возможности) избирательно самим Менеджером Проекта.

Итак, перед стартом разработки новой версии Менеджер Проекта собирает разработчиков и вместе с ними детализирует задачи разработки для этой версии. По результатам необходимо обновить План Проекта. В процессе обсуждения могут быть обнаружены новые «непонятки» в требованиях, также могут измениться оценки трудозатрат – это нормально.

Дополнительной (а иногда и основной) целью детализации задач разработки является «последняя проверка» полноты и ясности требований, а также правильности оценок / верности сроков. Актуальность такой проверки растёт с каждой следующей версией проекта – так как в процессе разработки и сдачи предыдущих версий часто появляется новая информация, которая приводит к изменению оценок и планов. Фактически, детализация задач – это «маленький подготовительный» этап для каждой версии, в чём-то повторяющий общий подготовительный этап для всего проекта в целом.

Когда все задачи разработки детализированы до оптимального уровня (один рабочий день на подзадачу это хорошо), и всё ОК со сроками и требованиями Менеджер Проекта даёт команду на начало разработки версии (старт итерации).