Перевод подготовлен редакцией  итеративно-функционального метода, новейшей альтернативы Agile и Kanban.

Гибкость (agility) — это, без сомнения, полезная вещь, и Манифест Agile не выглядит необоснованным. В сравнении с устаревшей практикой, известной как «Waterfall», Agile безусловно имеет свои преимущества. Тем не менее, многие аспекты Agile на практике оказываются весьма вредными, и я не считаю, что дихотомия «Agile/Waterfall» вообще является полезной концепцией.

Существует одна из разновидностей Agile, называемая Scrum, которую я наблюдал на практике, и она реально может привести к гибели компании. Под словом «гибель» я не имею в виду «ухудшение культуры». Я говорю о том, что акции этой компании упали почти на 90 процентов за меньше чем два года.

Что такое Agile?

Agile зародился в веб-консалтинге, где в своё время имел определённую ценность: работая с капризными клиентами, которые не знают, что именно им нужно, обычно приходится выбирать между двумя подходами. Первый — это управлять клиентом: установить ожидания, адекватно взимать плату за доработки и поддерживать отношения на основе равенства, а не подчинения. Второй — это принять дурное поведение клиента (как, например, приходится делать многим дизайнерам) и адаптировать рабочий процесс под его ограничения.

Программисты, как правило, не слишком сильны в управлении клиентами. Мы люди конкретные. Нам нравится работать с системами, где поведение чётко определено. Это делает взаимодействие с нетехническими людьми для нас более сложным, чем следовало бы, потому что мы склонны воспринимать каждую просьбу буквально, а не пытаться понять, чего на самом деле хочет клиент. Корпоративный Agile, лишённый контекста консалтинга, идёт ещё дальше и предполагает, что инженеры недостаточно умны, чтобы понять, что нужно их «внутренним клиентам». В результате работа дробится на «пользовательские истории» и «итерации», что часто лишает программистов морального удовлетворения от ее выполнения, а также исключает возможность формулирования долгосрочной стратегии развития.

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

Жестокая прозрачность

Существует множество трендов в работе, которые делают карьеру программиста крайне непривлекательной, особенно для тех креативных и умных людей, которые будут нужны для формирования следующего поколения профессионалов.

Оупен-спейсы — это самый яркий пример. Они не способствуют продуктивности. В них трудно сосредоточиться. Они антиинтеллектуальны, поскольку люди начинают бояться быть пойманными на чтении книг (или просто на размышлениях) во время работы. Когда вы заставляете людей играть в игру "попытайся казаться продуктивным", в дополнение к их рабочим обязанностям, они становятся менее продуктивными. Открытые офисы вообще не имеют отношения к продуктивности. Это скорее вопрос корпоративного имиджа. Стартапы, поддерживаемые венчурным капиталом, которые должны были «удовлетворять» инвесторов, использовали такие офисы, чтобы их рабочие пространства выглядели «занятыми». Если сказать прямо, программист в открытом офисе ценится больше как офисная мебель, чем за код, который он пишет. По ряду культурных причин это сделало открытые офисы «крутыми» и «молодёжными», и теперь эта тенденция проникла в корпоративный мир в целом.

Хорошо известно, что креативные люди теряют свою креативность, если им приходится оправдывать себя в процессе работы. То же самое касается и программирования. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile, так часто неправильно применяемые, требуют, чтобы они предоставляли унизительную видимость своего времени и работы, несмотря на отсутствие взаимности. Вместо того чтобы работать над реальными долгосрочными проектами, которые могли бы вдохновлять, их заставляют заниматься атомизированными «пользовательскими историями» и часто не позволяют работать над улучшениями, которые не могут быть связаны с краткосрочными, непосредственными бизнес-потребностями (часто исходящими сверху). Этот неправильный, но распространённый вариант Agile уничтожает концепцию собственности и превращает программистов в взаимозаменяемые шестеренки.

Scrum — это худший пример, с его нелепыми двухнедельными «итерациями». Он вызывает ненужный стресс из-за микрофлуктуаций собственной продуктивности. Нет абсолютно никаких доказательств того, что этот фуфломицин (snake oil) на самом деле делает процесс быстрее или лучше в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хорошо, потому что «работать будут быстрее». Я проработал программистом десять лет, как менеджер и как обычный сотрудник. Это неправда.

Конкретные недостатки «Agile» и Scrum

1. Бизнес-ориентированное программирование.

Agile часто продают в сравнении с «Waterfall». Что такое Waterfall?

