Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому

Генеральный директор компании Accera, консультант по Agile, DevOps и Digital Transformation Анатолий Шеин написал для vc.ru колонку о том, почему гибкая методология разработки может полностью остановить работу крупного бизнеса, но подходит маленьким стартапам.

Периодически мою ленту в Facebook заполняет поток претензий к некорректной работе банковских сервисов. Обычно жалобы пользователей становятся ответом на плановые релизы — обновления и «улучшения» интернет-банков и мобильных приложений.

Сегодня банки почти повально перешли на работу по гибким методологиям и, разом отказавшись от привычной и проверенной Waterfall, внедряют, почти не глядя, Agile. Это не просто модно — это инновационно, и это же реально работает во многих крутых компаниях. По Agile работают в Кремниевой долине, Facebook, Google, Uber. Да и в России на него подсаживаются не только ИТ-компании, но и, например, Министерство образования и Правительство Москвы.

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

Agile — это действительно передовая и эффективная методология. Но, как говорится, что русскому хорошо, то немцу смерть. Так и Agile. В течение одного года я консультировал три стартапа, разрабатывающих ПО в различных областях — от прогрессивной файловой системы до платформы для интернет магазинов. Всем им было достаточно двух-трех недель массированного обучения принципам Agile для того, чтобы перевести процесс разработки на новый лад и выпускать версию раз в две недели.

Совсем по-другому обстояло дело у глобального поставщика телекоммуникационных систем. Компания была на грани срыва поставки нескольких проектов обновления ПО общей стоимостью более $1 миллиона. Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены.

Это не случайность — Agile отлично работает в стартапах, маленьких командах, но на больших проектах, как правило, приводит к большим проблемам: отсрочкам запуска на месяцы и даже полному провалу.

Почему это происходит? При разработке по Agile все делается двухнедельными спринтами — в продакшн отправляются небольшие изменения. По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше.

На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее.

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

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

Да, вышеупомянутые Google, Facebook и Uber — это большие компании. И да, они тоже подвержены «болезням» Agile — время от времени все мы это видим сами или читаем жалобы других пользователей — вчера сервис не работал полдня, сегодня был недоступен полчаса и так далее. Но в этих компаниях цепочки работают почти безупречно, и в случае возникновения проблем команда устраняет их очень быстро. Хотя сейчас проблем становится все больше, и даже в условиях четко отлаженной коммуникации сроки их устранения увеличиваются.

Но все ли могут работать так, как Google? Наверное, банки и другие организации, деятельность которых регламентируется законом, должны всё-таки выстраивать процессы и создавать такую систему, которая сделает эффективной работу любого человека и не допустит серьезных ошибок.

Agile очень привлекателен, и перед ним не смогли устоять не только российские банки, но и многие крупные мировые бренды. И почти все они потерпели неудачу или даже хуже.

Например, в июле 2015 года торги на Нью-Йоркской фондовой бирже были остановлены на четыре часа. Первоначальная версия сбоя основывалась на кибератаке, но проблема оказалась всего-навсего в баге во время очередного обновления. Сложно даже представить, во сколько миллиардов обошлись эти четыре часа простоя центра мировой торговли.

Ладно брокеры — сейчас потеряли миллиард, потом заработали два. Но у авиакомпаний совсем другая история. Примерно так же после банального обновления ПО авиакомпании «Дельта» информация перестала поступать в диспетчерскую систему, и все рейсы пришлось отменить. И здесь, кроме прямых убытков, у авиакомпании возникли репутационные проблемы.

Наверное, один из самых громких провалов применения Agile — это запуск известной американской системы медицинского страхования Obama Care.

Для тех, кто не знает, поясню, что суть этой программы заключалась в предоставлении бесплатных страховых полисов для определенных категорий граждан США.

Чтобы получить право на этот полис, нужно заполнить анкету на сайте и дождаться решения от соответствующих служб. Естественно, сразу после запуска на сайт повалили тысячи и тысячи желающих бесплатной медицины, которые заполняли и заполняли анкеты. Но вот беда — они анкеты заполняли (а анкета там ого-го — кто подавал на получение американской визы, думаю, может себе представить), но не могли их отправить — падал сервер.

