—
10.11.2024
Текст написан в 2020 году (обновлен в 2022). В паре источников, которые на регулярной основе посматриваю, данный материал охарактеризовали как «эта статья остается самой важной критикой Agile, которую мы когда-либо читали».
Честно говоря, тема Agile меня интересует крайне опосредствованно, и эти рецензии вряд ли бы заставили сохранить статью в архив. Но оказалось, что автор фундаментально подошёл к вопросу и рассмотрел тему в гораздо более широком контексте: временном и тематическом.
Поэтому, несмотря на заголовок и отзывы, текст отнюдь не только про Agile. Это скорее:
Основными триггерами для сохранения эссе в архив (т.к. отслеживаю данные тематики) стали:
Традиционная ремарка ➜ Если позволяет знание английского, то лучше читать оригинал статьи на сайте автора. Если заметите совсем уж неточные формулировки в переводе, то можете написать про них в VK, подкорректирую текст.
Agile Manifesto — это иммунный ответ программистов на плохое управление. Документ является выражением травмы, и его интеллектуальные потомки продолжают нести этот багаж. Хотя эпоха Agile принесла замечательные достижения в методах управления проектами и инструментах разработки, она остается тактическим, техническим и, в конечном счете, реакционным движением. Пока Agile остается в этом положении, он будет подвержен обратным эффектам, уязвимый для тех самых проявлений плохого управления, для противодействия которым он изначально создавался.
Чтобы начать процесс исцеления, важно рассматривать Agile в более широком контексте. Многие важные идеи, связанные с Agile, появились на 20-30 лет раньше, чем он был разработан. Это не обвинение в плагиате; скорее, это утверждение о том, что существуют особенности разработки программного обеспечения (на самом деле, я утверждаю в другом месте, что программное обеспечение — это особый случай творческой работы в целом), которые остаются неизменными даже по мере совершенствования техники и технологий, и поэтому в конечном итоге вы обязательно повторите эти паттерны. Паттерны включают в себя, но не ограничиваются следующим:
Поскольку травма по определению является чем-то, что вы не можете «преодолеть», и только со временем начинаете «понимать», я утверждаю, что Agile-o-сфера постоянно поднимает эти вопросы в ущерб решению других, потенциально более плодотворных проблем.
Collaboration! Так много усилий уходит на написание и обсуждение вопросов collaboration, а также на создание инструментов, облегчающих collaboration и дистанционное взаимодействие, при молчаливом предположении, что больше совместной работы всегда лучше. Цитируя Фредерика Брукса (mp3), чем больше collaboration, тем лучше — «это далеко не самоочевидное утверждение и, конечно, не универсально верное». Действительно верно, в той степени, в какой совместная работа способствует разделению труда, но сомнительно как часть чьей-либо деятельности. Поскольку затраты на коммуникацию увеличиваются пропорционально квадрату числа людей в команде — факт, на который обратил внимание Брукс в 1970-х годах, — на самом деле вам нужно как можно меньше collaboration (как части деятельности).
Одна из причин, по которой все это пристальное внимание к совместной работе имеет смысл, заключается в том, что вы всегда можете повлиять на динамику вашей команды, даже если вы не имеете существенного влияния на основные стратегические решения организации.
Я уверен, что эти вещи существуют в той или иной форме; дело в том, что им не уделяется так много внимания.
Все, что выше по цепочке, чем управление проектами (Anything higher up the chain than project management)
За 20 лет Agile дал нам стендап-встречи, спринты, парное программирование, пользовательские истории, DevOps и непрерывную интеграцию. Это все тактические вещи. Контрактам уделяется немного внимания, но это не сравнится с тем вниманием, которое уделяется управлению проектами снизу. Где люди думают и говорят, например, об Agile procurement? Или об Agile enterprise resource planning? Это важно, потому что неудачи в реализации принципов Agile часто легко диагностируются как побочные эффекты ограничений устаревших procurement и contracting практик.
Градиент специфичности (A specificity gradient)
Software беспрецедентно по своей низкой стоимости разработки — по сравнению с hardware. Однако код, возможно, является самым дорогим средством выражения идей (если только вы не пишете на мраморе или чем-то еще). Популярный мем о превращении продукта из скейтборда в велосипед, мотоцикл или автомобиль — это милая история, но способ, которым программное обеспечение на самом деле создается, больше похож на переход от двигателя к трансмиссии, к монококу, к интерьеру.
За исключением того, что программное обеспечение совсем не похоже на автомобиль: если на то пошло, оно больше похоже на университетский городок, где разные здания являются самостоятельными полноценными артефактами, но слабо связанными друг с другом, образуя при этом единую службу (или, по сути, многочисленные службы, каждая из которых едина и работает параллельно). Вполне разумно, что некоторые части находятся в процессе строительства, в то время как другие в стадии планирования. Взятые в целом в любой момент времени, некоторые части системы будут иметь больше деталей (то есть они будут реализованы), а другие — меньше. Поэтому наши представления об итерации и инкрементности должны также оставлять место для других носителей, помимо кода.
Концептуальная чертова целостность (Conceptual friggin’ integrity)
Единственная идея из 1970-х годов, которая наиболее заметно отсутствует в дискурсе Agile, — это концептуальная целостность. Это — еще один вклад Брукса — примерно соответствует состоянию наличия единой ментальной модели как проекта, так и пользователя, разделяемой всеми членами команды. Концептуальная целостность делает продукт как более простым в разработке, так и более простым в использовании, потому что эта целостность передается как команде разработчиков, так и пользователю (и, если повезет, также высшему руководству) через продукт.
По словам Брукса, без концептуальной целостности «будет столько же ментальных моделей, сколько людей в команде». Такое положение дел требует, чтобы кто-то имел последнее слово в стратегических решениях. Кроме того, от этого (единственного) человека требуется наличие достаточно разнообразных знаний, чтобы мысленно описать — и, таким образом, иметь видение — весь проект во всех важных аспектах, пускай даже не с точностью до последней строки кода.
Кейфеб — термин из реслинга. Относится и к самой концепции изображения заведомо инсценированного зрелища как реального, и к искусству поддержания иллюзии.
Любой приверженец Agile может сказать вам, что Waterfall плох, и что если вы не используете Agile, вы обязательно используете Waterfall. Однако очевидно, что сравнительно немногие на самом деле читали статью Waterfall 1970 года (которая на самом деле не использует термин «Waterfall»). Если бы они это сделали, они бы узнали, что то, что они испытали — или, что более вероятно, услышали — было тем, что автор статьи назвал неправильным способом управления программным проектом. Можно даже задаться вопросом, почему разработчики в конечном итоге использовали такую заведомо плохую практику в течение стольких лет.
Существует история о том, что так называемое «большое проектирование наперед» — еще один лозунг Agile — в прошлом было скорее необходимостью, потому что:
Более того, есть аргумент, что рассматриваемый продукт должен выйти на рынок как можно быстрее, чтобы обеспечить преимущество первопроходца, или, возможно, в более мягкой форме, идея должна быть немедленно протестирована на рынке, чтобы убедиться, что это то, что хотят люди. Ни одно из этих утверждений не является ложным (кроме, может быть, последнего), но они также не являются всей правдой.
В частности, не все программное обеспечение является веб-приложением. Действительно, значительная часть программного обеспечения не является потребительским продуктом или даже не является «продуктом» вообще. Мы не учитываем объем, например, встраиваемых систем и одноразовой инфраструктуры. У первых цикл выпуска привязан к их хостовому оборудованию; последние вы можете обновлять, когда вам это будет достаточно удобно. Обе категории программного обеспечения существовали 50 лет назад, как и сегодня, и будут существовать в обозримом будущем: в 2020 году существует множество систем, которые фактически не подлежат обновлению (например, запущенных в космос); в 1970 году было множество систем, в которых вы могли внедрять новый код прямо в работающую программу (например, Lisp и Smalltalk — и это не считая всех тех, в которых это технически не предполагалось).
История о том, что раньше все было медленно, а теперь все быстро — и технологии, и рыночные силы — недостаточна для объяснения повсеместного принятия того, что стало называться Waterfall. История особенно плохо подходит, учитывая, что выдающиеся деятели в разработке программного обеспечения выступали за пошаговую и итеративную разработку с обратной связью от пользователей, вплоть до самой оригинальной статьи Waterfall 1970 года.
Я хочу, чтобы вы вместо этого рассмотрели возможность того, что Waterfall появился и продолжает существовать для удобства менеджеров: людей, чьи методы унаследованы от военного и гражданского строительства, и которые, больше всего на свете, нуждаются в том, чтобы вы обещали им что-то конкретное, а затем выполнили точно то, что вы им обещали, когда вы обещали это сделать. Существует множество угловых офисов, чей обитатель, если его заставят выбирать, предпочтет отсутствие неожиданностей существенному результату.
Эта альтернативная теория могла бы дополнительно объяснить запросы предложений (RFPs), которые настаивают на гибких процессах, но в то же время требуют предварительной формальной спецификации с подробным описанием feature milestones — или, как они любят их называть, «фаз» — и соответствующих им сроков.
Мое последнее замечание касается риторических рассуждений о проектировании как чего-то неотъемлемо принадлежащего Waterfall, и, следовательно, плохого и препятствующего выпуску продукта. Это не более чем провокация, совершаемое не столько профессиональными менеджерами (хотя они могут подписаться под этой позицией, если будут знать, что она доступна), сколько встревоженными основателями стартапов, которые беспокоятся о том, что их деньги кончатся раньше, чем они начнут их зарабатывать. Разработка программного обеспечения, опять же, связана с поиском ответов на тысячи вопросов. На некоторые из этих вопросов можно ответить только с помощью кода, на другие — никогда. Нет ничего, что мешает этим операциям выполняться параллельно, за исключением случаев, когда выполнение одной из них действительно зависит от выполнения другой.
Feature — это единица выходных данных программиста, которая примерно соответствует подпрограмме (одной или нескольким; функциям, методам, как бы вы их ни называли). Features работают как элемент управления, потому что они проявляются в конечном продукте, и их зависимость от времени, затрачиваемого программистом (programmer-hours), настолько близка к линейной, насколько это возможно.
Features также работают на маркетинг. Поскольку никто не может отрицать, что они существуют, удобная тактика — просто подсчитать их: «В нашем последнем релизе более 100 новых features!» Аналогично, каждый раз, когда в сообщении появляется что-то вроде «наш продукт позволяет вам...», речь идет о features. Действительно, отделы маркетинга во всем мире были бы брошены на произвол судьбы без почтенной Feature, на которую можно было бы опереться.
Features не работают в том смысле, что ими можно легко играться (манипулировать). Хрупкая и поверхностная реализация, сделанная быстро, наберет больше внутренних очков, чем надежная и полная. Если вопрос звучит «есть ли в продукте A feature X», то ответ в любом случае будет «да». Это также делает features ненадежной основой для сравнения конкурирующих продуктов, поскольку вам необходимо серьезно изучить их, чтобы определить, насколько они хороши.
Мы используем термин «фабрика функций» (feature factory) как уничижительный для обозначения компаний, которые пристрастились к добавлению features, одновременно накапливая неисчислимый так называемый технический долг. Эта ситуация создается руководством для удобства маркетинга, и я скептически отношусь к тому, что более верное применение принципов Agile исправит ее. Действительно, я подозреваю, что процессы Agile конституционно уязвимы для такого рода компромиссов.
Однако есть еще один объективно исчисляемый феномен, связанный с разработкой ПО, и это поведение (behaviour). Вопрос «выполняет ли продукт действие X, опционально при условии Y?» также является эмпирическим вопросом с ответом «да» или «нет». Программисты должны быть знакомы с этим шаблоном; именно так пишутся наборы тестов.
Поведение имеет преимущество перед features в том, что вы можете описать любую feature в терминах поведения, но вы не можете описать поведение в терминах features. Это потому, что features видны, пока программное обеспечение неактивно (например, маркетинг может делать скриншоты и печатать их в журналах), тогда как поведение видно только во время работы программного обеспечения. Более того, наличие feature может указать пользователю только на то, достижима ли цель, а поведение определит, насколько болезненным (или нет) будет достижение этой цели.
Последнее преимущество поведения, которое я здесь рассмотрю, заключается в том, что оно стирает грань между «исправлением ошибок» и «созданием features» и объединяет их в единый процесс «лепки поведения» (sculpting behaviour). Количество features может увеличиваться не так быстро (что совсем неплохо), но поведение продукта будет неуклонно возрастать с точки зрения тонкости и соответствия. Я также ставлю на то, что поведение менее поддается манипуляциям, потому что любая попытка будет выглядеть совершенно очевидной и глупой. Отдел маркетинга может сам позаботиться о себе, изучая корпус в поисках узнаваемых features; они и так уже это делают.
Как и любое другое творческое начинание, разработку программного обеспечения невозможно ускорить настолько, насколько мы можем устранить явления, которые ее замедляют. Достижения в процессах и инструментах, а также вычислительных ресурсах для их запуска можно интерпретировать как делающие именно это. В результате разработчики могут тратить большую часть своего времени на логику приложения (я на самом деле просто выдергиваю это утверждение из своей задницы и на самом деле имею основания сомневаться в нем). Сама логика приложения становится все более грубый и крупнозернистой с каждым годом (coarser and coarser-grained). В идеале вы могли бы просто сказать компьютеру, что вы хотите, и он бы это сфабриковал (fabricate it), но если бы вы могли это сделать, то не было бы необходимости в программистах.
Даже в мире, где не будет программистов, все равно придется разбираться — пусть уже и не в коде — в том, что вы хотите сказать компьютеру, чтобы он сделал для вас, как вы хотите, чтобы он себя вел. По-прежнему нужно принимать множество решений, помимо того, на каком фреймворке вы его напишете, используете ли вы NoSQL, или как вы разместите source tree. Если отбросить решения, которые связаны с тем, чтобы вообще заставить артефакт работать (с технической точки зрения), то останутся решения о том, работает ли он лучше одним способом, чем другим. Большинство из этих решений будут результатом проб и ошибок, и значительная часть из них будет связана с обратной связью от пользователей.
Полезно знать, что люди «открывали лучшие способы разработки программного обеспечения» задолго до того, как был написан Agile Manifesto, потому что это помещает его в контекст. Это позволяет нам понять конституционные ограничения и подумать о том, как выйти за их пределы.
Парадигма развития, которая может быть истолкована извне как придающая большое значение скорости — или, я полагаю, быстроте (это, в конце концов, векторная величина) — неизменно будет находиться под постоянным политическим и экономическим давлением, требующим ускорения. Из литературы не ясно, ожидали ли этого подписавшие Манифест (на самом деле они прямо упоминают постоянную частоту поставок). Если бы вместо этого вы утверждали, что работа представляет собой постоянные открытия (continual discovery), что она происходит с одной скоростью и потенциально может продолжаться бесконечно, вы, возможно, смогли бы сами задавать себе темп.
Я лично сталкивался с этими статьями и книгами, пропагандирующими принципы, известные в литературе по Agile. Я уверен, что есть и другие.
1970: Managing the Development of Large Software Systems (pdf). The original Waterfall paper by Winston Royce, in which he introduces the Waterfall model as an obvious and deliberate straw man, and makes a pretty clear case for a feedback loop.
1971: Program Development by Stepwise Refinement. An important paper on iteration by Niklaus Wirth.
1975: The Mythical Man-Month. The quintessential volume on software design and project management, by Frederick Brooks.
1980: Programs, Life Cycles, and Laws of Software Evolution. One of the agglomerating papers on Meir Lehman’s Laws of Software Evolution, which date back to 1974.
1981: Software Engineering Economics. Most of this 800-page tome by Barry Boehm is about estimating Waterfall-esque projects, but the introductory chapters deal with, among other things, uncertainty and feedback from users.
1988: A Spiral Model of Software Development and Enhancement. A subsequent meditation by Boehm on incrementalism, iteration and risk.
Я также должен отметить, что хотя это несколько косвенно связано с содержанием этого конкретного документа, то, что заставило меня достаточно напрячься, чтобы написать его, — это эпизод подкаста Laura Klein и Kate Rutter, Problems with Agile UX.