Разработчикам следует покинуть Agile

Часть 1. Кто виноват

Если вы разработчик, то ваш рабочий день скорее всего включает в себя утренний статус-митинг (под названием стендап или дейлик), перетаскивание карточек по канбан-доске, написание комментариев в этих карточках, периодические бэклог груминги, планировочные сессии, ретроспективы, и так далее. В перерывах между этими мероприятиями вы стараетесь писать код. Возможно, вы работаете в двухнедельных (или больше) циклах. Цикл заканчивается – на конвейер вываливаются новые карточки, чтобы тащить их дальше слева направо. И так до бесконечности, исхода нет. Эта ситуация более или менее универсальна вне зависимости от того, живете ли вы в постсоветском пространстве, США или ЕС, работаете ли вы в огромном банке или в маленьком агентстве.

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

На самом деле грехопадение профессии программиста началось чуть позже, в 2001 году, когда 17 консультантов собрались на горнолыжном курорте в Юте и решили написать Agile Manifesto. Да, кто-то называет их программистами, но по факту подавляющее большинство из них было именно консультантами. У каждого из них была за пазухой своя методика по управлению проектами. Очевидно, кто-то вдохновлялся веществами (Методология Crystal Алистера Кокберна), другие – игривыми аббревиатурами (DSDM Ари Ван Беннекума). Спортсмены тоже были – знаменитый Scrum Джеффа Сазерленда, о котором чуть ниже.

Не хватало только объединяющей идеи, и ей стала итеративность. В отличие от прошлого подхода, который аджилисты обозвали Waterfall, рабочее ПО предъявлялось заказчику по частям. Это действительно позволило улучшить обратную связь с заказчиком и пользователями, и также было удобнее для самих консультантов – за готовые кусочки работы можно было уже предъявить промежуточный счет. Итеративность, к слову, не была оригинальной идеей: такой подход в программировании применялся уже с 1950-ых годов. В 1968 году на конференции НАТО в Гармише, Германия, уже обсуждались инкрементальные подходы к программированию.

Однако простой итеративности оказалось мало. Было решено дописать еще 4 ценности и 12 принципов. Мало кто помнит даже несколько из них, кроме разве что знаменитого "Люди и взаимодействие важнее процессов и инструментов" (можно бесконечно спорить о том, что это должно обозначать на практике). Забавный факт – в 2008 году подписант Манифеста Роберт "Дядя Боб" Мартин предложил пятую ценность – "Мастерство превыше дерьма". В целом, посыл Манифеста – за все хорошее и против всего плохого.

Самую большую, пусть и не быструю, выгоду от попадания под зонтик Agile получили авторы методологии Scrum, разработчик из Иллинойса Кен Швабер и ветеран Вьетнамской войны, пилот и профессор математики Джефф Сазерленд. Именно Скраму мы обязаны пятью событиями, или церемониями, которые в той или иной форме знакомы очень многим: дейли scrum (стендап), спринт, спринт ревью, спринт демо, спринт ретроспектива. Некоторые авторы, как Майкл О. Черч, считают Scrum экстремистской версией Agile.

Церемонии, однако, лишь половина той чаши, которую разработчики вкушают до дна. Вторую половину составляет канбан-доска. Свое широкое распространение она начала получать с выходом в 2012 году Jira Agile Boards. Непосредственным отцом-теоретиком канбан-досок считается Дэвид Андерсон, выпустивший в 2010 году книгу The Kanban Method. Он, в свою очередь, мог вдохновляться книгой "Lean Software Development: An Agile Toolkit" супругов Поппендик, которые решили, что основанная на канбане конвейерная система Тойоты (Toyota Production System, TPS), может быть применена к созданию ПО. Забавный факт – будучи сторонницей канбана, Мэри Поппендик в личных беседах утверждала, что бэклог – это самый вредный концепт.

Творческий процесс итеративного проектирования и написания уникального программного обеспечения не имеет ничего общего с линейным производством идентичных автомобилей по заранее определенным чертежам, где каждая из сотен станций делает независимые и стандартизованные операции (об этом выйдет отдельная статья). Однако американцы всегда восхищались качеством японским машин, поэтому красивую картинку «мы взяли древние принципы крутых японцев» взяли, пересыпали красивыми японскими словами (muda, mura, muri), упаковали в виде книг и курсов и продали всему миру как гениальную разработку.

Дэвид Андерсон не являлся подписантом Манифеста и настаивал, что Канбан это часть Lean философии. Представители же Agile мира были рады выдать Канбан за свою практику. Так считает Atlassian, Asana и сам Agile Alliance. Однако с годами, по мере протухания бренда Agile как такового, дошло до того, что Андерсон написал статью о том, что именно Канбан это истинный путь к гибкости (agility), настоящий Agile 2.0, в отличие от остальных, негодных к употреблению и доказавших свою несостоятельность методов.

Таким образом, связка Agile + Kanban оказалась фантастически жизнеспособной, несмотря на огромной количество недовольных — hackernews и reddit изобилуют критическими постами и комментариями. На это есть три причины.