Obama Care «полетела» примерно через полгода после запуска. Для того, чтобы все заработало, пришлось пригласить внешнего специалиста-консультанта, который смог оценить картину целиком и, начав с конца — с продакшена, постепенно собирал части системы воедино и все-таки добился слаженной работы.

Agile вполне успешно решает проблему Time Delivery. Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта. В случае Obama Care, и это типичный случай, над проектом работало много людей — несколько больших групп — программисты, специалисты, которые отвечали за работу серверов, представители страховых компаний и другие. И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело.

В моей практике таких проблем не было ни в одном из многочисленных стартапов, однако случалось практически в каждом большом проекте. Например, один из проектов, в котором мы принимали участие, объединял порядка десятка систем — от CRM до системы выставления счетов клиентам. Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз.

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

Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). И после этого процесс проверки занимает по времени от нескольких месяцев до полугода.

Из главных принципов Agile вытекают и главные проблемы.

Во-первых, мы знаем, что общее — это обычно ничьё. Поэтому ответственность за качество продукта нивелируется, и крайнего здесь нет. А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента. В результате проверяются отдельные части программы, а не все приложение в целом.

Такая точечная проверка не позволяет протестировать систему от начала до конца и адекватно оценить общую картину. Именно в этом кроется источник проблем, о которых говорят пользователи в социальных сетях. А дальше как снежный ком — разработчики реагируют на баги, правят код, но в общей системе что-то снова меняется, и возникают новые проблемы. А потом технические проблемы влекут за собой ошибки в работе поддержки, что приводит к жалобам клиентов в ЦБ. В итоге, казалось бы, банальное обновление приводит к реальной угрозе самого существования банка.

Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи. Но должны ли пользователи выполнять работу Quality Assurance? И почему банки готовы идти на репутационные риски ради Agile?

P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в российских банках. Когда я закончил писать эту статью, то зашел на сайт своего банка в Израиле, и тот оказался недоступен.

Agile - это НЕ МЕТОДОЛОГИЯ и НЕ ПРОЦЕСС! Проявите наконец компетенцию, а если не разбираетесь, ну зачем писать. Громкое название статьи, но нет конкретики. Жертва - тот кто пал с концами. Падения на биржах были и из-за "высококачественных" вотерфольных проектов. И банки так же этим страдали. Так все таки кто жертва Agile ??

Кстати, Dmitry Dzhafarov действительно прав :-) Строго говоря, "Agile Software Development” не является ни методологией, ни процессом, а простым набором принципов. Однако за почти 20 лет существования понятие Agile превратилось в собирательное, например https://en.wikipedia.org/wiki/Agile_management

Вы, судя по всему, разбираетесь. Что же тогда - Agile?)

Методологии имеют описанные методы, процессы имеют описанные процессы. А что имеет Agile? Agile имеет вот это agilemanifesto.org/iso/ru/manifesto.html

Это набор принципов. А вот добрая часть доморощенных agile-экспертов по-моему не читали манифест и под эджайлом понимают какие-то методички по скраму.

Попытки обвинить инструмент в том, что исполнители и их руководители - недисциплинированные идиоты, очень наглядно характеризует авторов таких статей. Не вдаваясь даже в подробности, что есть совмещенные Waterflow и Agile фреймворки, как раз для больших государственных и бизнес-организаций, типа Prince 2 Agile.

- Как правило про аджайл, скрам и канбан пишут люди, которые про это не то что не читали, а считают все это одним и тем же. - Это работает на западе, потому что выстроен процесс вокруг что я делал вчера? Что я делаю сегодня? Что буду делать завтра. И как это все улучшить каждый день. Это будет работать, если каждый в команде будет задавать этот вопрос прежде всего самому себе. Более того, я решал 90% проблем за первую неделю, как Продакт Менеджер, просто применяя скрамбан. Увеличение производительности было на уровне 200-300%, при этом не было поиска виноватых и промахов на уровне: -"я сидел ждал пока Петя сделает то и нифига не делал". Каждую неделю надо следить за тем чтобы не допускать моментов, что кто-то блокирует работу, кто-то не работает и так далее. - Чем Agile/Scrum/Kanban всем не нравиться по моему опыту, это тем что надо работать, включаться в процесс, каждый день отвечать за то что ты делаешь и улучшать это, такой ритм не для всех подходит, но это тоже одна из фишек скрама, безболезненно улучшить процессы и убирать не нужных людей из проекта. - Для всего этого нужен крутой Product Manager/Product Owner, которые не будут заниматься мастурбацией, а будут выстраивать продукт изначально выстроив правильные Agile/Scrum процессы.

