Что такое Agile и откуда он взялся?

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

На встречах они не обсуждали функциональность продукта, а говорили о «пользовательских историях» – маленьких повествованиях, описывающих фичи. Каждой такой истории присваивались «story points» — условные единицы, оценивающие объём усилий, необходимых для выполнения задачи. Каждое утро они проводили «стендапы» – короткие собрания, на которых все стоят. В центре их офиса стояла доска, на которую они клеили стикеры и передвигали их по колонкам в зависимости от статуса задачи. Они работали «спринтами» – двухнедельными циклами, посвящёнными определённым задачам.

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

Так я и узнала, что такое Agile — метод управления разработкой, который получил колоссальную популярность в технической среде и, всё чаще, за её пределами (один TED-спикер даже рассказывал, как внедрил Agile дома, в семье).

Честно говоря, я была впечатлена. В своей работе я часто чувствовала себя потерянной: не до конца понимала, продвигаюсь ли я вперёд или делаю что-то действительно важное. А разработчики, казалось, точно знали, что делают. Если возникала проблема — ничего страшного, они просто с ней разбирались. Они понимали, что требования будут меняться, и двухнедельные спринты позволяли гибко перестраиваться: заменить одну фичу на другую или перейти на другой фреймворк.

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

Меня это заинтриговало — Agile отличался от всего, что я знала раньше. Мне стало интересно: откуда он взялся и почему?

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

Как из гиков сделали инженеров

Кризис в разработке ПО начался ещё до того, как появилось само слово «программное обеспечение». На конференции 1954 года, которую провели в Wayne State University в Детройте, лидеры отрасли, госструктур и академии обсуждали надвигающийся дефицит подготовленных программистов. Термин «software» в значении прикладного программирования впервые появился в печати лишь четыре года спустя — в статье статистика Джона Тьюки. К середине 1960-х в США работали как минимум сто тысяч программистов, но по оценкам специалистов требовалось ещё около пятидесяти тысяч.

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

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

Однако практика показала: кодинг — это не только наука, но и искусство. Как пишет Клайв Томпсон в книге Coders (2019), важнейшие прорывы совершали длинноволосые гики, обитавшие по ночам в университетских лабораториях. Хакеры считали себя скорее ремесленниками, чем просто логиками. Невозможность физически потрогать программу (в отличие от носителя) делала ПО более абстрактным и загадочным, чем любое другое инженерное творение. А постоянные изменения в «железе» лишь усиливали нестабильность почвы под ногами.

Тем временем бурно развивалась сфера автоматизации офисных процессов — «электронная обработка данных». Огромные машины, арендованные у IBM, становились символом технологически продвинутого бизнеса. Но им требовались целые команды специалистов: проектировщики программ, операторы, табуляторы. Руководители негодовали: "компьютерщики" становились всё более необходимыми, но отличались от "нормальных" сотрудников — и внешне, и по манере работы. Их проекты было невозможно оценить по времени и бюджету. Знаменитый Фредерик Брукс сравнил программные проекты с оборотнями: начинают как милые щенки, но быстро превращаются в "монстров сорванных сроков, раздутых бюджетов и недоделанных продуктов".

К концу 1960-х кризис в разработке имел три стороны: нехватка специалистов, необходимость сделать процессы предсказуемыми и, с точки зрения бизнеса, — желание заставить программистов вести себя "нормально".

В духе профессионализации отрасли лидеры индустрии предложили программистам принять титул «инженер по программному обеспечению». Историки часто отслеживают это движение к конференции НАТО по Software Engineering в 1968 году. Организаторы указывали: программирование хаотично, трудноконтролируемо и сложно для менеджмента. Почему бы не позаимствовать методики (и статус) у традиционных инженеров? Это придавало профессии научный, управляемый облик. А главное — облегчало жизнь корпорациям: "инженеры" по определению более склонны к дисциплине. Историк Натаниэл Энсменгер пишет: "В интересах эффективного производства ПО чёрная магия программирования должна была уступить место инженерной науке".

Гоняясь за водопадами

И это сработало — в какой-то степени. Название «software engineering» закрепилось, и его значимость росла параллельно с ростом институционального престижа тех, кто писал ПО. Университеты начали использовать этот термин, обучая студентов "инженерным" методикам: математическим доказательствам, строгим процессам.

