Agile: крупнейшая идеологическая проблема в IT

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» - обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile - самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile - это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.

В сущности, Agile была бунтом против корпоративного засилья в разработке ПО. Впервые было признано, что разработка ПО - сложный и зачастую таинственный процесс, который обязательно нужно уберечь от корпоративной забюрократизированности. Изменения, переизобретение, гибкость, динамизм - вот красные нити, проходящие через манифест Agile. Они показали себя бесконечно привлекательными: согласно одному глобальному исследованию, около 97% всех организаций в той или иной форме практикуют принципы Agile. Благодаря такому повсеместному распространению, Agile достигла в теории управления разработкой ПО тотальной номинализации: сегодня термином «аджайл» именуют идеологию, методы работы и даже системы, используемые для разработки ПО в современной организации. Agile даже распространяется за пределы программерских команд и все чаще практикуется в других командах, отвечающих, например, за финансы или управление человеческими ресурсами. Agile, трактуемая как универсальная теория менеджмента, оказалась исключительно доступной и популярной - несмотря на скудость эмпирических подтверждений ее эффективности и полезности.

Интересно, что в манифесте Agile не делается попыток артикулировать какие-либо конкретные методы работы, правила, процессы, системы или структуры, которые помогали бы разрабатывать ПО в стиле Agile. Это и неудивительно: ведь манифест Agile никогда и не претендовал на подробное описание того, как достичь целей этого манифеста. Такая явная размытость ничуть не убавила популярности Agile: фактически, стремительный рост спроса на конкретные методы и инструменты Agile привел к возникновению метаиндустрии на основе ресурсов Agile. Этот интерес стимулировал внедрение Agile, проникновение в новые отрасли самой идеологии Agile и ее производных. Наиболее отчетливо проявили себя тщательно определенные методологии Agile (например, Scrum и Kanban-т.e., детализированные описания процессов, которых нужно придерживаться для воплощения принципов манифеста Agile) и специализированные софтверные платформы, специально разработанные для поддержки Agile-разработки. Австралийская технологическая компания Atlassian продает целый ряд таких продуктов, предназначенных для поддержки процессов разработки ПО в стиле Agile; особого упоминания заслуживают Confluence и Jira, уже де-факто ставшие стандартами в индустрии. Для тех, кто не варится в технологическом сообществе, такие продукты кажутся весьма таинственными. Появился целый ряд поясняющих статей, прежде чем Atlassian попала в списки NASDAQ и непосредственно после этого. Статьи были призваны объяснить, что же именно продает Atlassian, и почему компания добилась такой высокой рыночной капитализации.

Подобно программным продуктам Atlassian, лексикон, описывающий процессы Agile и повседневные рабочие приемы, также стал все более непроницаемым для непосвященных. Практикующие Agile говорят о спринтах, досках Kanban, диаграммах сгорания задач, скоростях, пользовательских историях, эпиках и ретроспективах - значение всех этих слов зачастую меняется в зависимости от контекста, а сами эти термины могут быть аффилированы с одной или несколькими явно определенными методологиями Agile. Стоит ли удивляться, что, по мере усложнения методологии Agile, множится и когорта специалистов-консультантов, помогающих все это осмыслить. В Bain & Company к услугам клиентов - около 1000 практиков Agile. Пожалуй, это самый надежный индикатор, демонстрирующий, какой прибыльной стала индустрия Agile-консалтинга. Однако, если манифест Agile столь прост, каким кажется на первый взгляд, то зачем же столько консультантов? Насколько ощутимо услуги любого из них отражаются на качестве и эффективности работы в типичной технологической компании?

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

Энди Хант, один из авторов-основателей манифеста Agile, жалуется, что из-за абстрактной формулировки оригинального Манифеста появились и распространились бесконечные правила, используемые вне контекста и якобы образующие основу разработки в стиле Agile. Со временем такие правила кодифицируются в виде специализированных методологий, которым требуется бездумно следовать, забывая при этом об исходных руководящих принципах Манифеста. Иными словами, идеология Agile оказалась исключительно сложна для изучения, усвоения и практики. Поэтому некоторые персонажи опираются на жестко определенные правила или эвристику, которые выдают за Agile, а потом продолжают подменять этими правилами (часто вырванными из контекста) практику Agile, соответствующую целям Манифеста. В большинстве организаций никакого постепенного оттачивания процесса разработки не происходит; вместо этого менеджеры впадают в заблуждение, считая, что процесс не допускает изменений, отказываются от пошагового улучшения продукта, а стремятся содрать с разработчиков по три шкуры, оперируя при этом в основном взятыми с потолка и жестко зафиксированными канонами. Организациям, которым не удается извлечь никакой реальной пользы из Agile (а таких много) закономерно тяготеют к отслеживанию реализации некого Agile-процесса, игнорируя при этом более размытые, но при этом и более важные результаты процесса - то есть, поставку работоспособного ПО.

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

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