Waterfall — это действительно ужасная модель. Это модель «работа катится вниз», при которой каждый уровень организационной иерархии выбирает то, что он считает «интересным», и передаёт остальное дальше по цепочке. Проекты определяются руководителями, дизайн делают архитекторы, личные дедлайны устанавливают мидл менеджеры, реализацию выполняют самые низшие работники (программисты), а операции и тестирование передаются нижним уровням работников. Это крайне дисфункционально. Когда люди чувствуют, что все важные решения уже приняты, у них нет мотивации делать свою работу наилучшим образом.

Waterfall воспроизводит социальную модель дисфункциональной организации с чётко определённой иерархией. Agile, в свою очередь, часто воспроизводит социальную модель дисфункциональной организации без чётко определённой иерархии.

У меня смешанные чувства по поводу должностей, таких как «сеньор» или «принципал» и подобных. Они имеют значение, и, вероятно, я бы не согласился на работу ниже уровня принципала или директора, но мне не нравится, что они имеют значение. Если посмотреть на Scrum, то он создан для того, чтобы лишить прав старших, наиболее опытных инженеров, заставляя их следовать процессам (работать только с элементами из бэклога, тратить 5-10 часов в неделю на совещания по статусам), предназначенным для людей, которые только начали писать код месяц назад.

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

Agile, как он часто реализуется на практике, увеличивает частоту обратной связи, но не даёт инженерам реальной власти. Это невыгодная сделка, потому что это означает, что они будут чаще «дергать» или наказывать, если что-то займет больше времени, чем «должно». Это вызывает много стресса и спешки, но почти не даёт того, что действительно важно: создание отличных продуктов.

Силиконовая долина за последние пять лет сделала много ошибок, но одно из правильных решений, которое она приняла, — это концепция компании, управляемой инженерами. Не всегда лучше, чтобы инженеры управляли всей компанией, но когда инженеры руководят инженерным отделом и устанавливают приоритеты, выигрывают все: инженеры довольны своей работой (или, что лучше, самостоятельно определяют свою работу), а бизнес получает гораздо более качественное инженерное решение.

Если ваша компания изначально предполагает бизнес-ориентированную модель управления — это нормально. Просто тогда не нанимайте штатных инженеров, если вы рассчитываете на действительно сильных специалистов. В бизнес-центричных компаниях вы можете привлечь лучших инженеров только как консультантов (от $200 в час и выше, причём ставки быстро растут), но не как постоянных сотрудников. Хорошие инженеры хотят работать в компаниях, где инженерия управляет процессом, где они сами определяют, над чем работать, и не обязаны отчитываться перед «scrum-мастерами», «владельцами продукта» и слоями нетехнического менеджмента.

В конечном счёте, и Agile в его практическом применении, и Waterfall — это разновидности бизнес-ориентированной инженерии. Именно поэтому ни одна из этих моделей не способна стабильно производить качественное ПО или делать сотрудников по-настоящему счастливыми.

2. Культура вечной джуниорности

В инженерной культуре, увы, укоренилась идея «вечного джуниорства», которая подпитывает (глубоко ошибочное) представление о программировании как «игре для молодых», несмотря на то, что почти ни один из действительно выдающихся инженеров не является молодым.

Проблема с двухнедельными итерациями (или «спринтами») и пользовательскими историями в Agile в том, что в этой системе нет выхода. Там нет условия вроде: «Когда мы достигнем [X], мы сможем от этого отказаться». Всё устроено так, чтобы продолжаться бесконечно: бизнес-центричная инженерия, бесконечные статусы и стендапы никуда не исчезнут. Архитектура, исследовательская работа и настоящая продуктовая разработка не считаются частью обязанностей программиста, потому что это не укладывается в формат мелких «историй» или двухнедельных итераций.

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

Однажды я работал в компании, где менеджер по продукту сказал, что разница между старшим инженером и младшим инженером заключается в способности давать точные оценки. Нет, это оскорбительно. Я ненавижу оценки, потому что они порождают политику и на самом деле не ускоряют выполнение работы или не делают её лучше (наоборот, это чаще всего так).

Худшее в оценках — это то, что они подталкивают компанию к выполнению работы, которую можно оценить. Это заставляет программистов отдавать предпочтение низкодоходным, простым задачам, которые бизнесу на самом деле не нужны (даже если растерянные средние менеджеры думают иначе), но которые «безопасны». Всё, что действительно стоит делать, имеет ненулевой шанс на провал и слишком много неизвестных, чтобы оценки были полезны. Фокус Agile на краткосрочной бизнес-ценности в конечном итоге отталкивает людей от работы, которая действительно необходима компании, в пользу управления репутацией каждого программиста в реальном времени.