Компании с энтузиазмом взялись за организацию всё более понятной и управляемой группы разработчиков, и появились новые управленческие подходы. Один из них — Chief Programmer Team, разработанный в IBM, — предполагал наличие главного программиста, курирующего узкую команду специалистов. Другие подходы вводили многоступенчатую иерархию, где программисты оказывались в самом низу, исполняя решения вышестоящих администраторов.

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

Иронично, но сам термин "waterfall" впервые появился в статье, критикующей этот метод как нереалистичный. Однако и название, и философия прижились. Waterfall прекрасно вписывался в корпоративную иерархию. И привлекал менеджеров, потому что, как пишет Энсменгер: "Суть движения за software engineering была в контроле: контроле над сложностью, сроками, бюджетами и, возможно, в первую очередь — над упрямыми программистами". В этом методе всё должно было работать согласно инженерной логике.

Но довольно скоро индустрия снова оказалась в кризисе. В 1980 году университеты не могли обеспечить необходимое количество преподавателей, чтобы обучать растущий поток желающих стать инженерами-программистами. Ассоциация вычислительной техники (ACM) предупреждала: "Эта ситуация серьёзно угрожает способности компьютерных кафедр обеспечивать подготовку кадров, нужных как отрасли, так и обществу".

И это была не единственная проблема. Сам процесс разработки буксовал. Обещанная управляемость Waterfall оказалась иллюзией. Ни документация, ни процедуры не могли обеспечить предсказуемость сроков и затраченных ресурсов. Проекты разрастались, команды спорили, требования менялись. Крупнейшие компании с трудом доводили свои проекты до конца. Несмотря на усилия сделать разработку надёжной и управляемой, она становилась всё более хаотичной.

Инженеры жаловались, что громоздкие методики мешают им просто писать код. Бесконечные отчёты и собрания убивали мотивацию. Программирование 1990-х описывали как жизнь молодых специалистов в «Microserfs» Дугласа Коупленда или офисную апатию в фильме "Офисное пространство" Майка Джаджа — с тоской, скукой и подавленной яростью под поверхностью.

Хаки и папины джинсы

Появляется, пожалуй, самая неожиданная группа "рок-звёзд": семнадцать мужчин средних лет в хаки и джинсах, увлеченных управлением продуктами. Именно они, в феврале 2001 года на горнолыжном курорте Сноубёрд в Юте, составили знаменитый Agile-манифест — новую философию разработки программного обеспечения. Это было не первое их собрание: до этого они не раз встречались в разных составах, обсуждая подходы к разработке, но ни к чему конкретному не приходили. В этот раз всё изменилось.

На белой доске появились строки:

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: 

Люди и взаимодействие важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану 

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Манифест, дополненный двенадцатью принципами, точно попадал в болевые точки, о которых говорили инженеры. Waterfall исходил из того, что требования стабильны, а сбои — результат отклонения от плана. Agile же полностью отвергал высокоуровневые дорожные карты. В его основе была идея: пусть сами разработчики решают, как действовать, по мере изменения требований и технологий. Главное — меньше документации, больше реального кода. И — никакой бесконечной волокиты и митингов.

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

Организационные анархисты

Вероятно, сдвиг в восприятии природы разработки ПО произошёл не в 2001 году, когда был опубликован Agile-манифест, а в течение десятилетия до этого. Среди разработчиков, да и среди менеджеров, всё чаще звучало мнение, что программирование не вписывается в схемы и таблицы, на которые возлагали надежды аналитики. Как писал историк Стюарт Шапиро в 1997 году, программное обеспечение обладает «особой сложностью»: проблемы здесь «размытые, переменные и многослойные», поэтому редко поддаются какому-то одному подходу — они требуют гибридных и адаптивных решений. То есть не форм, отчётов и табелей учёта рабочего времени.

Кроме того, в 1990-е годы численность программистов росла скачкообразно, и компании вынужденно нанимали людей без классического ИТ-образования. У этих молодых сотрудников, скорее всего, не было той приверженности идее превращения программирования в точную науку, как у специалистов 1970–1980-х годов. Поэтому Agile-манифест стал не выстрелом по корпоративной бюрократии, а скорее восклицательным знаком — итогом многолетнего недовольства существующими управленческими моделями.

