Измерение скорости. Velocity is Killing Agility!
| November 16, 2011 | Posted by admin under Практики, Статьи |
Автор: Jim Highsmith
http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/
По разговорам с различными компаниями ясно, что многие из них увязли в теме производительности, эффективности и оптимизации. Их легко вычислить, поскольку часто они маниакально занимаются измерением скорости – скорости отдельной команды, скорости всех команд, скорости на уровне организации и скорости каждого разработчика в частности. Тем самым, убивается гибкость (agility). Происходит неразумное применение разумного инструмента:
- Скорость используется как мера продуктивности (а не единица мощности, как это должно быть), которая привлекает слишком много внимания к объему поставленных story point-ов.
- Фокусирование на объеме story point-ов отвлекает от оценки качества пользовательского опыта (customer experience), и от вложения в инструменты качественной поставки (техническое качество).
- Проблема усугубляется, если отдать полный контроль product owner-у/менеджеру: мы переходим от фокусирования на заказчике к контролю, осуществляемому заказчиком. Это еще сильнее смещает баланс инвестирования между новыми фичами (features) и инструментами качественной поставки.
- Там, где критичной является быстрая реакция на запросы клиента (цикл разработки измеряется в днях или неделях), вложения в инструменты качественной поставки так же критичны, как и инвестиции в новые фичи.
- Менеджмент должен распределить ресурсы между работой по фичам и инструментами качественной поставки. Затем нужно создать product ownership-команду, состоящую из product owner-а и технического специалиста, для приоритезации фич.
- Метрики value points и время цикла помогают сбалансировать негативные эффекты измерений скорости (velocity).
Слишком большое внимание скорости (velocity) вызывает проблемы, из-за того, что она широкого используется как показатель продуктивности. Правильно использовать скорость в качестве калибровочного инструмента, для планирования на основе мощности (capacity-based planning), как описано у Kent Beck в Extreme Programming: Embrace Change. Измерение продуктивности имеет мало смысла, но это тема для другого поста. Измерение скорости является соблазнительным, поскольку ее легко посчитать. Story-point-ы за итерацию считаются по поставленным фичам, а суть скорости – это потраченные усилия.
Agile команды стараются сфокусироваться на поставке фич с высокой ценностью, и отчеты по продуктивности являются лишь отвлекающим моментом. Время от времени я слышу такие фразы от менеджеров или product owner-ов: “Ваша скорость снизилась с 24 на предыдущей итерации до 21 в этой. В чем дело? Возвращайтесь в тому, что было, или постарайтесь повысить.” В этом сценарии скорость потеряла смысл полезного калибровочного инструмента (какова наша мощность для следующей итерации?) и стала использоваться для измерения продуктивности. В итоге вы недосчитаетесь двух вещей: качество пользовательского опыта (customer experience) (количество фич на пользовательский опыт) и улучшение инструментов качественной поставки (техническое качество).
Гибкость (agility) – это способность создавать и отвечать на изменения для процветания в меняющейся бизнес среде. Это означает, что мы должны создать и поддерживать машину, постоянно поставляющую ценный продукт, а не такую, которая поставляет много фич в первом релизе, а затем ее возможности постоянно отказывают. С точки зрения разработки ПО гибкость (agility) означает непрерывную поставку и установку. Нашей целью должна быть не продуктивность, а “Разработка и поставка пользовательского опыта (customer experience) быстро и непрерывно”. Для того, чтобы отвечать на запросы бизнеса, технологий и меняющегося рынка, мы должны сфокусироваться на поставке отличного пользовательского опыта (customer experience), построении новых фич и улучшении инструментов качественной поставки, что позволяет делать быструю поставку в каждом релизе.
Agile фокусируется на высоком уровне вовлеченности заказчика, что в общем-то хорошо, но мы зашли слишком далеко. Большое число Agilist-ов отмечают, что они не могут заставить организации сфокусироваться на технических практиках. Но это не удивительно, раз мы поощряем менеджеров/product owner-ов принимать все решения по приоритезации и измерять производительность используя скорость (velocity). Мы чрезмерно компенсировали недостаток внимания к заказчику в традиционных методологиях тем, что передали контроль над приоритезацией product owner/менеджеру. Есть тенденция сваливать всю работу под заголовком “customer-facing” stories и считать, что мы убедим product owner-ов согласиться на все технические работы. Это чрезмерное исправление ситуации, которая была в традиционных проектах, где месяцы технической работы предшествовали любой работе, которая была бы наглядно видна пользователям (что даже еще худшая проблема).
Product manager-ы/owner-ы понимают приоритезацию работ, касающихся пользовательского опыта (customer experience), но они не понимают технические работы. Необходимо создать product ownership-команду, состоящую из product owner-а и технического специалиста, а также, возможно, специалиста QA. Product owner-ы отвечают за заказчика сейчас, а технический специалист и QA отвечают за заказчика завтра.
Представьте инструменты качественной поставки (delivery engine) ПО как мощный реактивный двигатель в истребителе. Если мы не сможем обеспечить адекватную поддержку этого двигателя, он испортится. Что если периодически не перестраивать части этого двигателя? Что касается поставки ПО, то мы ломаем двигатель, когда: игнорируем технических долг, откладываем рефакторинг, не учитываем автоматизированное тестирование, не инвестируем в инструменты и процессы непрерывной интеграции и допускаем длинный цикл разработки. Эти вещи часто рассматривают как “технические тонкости”, вместо того, чтобы обеспечить оптимальную работу инструментов качественной поставки.
Don Reinertsen в своей книге The Principles of Product Development Flow предлагает формулу: Cycle time / Value added time = 1 / (1 – Utilization). Поэтому, когда команды оптимизируют свой процесс для улучшения скорости, они увеличивают траты процесса поставки и увеличивают время цикла разработки. И наоборот, когда команда оптимизирует время цикла, лишние траты (и скорость) уменьшаются. Необходим баланс.
Бизнес перешел из мира периодических изменений в мир непрерывных изменений. Параллельно этому, разработка ПО эволюционирует от проектной работы (поставка ПО большими объемами и затем поддержка) к продукто-ориентированной работе (поставка ПО в непрерывных релизах). Чтобы двигаться в правильном направлении, мы должны использовать такие метрики как value points, время цикла поставки и техническое качество, как критерии производительности. Нам нужно считать “value” point-ы и “effort” point-ы (story point-ы). Время цикла это прекрасная метрика, потому что она зависит от того, насколько хорошо работают инструменты качественной поставки. И эту метрику понимает заказчик. Когда мы говорим: “Что мы хотим – новые фичи или качество (или например, уменьшение технического долга)”, product owner-ы/заказчики могут легко ответить “конечно новые фичи”. Вместо этого нам нужно сказать “Как нам сбалансировать поставку новых фич с уменьшением времени цикла?”. [Замечание: Стоимость задержки, из книги Don Reinertsen, тоже может быть полезной метрикой.]
Не нужно интерпретировать этот пост как анти-скорость (anti-velocity). Она занимает свое место при планировании на основе мощности. Проблема заключается в том значении, которое придается скорости, и в том, что ее превращают в меру продуктивности. Мы измеряем ее, поскольку ее легко померить. Но гораздо более важным является измерение ценности фичи (feature value), времени цикла поставки фичи и метрики качества (дефекты, технический долг и т.п.). Поставка значимых фич должна быть приоритетной, но нужно сфокусироваться не на одной поставке, а на непрерывной поставке. Это не спор фич и качества. Нужно найти баланс между быстрой поставкой фич сегодня и увеличением нашей способности быстро поставить фичи завтра, и непрерывно. Способность отвечать на запросы бизнеса (business responsiveness) – это свойство, а не одноразовое событие. Для поддержки насущной необходимости в чувствительности к запросам бизнеса (business responsiveness) необходим мощный, “хорошо смазанный” механизм.
Замечание: я благодарю Martin Fowler, Jez Humble и Ken Collier за их комментарии и идеи по этой статье.
