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

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

Автор: Джим Хайсмит (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-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.