Тем не менее, несмотря на преданных сторонников, сам дух Agile — отказ от иерархического управления и детального планирования сверху — был рискованным. Он предполагал, что руководство хотя бы частично передаст контроль разработчикам. Большинство крупных компаний были к этому не готовы — по крайней мере, до 2010-х. Но между 2012 и 2015 годами, согласно данным консалтинговой компании Planview, более 50% команд разработки уже идентифицировали себя как «Agile».

Часть этой популярности объясняется, безусловно, ростом скорости интернета, который радикально изменил модель релизов. Раньше обновления ПО выходили раз в год — а то и реже. Их нужно было распространять на физических носителях: CD-ROM или дискеты, что тормозило выпуск новых версий. Высокоскоростной интернет всё изменил: теперь компании могли выкладывать исправления и новые фичи хоть каждый день. В такой среде Agile оказался чрезвычайно уместным.

Знаменитый девиз Facebook — «Двигайся быстро и ломай вещи» — отлично передавал дух новой эпохи. Это было время, которое вознаграждало дерзость — как в разработке программного обеспечения, так и среди генеральных директоров. Венчурные фонды, охотясь за «единорогами», вливали рекордные суммы в технологический сектор в 2010-х годах и хотели видеть результаты как можно быстрее. Чтобы конкурировать со стартапами, нужно было уметь мгновенно адаптироваться, выпускать обновления непрерывно и развивать продукт с головокружительной скоростью. Соотношение рисков изменилось: теперь опасным казалось не использовать Agile, а оставаться на водопаде.

В равной степени изменилось и само понимание того, кто такой разработчик. В 1970-х и 1980-х годах идеалом программиста считался системно мыслящий, любящий логику учёный. Но с годами этот идеал так и не прижился. Программисты 1990-х читали Wired, а не Datamation. Если судить по Манифесту Agile, они были искренне преданы высочайшим стандартам, работали быстро и уверенно, потому что менеджеры «доверяли им довести дело до конца». Они отказывались делать что-либо только потому, что «так всегда делали», и сосредотачивались на «постоянном внимании к техническому совершенству». Быстро меняющиеся требования их не пугали — наоборот, они видели в них возможность «использовать изменения для конкурентного преимущества клиента».

Образ свободомыслящего нонконформиста хорошо соответствовал философии Agile. Авторы манифеста могли выглядеть как классические инженеры — в рубашках и с кобурами для мобильных телефонов, — но, по словам одного из них, Джима Хайсмитa, «трудно было бы найти более анархичную группу в организационном смысле». Особенно в первые годы активно обсуждался вызов, который Agile бросал традиционному управлению. Сторонники Agile гордились своей нонконформностью: «Agile пугает традиционалистов до смерти», — писал Хайсмит в 2001 году. «Agile изначально был открыто и яростно антименеджерским», — отмечает разработчик и консультант Эл Тенхундфельд. — «Например, Кен Швабер [один из авторов манифеста] открыто и недвусмысленно заявлял, что его цель — избавиться от всех проектных менеджеров».

Антиуправленческий — возможно, но никак не антикорпоративный. Легко представить архетипичного разработчика Agile как возрождение длинноволосого контркультурного гика, который бродил вокруг перфокартных машин в конце 1960-х. Но эти два образа сильно различаются. Экцентрики ранних лет вычислительной техники программировали ради чистого удовольствия — ради самого процесса освоения новой технологии. Разработчик в представлении Agile прежде всего предан проекту. Он ненавидит административное вмешательство не из идеологических соображений, а потому что оно мешает его главной цели — выполнять работу на высочайшем профессиональном уровне. Как герои фильма Аарона Соркина "Социальная сеть", он больше всего хочет оказаться в «потоке»: наушники надеты, всё отвлекающее устранено, состояние полного единения с работой.

Месть менеджмента

Работая в библиотеке, я наблюдала за разработчиками, восхищаясь их командной работой и прагматизмом. Но со временем мне начали бросаться в глаза трещины в этой внешней картине. Несмотря на диаграмму скорости и дисциплинированный учёт фич, разработчики, казалось, не особо продвигались вперёд. Они работали усердно — это было очевидно — но имелся фатальный изъян: никто на самом деле не знал, каким должен быть конечный результат проекта или какую именно цель он должен был служить. Команда могла разрабатывать функции, но было непонятно, к чему именно эти функции добавляются. Возможно, дело было в дисфункциональности самой организации, и её было немало. Тем не менее, я начала задумываться, есть ли у методологии Agile свои ограничения.

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

