Управление проектами: статьи

Среднесрочный план на полгода вперед

Не так-то просто просчитать, и более того поддерживать, планы работ на такой горизонт в среде с высокой изменчивостью. Но в соответствии с Agile-принципами, это и не нужно. Четко ставить сроки достаточно только по критичным стримам, которые важно завершить к дате, а менее важные задачи из серии “could have” могут и делаться по остаточному принципу, по мере наличия времени. То есть на задачах относительно низкого приоритета мы можем балансировать спринт, если кто-то из разработчиков вдруг остается недогруженным.

По приоритетным задачам считается классический ресурсный план. Эти задачи всегда назначаются на конкретного исполнителя как можно раньше, так мы не только фиксируем ресурс, но и получаем возможность его выравнивания стандартной процедурой MS Project. К сожалению именно по спринтам MS Project выравнивать пока не умеет, поэтому остается ручная процедура проставления задачам приоритетных стримов значения Future sprint, в соответствии с рассчитанными датами, вплоть до даты окончания стрима. Но это нетрудоемко, особенно с учетом того, что процедуру пересчета ресурсов достаточно делать где-то раз в месяц. Поскольку, по must- и should-have задачам ресурс прибивается заранее даже в нашей сильно изменчивой среде, и с этим будущими назначениями не так часто что-то происходит. А по could- и would-have задачам мы в сроки и не коммитимся, так что нестрашно если они поуезжают вперед при очередном выравнивании, подвинув также и крайнюю правую дату общего родмапа работ.

Отслеживание исполнения

Отслеживание факта не менее важно, чем планирование ресурсов, ведь факт исполнения всегда может дать корректировки на план! При должной культуре работы в Jira, и конечно при наличии синхронизации Jira с MS Project процесс сбора факта можно автоматизировать на 100%. В Jira команда разработки отмечает факты по задаче, то есть списанные часы, и статус задачи. А раз все задачи из Jira стянуты в файл MS Project, то для сбора факта достаточно нажать одну кнопку Synchronize. Проверка статуса 1-2 раз в день очень добавляет РП проактивности, поскольку дает ответы на следующие вопросы:

• какие задачи спринта успешно закрылись?
• какие задачи спринта зависли в Ожидании заказчика или ином “нехорошем” статусе, и надо вмешаться?
• кто из разработчиков уже сделал весь план раньше срока (и можно ему отсыпать еще задачу)? 
•  кто из разработчиков напротив не успевает, и почему:
  • недооценил задачу?
  • застопорились влияющие на нее задачи иного разработчика, и надо вмешаться?

РП остается только принимать решения девиантным задачам, разбирая варианты вместе с заказчиком и разработкой, и по необходимости вносить коррективы в план.

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