У папы есть хорошие советы о необратимых действиях, но программное обеспечение — не скворечник.
Семь раз отмерь, один раз отрежь — один из немногих фрагментов Совета папы, который действительно имеет смысл. Передававшийся от опытных плотников к начинающим умелым плотникам, к самым разным профессиям из поколения в поколение, он воплощает в себе мысль о том, что тщательное планирование может предотвратить дорогостоящие ошибки. И это это отличный совет, когда вы хотите буквально что-то вырезать, хотя он также полезен, когда вы прибиваете гвозди, склеиваете, паяете, свариваете, сверлите или делаете сотни других вещей, которые легко сделать, но трудно отменить.
Если почти ничего не стоит перепроверить ваши измерения по сравнению со стоимостью одного куска пиломатериала, если вы ошиблись, то это хорошая ставка! По мере того, как цена ошибки растет, растут и разумные затраты на ее устранение. Если вы строите мост, и он не достигает другой стороны, внезапно вам придется исправлять очень дорогостоящую ошибку. Разумно тратить тысячи долларов на предотвращение ошибок на миллионы долларов. Физическая инженерия почти всегда содержит этот риск, потому что физические изменения часто трудно отменить — они необратимы.
Программное обеспечение разное. Если подрезать не в том месте с помощью ПО, затраты минимальны. Отменить можно одним нажатием клавиши. Возможно, вам нужно отменить коммит. Программное обеспечение не имеет материалов. Он просто перемещает немного электричества вокруг. Даже если вам нужно переписать с нуля, нет дополнительных затрат на снос того, что вы создали, или на покупку нового материала. Есть только необратимые затраты на то, что вы уже сделали, и обычные затраты на создание нового программного обеспечения. Изменения в программной инженерии в значительной степени обратимы; Двери с двусторонним движением Безоса, если хотите.
Зачем дважды отмерять, если можно дважды отрезать бесплатно? Именно из-за такого несоответствия и возник Agile. Когда изменения дешевы, люди и взаимодействия становятся лучшим компромиссом, чем твердые процессы и инструменты. Когда изменения дешевы, гораздо быстрее возиться с работающим программным обеспечением, чем читать исчерпывающую документацию. Когда изменения дешевы, мы можем с большей готовностью приспособиться к сотрудничеству с клиентами, чем к тяжеловесным переговорам по контракту. Когда изменения обходятся дешево, инженеры-программисты могут реально реагировать на меняющийся рынок, а не следовать плану и надеяться на лучшее. Мышление плотника плохо служит нам в нематериальном ремесле.
Что еще хуже, многие аспекты разработки программного обеспечения нельзя измерить, пока они не будут созданы. Измерить некоторое расстояние на куске пиломатериала достаточно легко, и папа может это сделать. Даже предварительный расчет сил, воздействующих на конструкцию моста, — довольно детерминированный процесс. Каждая часть может быть протестирована независимо на различные прочности и допуски. Затем небольшая куча математики, и вы можете заранее узнать нагрузку на каждую деталь (с некоторым уровнем неопределенности для учета производственных отклонений). Наука хорошо известна.
Даже если вы думаете, что разработка программного обеспечения когда-нибудь достигнет этого, это еще не так. Мы не можем надежно предварительно рассчитать производительность новых программных систем. Мы не можем точно сказать, как люди будут взаимодействовать с системой, пока они этого не сделают. Мы не узнаем, как масштабируется система, пока это не произойдет. Пока не будет чего измерять, все, что у нас есть, — это обоснованные догадки. Это не «Угадай дважды, один раз отрежь». Это глупо и бесполезно.
Поскольку изменения в программной инженерии обратимы, гораздо лучше сокращать, измерять, снова сокращать, снова измерять и так далее, пока результат не станет достаточно хорошим. Здесь нет никаких предположений, за исключением первоначальной гипотезы о том, что определенные изменения в определенном месте приведут к улучшениям — гипотеза, которая будет быстро подтверждена или опровергнута последующими измерениями. Таким образом, инженеры-программисты в меньшей степени являются инженерами и больше похожи на исследователей программного обеспечения. Бесполезно разрабатывать жесткие планы вокруг гипотез, которые вряд ли все верны.
Чтобы было ясно, только потому, что изменение программного обеспечения дешево, не означает, что необнаруженный сбой дешев. Программное обеспечение по-прежнему способно производить чрезвычайно дорогостоящие ошибки. Подход к снижению этого риска (уровни тестирования, культура качества, расстановка приоритетов на основе режимов сбоя, изящный/безопасный сбой и т. д.) не меняется в среде Agile. Вам все еще нужно ловить ошибки. Вам по-прежнему необходимо создавать устойчивые системы. Как это сделать, когда части системы неизмеримы заранее (и большую статью в другой раз).
Кроме того, тот факт, что изменения в программном обеспечении обратимы, не означает, что изменения в продукте обратимы. Исправление разочаровывающего пользовательского интерфейса технически не так уж плохо. Вам не нужно покупать детали для совершенно нового пользовательского интерфейса или тратить кучу денег, чтобы снести плохой. Этот разочаровывающий пользовательский интерфейс, вероятно, имел больше технических эффектов. Вероятно, это привело к ухудшению репутации у пользователей. Возможно, это привело к негативным отзывам. Такие вещи менее обратимы. Отчасти поэтому между инженерами и остальной частью компании обычно возникают трения.
Но дело в том, что почти каждая крупная разработка за последние несколько десятилетий только усиливала обратимость изменений программного обеспечения. Благодаря микросервисам изменения можно создавать, развертывать и масштабировать независимо друг от друга. Непрерывная интеграция и развертывание (наряду с распространением автоматических тестов) помогают инженерам измерять сокращение, как только оно сделано. Облачные среды позволяют разработчикам программного обеспечения измерять свои сокращения в системах в масштабе. Развитие программного обеспечения как услуги означает, что изменения в программном обеспечении больше не нужно доставлять заказчику, а только в центр обработки данных. Kubernetes и ему подобные делают даже подготовку инфраструктуры более похожей на обратимое изменение программного обеспечения. Ни один из них не поможет вам спланировать до написания кода.
Тем не менее, компании по-прежнему подходят к программному обеспечению с тем же мышлением, что и мой папа, когда он делает скворечник. Они пытаются измерить то, что не поддается измерению, а потом удивляются, почему результаты неверны. Они тратят массу времени и усилий на планирование, чтобы сэкономить немного времени и усилий на исправлении ошибок. Вот что происходит, когда люди рассматривают Agile как процесс, а не как культуру, где люди предпочитают определенные компромиссы.
«Семь раз отмерь, один раз отрежь» — отличный способ снизить риск необратимых действий. Но когда ваши действия обратимы, ваш риск уже снижен. Если это плохо, просто отмените изменение! Да, вы потратили некоторое время и усилия, чтобы внести изменения, но вы все равно собирались это сделать. Когда изменения обратимы, Agile-мышление с небольшими итеративными сокращениями — лучший способ построить.
