Контроль итерации.
Все выполняющиеся итерации необходимо контролировать. Время, затрачиваемое на решение проблем, влияет на общий темп проекта. При выдаче запросов поиска проблем зарегистрировать заблокированные описатели позволяет флаг «Issue». Запросы поиска проблем должны выполняться хотя бы один раз в начале рабочего дня. По завершении итерации необходим анализ сделанного для определения путей совершенствования процесса и рабочей среды. Если итерация начинается с собрания, на котором она планируется, заканчиваться она должна собранием, закрывающим итерацию, на котором проводится ретроспективный анализ проделанной работы.
Операции:
· Мониторинг итерации.
· Обзор приоритетов в описателе.
· Снижение риска.
· Выполнение ретроспективного анализа.
Операция: Мониторинг итерации
Понимание текущего состояния итерации очень важно для ее успешного завершения. Один из важнейших моментов в оценке хода итерации – анализ описателей высокоприоритетных сценариев, требований к качеству и ошибок в данной итерации. Актуализируйте план итерации, чтобы увидеть незакрытые задачи, связанные с описателями перечисленных типов. Определите завершившиеся задачи и распределите приоритеты так, чтобы сначала заканчивались наиболее важные части итерации. Задача менеджера проекта состоит в том, чтобы распознать потенциальные проблемы, приводящие к остановке работы, а также распознать узкие места, снижающие темп выполнения работы, и обеспечить непрерывное выполнение проекта.
Операция: Обзор приоритетов в описателе
Если в процессе итерации изменяются приоритеты описателей сценариев или требований к качеству, менеджер проекта отвечает за то, чтобы организовать короткое совещание с участием бизнес-аналитиков, архитекторов, разработчиков и тестировщиков для обсуждения изменений. Приоритеты могут меняться по многим причинам: из-за возникновения технических вопросов, изменения приоритетов заказчика или зависимостей.
Решение проблем. Ежедневно выполняйте запросы поиска проблем и проверяйте, не заблокированы ли те или иные задачи разработки или тестирования. При возникновении проблем привлекайте к их решению других участников команды.
Операция: Снижение риска
Для снижения риска необходимо предпринять шаги с целью уменьшения его вероятности или смягчения его воздействия. Проактивное управление рисками эффективней реактивного. Чтобы проактивное управление рисками было рентабельным, в первую очередь нужно уделять внимание наиболее рискованным моментам, но тратить на их устранение не больше, чем они могут принести убытков.
Уменьшение вероятности риска. Предложите варианты снижения вероятности возникновения неблагоприятных событий.
Смягчение воздействия. Если вероятность возникновения неблагоприятной ситуации остается высокой, предложите способы смягчения вредного воздействия.
Выработка плана на случай чрезвычайных обстоятельств. Если риск все же остается неприемлемо высоким – пересмотрите все сделанные допущения и требования к качеству, особенно относящиеся к эксплуатационной среде, доступности и специальным возможностям.
Применение решений. Реализуйте выбранное решение, обеспечивающее уменьшение вероятности и смягчение воздействия неблагоприятных обстоятельств.
Операция: Выполнение ретроспективного анализа
Обратная связь является важной составляющей любого гибкого процесса разработки ПО. Поскольку всякая проектная группа – как и каждая проблема, с которой она сталкивается, – уникальна, создание среды, отвечающей всем потребностям ее участников, является ключевым фактором в увеличении производительности их труда. Ретроспектива позволяет команде разработчиков проанализировать свои правильные и ошибочные действия после завершения очередной итерации. Главное здесь – увидеть возможные пути совершенствования процесса и соответствующим образом перестроиться. Чтобы извлечь максимальную пользу от ретроспективы, соответствующее совещание должно длиться около двух часов. Однако если члены команды видят, что все идет гладко, встречу можно сократить. Последняя итерация заканчивается ретроспективным анализом проекта.
Организация совещания для ретроспективы. Пригласите участников команды на совещание. Оно должно проводиться после завершения итерации с участием всех членов коллектива. Совещание должно быть относительно коротким, но достаточным для того, чтобы сделать необходимые выводы (обычно около двух часов). Окончательный ретроспективный анализ (в конце проекта) может занять больше времени – вплоть до нескольких дней для масштабных проектов. Это завершающее собрание целесообразно организовывать таким образом, чтобы оно не мешало повседневной деятельности.
Проведение совещания. Установите четкие правила участия сотрудников в совещаниях. Используйте список из двух столбцов: «плюсов» и «минусов» завершенной итерации.
Учитывайте результаты анализа в следующих итерациях. Там, где это возможно, используйте результаты проделанного ретроспективного анализа для корректировки планов следующих итераций.