Эта культура говорит мне, что программирование — это детское занятие, которое следует оставить до 35 лет. Я с этим не согласен. На самом деле, я считаю, что это вредно; мне чуть за 30, и я чувствую, что только начинаю становиться хорошим программистом. Прогонять наших старших коллег только потому, что они достаточно опытны, чтобы понять, что этот процесс «Agile»/Scrum не имеет ничего общего с информатикой (computer science) и не приносит пользы — ужасная идея.

3. Краткосрочность планирования опасна и глупа

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

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

В рамках Agile технический долг накапливается и не решается, потому что люди из бизнеса, принимающие решения, не видят проблемы до тех пор, пока она не станет слишком большой или, по крайней мере, слишком дорогой для исправления. Более того, отдельные инженеры оцениваются и вознаграждаются исключительно по метрикам текущей двухнедельной «итерации», что означает, что никто не планирует работу на пять «спринтов» вперёд. Agile — это просто один бессмысленный, близорукий «спринт», идущий за другим: без прогресса, без улучшений, только задачи за задачей.

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

4. Это не учитывает системный подход к построению карьеры

Атомизированные пользовательские истории не способствуют развитию карьеры инженеров. К 30 годам от вас ожидается, что вы сможете работать на уровне всего проекта и что вы, по крайней мере, готовы выйти на более высокий уровень, например, в инфраструктуру, архитектуру, исследования или руководство.

В экстренных ситуациях, будь то консалтинг, стремящийся угодить важному клиенту, или корпоративная «комната войны» (war room), целостность карьеры может подождать. Немногие откажутся выполнить пару недель неприятной или несоответствующей их карьерному пути работы, если это действительно важно для компании. Важность работы создает карьерные преимущества. Если вы можете сказать: «Я был в комнате войны и общался 20 минут в день с генеральным директором», это оправдывает выполнение рутинной работы.

Однако, когда нет экстренной ситуации, программисты ожидают, что их карьерный рост будет восприниматься всерьез, и они уйдут, если это не так. Сказать «Я был в Scrum-команде» означает «Пни меня». Одно дело делать рутинную работу, потому что генеральный директор понял, что неприятная задача принесет миллионы долларов ценности (и он соответственно вознаградит за это), но выполнять рутинную работу только потому, что вам назначили «пользовательские истории» и задачи в Jira, показывает, что вас воспринимали как неудачника.

5. Его цель — выявить слабых сотрудников, но Agile / Scrum имеет неприемлемо высокий уровень ложных срабатываний.

Scrum продается как процесс для «удаления препятствий», что является красивым способом сказать «выявление тунеядцев». Проблема заключается в том, что он создает больше неэффективных работников, чем находит. Это система слежки, требующая от инженеров предоставить детализированную информацию о своей работе и скорости продуктивности.

Есть заблуждение, которое часто встречается в дебатах о гражданских свободах: аргумент «ничего скрывать». Некоторые утверждают, что вторжения в личную жизнь — например, со стороны правоохранительных органов — не имеют значения, потому что они сами не преступники. Это упускает несколько ключевых аспектов. Во-первых, законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей государство слежки — это состояние стресса.

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

Agile и особенно Scrum эксплуатируют заблуждение «ничего скрывать». Если только вы не являетесь «низкопроизводительным» - low performer - (охота на ведьм, не правда ли?), вам ведь не должно мешать ежедневный статус апдейт, верно? Единственные люди, которые будут возражать против оправдания своей работы с точки зрения краткосрочной бизнес-ценности, — это «тунеядцы», которые хотят украсть у компании, так ведь? Ну, нет. Очевидно, что это не так.

Часто именно лучшие сотрудники терпят самые большие потери, когда внедряется Agile/Scrum, потому что исследования и разработки фактически устраняются, а одержимость краткосрочными «итерациями» или спринтами означает, что нет места для чего-то, что действительно может не удаться.

Правда о неэффективных исполнителях заключается в том, что вам не нужен «Agile», чтобы выяснить, кто они. Люди знают, кто они. Причина, по которой некоторые команды перегружены незаинтересованными, некомпетентными или токсичными людьми, заключается в том, что никто не предпринимает с этим ничего. Это проблема управления на уровне людей, а не проблема процесса на уровне рабочего потока.

6. Эффект «Залитых виски глаз»

