Анонимная жертва Agile: «Agile-консультанты угробили команду программистов, в которой я работал. Писать качественное ПО сложно. Любой умелец, заявляющий: "Я знаю волшебный метод, гарантирующий создание высококачественных программ", — просто шарлатан. Я понимаю желание некоторых нагреть руки, но всерьез рекомендую таким людям проворачивать свои аферы где угодно, но не в софтверной индустрии».
В начале этого поста я хотел бы сделать важную оговорку: признаю, что Agile-методологии в области разработки и тестирования показали себя чудодейственными в тысячах организаций. Все положительные аспекты Agile — ускоренный вывод продукта на рынок, улучшение коммуникации между разработчиками, снижение стоимости разработки — давно известны в софтверной индустрии. И поскольку множество высокопрофессиональных программистов достигли успеха при помощи этого подхода, не буду же я им доказывать, что они ошиблись с методологией! Нет, в этой статье я нисколько не собираюсь дискредитировать Agile и людей, занятых ее продвижением.
Вместо этого я хотел бы заострить внимание на тех ситуациях, в которых Agile может вас подвести. Несмотря на огромную армию сторонников, Agile вызывает у многих здоровый скептицизм и раздражение. Противники этой философии — это люди, которые имеют совсем иной опыт Agile-разработки. Для такой «работы» характерны хаотичные процессы, низкое качество, постоянное недопонимание и ряд других проблем. Разумеется, такие скептики высказывают исключительно негативные мнения о таких «недостатках Agile». Вот один многозначительный комментарий:
Эта система раздута из-за постоянных собраний, в ней полно разных экселевских табличек, но почти нет реальной документации. Agile и сторонники этой методологии слишком много о себе мнят, их неприятие всякой документации рушит реальную рабочую коммуникацию. Поскольку документацией никто не занимается, людям приходится из планерки в планерку вариться в облаке идей. Agile полна эгоистичных и самодовлеющих идей, здесь любят сыпать пустыми словами, например "гибкий" и "динамичный". Люди часто не помнят, что утверждали на одном собрании, а что — на другом».
Увы, несоответствие очевидно. Как один и тот же подход может великолепно работать в одной команде, а в другой приводить к плачевным результатам? Полностью ответить на этот вопрос в рамках одной статьи (и даже целой книги), наверное, не удастся, но я хотел бы остановиться на некоторых наиболее очевидных причинах. Итак:
Сложно изживать старые привычки
По моему опыту и по наблюдениям некоторых серьезных экспертов, Agile обычно «проваливается» в тех случаях, когда эту методику насаждают в команде или организации, которая привыкла работать по другим принципам. После многолетнего тестирования и разработки в одном ключе сложно гарантировать гладкий переход на новые рельсы. Хотите доказательств? Вот результаты одного исследования, в котором приняли участие более 200 компаний, недавно перешедших на использование принципов Agile.
Из более чем двухсот участников 64 процента указали, что переход на Agile-разработку дался тяжелее, чем это казалось на первый взгляд. 40 процентов респондентов не обнаружили в этой методологии особых преимуществ. Из тех компаний, в которых проявились положительные изменения, 14 процентов связывали прогресс с ускорением релизов, 13 процентов — с улучшением коммуникации. Семь процентов отметили, что разработчики положительно воспринимали Agile, так как смягчались требования к планированию работы и подготовке документации.
По данным Voke, со времен мирового финансового кризиса 2008 года средняя стоимость софтверных проектов резко возросла, и это притом, что команды разработчиков в среднем стали меньше, а сроки ужесточились. В то же время, риск провала проекта, созданного по Agile-методологиям, остается высоким.
Распространено мнение, что Agile означает "быстрее, лучше, дешевле", но на практике результаты таких разработок очень разнятся. Многие организации берут на вооружение Agile-методологии, не вполне понимая, что это такое и каковы могут быть последствия такого перехода. Бывает сложно понять, что сегодняшние решения уже завтра могут превратиться в проблемы», — отмечает Тереза Лановиц, ведущий аналитик в Voke.
Я считаю, что процесс перехода на Agile требует ясных объяснений и четкого описания (подробнее об этом — чуть ниже). В противном случае ваши принципы разработки останутся прежними, изменится только название.
Я не думаю, что многие люди нуждаются в разъяснении Agile-принципов, даже если их интересует лишь ускорение релизов, — считает Нейт Остер, Agile-коуч и основатель CodeSquads. — Но на практике многие черты водопадной модели сохраняются, их лишь маскируют при помощи нового лексикона. Если мы работаем на результат, то нужно менять не жаргон, а саму суть нашего взаимодействия!»
Далее Остер отмечает: «Думаю, глубинная причина неприятия Agile заключается в том, что этот метод требует от нас изменить подсознательное восприятие рабочего процесса. Многие излюбленные "проверенные методы" водопадной модели сводятся к оптимизации "нашей работы", чтобы мы могли "повысить эффективность". В действительности же они подрывают основную цель Agile — стремление регулярно выдавать результат, добиваясь максимальной сплоченности команды».
В качестве пережитка водопадной модели Нат приводит следующий пример: многие команды тестировщиков по-прежнему убеждены, что тестировать можно только ту функцию, разработка которой полностью завершена.
Это философия полной проверки, оставшаяся от водопадной модели, где работа тестировщика заключается в эффективном нахождении всех допущенных багов, — говорит Нат. — В Agile-командах мы не допускаем появления этих багов, разрабатывая функцию всей командой одновременно, опираясь на тестирование компонентов и поэтапно выстраивая маленькие фрагменты функционала. Когда мы работаем с такими мелкими итерациями, тестирование проводится на протяжении всей разработки, а не откладывается до ее завершения. Именно так нам удается избежать мини-водопадного тестирования».
Не значит ли это, что полноценный переход на Agile невозможен? Ничего подобного. Сложен ли такой переход? Да, сложен. Необходим ли он? Вот что говорит об этом Скотт Барбер, эксперт по Agile:
Я считаю, что тренд массового перехода на Agile в целом ошибочен. Если в вашей компании разрабатывают качественный софт, команду устраивают условия труда, рабочие процессы стабильны, а заказчиков устраивает предоставляемый продукт, то незачем экспериментировать с переходом к Agile. В Agile есть свои нюансы, как и в любой профессиональной культуре, но сложнее всего приходится таким компаниям, которые пытаются одним махом решить все накопленные проблемы с разработкой, управлением процессами и/или распределением задач, просто "приняв Agile". Команды, сплоченные в принципиально иной культуре, просто не смогут легко этого сделать».
Нереалистичные ожидания
Еще одна причина провалов с Agile объясняется нереалистичными ожиданиями, связанными с теорией и практикой этой методологии (что она собой представляет и чего позволяет достичь). Распространено мнение, что Agile — это набор методов, процессов и инструментов, тогда как на самом деле Agile — это вид менталитета и профессиональной культуры.
Рабочие процессы разнятся в зависимости от конкретной компании, разрабатываемого продукта и коллектива. Неудивительно, что иногда процессы применяются неверно, что приводит к плачевным результатам. С другой стороны, вышеупомянутые менталитет и профессиональная культура могут пересилить эти факторы. Скотт Эмблер приводит отличную аналогию, помогающую понять эту проблему (курсив мой):
Разве стоит применять одни и те же подходы при создании семейного веб-сайта и разработке прошивки для космического зонда? Определенно нет. А при разработке бизнес-приложения и такой прошивки? Думаю, тоже нет. Будете ли вы использовать в команде из шести человек те же приемы работы, что и в команде из шестидесяти человек? Опять же, скорее всего, нет. Очевидно, что различные ситуации требуют разного подхода».
Никто не будет спорить, что при разработке семейной веб-страницы и прошивки для космического зонда требуются разные подходы. Скорее всего, ваша компания не занимается одновременно и тем и другим, поэтому вам не составит труда взглянуть на ситуацию со стороны и оценить разницу. Было бы просто глупо вести эти проекты по одному и тому же принципу — для написания семейного сайта достаточно наладить элементарные процессы, в то время как разработка прошивки для зонда требует выстраивания сложных и строгих процессов. Если разрабатывать зонд как веб-страницу, то вы подвергнете проект огромному риску, а если подойти к написанию веб-страницы как к созданию прошивки для зонда, то стоимость проекта будет неоправданно высока. Поэтому выбор правильного процесса очень важен.
Если вы ожидаете, что Agile поможет вам совершить чудо или немедленно изменит процесс разработки, действующий в вашей компании — то гораздо вероятнее, что этот метод обернется для вас большими неприятностями.
Несогласованность отделов
Что делать, если команда разработчиков придерживается принципов Agile, а отдел тестирования — нет? Бывает и обратный случай: тестировщики стремятся участвовать в разработке уже на самых ранних этапах, а программисты и менеджеры проектов этому препятствуют. Как поступить, если руководство просто хочет, «чтобы все было аджайл», не понимая, что это значит?
Когда я слышу заявление «Мы — команда аджайл-тестировщиков», то оно кажется мне оксюмороном, — признается Остер. — Если они занимаются только тестированием, то это не соответсвует принципам Agile. Действительно, Agile-команды часто создают великолепные программы, и эта работа включает в себя тестирование. Настоящая Agile-команда должна обладать всеми навыками, необходимыми для создания софта: уметь программировать, анализировать и тестировать, независимо от того, кто именно будет выполнять конкретные задачи. Мне нравится, когда члены новоиспеченной Agile-команды начинают обучать друг друга, усваивать навыки, выходящие за рамки их номинальных обязанностей. Члены зрелой Agile-команды знают: отсутствует четкая граница между "моей работой" и "твоей работой". Есть только стоящие перед нами задачи, и все вкладывают в общее дело свои навыки. Тогда мы выполняем работу как единая боевая единица».
Как было указано выше, Agile — это не правила игры, не набор рекомендаций, не контрольный список операций. Скотт Барбер верно описал Agile как определенный менталитет и профессиональную культуру — и для успеха Agile нужны заинтересованность и участие в рамках всей организации.
Не спешите сдаваться
Итак, переход к Agile непрост. Нейт Остер верно отмечает, что сложности такого перехода связаны не столько с самой практикой Agile, сколько с отказом от привычных методов.
По моему опыту, главная проблема при переходе к Agile связана с тем, как безжалостно этот метод открывает нам глаза на наши слабые места. Во многих организациях самое слабое место — это отдел тестирования, — считает Нейт. — Когда цель — регулярная выдача все новых готовых функций, команды вынуждены выстраивать работу в виде коротких насыщенных отрезков. Поэтому Agile показывает, насколько силен в тестировании принцип "пусть код накопится, а там разберемся". Традиционное тестирование — это порочная система, так как в ней приходится выполнять огромную работу на последнем этапе проекта».
Если вы пытаетесь перестроиться на Agile-методологию, то всегда можно найти тысячу объяснений, почему у вас это не получается. Те, кто понимают истинную пользу этого подхода (и действительно стремятся к такому переходу), вероятно, достигнут успеха. Те же, кто только ищет оправдания своих неудач, будут вынуждены либо отказаться от перехода на Agile, либо скатятся на так называемую «видимость Agile» (термин предложен Элизабет Хендриксон).
********
Я хотел завершить этот пост вопросом ко всем разработчикам, тестировщикам и менеджерам проектов: доводилось ли вам терпеть неудачу с Agile? Если да, то по каким причинам? Если же Agile стала вашим путем к успеху — то какие причины поспособствовали этому?
Майк Браун
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.