БЛИЖАЙШИЕ МЕРОПРИЯТИЯ:
22-23 июня: КИЕВ,
Certified ScrumMaster by ScrumAlliance | Курс c Натальей Трениной (на русском языке)
27 июня: ХАРЬКОВ,
AgilePizza #68
27 июня: КИЕВ,
AgilePizza #69

2013/11/21

Погоня за велосити убивает гибкость

Автор: Джим Хайсмит (Jim Highsmith)
Переведено с английского проектом Agile Translations.



Когда я общаюсь с представителями компаний из всех уголков мира, становится ясно, что значительное их количество все еще погрязло в болоте продуктивности, эффективности и оптимизации. Их легко вычислить, потому что они часто одержимы измерением велосити (veloctiy) — велосити команды, велосити среди нескольких команд, велосити на уровне организации или даже велосити конкретного разработчика (ой!). Погоня за увеличением велосити убивает гибкость.

Это крайность в употреблении неплохого инструмента для неправильных целей:
  • Велосити все чаще используется в качестве метрики продуктивности (а не в качестве способа нормирования нагрузки команды, как задумывалось), что слишком фокусирует внимание на объеме законченных стори поинтов. 
  • Фокусировка на объеме отвлекает внимание от качества удовлетворения потребителей и достаточного инвестирования в механизм поставки (в техническое качество). 
  • Полный контроль Владельца Продукта/Менеджера Продукта над приоритетами только ухудшает ситуацию — мы уходим от фокусировки на клиентах к контролю клиентов, который сдвигает равновесие все дальше от инвестирования в механизм поставки к разработке новой функциональности. 
  • Особенно для таких видов бизнеса, где необходим быстрый ответ рынку (цикл поставки измеряется днями или неделями), инвестиции в механизмы поставки также важны, как и новая функциональность. 
  • Руководству необходимо распределять ресурсы между новой функциональностью и техническими улучшениями, а также создать команду владельцев продукта, включающую Владельца Продукта и технического лидера для совместного определения приоритетов. 
  • Такие метрики, как ценность новой функциональности и время цикла помогут сбалансировать разрушительное влияние метрики велосити.


Чрезмерное внимание к велосити вызывает проблемы из-за того, что она часто используется как метрика продуктивности команды. Велосити правильно использовать в качестве инструмента для определения допустимой загрузки команды, чтобы делать планирование исходя из нагрузочной способности команды, как это описывает Кент Бек в “Экстремальном Программировании” (Kent Beck: Extreme Programming: Embrace Change). Измерения продуктивности вообще имеют не так много смысла для умственной работы, но это уже тема для другой статьи.

Велосити — это очень соблазнительная метрика, потому что ее легко посчитать. Даже несмотря на то, что количество стори поинтов, законченных за итерацию, подсчитываются на базе функциональности, готовой к релизу, все же велосити акцентирует внимание именно на приложенных усилиях. В то время как Agile команды стараются сфокусироваться на поставке функциональности с наивысшей ценностью для бизнеса, они отвлекаются на отчетность о своей продуктивности. Время от времени я слышу о комментариях от менеджеров или Владельцев Продукта, “Ваша велосити упала c 24 в прошлую итерацию до 21, что пошло не так? Давайте поднимем велосити до предыдущего значения, а еще лучше - выше.” В этом сценарии велосити превратилась из полезного инструмента планирования (какова наша нагрузочная способность на следующую итерацию?) в инструмент измерения производительности. Это говорит о пренебрежении к двум вещам: качеству удовлетворения пользователей (количество функциональности доминирует над улучшением юзабилити) и улучшению механизма поставки (техническому качеству).

Гибкость — это способность отвечать на изменения для того, чтобы процветать в непрерывно меняющейся экономической обстановке. Это означает, что нам нужно создать и поддерживать непрерывный механизм поставки, а не выпустить много функциональности в первом релизе, а затем быстро снизить производительность. Основное проявление гибкости в разработке программного обеспечения — это непрерывная поставка (continuous delivery). Нашей целью должна быть не продуктивность, но “быстрая поставка программного обеспечения, имеющего ценность для пользователей — снова и снова.” Чтобы реагировать на изменения бизнеса, технологий и действия конкурентов, мы должны сфокусироваться на превосходном удовлетворении пользователей, создании новой функциональности и улучшении механизма поставки, который позволит нам быстро выпускать функциональность в каждом релизе. 

Усугубляя проблему, Аджайл движение фокусировалось на высоких уровнях вовлеченности клиента — отличная вещь сама по себе — но мы зашли слишком далеко. Большое количество аджайлистов с осуждением говорят о том, что они не могут заставить организации сфокусироваться на технических практиках — но почему это вызывает удивление, если мы поощряем Владельцев Продукта принимать все решения по приоритету, а также измерять продуктивность, используя велосити? По сравнению с традиционной методологией, мы с избытком компенсируем отсутствие фокуса на клиенте путем передачи Владельцу Продукта полного контроля над приоритетами. Зачастую мы сваливаем всю необходимую техническую работу в пользовательские истории, предполагая, что мы сможем убедить Владельца Продукта/Менеджера Продукта согласиться на выполнение этой дополнительной работы. Это излишняя корректировка традиционных подходов, когда месяцы технических работ предшествовали разработке функциональности, которую сможет увидеть пользователь (что было даже худшей проблемой).

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

