Классическая ловушка
Бывает, что организации пытаются внедрять Agile подходы в своей разработке, при этом оставляют сущности, применимость и совместимость которых с Agile весьма сомнительна. Одним из краеугольных камней является управление стоимостью проекта или разработки продукта.
Есть проектный подход PMI с вычислениями по Методу освоенного объёма (Earned Value Management) через несколько показателей и индексов:
1️⃣ BAC — Совокупная запланированная стоимость (Budget at completion)
2️⃣ PV — Плановый объем (Planned value)
3️⃣ EV — Освоенный объем (Earned value)
4️⃣ ФС (AC, ACWP) — Фактическая стоимость выполненных работ (Actual Cost, Actual Cost of Work Performed)
5️⃣ ИВСР (SPI) — Индекс выполнения сроков (Schedule Performance Index)
6️⃣ ИВСТ (CPI) — Индекс выполнения стоимости (Cost Performance Index)
При переходе на Agile c постоянно пополняемым Backlog, упрощенной моделью риск-менеджмента, дорогая сердцу модель освоенного объема, разумеется, перестает работать. Графики начинают расползаться вверх как на дрожжах, а значения коэффициентов скакать то вверх, то вниз, путая старших менеджеров. Еще хуже, когда менеджеры начинают транслировать слепки этой "неправильной" информации, не понимая сути явления, остальным заинтересованным лицам. Я уверен, что не одному мне приходилось слышать вопросы от стейкхолдеров о том, на сколько же процентов "увеличились" описанные индексы при периодическом мониторинге. 🤦♂️
Что же делать? Как минимум избавиться от старого наследия.
В многих Agile фреймворках применяется совсем другой инструмент оценки – Диаграмма сгорания задач (BurnDown Chart). Именно она после нескольких итерационных циклов является более адекватный визуальный инструментом, а также позволяет рассчитать приблизительные оценки по стоимости в определённые моменты времени.
Нельзя менять отдельные элементы системы, не встав на ступеньку выше, и не посмотрев общую совместимость и применимость.
@aheadofthepack
Post #23
452