Для тех кто все таки не читал, но осуждает, прочитайте книгу Джеффа Сазерленда - SCRUM.

под Agile принято сметать весь тот бардак в компании, с которым проект встречается задолго до разработки.

Если есть рабочие примеры agile у больших компаний, как фб, гугл, значит ли это что он не для крупняков?

Заголовок надо поправить на "бардак губит крупный бизнес".

Agile это в первую очередь образ мышления команды, а уж потом фреймворки типа скрама и прочие прикладные вещи. Если команда не понимает и не принимает манифест аджайла на низовом уровне это рождает как раз такие проблемы как в примерах.

Хорошая статья :thumbsup:

"Во-первых, мы знаем, что общее — это обычно ничьё. Поэтому ответственность за качество продукта нивелируется, и крайнего здесь нет."

А как же прожект менеджеры? Для них это одно из главных качеств. Уложить проект в треугольник..

Действительно, менеджеры - "скрам-мастера” и всякие остальные “куры” - отвечают за сроки и содержание. Считается, что качество придёт само собой, стоит только запустить автоматические проверки и, в крайнем случае, благодаря “continuous deployment”, за очень короткие сроки починить в “production” . Этот подход замечательно работает для таких компаний, как Facebook - ну подумаешь, лайк не сработал.

Это прекрасно работает для RTB-рекламных серверов с DMP и прочей доставкой контента. Пока только инфраструктура напрягает- то фрагмент сети отвалится у провайдера, то диск улетит в мир иной. Отдела тестирования в той команде нет вообще. Только автотесты. На UI да, бывают баги, но деньги платят не за это.

Сдается мне, что все доводы построены на заблуждении: "Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта.".

Потому что, говоря о разработке программного обеспечения время доставки ценности может быль маленьким если обеспечивается Качество продукта. А Качество продукта обеспечивается Качеством процесса. И инженерные техники eXtrem Programming (Парное программирование, Тесты первыми (TDD) , Непрерывная интеграция, Рефакторинг) направлены в первую очередь на обеспечение Качества продукта.

Если под Agile понимать только спринты, летучки, игры в планирование то конечно это не будет работать. Гибкая разработка ПО это не всегда ДЕШЕВО, БЫСТРО. Это НЕ ДЕШЕВО, это только иллюзия что быстро, потому что результат доставляется кусочками и можно корректировать развитие. НО за все нужно платить. Поэтому нужны автотесты, нужен TDD, нужна непрерывная интеграция, нужны автоматические приемочные тесты, нужен рефакторинг. И если что-то выкинули "это очень дорого для нас", то готовьтесь к тому что после внедрения будут проблемы.

И чтобы потом не обвинять "Это не мы виноваты, это Agile у нас не работает", Используйте простое правило:

Качество превыше всего.

Улучшая качество, вы улучшите процессы и скорость доставки доставки ценности.

Очень печально, что такие псевдоэкспертные статьи выносятся редакторами на публику. Весь посыл статьи, Agile не работает у больших компаний, потому что есть примеры фейлов. Во-первых, я бы подробнее разобрал эти фейлы, ну даже если принять их, то , во-вторых, назовите мне принципы/подход/методологию/процесс и Пр. , с которыми не было фейлов. С тем же вотерфоллом фейлов не меньше уж точно. Ну вы сами себя послушайте? "Тестирование становится сложным"- это же прямое противоречие тому, что пишите сами. В вотерфолле тестирование на порядок сложнее, более трудоемкое и вероятность пропустить ошибку выше. Да, есть задачи, которые аджайлом не покрыть- строительство атомой станции итерациями и "фаст фейлом" не построить, но не надо говорить про "все" большие корпорации, банки в том числе. Любую хорошую идею можно утопить.

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

Однако Agile в комплексных проектах приводит к потере равновесия между частотой изменений и частотой тестов Почему же? Если так случается, то ценность поставки "работающего продукта" теряется и это уже не agile, а "фигак-фигак-и в продакшн".

Статья не дает ответа на вопрос, какая связь между Agile и отсутствием тестирования бизнес-критичного функционала при релизе

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

