S(crum)-Light – Понятный путь управления проектами

Эффективность

Анализ эффективности является важным процессом повышения производительности команды.

Цель

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

Оценка задач

Первый шаг к пониманию эффективности команды является оценка задач. Задачи рекомендуется оценивать в относительных величинах, сравнивая их друг с другом. Проще и легче всего внедрить оценку в Story points, когда задачи измеряются в абстрактных величинах. Команде нужно начать замерять, сколько Story points она «съедает» в конце спринта (если разработка идет без спринтов, то за неделю, две недели, месяц) и, на основе этих данных, может прогнозировать свою эффективность в следующем отрезке (спринте) разработки.

Метрики

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

Команды могут использовать различные метрики, но наиболее простые и эффективные на начальном этапе являются:

Velocity

Скорость работы команды. Средняя величина выполнения задач. Может измеряться, как в количестве задач, так и в Story points. Рассчитывается из среднего значения выполненных задач / Story points за последние 4–6 спринтов. Рекомендуется определять данную метрику, как по команде в целом, так и по каждому разработчику (тут имеется ввиду именно разработчик = программист). Постоянно обновляя данную метрику, можно более точно провести анализ достижения различных целей.

Code destiny

Чистота кода. Измеряется в процентном соотношении количества багов к количеству задач во всем бэклоге продукта. Индикатор отслеживается на регулярной основе, помогая определить на сколько чистый код пишет команда и не является ли количество багов в продукте критичной проблемой. Рекомендуется держать данный показатель не выше 30 %.

Дополнительные метрики

• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки (команда должна установить, что является точкой старта и окончания работы над задачей).

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

• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.

• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.

• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.

Команды могут внедрять много разных метрик, главное помнить, что метрики внедряются не ради самих метрик, а для того, чтобы понимать, где в процессе возникают проблемы. Если метрика не дает этого понять, то ее следует исключить и не тратить на нее время.

Метрики должны служить главной цели – повышение точности прогнозирования. За метрики, обычно, отвечает менеджер проекта (РМ).