К основному контенту

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

Автор: Джим Хайсмит (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

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Недавно меня спросили, для какого вида проектов больше всего подходит применение гибкого подхода разработки, и сейчас я хотел бы об этом поговорить. Мне кажется, самыми подходящими для использования гибких методик являются проекты с агрессивными сроками выполнения, высокой степенью сложности и так же высоким уровнем инновации (уникальности). Мы хотим использовать Agile, когда делаем что-то новое, по крайней мере, новое для конкретной команды разработки. Если команда делает то, что она уже делала не один раз, она, вероятно, не нуждается в гибком подходе. На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что