Коли зашёл разговор о тестах, то мне как тестеру было бы интересно получить пару ответов:

1) "Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены." (с) - А чем эти тесты занимались раньше, как и что они тестировали до этого момента? - Что понимается под "реальной базой данных"? Если это база с прода, то что мешало сделать копию и тестировать на ней изначально? - Как проверялась работоспособность продукта? Ведь это основная ценность agile.

В целом крайне похоже на историю с водопадом, когда люди делали-делали, а потом начинают тестировать и понеслось.

2) "По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше." На сайте говорится "They have 24 times faster recovery times and three times lower change failure rates." - что относится к fail/success самих билдов больше, чем количеству багов в билде (если я умею английский и осознал смысл происходящего). (ваша ссылка https://puppet.com/resources/white-paper/2016-state-of-devops-report)

Статистика в общем-то говорит о влиянии DevOps практик на результат команд, судя из названия статьи, а не сравнивает Waterfall и Agile. Насколько я понял, интернет говорит, что "DevOps + waterfall != love", и вряд ли где-то это реально работает вместе. А следовательно данная статистика скорее всего говорит о том, как разнятся данные в самих Agile компаниях, что частично подтверждается формулировкой наиболее продуктивные и наименее продуктивные в этом пункте "High-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times."

3) "На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее."

Да, работы прибавляется. Но она пропорциональна изменениям в релизе. Не уверен про уменьшение количества проблем в 3 раза - о чём я писал в п.2. Разница в скорости поставки выглядит правдоподобной. Если говорить о проблемах в этих "небольших изменениях" - то QA в силу размера изменений достаточно быстро даёт фидбек разработчикам, которые всё ещё в контексте проблемы, что приводит к более быстрым фиксам и меньшим постэффектам, но всякое бывает и зависит от сложности кода. Следовательно вопросы таковы: - почему в данной моделе тестирование стало особняком от деятельности команды, так как в Agile нет отдельного этапа тестирования, там говорится о доставке продукта? Да и в Agile в команде разработки есть "член команды", там нет выделенной роли QA. Она разделена между всеми членами команды и одним "эекспертом в этой области", если он есть. - почему число 60, являясь результатом работы QA службы, становится показателем нагрузки на неё же? - тестеры вполне себе могли не успевать проверить сисетму в waterfall, так как на этапе разработки/интеграции у разработчиков возникали проблемы, что отъедало время тестирования. А менеджеры принимали решение провести сколько успеем, что бы войти в бюджет. Где принципиальная разница?

4) "Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов." (с) и "Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность. " (с) - почему эти высказывания противоречат друг другу?

5) "И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело." - Почему пробелемы в коммуникациях стали проблемой только в Agile? В Agile нет как-такого деления "своя работа" - у всей команы есть продукт "obama care", и то что никто ни разу не попробовал его запустить целиком до окончания разработки - это как раз не Agile. Ибо у них не было рабочего продукта (главная ценность и показатель прогресса в Agile) практически до конца разработки. Пока это выглядит как waterfall - каждая команда собрала требования, "реализовала свою часть хорошо", а потом оказалось, что всё не работает. Нет той пресловутой проверки "работоспособности продукта" на каждом этапе.

6) "В моей практике таких проблем не было ни в одном из многочисленных стартапов, однако случалось практически в каждом большом проекте." Так в этом-то и дело, в маленьких проектах код проще, взаимодействия не такие страшные как в большом проекте. Там бы и "ковбойский стиль программирования" отлично бы работал.

7) "Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз." Agile говорит, что проверять надо постоянно работоспособность продукта, а не работоспособность компонента. - проблема в понимании тестирования, а не в Agile.

8) "А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента." - Почему вы решили, что Agile запрещает создавать тесты более высоких уровней: интеграционных и системных? Что бы добиться высокой скорости - рутинную работа автоматизируют, но то, то автоматизация заключается исключительно в unit тестах это проблема конкретной команды\ проекта\ компании. Видимо они не слушают тестеровщиков или изрядно на них экономят. Но это никак не связано в Agile напрямую, скорее как и везде "авось и без них справимся, все же код писать умеем".

9) "Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи." Такое случается, когда тестирования нет или оно выполняется абы как. - Говорит ли Agile что-нибудь о том, как и что надо тестировать?