Когда-то мне доводилось участвовать в попытках внедрения Agile в команде, разрабатывающей ПО. В регулярных дискуссиях, стараясь, чтобы это внедрение не превратилось в карго-культ, я снова и снова цитировал пост в блоге Элизабет Хендриксон. Ему уже больше трёх лет, но мне он нравится, и я бы хотел представить вашему вниманию (и вашей борьбе с карго-культом) перевод этого поста.
Какое-то время назад я написала о том, как я определяю Agile:
Agile команды производят непрерывный поток востребованного кода, со стабильной скоростью, при этом адаптируясь к изменяющимся нуждам бизнеса.
Этот пост слегка наделал шума, и несколько человек сказали мне, что у Agile есть только одно определение, которое выражено в Agile-манифесте. Подразумевалось, что, раз моё определение отличается от манифеста, оно неверное.
По настояниям знакомого, я перечитала принципы Agile-манифеста. И обнаружила, что моё «определение» там есть. Оно находится в принципах: "… регулярной поставке ценного программного обеспечения...", "… изменение требований приветствуется...", "… устойчивый процесс разработки....", "… поддерживать постоянный ритм бесконечно...".
Хорошо, я сдаюсь. Определение Agile дано в манифесте. А мое «определение» — это мой нелицеприятный тест, не взирающий на лица и могущий привести к неприятным открытиям.
Множество организаций утверждают, что у них есть Agile. Немногим хватает смелости и дисциплины, чтобы делать что-то кроме пустых слов. Потом они говорят «Agile не работает» (моя любимая реакция на это — пост «Мы попробовали бейсбол, и он не работает»).
Поэтому, когда команда заявляет мне, что у них есть Agile, я применяю свой тест, чтобы проверить, так ли это на самом деле. Я спрашиваю:
Как часто вы выкатываете обновления?
Когда я говорю, что Agile команды производят непрерывный поток востребованного кода, я имею в виду, что они производят ценный для бизнеса, готовый к внедрению/продаже код как минимум раз в месяц, а лучше чаще. «Готовый к внедрению/продаже» надо понимать буквально. Он сделан, в смысле совсем. Внедрен, протестирован и принят Product Owner'ом.
Некоторые организации доводят это до предела с непрерывной интеграцией. В этом случае код после чекина оказывается на продакшене спустя минуты. Конечно, это не всегда и не всем подходит, но, даже если для вас это не имеет смысла на продакшене, подумайте, может, это пригодится на ваших тестовых или девелоперских стендах для сокращения цикла разработки.
Проще говоря, Agile команды часто выкатывают готовые куски продукта. Выкатывание «почти сделанного» или «сделанного, но не протестированного» не считается.
Вы можете работать в таком режиме бесконечно?
«Со стабильной скоростью» означает, что команда может делать новый функционал с более-менее постоянной скоростью, без учета изменений размера команды.
Для сохранения стабильной скорости критичны два аспекта:
- люди
- технические активы
До начала работы на Agile проектах я привыкла к тому, что последние недели или месяцы проекта проходили в режиме «стиснув зубы». Вся команда перерабатывала (80-100 часов в неделю были нормой). Мы накачивались кофе, выматывались и озлоблялись. Но мы делали то, что было необходимо для сдачи проекта.
Сдав проект, мы праздновали свой героизм и валились с ног.
Несколько дней спустя, мы притаскивали свои тушки в офис. Мы говорили: «Теперь мы всё сделаем правильно!» Мы тратили вагоны времени на планирование, требования и дизайн. Но, объективно, мы были измотаны и работали медленнее. Дедлайн неумолимо приближался, нам снова не хватало времени, и мы опять оказывались в режиме «стиснув зубы».
Такой режим нельзя выносить долго. Несколько итераций, и люди спекались. Кто-то уходил на травку позеленее, привлеченный большей зарплатой и/или более вменяемым режимом работы. Кто-то уходил на другие должности. Немногие, оставшиеся из-за лояльности или рабочей этики, обнаруживали, что окружены новичками или бесполезными коллегами, и ничего нельзя сделать. Прогресс разработки скрипит, замедляется и в конце концов останавливается.
Поэтому забота о людях — это задача номер один для поддержания постоянной скорости разработки.
Но её недостаточно. Второй частью является забота о технических активах. Легкие неверные решения, типа копирования большого куска кода в другое место программы и отказ от рефакторинга для исправления дублирования, или запихивание кода куда быстрее, вместо нужного места, или отказ от написания автотеста, который нужно написать, и мы это знаем, создают технический долг. С ростом технического долга растут и проценты, которые мы вынуждены платить.
Простые изменения требуют работы со многими файлами. Код становится хрупким. В конце концов команда доходит до состояния, когда даже небольшое изменение приводит к огромному количеству багов на регрессионном тестировании (если оно у вас вообще есть! — прим. перев.). Небольшое изменение приводит к тому, что команда днями гоняется за багами, чиня то, что работало, но сломалось. Опять же, прогресс разработки скрипит, замедляется и в конце концов останавливается.
Также, обратите внимание на связь между людскими и техническими аспектами — усталые люди будут чаще пытаться «срезать путь на костылях».
Если организация не заботится о людях, а люди не беспокоятся о технических активах, проблемы неизбежны. Они придут не сегодня, не завтра, но достаточно скоро, и продлятся всё время существования этого кода.
Как команда справляется с изменениями?
Я навестила одну команду в процессе перехода на Agile. Команда была очень довольна своим прогрессом. Они работали со спринтами длительностью две недели и хорошо справились с достижением и удержанием стабильной скорости разработки.
Но я вздрогнула, когда увидела их план проекта. Их спринты были запланированы на полгода вперед! Они углубились в план всего на несколько спринтов, но я видела проблему впереди. «Что будет, если изменится приоритет требований?» — спросила я. Менеджер проекта поёжился. По этому плану были даны обещания, от него нельзя было отклоняться.
Но изменения неизбежны. Я не знаю конца этой истории, но, готова поспорить, что менеджер проекта перерисовывал эту диаграмму Ганта миллиарды раз, пока они не сдали проект.
Если команда планирует слишком далеко вперед, они не смогут адаптироваться, когда, неизбежно, приоритеты и потребности изменятся. Они смогут стабильно выпускать обновления, но эти обновления будут иметь меньшую ценность для организации.
Немногие действительно внедрили Agile.
Часто, когда я выступаю перед аудиторией, я спрашиваю, сколько людей работают на Agile проектах. Сейчас, вне зависимости от аудитории, поднимается множество рук. Agile — это классная модная штука, с ней играют все разработчики младшего возраста. Но когда я предлагаю аудитории проверить себя по этим критериям и снова спрашиваю, кто работает на Agile проектах, руки остаются опущенными. Очень небольшое количество организаций достигают такого уровня Agile.
Следовательно, это означает, что очень малая доля организаций получают выгоду от Agile. А в худшем случае Agile означает ухудшение качества, повышение давления и более изматывающую работу. Люди с этих проектов говорят, что Agile рушит их жизни.
В таких средах Agile часто внедряется как:
- Сжатие сроков (потому что Agile значит «быстрее», не так ли?)
- Отсутствие документации (потому что Agile это означает, что мы не будем документировать, верно?)
- Написание кода до последней минуты (потому что Agile означает, что всегда можно поменять что угодно, а?)
Это рецепт кошмара: увеличение технических долгов, стресса, хаоса и, в конце концов, срыв сдачи проекта и несколько раундов увлекательной игры «Кто виноват?» Да, в этих организациях «Agile», точнее его извращенная версия «облажайл», действительно рушит жизни.
Я надеюсь, что, если вы окажетесь в такой атмосфере, «нелицеприятный тест вашего Agile» поможет вам сообщить Тем, Кто у Руля, что такое настоящий Agile и как он выглядит, когда сделан хорошо.
Запомните, если кто-то говорит, что он использует Agile, это не значит, что так и есть на самом деле. Авраам Линкольн сказал: «Если вы назовете хвост ногой, сколько ног будет у собаки? Четыре. Потому что назвать хвост ногой не значит сделать его ногой.»
