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

Трансформация на ходу

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

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

В целом цифровая трансформация в сложившейся компании напоминает мне попытку поменять колесо у спорткара, несущегося со скоростью 200 км/ч, или перебрать двигатель у большегруза на ходу. В теории такое возможно и без остановки, но на выходе, скорее всего, получится стройная система из костылей и подпорок, которая работает абы как. Зато KPI выполнен на все 100%.

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

Я вообще редко видел, чтобы постулаты Agile были реализованы хотя бы приблизительно так, как написано в манифесте. Когда меня на собеседованиях спрашивали, по каким подходам я работал, я отвечал: «Называлось это по-разному — водопад, аджайл, скрам, канбан, — но по факту везде было одно и то же. По-моему, это называется Gang Bang».

Откуда взялся Agile

Все знают, что Agile придумали в противовес Waterfall. Но кто и зачем? Какие-то 17 сноубёрдистов собрались в 2001 году и написали какую-то муть, назвав её Agile-манифестом…

А давайте посмотрим, кто эти 17. Не буду перечислять всех, хотя каждый заслуживает внимания и уважения, назову троих: Мартин Фаулер, Роберт Мартин (он же дядюшка Боб) и Кент Бек. Последнего знают реже, но для меня он один из тех, кто изменил процесс разработки так, как до него никто не менял. Он автор eXtreme Programming — это оттуда CI/CD, TDD, парное программирование, code owneership, частые маленькие релизы — и соавтор первой версии тестового фреймворка JUnit.

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

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

Итого: разработчики «снизу» придумали win-win-стратегию, как убрать боли и оздоровить процессы компании. Не только процесс разработки, а вообще все процессы — если компания хочет быть хоть отчасти ИТ-компанией. Пишете свою ERP — вы уже ИТ. Есть только лендинг — молодцы, но нет.

Как Agile должен приходить в компанию

Одним из главных проводников XP и Agile в индустрии стала консалтинговая компания ThoughtWorks, где Мартин Фаулер с 2000 года работает Chief Scientist. Тут у читателя может зародиться желание найти этот рассадник зла и стереть его с лица земли, НО не будем торопиться.

Вот как, по рассказам друга, который работал в одном европейском банке, это выглядело у них (а Сергей Бухаров @storms, работавший в ThoughtWorks, может рассказать в комментариях, как бывало на самом деле). ThoughtWorks приходят в компанию и говорят: «Вы говноеды и работаете неправильно» — шутка. Они заводят в отдел свою команду разработчиков, которые пишут чистый код по XP-практикам, и ещё подсаживают по одному-два разработчика в другие команды. Никто никого не заставляет что-то делать или перенимать — ребята просто делают своё дело.

И дальше происходит интересное: коллеги видят, что у ребят получается красиво, и начинают расспрашивать, что к чему. А те помогают точечно и проводят мастер-классы. То есть практики распространяются через любопытство коллег, а не через насильственное навязывание. Agile идёт bottom-up — ровно так, как он и зарождался. Изменения происходят итеративно, но необратимо, по принципу улиток.

А где же Agile-коучи?

Естественный вопрос: а где в этой истории Agile-коучи? А их нет. Точнее, эти самые разработчики из ThoughtWorks и есть Agile-коучи. Только такие, которые сами прошли путь боли, нашли решение, осознали его и готовы им делиться, работая руками, а не ртом.

У такого подхода несколько проблем:

1. пацанчики мутят лавешку и стоят недёшево;

2. масштабируются небыстро;

3. меняют компанию медленно, итеративно.

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

Думаю, вы понимаете, какие советы может дать «специалист», который в лучшем случае видел hello world на обучающем слайде и никогда не испытывал боли от кривых процессов, бессонных ночей над проектом и горящей задницы при падении прода в прайм-тайм. Говорить — не мешки ворочать; нужно показывать, а показать Agile-коуч по умолчанию мало что может.

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