Термин «продавец змеиного масла» часто используется для описания людей, которые занимаются мошеннической маркетинговой практикой. Персонажи Дикого Запада, такие как Кларк Стэнли, рекламировали свой змеиный жир как чудесное лекарство от всех болезней. Но в 1916 году Химическое бюро правительства сша проверило мазь и обнаружило, что ее цена значительно завышена и ее ценность ограничена, и Стэнли был оштрафован на 20 долларов.
Но это еще не конец истории.
Вы, вероятно, используете змеиное масло
Змеиное масло не было полностью бесполезным. Хотя это правда и не соответствует заявленным на бутылке характеристикам, некоторые ингредиенты, такие как капсаицин и камфора, оказались ценными при использовании в законных целях.
Капсаицин, полученный из перца чили, теперь используется в средствах для обезболивания кожи, облегчающих мышечную и суставную боль. Это терапевтическое лечение, одобренное FDA. Камфора также широко используется в качестве противораздражительного средства, помогающего облегчить зуд от укусов насекомых. Это также популярный ингредиент для растираний груди, которые вы, вероятно, использовали в качестве противозастойного средства во время простуды.
Таким образом, хотя змеиное масло и не оправдало диких заявлений его торговцев, оно не было полностью бесполезным. Это справедливо и для индустрии программного обеспечения, поэтому умение отделять ценные ингредиенты от опровергнутых рецептов доставки программного обеспечения является важнейшим навыком.
Цена на водопад завышена и его ценность ограничена
Термин «водопад» часто используется как универсальное название для поэтапной поставки программного обеспечения, когда задачи выполняются в последовательном порядке, напоминающем водопад. Когда легковесный бунт сверг тяжеловесные модели того времени, это породило ошибочное мнение, что поэтапные модели программного обеспечения просто неправильны.
Но создатели этих старых моделей были обмануты, поскольку они все время говорили нам работать по-новому.
Источник: Производство больших программ. Герберт Д. Бенингтон. 1956.
В своей статье 1956 года «Производство больших программ» Герберт Бенингтон обсуждает концепции, которые мы сейчас назвали бы разработкой платформ. Бенингтон осудил идею нисходящего программирования, при котором спецификация заполняется до написания кода. Уинстон Ройс в своей статье 1970 года «Управление разработкой больших программных систем» советовал людям работать с небольшими постепенными изменениями, поскольку это уменьшит сложность и позволит организациям вернуться к предыдущей версии, если они движутся в неправильном направлении. Эти идеи вновь всплыли в спиральной модели Барри Бема.
Успех Agile во многом был обусловлен тем, как сторонники облегченной доставки программного обеспечения тщательно извлекли полезные ингредиенты из тяжеловесного рецепта змеиного масла, используемого в популярных процессах, доминировавших в отрасли в 1990-х годах. Они сохранили хорошие части и выбросили большую часть токсичных.
Понимание этого интенсивного процесса фильтрации – наш путь выхода из кризиса, который постоянно повторяется в нашей отрасли.
Повторяющийся кризис
Кризис возникает из-за тенденции руководства увлекаться процессами и отталкиваться техническими и культурными практиками. У них есть тяга вновь ввести элементы водопада, которые были умело удалены, и они хотят отказаться от важных техник, которые они не понимают (или которые кажутся тяжелой работой).
Увеличение веса процесса при снижении технического совершенства — это путь к разрушению.
Канонический пример этой ошибки управления относится к заре Agile. Во времена Agile-манифеста ведущим облегченным методом было экстремальное программирование (XP). В нем были элементы процесса, аналогичные Scrum, а также карта взаимосвязанных технических практик, которые позволяли поддерживать низкую стоимость изменений, что является ключом к поддержанию гибкости в долгосрочной перспективе.
Для менеджеров исключительная ориентация Scrum на процессы не представляла угрозы, в то время как акцент XP на технических навыках вселял страх в их сердца. Когда дело дошло до управления, Scrum был лидером. В результате мы потратили десять лет, пока Дэйв Фарли и Джез Хамбл не возродили и не обновили идеи XP в своей знаковой книге «Непрерывная доставка».
Конечно, Scrum не остановился на этом. Если у вас нет технического совершенства, элементы процесса Scrum не дают результатов, ожидаемых от гибкой разработки программного обеспечения. В результате руководство отреагировало увеличением объема процесса для «работы в масштабе» или «удовлетворения потребностей предприятия». Настоящей мотивацией этого, конечно же, был комфорт процесса, работающий против сложности реальности, которую можно решить только социальными и техническими средствами.
Когда DevOps впервые появился, его можно было охарактеризовать как разрушение разрозненности между разработкой и эксплуатацией. Эта идея была доработана, чтобы согласовать цели двух команд и побудить их к более эффективному сотрудничеству. Все были согласны с этим, пока десятилетие исследований не выявило необходимость этих устрашающих технических элементов, необходимость трансформационного лидерства и ценность бережливого управления продуктами. Когда DevOps стал слишком реальным, желание сбежать усилилось.
Спешка от сложных реалий к упрощениям — это ошибка, которую мы постоянно совершаем. Грубо говоря, падение всех хороших методов является результатом того, что менеджеры в ужасе бегут от вещей, которые они не понимают так хорошо, как следовало бы.
Найдите настоящее лекарство
Проблема индустрии программного обеспечения заключается не в том, что у нас слишком много методов и практик; дело в том, что нас слишком мало. Дело в том, что мы утратили способность критически относиться к ним. Мы принимаем оптовую торговлю, когда нам следует выбирать наиболее выгодные условия. Мы следуем рецептам, когда нам нужно экспериментировать.
Самые эффективные команды разработчиков программного обеспечения — это не те, кто нашел идеальную структуру. Это те, кто научился извлекать пользу из несовершенных, кто понимает, что каждая практика зависит от контекста, и кто постоянно задается вопросом, действительно ли то, что они делают, помогает.
Змеиный жир преподал нам важный урок, но это был не тот урок, о котором мы думали. Дело не в том, что старые средства бесполезны. Это то, на что нам нужно выйти за рамки маркетинга, чтобы понять, что на самом деле работает. То же самое относится и к практикам разработки программного обеспечения. За каждой структурой, методологией и передовым опытом лежит ядро понимания, которое решает реальную проблему.
Наша работа не в том, чтобы бездумно следовать или бездумно отвергать. Речь идет о понимании, извлечении и разумном применении.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Стив Фентон — октонавт в Octopus Deploy, руководитель сообщества DORA и шестикратный обладатель награды Microsoft MVP с более чем двадцатилетним опытом разработки программного обеспечения. Он написал книги по TypeScript (Apress, InfoQ), Octopus Deploy и веб-операциям…. Подробнее от Стива Фентона.
