Автор: Джим Хайсмит (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), он предлагает такую формулу:
Бизнес сдвинулся из мира периодических изменений к миру непрерывного изменения. Параллельно с этим, разработка программного обеспечения эволюционирует от проектно-ориентированной работы (поставка программ большим куском и затем его поддержка) к продуктно-ориентированной (непрерывная поставка). Чтобы направлять поведение в правильном направлении, нам нужно включать такие метрики, как ценность, время цикла поставки и техническое качество в наши критерии продуктивности. Нам нужно высчитать ценность новой функциональности наряду с ее объемом (стори поинты). Время цикла может быть превосходной метрикой, потому что оно зависит от оптимальной работы механизма поставки программного обеспечения и это метрика, понятная бизнесу. Когда мы спрашиваем: “Стоит ли нам работать над новой функциональностью или повышением качества (сокращением технического долга, и т.д.)?”, Владельцу Продукта легко ответить, “разумеется, работайте над новой функциональностью.” Вместо этого нам нужно спросить: “Как нам сбалансировать поставку новой функциональности и уменьшение времени цикла?” [Примечание: Цена Отсрочки, из книги Дона Райнерстена (Дон Reinertsen) также может быть полезной метрикой].
Эту статью не следует воспринимать как агитацию против метрики велосити; она все еще нужна для планирования загрузки команды. Проблема заключается в важности, которой наделили эту метрику, превратив ее в метрику продуктивности. Мы измеряем ее, потому что ее легко измерить. Но гораздо более важно измерять такие показатели, как ценность новой функциональности, время цикла поставки и метрики качества (дефекты, технический долг). Поставка наиболее ценной функциональности клиентам должна быть первостепенной, но фокус должен быть не на разовой, а на непрерывной поставке. Речь не о том, что более важно — новая функциональность или качество; речь о балансе между поставкой функциональности сегодня и ростом нашей способности быстро поставлять новую функциональность завтра — снова и снова. Быстрая реакция на изменения бизнеса - это постоянная способность, а не одноразовое событие. Поддержание этой быстрой реакции требует мощного, “хорошо смазанного” механизма поставки программного обеспечения.
Примечание: Спасибо Мартину Фаулеру (Martin Fowler), Джезу Хамблу (Jez Humble) и Кену Кольеру (Ken Collier) за их комментарии и дополнения к этой статье.
Переведено с английского проектом Agile Translations
Алина Проскурина, Тимофей Евграшин, Дарья Дубинина
Оригинальная статья: "Velocity is Killing Agility" by Jim Highsmith
Переведено с английского проектом Agile Translations.
Это крайность в употреблении неплохого инструмента для неправильных целей:
- Велосити все чаще используется в качестве метрики продуктивности (а не в качестве способа нормирования нагрузки команды, как задумывалось), что слишком фокусирует внимание на объеме законченных стори поинтов.
- Фокусировка на объеме отвлекает внимание от качества удовлетворения потребителей и достаточного инвестирования в механизм поставки (в техническое качество).
- Полный контроль Владельца Продукта/Менеджера Продукта над приоритетами только ухудшает ситуацию — мы уходим от фокусировки на клиентах к контролю клиентов, который сдвигает равновесие все дальше от инвестирования в механизм поставки к разработке новой функциональности.
- Особенно для таких видов бизнеса, где необходим быстрый ответ рынку (цикл поставки измеряется днями или неделями), инвестиции в механизмы поставки также важны, как и новая функциональность.
- Руководству необходимо распределять ресурсы между новой функциональностью и техническими улучшениями, а также создать команду владельцев продукта, включающую Владельца Продукта и технического лидера для совместного определения приоритетов.
- Такие метрики, как ценность новой функциональности и время цикла помогут сбалансировать разрушительное влияние метрики велосити.
Чрезмерное внимание к велосити вызывает проблемы из-за того, что она часто используется как метрика продуктивности команды. Велосити правильно использовать в качестве инструмента для определения допустимой загрузки команды, чтобы делать планирование исходя из нагрузочной способности команды, как это описывает Кент Бек в “Экстремальном Программировании” (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