PMsoop: Глава №26: Подготовка к работе над следующей версией

В ролях - Менеджер Проекта, команда проекта, Заказчик

Артефакты – требования, план проекта, техническая документация

Суть – Обновляем всё что надо

Теперь кратко рассмотрим рекомендуемые (необходимые) действия при старте разработки каждой следующей (после первой) версии.

Шаг 1. Обновляем требования. Скорее всего, в процессе разработки и сдачи предыдущей(их) версии(й), появились некоторые ченджи. Часть из них уже реализована, другая часть – запланирована к реализации в последующих версиях. Ченджи – запросы на изменения – меняют требования проекта. А значит, чтобы ничего не забыть избежать недоразумений и противоречивых требований, необходимо обновить сводный документ с требованиями с учетом всех (сделанных и запланированных) ченджей.

Обновление требований – работа для аналитика проекта, или кого-то кто выполняет эту роль. Логично предположить, что обновление требований требует определённых трудозатрат, которые нужно учесть в планировании задач и сроков сдачи проекта. Эти трудозатраты полезно предусмотреть ещё при начальном планировании проекта, до старта первой версии, на что и указано в соответствующей главе.

Впрочем, есть интересный способ работы с требованиями, который облегчает жизнь и аналитика, и менеджера проекта, да и всей остальной команды. В начале проекта используется сводный документ с требованиями – SRS, PFD etc. Затем, при старте первой версии все задачи разработки заводятся как таски в issue tracking system (viva Jira!). В описание таска копируем соответствующий раздел требований. Далее, в процессе работы, при поступлении ченджей (утверждённых) – информацию про ченджи добавляем к соответствующим таскам как комментарий. В общем, при условии доступа Заказчика к используемой системе, там же это всё сразу и обсуждается и утверждается, соответственно у таска меняются planned effort и т.п. Далее, при старте следующей версии – снова заводим таски, копируем требования новой версии из первичного документа, и сразу добавляем ченджи. Таски на новую версию заводим только перед её стартом – т.к. к этому времени часть первичных требований может быть уже не нужна, либо изменена до неузнаваемости.

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

Обновлённый документ с требованиями (либо заведенные таски на новую версию) нужно обязательно утвердить с Заказчиком.

Шаг 2. Replanning. Вне зависимости от того, как вы обновляете требования, предположим что это сделано. Логично, что при изменении требований (ченджи), оценка необходимых для их реализации трудозатрат изменяется. Так что теперь нужно обновить план проекта – проверить все оценки для новой версии, внести необходимые изменения в задачи и их продолжительность.

Кроме ченджей, нужно учесть исправление дефектов, которые были признаны незначительными при приёмке предыдущей версии. На это тоже нужно время, что полезно отразить в ПП.

Переоценку трудозатрат и проверку корректности последовательности задач нужно делать вместе с командой проекта. Даже если после сдачи предыдущей версии нет ни ченджей, ни дефектов. Не стоит забывать про возможные изменения планов внутри команды проекта – кто-то может перенести свой отпуск, кто-то запланировать пару отгулов перед/после праздников, праздники, кстати, тоже надо учитывать. Так что, собираем команду, все вместе проверяем задачи проекта и личные планы, вносим изменения в ПП и пересчитываем сроки (milestones).

Обновлённый план проекта, естественно, нужно утвердить с Заказчиком до старта разработки следующей версии.

Шаг 3. Обновляем техническую документацию. Как я уже упоминал, для крупных проектов следует вести техническую документацию.

Под «крупными» понимаем проекты, в которых:

· участвует более 3х разработчиков,

· тянутся более полугода,

· используются сложные технические решения,

· происходит частые замены в команде проекта.

Под «технической документацией» понимаем как минимум:

· концепцию архитектуры проекта,

· комментарии в коде (стандартизированные!),

· диаграмму классов,

· описание структуры БД.

Зачем это всё нужно я уже описывал, да и, в общем, это очевидно.

Техническую документацию (техдоки) надо обновлять в течение проекта, и удобно это делать после приёмки версии Х но перед стартом версии Х+1. Приёмка версии Х Заказчиком означает, что в ней серьёзных изменений уже не будет. Соответственно, можно (нужно) проверить и обновить техдоки таким образом, чтобы написанное соответствовало сделанное. Далее, после обновления требований и переоценки трудозатрат, логично проверить, что изменения могут быть нормально реализованы с учётов выбранной архитектуры. То есть снова проверяем, и, при необходимости, обновляем техдоки.

Обновлённую техническую документацию нужно обсудить и утвердить при участии всей команды проекта.

Шаг 4. Начинаем работы по новой версии. Ну, то есть, если всё готово – то «побежали».