Канбан. Альтернативный путь в Agile - Дэвид Андерсон

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

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

Уравнение, оценивающее эффективность поставки, можно вывести двумя способами. Наиболее простой из них – рассмотреть финансовые и трудовые затраты. Другой метод связан с анализом создаваемой ценности.

Итак, первый вариант – модель на основе затрат. Мы должны учесть общие расходы между релизами. Часто их величина известна – это среднемесячные затраты организации. Если мы выпускаем релиз каждый месяц и ежемесячные затраты составляют 1,3 миллиона долларов, то наши расходы равняются минимум 1,3 миллиона долларов на релиз. В координационные издержки могут быть также включены расходы на физическое производство, печать, рекламу и накладные. Все это легко подсчитать. Предположим, они равняются 200 тысячам долларов. Итак, общая стоимость релиза составляет полтора миллиона.

Мы знаем, что дополнительные накладные расходы на релиз равны 200 тысячам, но какая часть из 1,3 миллиона потрачена на планирование, координацию и поставку продукта? Если у нас есть подходящие данные по учету рабочего времени, то можно посчитать и это. Но даже если их нет, мы все-таки способны сделать близкое к истине предположение. Сколько совещаний, людей? Как долго длились совещания? Включите сюда и число человеко-часов, потраченных на сдачу продукта. Умножьте на часовую ставку. Если результат составил около 300 тысяч долларов, то мы получили величину операционных и координационных издержек релиза на полмиллиона.

Эффективность релиза в процентах = 100 % × (общие затраты – (координационные затраты + операционные затраты)) / общая стоимость программного релиза.

В нашем примере эффективность равна

100 % × (1 500 000 – 500 000) / 1 500 000 = 66,7 %.

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

Какая эффективность считается достаточной?

Этот вопрос остается открытым. У всех компаний свои взгляды на достаточные показатели эффективности, и многое зависит от создаваемой ценности.

Когда мы осознали, какую ценность будет приносить данная поставка, можно принять оптимальное решение относительно темпов. Если ежемесячный программный релиз будет давать выручку в два миллиона при затратах в полтора, то несложно подсчитать, что наша прибыль составит полмиллиона. Можем переписать уравнение эффективности так:

Эффективность релиза в процентах = 100 % × (1 – ((операционные затраты + координационные затраты) / (прибыль + операционные затраты + координационные затраты))).

В нашем примере показатель эффективности составит

100 % × (1 (500 000 / (500 000 + 500 000))) = 50 %.

А теперь все становится еще сложнее, поскольку подсчет истинной ценности релиза может оказаться почти невозможным. У нас может не появиться заказов по твердым ценам. Мы можем спекулировать на потреблении рынка, изменяя тем самым стоимость товара и прибыль. Мы можем выпускать релизы, которые скажутся на неосязаемых активах – например, изменении идентичности бренда, маркетинговых материалах или пакете устранения ошибок и улучшении потребительских свойств продукта или сайта.

Не легче вычислить, стоит ли во имя эффективности снизить темп и выпускать релизы пореже. Увеличение времени выхода на рынок может негативно сказаться на рыночной доле, цене и прибыли. Идея эффективности релиза не является знанием в области точных наук. Важнее всего то, что вы, команда и организация в целом имеете представление о расходах на релиз – затратах времени и денег – и способны провести рациональную оценку, которая приведет к расчету приемлемой частоты релизов.

Если команде из пятидесяти человек требуется три дня и десять сотрудников для успешной выдачи кода, то стоит ли выпускать релиз каждые десять рабочих дней (то есть две календарные недели)? Ответ, вероятно, отрицательный. Лучше установить месячную каденцию (то есть двадцать рабочих дней). Но в то же время не стоит забывать об особенностях рынка, где гибкость и время выхода на рынок имеют большое значение, а риски в основном гасятся более частыми релизами. Так что игра стоит свеч. Вы должны все взвесить и принять самостоятельное решение.

Вернемся к нашему примеру. Мы пришли к выводу, что десять человек выпускают код за три дня. Из этого мы заключили, что приемлемыми будут ежемесячные релизы. Однако некоторые сотрудники считают, что при улучшении качества кода, управления конфигурациями, инструментов для управления, переноса данных и регулярных репетиций процедур распространения продукта удастся сократить трехдневный срок работы до восьми часов, и тогда внезапно оказывается, что вполне возможна двухнедельная и даже еженедельная каденция. Что вы будете делать?

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