Существуют доказательства того, что агрессивное управление может подтолкнуть немного некомпетентных людей к тому, чтобы они стали немного более трудоспособными. Я называю это эффектом «залитыми виски глаз»: он превращает троек и четвёрок в пятёрок в ваших глазах, но делает вас настолько небрежными (sloppy), что семёрки и девятки не хотят иметь с вами ничего общего. Не в состоянии раскрыть свои творческие способности в системе, где всё нужно оправдывать с точки зрения краткосрочной бизнес-ценности, лучшие программисты уходят.

С точки зрения менеджера, не понимающего, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько первоклассных семёрок и выше уходят из-за «Великого Нового Scrum», а троечники и четвёрки становятся просто приемлемыми пятёрками. Проблема в том, что разница между программистом уровня «7» и программистом уровня «5» значительно больше, чем между «5» и «3». Если вы теряете своих лучших сотрудников и лидеров (которые могут не быть в лидерских позициях в организационной структуре), то незначительное улучшение некомпетентных работников, для которых и создан Scrum, не приносит пользы.

Scrum и Agile играют на том, что я называю «предвзятостью статуса». По сути, многие люди в бизнесе оценивают свой успех или неудачу не в объективных терминах, а исходя из достигнутой разницы в статусе. Скажем, рыночная стоимость программиста уровня «3» составляет $50,000 в год, а для программиста уровня «5» — $80,000. (На самом деле, зарплаты программистов сильно варьируются: я знаю троечников, зарабатывающих больше $200,000, и семёрок, получающих меньше $70,000, но давайте это опустим.) Уговорить программиста уровня «5» работать за зарплату программиста уровня «3» (в обмен на акции стартапа!) психологически воспринимается не как прибыль в $30,000 (что совсем немного), а как прибыль в 2 балла.

Agile/Scrum и культура дискриминации по возрасту в целом ориентированы на получение впечатляющих «статусных» выгод, а не на реальные экономические прибыли, которые обычно достигаются путем найма людей, которые принесут наибольшую ценность (даже если вам нужно платить на 50% больше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной стоимости).

Наименее осведомлены о том, какой социальный статус им «положен», молодые люди. Вы найдете 22-летнего программиста уровня 6, который думает, что он — уровень 3, и будет подчиняться Scrum, но 50-летняя женщина уровня 9, вероятно, знает, что она — 9, и может сдержанно согласиться на условия уровня 8.5, но она точно не согласится опуститься до уровня 3 или даже 6. Стремление к статусным выгодам, конечно, бесполезно. Эти баллы ничего не значат. В бизнесе выигрывают, зарабатывая больше денег, чем тратят на расходы, а не создавая маржу в бессмысленных статусных баллах. Возможно, существует целая индустрия, которая нанимает инженеров уровня 5 и обращается с ними (и платит им) как с 4-ми, но в нынешних рыночных условиях гораздо выгоднее нанять инженера уровня 8 и относиться к нему как к инженеру уровня 8.

7. Agile / Scrum недобросовестно продаётся.

Чтобы осветить этот момент, я сосредоточусь на Scrum. Некоторые утверждают, что Scrum — это «экстремистская версия Agile», а другие говорят, что это наименее гибкая версия Agile. (Возможно, это лежит в основе одной из проблем, ведь мы едва ли можем согласиться, что такое «Agile», а что — нет).

Что-то вроде Scrum имеет своё применение: очень ограниченное и временное. Нечестность в его маркетинге заключается в том, что его представляют как универсальное решение, подходящее для всех ситуаций на постоянной основе.

Для чего Scrum хорош

До того как увлечение Agile сделало его постоянным процессом, термин «Scrum» использовался для описания того, что корпорации могли бы назвать «красной кнопкой» или «экстренной ситуацией в War Room». Если возникала неожиданная, быстро развивающаяся проблема, собирали лучших людей и формировали кросс-функциональную команду.

Эта команда не имела чёткого менеджера, поэтому выбирался лидер (например, «Scrum-мастер»), которому давалась власть. Важно, чтобы он не был официальным «менеджером людей», поскольку ему нужно быть максимально беспристрастным. Поскольку кризис краткосрочный, карьерные цели участников могут быть поставлены на паузу. Это считалось «спринтом», потому что от людей ожидалось, что они будут работать максимально быстро, чтобы решить проблему, и потому что им будет разрешено вернуться к обычной работе после завершения. Также, в такой экстренной ситуации нужно чётко дать понять, что никто не оценивается индивидуально. Внимание сосредоточено исключительно на задаче.

