«У вас не Agile» — сказал agile-коуч
Эта статья родилась из наблюдений за тем, как менеджеры разных компаний активно навязывают Agile. Сразу предупреждаю: воды здесь много, так что читайте с включённым критическим мышлением — автор тот ещё «профессор лука».
Про профессора лука
Первоисточник этой истории найти не удалось, поэтому возможны искажения. Если знаете, откуда она, напишите, пожалуйста, в комментариях.
90-е, военно-медицинский институт. Один профессор пригласил коллегу, изучающего пользу репчатого лука, выступить перед студентами. Гость прочитал лекцию о своих исследованиях и о том, что репчатый лук лечит длинный перечень заболеваний, в том числе рак. Студенты слушали с огромным интересом, конспектировали, задавали вопросы и проводили лектора овациями.
Когда аудитория успокоилась, профессор-организатор спросил: «Как вы думаете, кто перед вами сейчас выступал?» Студенты без сомнения ответили: «Конечно, профессор, который исследует пользу репчатого лука». На что профессор пояснил: «Перед вами выступал пациент местного психоневрологического диспансера с диагнозом „шизофрения“».
Трансформация на ходу
Когда я слышу про цифровые трансформации, особенно в крупных компаниях, перед глазами встаёт сцена из «Трансформеров»: Бамблби на бегу превращается из робота в автомобиль и мчится дальше на полной скорости. Подозреваю, что у менеджеров примерно такое же представление о процессе. Особенно греет их душу обещанный эффект: рост эффективности разработки, ускорение процессов, ползущие вверх графики прибыли (ну или чего угодно) и, конечно же, выполненный 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.
Отступление про JUnit
Первую версию JUnit Кент Бек и Эрих Гамма (тот самый, из «банды четырёх») написали в 1997 году в самолёте, летя из Цюриха в Атланту на конференцию OOPSLA. Писали в паре, разумеется, по TDD. За основу взяли SUnit — фреймворк, который Бек до этого сделал для Smalltalk. Так из одного перелёта выросла целая семья xUnit-фреймворков, которыми мы пользуемся до сих пор.
Самое важное для меня — роли этих людей. По факту они были разработчиками. Не чистыми менеджерами, а именно разработчиками, которые устали от проектного подхода: получать на выходе то, что уже никому не нужно, — удовольствие на любителя. Этим ребятам было не всё равно, зачем они создают софт и что получится в результате.
Перечитывая манифест и наблюдая за проблемами в компаниях, я начинаю понимать, что у Agile есть более глубокий смысл: поднять влияние разработки на один уровень с бизнес-процессами, чтобы разработка перестала быть портным.
Отступление про портного
Иногда я спрашиваю коллег: есть ли что-то общее между ремеслом портного и работой разработчика? Обычно находят, причём скорее даже со швеёй.
Тогда я привожу пример. К портному приходит низкорослый кареглазый брюнет с пятью короткими ногами, с расплывшейся фигурой, и хочет костюм, в котором будет выглядеть рослым голубоглазым блондином с подтянутым спортивным телом. Как бы портной ни старался, получится срамота. Но если мы будем одновременно портным, хирургом, диетологом и психологом, то, возможно, сумеем привести бренное тело заказчика в сносное состояние.
Итого: разработчики «снизу» придумали win-win-стратегию, как убрать боли и оздоровить процессы компании. Не только процесс разработки, а вообще все процессы — если компания хочет быть хоть отчасти ИТ-компанией. Пишете свою ERP — вы уже ИТ. Есть только лендинг — молодцы, но нет.
Как Agile должен приходить в компанию
Одним из главных проводников XP и Agile в индустрии стала консалтинговая компания ThoughtWorks, где Мартин Фаулер с 2000 года работает Chief Scientist. Тут у читателя может зародиться желание найти этот рассадник зла и стереть его с лица земли, НО не будем торопиться.
Вот как, по рассказам друга, который работал в одном европейском банке, это выглядело у них (а Сергей Бухаров @storms, работавший в ThoughtWorks, может рассказать в комментариях, как бывало на самом деле). ThoughtWorks приходят в компанию и говорят: «Вы говноеды и работаете неправильно» — шутка. Они заводят в отдел свою команду разработчиков, которые пишут чистый код по XP-практикам, и ещё подсаживают по одному-два разработчика в другие команды. Никто никого не заставляет что-то делать или перенимать — ребята просто делают своё дело.
И дальше происходит интересное: коллеги видят, что у ребят получается красиво, и начинают расспрашивать, что к чему. А те помогают точечно и проводят мастер-классы. То есть практики распространяются через любопытство коллег, а не через насильственное навязывание. Agile идёт bottom-up — ровно так, как он и зарождался. Изменения происходят итеративно, но необратимо, по принципу улиток.
Отступление про аквариум и улиток
Когда я прихожу в новый проект или кто-то приходит к нам в команду, я рассказываю метафору, которую называю «Аквариум».
Представьте аквариум со сложившейся экосистемой. Ему несколько десятков лет, стёкла заросли грязью, но рыбки плавают, водоросли растут, токсичных газов он не выделяет и в целом никому не мешает. Иногда в него попадают чужаки, и экосистема относится к ним настороженно. Если она пережила много таких вторжений, то научилась как-то работать и защищаться от пришельцев.
Хотите отмыть аквариум и сделать стёкла прозрачными? Запустите улиток, а ещё лучше — закиньте икринки. Улитки итеративно, в течение довольно долгого времени, очистят стёкла. А вот лягушек забрасывать не нужно: они только взбаламутят воду и выпрыгнут восвояси, а то и вовсе сделают аквариум токсичным.
Так что мой подход к спокойным мутным аквариумам — разобраться в исторических причинах сложившихся процессов, понять боли людей и только потом думать, как выходить из ситуации. А не орать на всех уровнях: «Они тут дебилы и ничего не понимают!» (это контрпродуктивно, зато эффективно для ЧСВ и KPI).
Другое дело — аквариум с недружелюбными обитателями, которые переварили уже не одну лягушку и улитку, да ещё и источают токсичные газы, заражая соседние аквариумы и всё жильё. Тут порядок действий другой: быстро понять причины такого состояния, принять решение и действовать радикально — отсадить здоровых обитателей в чистую воду и выстраивать экосистему заново.
А где же Agile-коучи?
Естественный вопрос: а где в этой истории Agile-коучи? А их нет. Точнее, эти самые разработчики из ThoughtWorks и есть Agile-коучи. Только такие, которые сами прошли путь боли, нашли решение, осознали его и готовы им делиться, работая руками, а не ртом.
У такого подхода несколько проблем:
пацанчики мутят лавешку и стоят недёшево;
масштабируются небыстро;
меняют компанию медленно, итеративно.
Как мне кажется, именно в этих условиях появился другой способ «демократизировать» Agile. На дворе начало нулевых, МММ недавно рухнул, сетевой маркетинг набирает обороты — и те, кому не нашлось места в пирамидах, пошли в… Agile-коучи! А что: говорить умеют, убеждают некисло, шаблонные фразы выучили, продавать дорого всякую дичь тоже умеют. Зачем толкаться локтями в тесной пирамиде, когда есть айтишники-лохобританцы!
Думаю, вы понимаете, какие советы может дать «специалист», который в лучшем случае видел hello world на обучающем слайде и никогда не испытывал боли от кривых процессов, бессонных ночей над проектом и горящей задницы при падении прода в прайм-тайм. Говорить — не мешки ворочать; нужно показывать, а показать Agile-коуч по умолчанию мало что может.
Зато сверху видно, как круто преображается компания: команды разбиваются, митинги проводятся, графики цифровой трансформации летят вверх. А то, что графики производительности, корректности и адекватности катятся вниз, — так это проблемы аборигенов мышек, они в KPI топов не входят.
Анекдот про мышек
Жили-были мыши. Все их обижали. Пришли однажды мыши к сове: — Мудрая сова, помоги! Все нас едят, скоро нас совсем не останется. Что делать? Подумала сова и говорит: — Мыши, станьте ежами! Будете колючими, и никто вас не тронет. Побежали мыши радостные: — Станем ежами! Станем ежами! Вдруг одна остановилась: — А кто-нибудь знает, как стать ежами? Никто не знал. Побежали обратно к сове: — Сова! А как нам стать ежами? — Мыши, отстаньте! Я не тактик, я стратег!
Что делать мышкам
Раз Agile становится проблемой мышек, то есть нашей с вами, может, стоит взглянуть на него иначе? Например, прочитать «Чистый Agile» дядюшки Боба, чтобы понять, какие проблемы он вообще решает. Или пройти хороший курс от практиков — я сам проходил один, местами с авторами не согласен, но в целом годно (ссылку дам в комментариях, если интересно, — не реклама, меня никто не просил).
Но в первую очередь, думаю, стоит задать себе вопрос: «А уместен ли у нас Agile и продуктовый подход?» — и ответить на него максимально честно. Возможно, после этого вы встанете на путь осознания ценности Agile. Правда, рискуете оказаться одиночкой, как герой песни Хаски «Пуля-дура». Я им пока и остаюсь — но хочу стать автоматом.
P.S.
В эпоху, когда написание кода стремительно дешевеет (привет, AI), суть разработки ПО, возможно, дистиллируется до предела: быть гибкими и влиять на бизнес-процессы там, где это уместно. При таких вводных Agile начинает играть новыми красками. Правда, если впихивать глобус в сову, мы снова получим лишь видимость изменения процессов.
А как Agile внедряли у вас — улитками или лягушками? Делитесь в комментариях.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.