Сроки и долгосрочное планирование в Agile

Задача классического управления проектами: «Сделать проект в срок, в рамках бюджета, реализовав полностью функционал и соблюдая установленные критерии качества».

Давайте посмотрим на первую составляющую – на сроки.
Главной причиной появления этого ограничения проекта является недоверие. Это может быть недоверие между заказчиком и исполнителем, между менеджментом и командой и так далее. Наличие сроков создает ощущение управляемости (при поставленных процессах и обеспечивает управляемость), но приводит к недопониманию и еще большему недоверию, образуя замкнутый круг, компоненты которого усиливают друг
друга.
Ограничение по срокам возникает как институт, который призван снизить риски
заказчика. Но на практике получается наоборот, жесткие давящие сроки приводят к
деструктивной позиции обеих сторон: исполнитель запрещает заказчику менять
требования, даже если для этого имеется реальная бизнес-необходимость, а заказчик
жестко требует исполнения сроков порой в ущерб качеству, ведь масштаб проекта также
фиксируется.

Оценка сроков методом PERT

Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.
Метод заключается в получении трех оценок:

• Оптимистичной (Мин)
• Вероятной (Сред)
• Пессимистичной (Макс)

Тогда вычислить наиболее вероятную дату завершения можно по формуле:

(Мин + 4*Сред + Макс) / 6
Отклонение можно вычислить по формуле:

(Макс – Мин) / 6.

Оценка сроков релиза в Scrum проекте

Для оценки сроков релиза в Scrum проектах необходимы исторические данные либо из нескольких первых спринтов, либо из предыдущих проектов данной команды. После этого можно построить диаграмму сгорания для релиза целиком:

Обратите внимание, что пунктиром построена линейная аппроксимация, с помощью которой можно вычислить, что проект завершится на 13-ом спринте.

Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.

• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
• Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.