Через 25 лет после agile-революции можно подвести итоги, чем она закончилась. Последние десять лет я это наблюдаю из места где agile зародился — в США.
1. Мир до Agile
Начнем с предыстории. Примерно до 2000 года дискурс в организации разработки задавала академия и инженеры. Это было время свободной конкуренции идей.
Взять методологии анализа и моделирования -- не было единого стандарта, однако была наиболее популярная по выбору людей -- OMT (40% применений). Можно было спорить, сравнивая и обсуждая, эта дискуссия вскрывала проблемы, и давала направление развития.
Все изменилось, когда компания Rational решила что сдесь закопано бабло, и попыталась монополизировать область. Она купила авторов трех авторов наиболее влиятельных методологий, и поручила им разработать UML.
Rational стала агрессивно продвигать UML, засовывая всем в глотку это поделие и свой продукт для рисования диаграмм и синхронизации их с кодом. Но скоро выяснилось, что люди в общем прекрасно могут обходится без того, чтоб синхронизировать диаграммы с кодом, а рисовать диаграммы могут и бесплатно. Как они и делали десятилетиями. И бабла там нет.
Сейчас про Rational никто не знает. Однако, они смогли убить когда-то живую и интересную область, оставив на ее месте радиоактавный кратер. Теперь всякий, кто рисует диаграмму, вызывает изумление, будто явился из мезозоя.
Тем кто присматривался к процессу разработки повезло больше. Сначала из этого попытались извлечь бабло академики -- Хамфри со своим CMMI и сертификациями. Сообщество отметило парадокс -- модель CMMI хороша, но все программы повышения уровня лютый треш. Они часто работают как, я не знаю, перекрасить ржавую копейку в цвета болида Феррари -- блестит, но не едет. Потому, что CMMI описывает следствия-симптомы, а не первопричины.
Разумеется, тут опять влезла Rational (она повсюду она везде) и попыталась монополизировать рынок придумав RUP. Получилось настолько тяжеловесное уебище да нет, все таки уебище, что индустрия только головой покрутила, и вежливо но твердо спустила это в унитаз. Вместе с компанией Rational и остальными ее идеями. И с тех пор, к счастью, о них больше никто не слышал.
Черт его знает как бы все повернулось. Но! Тут на сцене появился Agile. И все изменилось навсегда.
2. Да здравствует Agile
В 2001-м выходит Agile Manifesto — документ на полстраницы, в котором всё разумно: здравый инженерный компромисс между планом и практикой.
Появился десяток методологий под зонтиком Agile, и многие из них были действительно интересны. Их объединял фокус на результате, а не на формализме. Наиболее популярны стали XP и Scrum.
XP — это набор инженерных практик, основанных на достоверных, но контринтуитивных наблюдениях. Он ввёл в обиход то, что сегодня кажется само собой разумеющимся. Вы как минимум об этом слышали.
unit-тесты, BDD и подход “тест как спецификация”, написание теста до написания кода.
Парное программирование — как форма непрерывных микроревью.
Движение вперёд короткими итерациями вместо попытки продумать всё заранее.
Постоянный рефакторинг — как итеративный дизайн после факта, а не перед ним.
И мое любимое. YAGNI! Будь проще! Не выдумывай сложности впрок
Именно XP породил культуру инженерного самонаблюдения, где каждое правило имеет под собой механистическое объяснение.
Ключ к пониманию XP, почему он такой какой есть, лежит в том что Кент Бек писал на смолтоке. Smalltalk — язык без статической типизации, без проверки контрактов на этапе компиляции. Там любая ошибка становится известна только во время выполнения. Без тестов всё развалится. А думать наперёд трудно не потому, что Бек был против дизайна, а потому что язык не давал инструментов, чтобы думать о нём типологически.
В этом контексте XP — не «религия практик», а компенсация отсутствия статической модели мира. Unit-тесты там выполняют ту же роль, что строгая система типов в Haskell: удерживают реальность от распада. Парное программирование заменяет статический анализ: один человек играет роль компилятора, другой — рантайма. Рефакторинг — способ постепенно вырастить структуру из хаоса, а не нарисовать её заранее.
Когда вы это понимаете, XP предстает гениальной адаптацией: практическая инженерия без теоретической опоры. Он позволяет существовать порядку в мире, где нет типов, нет компилятора и нет гарантии, что код вообще доживёт до следующего запуска.
Но — и это важно — XP невозможно управлять извне. Им можно только заниматься. Менеджеру в нём делать нечего, кроме как стоять в сторонке и не мешать. Это не процесс, а ремесло; не фреймворк, а культура инженерной ответственности.
И именно поэтому, на сцену вышел Scrum.
3. Заводы — рабочим
Scrum был не об инженерии, а о социальном взаимодействии. В центре стояло понятие самоуправляющейся команды — коллектив, который сам себе хозяин. Скрам уничтожал иерархию, развивая идею, что всё может работать параллельно, без начальников и надзора. И доводя ее до абсолюта.
Менеджеры не нужны! Команда сама собой управляет! Ура, товарищи!
Даже смотрящий за процессом — Scrum Master — не начальник, а просто инженер из команды. И даже не «первый среди равных», а равный среди равных, но с таймером.
Product Owner (переименованный заказчик) — не начальник, а партнёр. Он говорит, что нужно сделать и решает, достигли ли цели, но не смеет диктовать, как и когда.
Со сроками — всё по-новому. Что сделали за спринт фиксированной длины — то и готово. Планировать можно сколько угодно наперёд, но оценивать трудозатраты и решать, что «влезет», будет всё равно команда. Теперь сроки стали не обязательством, а естественным ограничением среды.
Надо отметить, что части третья и четвёртая — те, что аккуратно делят ответственность между Product Owner и командой, — вовсе не бесполезны. Наоборот, они нацелены на исправление реальной и большой организационной проблемы.
В корпорации обычно задачи и сроки спускались сверху вниз по иерархии. А Скрам с одной стороны защищает инженеров от давления по срокам и размытых задач, с другой - позволяет инженерам взаимодействовать с Product Owner в матричной структуре, по внятному протоколу с разделением ответственности.
Этот водораздел позволяет разгрузить коммуникацию, сделав ее горизонтальной и убрав вечный конфликт «менеджеры требуют невозможного, инженеры саботируют непонятное». Помимо этого, Скрам подразумавает кросс-функциональную команду, а не конвейер по специальностям. Это действительно очень много. И это правда сильно помогает. Понимать это очень важно.
Но. Пункты 1-2 -- это звучало как технологический анархизм, как производственная утопия без начальников. Как так получилось, что бизнес согласился с “менеджеры не нужны”, спросите вы?
Ну конечно он не согласился. Смеетесь штоль.
4. Скрам чинит матрицу
Скрам менеджменту очень понравился. К тому времени уже стало ясно, что иерархические структуры с отделами по специальностям работают из рук вон плохо. В качестве лекарства повсеместно прописывали матричную модель — сбоку ставили проектный офис и Project Manager’ов, которые должны всё это координировать, собирая временные команды под проекты. Это тоже работало плохо, потому что:
Далеко не вся деятельность — проектная. Плюс-минус половина нагрузки — текучка. Для ее обработки проектный офис не подходит.
Было непонятно, за что же точно отвечает ПМ, за что разрабы, и где граница. В разных компаниях матрица настраивалась по-разному: где-то ПМ мог всё, где-то ничего, и никто не понимал, где кончаются полномочия одних начальников и начинаются других.
Проблема усугублялась тем, кто вообще такой классический Project Manager. По сути — бюрократическая прокладка между теми, кто понимает что нужно сделать, и теми, кто знает как.
Так получилось не сразу — сначала это была роль, потом стала профессией, а потом её сертифицировали. После этого всё пошло под откос: компетенция ушла, остался процесс.
В итоге выходило, что матрица в теории работать должна, а на практике -- работала так же через жопу как и без нее, но с вдвое большим количеством начальников.
И вот тут Scrum решил проблему блестяще. Он просто ликвидировал Project Manager’а и заменил его на Product Owner’а. Фокус сместился с отчётности перед «проектным офисом» на управление требованиями и ценностью продукта. Это было по-настоящему умное изменение — и его невозможно не приветствовать.
Кроме того, Scrum чётко ограничил полномочия Product Owner: он решает “что и зачем”, но не лезет в “как”. Эта простая линия разграничения починила матрицу. Организации начали убирать проектные офисы и отделы по специалтностям, заменяя их кросс-функциональными командами, работающими напрямую с PO.
Однако оставался вопрос: раз у нас самоуправляемые команды — то что делать с CTO? Увольнять, что ли?
Конечно нет. В корпорации у всего должен быть начальник. Потому что если отвечают все — не отвечает никто. И бизнес тихо проигнорировал этот пункт, вписав Scrum-команды в иерархию — под CTO, под VP of Engineering, под Chief of Something. А чтоб никто ничего такого не подумал -- менеджеры тоже объединились в скрам команды, назвав это скрам оф скрамс. И все. Кругом тотальный скрам.
Это вместе с проектным офисом и убило проектное управление. Но, справедливости ради, — то, что мертво, умереть не может. Оно было убито задолго до Скрам’а — в тот момент, когда из роли руководителя проекта сделали профессию. Когда вместо умения координировать людей появилось ремесло заполнения отчётных форм.
Подводя итоги необходимо отметить, что причины, почему Scrum работает, лежат не в деталях процесса, а в том, как он перестраивает структуру управления на верхнем уровне. Он работает не потому, что правильно устроен где-то там внутри, а потому, что меняет архитектуру власти снаружи.
И вот это — критически важно понимать. Причины, почему Скрам хорош, — не в самом Скраме.
Причины, почему Скрам хорош, — не в самом Скраме.
5. Матрица переварила скрам
Как только бизнес понял, что Скрам помогает, он не стал разбираться почему. А поступил так, как он всегда поступает.
Линейный менеджмент, как мы отметили выше, почему-то самоубиваться не спешил. В итоге — инженерам от идеи «самоуправляемой команды» оставили только риторику и ответственность. Всё остальное — забрали наверх.
А роль Scrum Master’а, разумеется, стала отдельной карьерной траекторией. Потому что управление процессом — это власть. И что, её этим красноглазикам-джунам оставлять, что ли? Смеётесь?
Поразительно, но даже из набора простейших ритуалов умудрились высосать целую индустрию сертификаций. Как и с управлением проектами, сертификация приносит больше вреда, чем пользы. Пройти её может кто угодно: входного барьера нет, а на выходе проверяется лишь способность говорить правильные слова.
В результате масса не самых талантливых, но весьма амбициозных людей увидела в этом фантастическую карьерную возможность. Они могут быть прекрасными людьми. Но хороший человек — это не профессия. И — если он нанят, он занимает место того, кто мог бы действительно понимать, что и зачем он делает.
Это создало условия для эрозии способности компаний рефлексировать над процессом разработки. За один год ничего не случилось, но за десять — стала исчезать сама культура обсуждения, как мы работаем. Рациональность сменил ритуал.
Одновременно с этим, вместе с проектным офисом из организаций ушел сам язык управления проектами. Никакой иерархической структуры работ, сетевых графиков, и анализа рисков.
Этот язык позволял говорить о причинности — о том, зачем мы вообще что-то делаем и как одно вытекает из другого. А это, в свою очередь, абсолютно необходимо для любой целенаправленной деятельности. Без него невозможно стратегическое планирование, и невозможна даже сама постановка цели.
Scrum адекватной замены не предложил — потому что предложить её трудно. И, если честно, незачем: эта часть и так была хороша. Ее не нужно переоткрывать.
В сухом остатке, проблему матрицы и проектного офиса Скрам действительно решил. Но индустрия подошла к делу творчески, и тут же нашла другие способы свести весь эффект на говно.
6. Кто виноват Что делать?
Выводы не сложны, но требуют решимости. Если кратко, всё чинится двумя простыми мерами.
Ликвидировать скрам-мастеров как отдельную должность. Без компенсаций, без трансформаций, без “переобучений”. Выжечь культ agile с институтом жрецов каленым железом, как инфекцию, противоречащую манифесту Agile.
Вернуть управление проектами, вменив его в прямые обязанности руководству разработки, и разделив ответственность за него с Product Owners по уровням тактика/стратегия.
Не “в дополнение”, а как необходимую часть ремесла. Потому что понимать, зачем, почему, и как ты делаешь вещи — и есть суть любого управления. Вот это — с тренингами и переобучениями. Руководителей не способных управлять проектами — увольнять.
Всё остальное можно оставить как есть. Эти две меры вернут причинность и ответственность туда, где они должны быть — в голову человека, который делает работу, а не в Excel-таблицу того, кто собирает по ней отчетность.
А за попытки возродить “проектный офис” как институт — расстрел на месте. Не надо сваливать свою работу на других. Функции “проектного офиса” разделены между разработкой и управлением продуктом, и Скрам говорит вам — как. Скажите ему спасибо за это.