Представьте себе наш механизм поставки программного обеспечения как мощный реактивный двигатель в самолете-истребителе. Если мы не сумеем произвести надлежащее обслуживание этого двигателя, то он сломается. Что произойдет, если мы не будем периодически менять части двигателя? В разработке программного обеспечения мы ломаем двигатель, когда: игнорируем технический долг, откладываем рефакторинг, пренебрегаем автоматизированными тестами, вкладываем слишком мало в непрерывную интеграцию и смиряемся с долгими циклами поставки. Эти вещи часто воспринимаются как «технические излишества», а не возможность поддерживать двигатель на оптимальной производительности.

В книге Дона Райнертсена, “Принципы Потока Разработки Продукта” (Don Reinertsen: The Principles of Product Development Flow), он предлагает такую формулу:
Время цикла/Время добавленной ценности = 1/(1 - Утилизация)
Поэтому, когда команды оптимизируют свой процесс для повышения велосити, они увеличивают количество потерь в процессе поставки, и увеличивают время цикла. Наоборот, когда команды оптимизируют время цикла, утилизация (и таким образом велосити) снижаются. Нужно сохранять баланс.

Бизнес сдвинулся из мира периодических изменений к миру непрерывного изменения. Параллельно с этим, разработка программного обеспечения эволюционирует от проектно-ориентированной работы (поставка программ большим куском и затем его поддержка) к продуктно-ориентированной (непрерывная поставка). Чтобы направлять поведение в правильном направлении, нам нужно включать такие метрики, как ценность, время цикла поставки и техническое качество в наши критерии продуктивности. Нам нужно высчитать ценность новой функциональности наряду с ее объемом (стори поинты). Время цикла может быть превосходной метрикой, потому что оно зависит от оптимальной работы механизма поставки программного обеспечения и это метрика, понятная бизнесу. Когда мы спрашиваем: “Стоит ли нам работать над новой функциональностью или повышением качества (сокращением технического долга, и т.д.)?”, Владельцу Продукта легко ответить, “разумеется, работайте над новой функциональностью.” Вместо этого нам нужно спросить: “Как нам сбалансировать поставку новой функциональности и уменьшение времени цикла?” [Примечание: Цена Отсрочки, из книги Дона Райнерстена (Дон Reinertsen) также может быть полезной метрикой].

Эту статью не следует воспринимать как агитацию против метрики велосити; она все еще нужна для планирования загрузки команды. Проблема заключается в важности, которой наделили эту метрику, превратив ее в метрику продуктивности. Мы измеряем ее, потому что ее легко измерить. Но гораздо более важно измерять такие показатели, как ценность новой функциональности, время цикла поставки и метрики качества (дефекты, технический долг). Поставка наиболее ценной функциональности клиентам должна быть первостепенной, но фокус должен быть не на разовой, а на непрерывной поставке. Речь не о том, что более важно — новая функциональность или качество; речь о балансе между поставкой функциональности сегодня и ростом нашей способности быстро поставлять новую функциональность завтра — снова и снова. Быстрая реакция на изменения бизнеса - это постоянная способность, а не одноразовое событие. Поддержание этой быстрой реакции требует мощного, “хорошо смазанного” механизма поставки программного обеспечения.

Примечание: Спасибо Мартину Фаулеру (Martin Fowler), Джезу Хамблу (Jez Humble) и Кену Кольеру (Ken Collier) за их комментарии и дополнения к этой статье.



Переведено с английского проектом Agile Translations  
Алина Проскурина, Тимофей Евграшин, Дарья Дубинина

Оригинальная статья: "Velocity is Killing Agility"  by Jim Highsmith

3 comments:

Artem Serdyuk said...

a) местами в переводе белиберда:
"мы уходим от фокусировки на клиентах к контролю клиентов" - это что значит?

"Время цикла/Время добавленной ценности = 1/(1 - Утилизация)"
Утилизация - в каком смысле?

б) согласен со статьей в целом, но не согласен с целым набором частностей. Например:

"Бизнес сдвинулся из мира периодических изменений к миру непрерывного изменения." - это значит, в частности, что Lean-подходы становятся все менее применимы. Лин не терпит постоянных изменений, ему нужна стабильность в процессе. Поэтому время цикла и время поставки НЕ МОЖЕТ быть правильной метрикой.

"разработка программного обеспечения эволюционирует от проектно-ориентированной работы к продуктно-ориентированной" - почему продуктно, а не сервисно-ориентированной?

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

В общем, ощущение, что или статья "неряшливая", или что-то не так с переводом.

Alina Proskourina said...

Артем, привет! Спасибо за комменты, как начинающему переводчику, любая критика мне очень полезна.

"мы уходим от фокусировки на клиентах к контролю клиентов" - это что значит?
Здесь речь о том, что клиентам отдается полный контроль над приоритетами, и в результате страдает техническое качество.

Утилизация - в каком смысле? Насколько я поняла статью, речь идет о загрузке членов команды. Там есть ссылка на книгу, где можно подробней почитать.

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

Остальные два коммента больше по смыслу, а там действительно есть с чем поспорить.

Alina Proskourina said...

Артем, привет! Спасибо за комменты, как начинающему переводчику, любая критика мне очень полезна.

"мы уходим от фокусировки на клиентах к контролю клиентов" - это что значит?
Здесь речь о том, что клиентам отдается полный контроль над приоритетами, и в результате страдает техническое качество. Тут стоило бы понятней сформулировать.

Утилизация - в каком смысле? Насколько я поняла статью, речь идет о загрузке членов команды. Там есть ссылка на книгу, где можно подробней почитать.

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

Остальные два коммента больше по смыслу, а там действительно есть с чем поспорить.