1. Agile трудно критиковать, потому что трудно описать. Если вам не нравится Agile, значит вы готовите его неправильно. Это логическая уловка, известная как «Ни один истинный шотландец».

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

3. Что вы предлагаете взамен? Waterfall? И на этот вопрос до недавнего времени ответа не было. Теперь — есть.

Часть 2. Что делать?

Итеративно‑функциональный метод и одноименная платформа создается в России с 2024 года. Agile был создан как ответ на косность Waterfall. ИФ Метод, в свою очередь, как ответ на фактическую импотенцию Agile практик и превращение его в своеобразную религию. Единственное сходство двух подходов — это итеративность, которая не является оригинальной идеей Agile. ИФ Метод строится на трех главных понятиях — итерации функции (фичи), самой функции и очередях итераций. ИФ Метод не признает никакой философии, ценностей или принципов — это маркетинговая чушь, которую используют, чтобы продать вам книги, курсы и консультационные услуги. ИФ Метод не использует канбан‑доски, имея оригинальный способ визуализации работы. По каким причинам ИФ Метод может быть удобнее и выгоднее для разработчиков, продуктовых менеджеров и высших руководителей?

Для разработчиков:

• Обновление статуса работы в один клик. Вам больше не нужно перетаскивать один или несколько тикетов, перекидывать его на других людей. В отличие от канбан доски, все карточки итераций неподвижны и остаются в колонке разработчика до самого конца разработки.

• Нет оценки в стори‑поинтах. Автомобильный конвейер не имеет ничего общего с разработкой программного обеспечения, но на конвейере единицы должны быть разделены по какому‑то принципу. Для этого используют концепт стори поинтов, придуманных Роном Джеффрисом, подписантом Манифеста и автором экстремального программирования. В 2019 году в этой статье он извинился за свое изобретение и посоветовал не использовать стори поинты, потому что они «мусор» (waste).

• Отдельная документация больше не нужна. Другой концепт экстремального программирования Рона Джеффриса, знаменитые User Stories, исторически привел к тому, что людям нужно делать двойную работу, сначала писать user story в жанре As a User, I want X, so Y, а потом еще писать документацию о том же самом, но уже в жанре нормального повествования. С учетом того, что требования нередко меняются в ходе работы, обновлять и тикеты, и документацию — это двойная работа, на которую ни у кого нет времени. Итерации в ИФ Методе пишутся в простом повествовательном стиле и сами служат документацией.

• Технический урон вместо технического долга. На эту тему будет отдельная статья, но ИФ Метод оперирует новым термином — технический урон, который включает в себя не только дефекты, но и некачественный / нечитаемый / неподдерживаемый код, мисконфигурации и все, что мешает не только customer experience, но и developer experience. Забавный факт — после того, как я рассказал известному аджилисту Аллану Холубу (Allan Holub) о концепции технического урона, он «придумал» новый термин — technical malfeasance («техническое злодеяние»).

Для продуктовых менеджеров

• Нет необходимости в user story. Больше не нужно писать портянки текста с acceptance criteria. По принципу single source of truth (один источник правды), если информация может быть получена из дизайн‑документа (макет, блок‑схема, OpenAPI референс), то дублировать ее не нужно. Поэтому продуктовые менеджеры и аналитики могут сконцентрироваться на продуктовых исследованиях и экспериментам вместо бесконечного написания тикетов.

• Четкая структура ответственности. За каждой итерацией функции закреплен лид, который отвечает за качество и своевременность работы всех разработчиков, занятых в этой итерации. Нет необходимости опрашивать всех на общем статус‑митинге, достаточно взаимодействовать с лидом итерации.

• Прозрачность качества работы. Каждый дефект должен быть привязан к итерации функции, в которой он был допущен. В отличие от канбана, где любой дефект внешне равноценен user story, ИФ Метод подчеркивает, что главная работа программиста — это разработка фич, а дефекты — это анти‑работа, и нужно стремиться к тому, чтобы этой анти‑работы было все меньше.

Для собственников бизнеса и высшего руководства

• Радикальное сокращение расходов.

• Радикальное снижение рисков. Только 9 апреля все облачные сервисы Кайтена лежали весь день из‑за проблем с базой данных (на минуту, они заявляют о 100 тысячах клиентов в России), между тем как коробочная версия доступна их клиентам только на тарифе Enterprise от 300 человек. Система управления продуктом / проектами — это критически важный компонент рабочего цикла айти компании, поэтому self‑hosted версия ИФ Метода доступна всем пользователям без ограничений и является приоритетом развития. Вы можете развернуть свой инстанс ИФ Метода за 15 минут и никто его никогда не сломает, кроме вас самих.

• Упрощение организационной структуры. ИФ Метод не предусматривает обязательной формализованной коммуникации, церемоний, ритуалов, танцев, плясок. Единственный фокус метода — в итеративном строительстве продукта. Метод не нуждается в скрам‑мастерах и прочих коллегах, занятых в основном созвонами и презентациями. ИФ Метод создан для активного выявления имитаторов бурной деятельности и избавления от них.

Чтобы узнать больше об итеративно‑функциональном методе, заходите на русскоязычный сайт и подписывайтесь на телеграм‑канал проекта.