Часть проблемы заключается в гибкости Agile. Ян Вишвех, независимый разработчик, называет это проблемой «настоящего шотландца». Любая практика Agile, которая кому-то не нравится, внезапно оказывается вовсе не Agile. Это почти неизбежно, учитывая саму структуру манифеста: поскольку он не предписывает конкретных действий, нужно судить по «духу» применяемых методов — а это полностью зависит от восприятия конкретного человека. Agile настаивает на том, что это «мышление», а не методология, поэтому, похоже, он неизбежно принимает черты любой организации, которая его использует. И он поразительно устойчив к критике, ведь его нельзя свести к конкретному набору методов. «Если у тебя что-то не работает, люди решат, что ты просто делаешь это неправильно, — сказал мне один продукт-менеджер. — А не потому, что с самой системой что-то не так».

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

Эл Тенхундфельд отмечает, что авторы манифеста Agile были практикующими разработчиками, и что изначально манифест распространялся среди самоорганизующихся команд программистов. Сейчас же немало людей специализируется на внедрении Agile, а на конференциях по Agile, как известно, доминируют менеджеры, а не разработчики. Поскольку Agile повсеместен, его теперь так же часто навязывают сверху, как и требуют снизу. А Agile-менеджеры проектов, которые, как правило, встроены в команду в роли «продакт овнера», оказываются разрываемыми между двумя силами: с одной стороны — интересы разработчиков, с другой — обещания, данные менеджменту.

Даже когда команду тянут в разные стороны, от неё всё равно требуют продвигать проекты с постоянно нарастающей скоростью. «Спринт», в конце концов, по определению — это про скорость. И действительно, перспектива выгорания оказалась вполне реальной для многих программистов и аналитиков, с которыми я говорила. «Ты стараешься определить, что реально сделать за этот период времени, — говорит технический писатель Сара Моир. — А потом бежишь к финишу, а потом снова. И снова к следующему финишу, и так далее. Это может быть довольно изматывающе, если ты выкладываешься на все сто».

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

«Сторипойнты» — абстракция, с помощью которой команды оценивают трудоёмкость задач, — тоже во многом утратили свою привлекательность. Изначально они задумывались как способ дать программистам контроль над объёмом и содержанием своей работы. Но на практике часто используются для оценки их производительности.

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

Следующий кризис

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

А за последние несколько лет именно эти фундаментальные вопросы приобрели особую важность и остроту. Мы видели множество примеров того, как сотрудники технологических компаний объединялись, чтобы изменить стратегическое направление своих компаний: разработчики Google выступали против контракта на ИИ для Министерства обороны США, разработчики игр требовали прекратить сексуальные домогательства. Эти требования выходят за рамки Agile, ведь их цель — не просто улучшить условия труда, а изменить сам характер этой работы.

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

Возможно ли, что Agile сыграл роль и в некоторых из наиболее печально известных провалов технологической индустрии? Эта мысль пришла мне в голову, когда я смотрела, как Фрэнсис Хауген, бывший менеджер Facebook, выступала в Конгрессе США в октябре 2021 года в качестве разоблачителя (whistleblower). Если компания ставит цель — повысить вовлечённость пользователей, Agile как раз и предназначен для того, чтобы разработчики целенаправленно работали на достижение этой цели — а не спорили с менеджерами о том, стоит ли, например, показывать людям контент, разжигающий их предубеждения. Такие этические дискуссии несовместимы с приверженностью Agile тому, чтобы разработчики как можно более усердно трудились над любым проектом, каким бы он ни был.

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

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

Манифест Agile рисует привлекательную картину демократичного рабочего пространства. Проблема в том, что его почти всегда внедряют в организациях, ориентированных на прибыль, а не на благополучие сотрудников. Иногда эти приоритеты совпадают: манифест убедительно утверждает, что автономия работников может укрепить продукт компании. Но они так же легко могут вступить в конфликт — например, когда менеджер проекта оказывается зажат между обещаниями клиенту и приоритетами самих разработчиков.

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

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

Но у Agile есть и другая сторона. Некоторые собеседники отмечали, что Agile потенциально способен укреплять солидарность среди работников. Если команды действительно самоорганизуются, делятся заботами и говорят открыто, возможно, Agile действительно может способствовать объединению работников. Может быть, менеджмент с помощью Agile сам выращивает себе могильщиков. Возможно, следующий кризис в разработке программного обеспечения придёт от самих работников.

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