Когда вы навязываете процесс и требуете односторонней прозрачности от всех работников, люди начинают чувствовать себя под наблюдением. У них возникает ощущение, что за ними следят, и что их сразу же сочтут «низкопроизводительными», как только их недельные флуктуации производительности пойдут не в ту сторону. В результате они получают стресс. Это дисфункционально. С другой стороны, когда вы собираете группу высококлассных исполнителей для решения конкретной временной кризисной ситуации, они не возражают против частых обновлений статуса, если знают, что причина в том, что ситуация требует этого.

Существует два сценария, которые должны прийти на ум. Первый — это корпоративная «комната войны», и если конкретные сотрудники (исключая топ менеджмент) проводят в режиме «комнаты войны» более 4 недель в год, значит, что-то не так с компанией, потому что чрезвычайные ситуации должны быть редкостью. Второй — это консалтинг, который пытается утвердиться на рынке или не умеет эффективно управлять клиентами и строить независимую репутацию, и поэтому вынужден работать в постоянном состоянии чрезвычайной ситуации.

Две проблемы

Таким образом, Scrum признаёт необходимость временно предоставлять чрезвычайные полномочия ответственным лидерам, которые делают всё, что считают нужным, чтобы завершить задачу, откладывая обсуждение на потом. Это нормально. Так иногда должно быть.

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

Кроме того, для амбициозного демагога (например, «scrum-мастера»?) гораздо впечатляюще быть видимым «убийцей драконов», чем избежать того, чтобы драконы вообще появились в деревне. Проблема с агрессивной настойчивостью Scrum в бизнес-ориентированной инженерии заключается в том, что она превращает в достоинство привлечение и уничтожение драконов (известных как «требования»), хотя, возможно, было бы более разумно не вызывать их из их пещер с самого начала.

«Agile» и Scrum глорифицируют чрезвычайные ситуации. Это первая проблема. Они представляют собой переосмысленную версию того, что в индустрии видеоигр называют «кранч», или кризис сроков. Работать так — это нежизнеспособно. Агрессивное внимание к индивидуальной производительности, отсутствие внимания к карьерным целям людей при распределении работы и обязательство работать только над объявленной главной приоритетной задачей — все это приносит много пользы в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе. Люди будут терпеть временную утрату автономии, но только если будет чётко понятно, когда они получат её обратно.

Вторая проблема заключается в том, что эти практики продаются недобросовестно. Вокруг обучения компаниям «Agile» в разработке программного обеспечения сформировалась целая индустрия. Проблема в том, что большинство основных идей не новы. Терминология свежа, но концепции в основном устарели и являются неудачными элементами «научного менеджмента» (который, кстати, далеко не был научным и не работал). Снова, эти процессы иногда могут быть эффективными для достижения чётко определённых целей в экстренных ситуациях, но постоянный Scrum — это катастрофа.

Если бы кто-то разобрался с негативными и позитивными сторонами «Agile» и Scrum, у меня не было бы такого предубеждения против этих концепций. Если у компании есть команда только из младших разработчиков, и нужно быстро сделать функционал, она может подумать о внедрении этих техник на короткий срок, с планом убрать их по мере роста сотрудников и увеличения гибкости сроков. Однако если бы Scrum продавался как то, что оно есть — набор экстренных мер, которые нельзя использовать для постоянного улучшения продуктивности — тогда было бы гораздо меньше покупателей, и индустрия консалтинга по «Agile» бы не существовала. Только через нечестный маркетинг этих техник (глорифицированный «кранч тайм», упакованный как постоянное решение) они становятся продаваемыми для корпоративного мира в целом.

Взгляд в будущее

Пришло время положить конец культуре вечной джуниорности, низкой автономии и агрессивного управления. Это не просто плохие идеи. Они гораздо более опасны, потому что существует целое поколение инженеров-программистов, которые усваивают их, не зная, что есть и другие подходы. Слишком много молодых программистов обречены на посредственность из-за идеи, что бизнес-ориентированная инженерия и «пользовательские истории» — это то, как всегда всё делалось. Этого нужно избежать; будущее целостности нашей отрасли может зависеть от этого. «Agile», по крайней мере в той извращённой форме, которую я видел в каждом из его применений, — это полная чепуха, не имеющая ничего общего с программированием и, конечно, с информатикой. Бизнес-ориентированная инженерия, в общем, — это тупик. Её следует вернуть в болото, откуда она пришла.