Гибкое управление проектами и продуктами | страница 27

А между тем это, как ни парадоксально, очень точная метрика. Два программиста в команде правят примерно одинаковое количество строчек за один и тот же промежуток времени. Конечно, необходимо много условий (схожие задачи, наличие стандартов кодирования, например максимальная длина метода, отсутствие дублирования, рефакторинг и т. д.), но все же метрика достаточно точная… если не использовать ее как оценку производительности.

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

Необходимо отметить, что недоверие преодолеть очень непросто.

Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.

Метод заключается в получении трех оценок:

• оптимистичной (Мин);

• вероятной (Сред);

• пессимистичной (Макс).

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

(Мин + 4 × Сред + Макс) / 6.

Отклонение высчитывается по формуле:

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

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

Диаграмма сгорания релиза показывает расчетную дату завершения проекта

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

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

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