Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому
Генеральный директор компании Accera, консультант по Agile, DevOps и Digital Transformation Анатолий Шеин написал для vc.ru колонку о том, почему гибкая методология разработки может полностью остановить работу крупного бизнеса, но подходит маленьким стартапам.
Жертвы Agile
Периодически мою ленту в Facebook заполняет поток претензий к некорректной работе банковских сервисов. Обычно жалобы пользователей становятся ответом на плановые релизы — обновления и «улучшения» интернет-банков и мобильных приложений.
Сегодня банки почти повально перешли на работу по гибким методологиям и, разом отказавшись от привычной и проверенной Waterfall, внедряют, почти не глядя, Agile. Это не просто модно — это инновационно, и это же реально работает во многих крутых компаниях. По Agile работают в Кремниевой долине, Facebook, Google, Uber. Да и в России на него подсаживаются не только ИТ-компании, но и, например, Министерство образования и Правительство Москвы.
Искушение для банков, естественно, очень велико. Особенно, учитывая тот факт, что глава самого крупного из них говорит о дигитализации и внедрении Agile не только на отраслевых площадках, но и на центральном телевидении.
Секрет успеха Agile
Agile — это действительно передовая и эффективная методология. Но, как говорится, что русскому хорошо, то немцу смерть. Так и Agile. В течение одного года я консультировал три стартапа, разрабатывающих ПО в различных областях — от прогрессивной файловой системы до платформы для интернет магазинов. Всем им было достаточно двух-трех недель массированного обучения принципам Agile для того, чтобы перевести процесс разработки на новый лад и выпускать версию раз в две недели.
Совсем по-другому обстояло дело у глобального поставщика телекоммуникационных систем. Компания была на грани срыва поставки нескольких проектов обновления ПО общей стоимостью более $1 миллиона. Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены.
Почему это происходит? При разработке по Agile все делается двухнедельными спринтами — в продакшн отправляются небольшие изменения. По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше.
На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее.
Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов. И в этом заключается еще один «большой секрет для маленькой компании» — некоторые стартапы и большие ИТ-компании (преимущественно из Кремниевой долины) могут позволить себе нанимать крутых специалистов. И это еще одна причина, почему у них все работает хорошо. Возможно, будь у этих людей в распоряжении просто лопата, а не самая модная методология, они бы все равно сделали все очень круто.
В больших же компаниях работает много людей, и большинство из них — это средние специалисты. Конечно, каждый работодатель стремится к тому, чтобы брать к себе лучших, и HR-служба действительно старается. Однако статистика — штука строгая, но справедливая — все лучшие очень быстро делятся на хороших, средних и не очень хороших. И в конце концов все работают как среднестатистические специалисты. В этом случае проекты будут работать хорошо, только если сама методология это позволяет. Потому что при таком раскладе уже нельзя полностью полагаться на хорошую работу сотрудников.
Да, вышеупомянутые Google, Facebook и Uber — это большие компании. И да, они тоже подвержены «болезням» Agile — время от времени все мы это видим сами или читаем жалобы других пользователей — вчера сервис не работал полдня, сегодня был недоступен полчаса и так далее. Но в этих компаниях цепочки работают почти безупречно, и в случае возникновения проблем команда устраняет их очень быстро. Хотя сейчас проблем становится все больше, и даже в условиях четко отлаженной коммуникации сроки их устранения увеличиваются.
Но все ли могут работать так, как Google? Наверное, банки и другие организации, деятельность которых регламентируется законом, должны всё-таки выстраивать процессы и создавать такую систему, которая сделает эффективной работу любого человека и не допустит серьезных ошибок.
Agile-провалы больших компаний
Agile очень привлекателен, и перед ним не смогли устоять не только российские банки, но и многие крупные мировые бренды. И почти все они потерпели неудачу или даже хуже.
Например, в июле 2015 года торги на Нью-Йоркской фондовой бирже были остановлены на четыре часа. Первоначальная версия сбоя основывалась на кибератаке, но проблема оказалась всего-навсего в баге во время очередного обновления. Сложно даже представить, во сколько миллиардов обошлись эти четыре часа простоя центра мировой торговли.
Ладно брокеры — сейчас потеряли миллиард, потом заработали два. Но у авиакомпаний совсем другая история. Примерно так же после банального обновления ПО авиакомпании «Дельта» информация перестала поступать в диспетчерскую систему, и все рейсы пришлось отменить. И здесь, кроме прямых убытков, у авиакомпании возникли репутационные проблемы.
Для тех, кто не знает, поясню, что суть этой программы заключалась в предоставлении бесплатных страховых полисов для определенных категорий граждан США.
Чтобы получить право на этот полис, нужно заполнить анкету на сайте и дождаться решения от соответствующих служб. Естественно, сразу после запуска на сайт повалили тысячи и тысячи желающих бесплатной медицины, которые заполняли и заполняли анкеты. Но вот беда — они анкеты заполняли (а анкета там ого-го — кто подавал на получение американской визы, думаю, может себе представить), но не могли их отправить — падал сервер.
Obama Care «полетела» примерно через полгода после запуска. Для того, чтобы все заработало, пришлось пригласить внешнего специалиста-консультанта, который смог оценить картину целиком и, начав с конца — с продакшена, постепенно собирал части системы воедино и все-таки добился слаженной работы.
Ловушка Agile
Agile вполне успешно решает проблему Time Delivery. Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта. В случае Obama Care, и это типичный случай, над проектом работало много людей — несколько больших групп — программисты, специалисты, которые отвечали за работу серверов, представители страховых компаний и другие. И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело.
В моей практике таких проблем не было ни в одном из многочисленных стартапов, однако случалось практически в каждом большом проекте. Например, один из проектов, в котором мы принимали участие, объединял порядка десятка систем — от CRM до системы выставления счетов клиентам. Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз.
Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность, в отличие от Waterfall, где за качество продукта отвечают специально обученные люди. Кроме того, при использовании гибкой методологии проверка качества должна быть максимально автоматизирована, чтобы вся работа уложилась в короткие сроки двухнедельного спринта.
Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). И после этого процесс проверки занимает по времени от нескольких месяцев до полугода.
Во-первых, мы знаем, что общее — это обычно ничьё. Поэтому ответственность за качество продукта нивелируется, и крайнего здесь нет. А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента. В результате проверяются отдельные части программы, а не все приложение в целом.
Такая точечная проверка не позволяет протестировать систему от начала до конца и адекватно оценить общую картину. Именно в этом кроется источник проблем, о которых говорят пользователи в социальных сетях. А дальше как снежный ком — разработчики реагируют на баги, правят код, но в общей системе что-то снова меняется, и возникают новые проблемы. А потом технические проблемы влекут за собой ошибки в работе поддержки, что приводит к жалобам клиентов в ЦБ. В итоге, казалось бы, банальное обновление приводит к реальной угрозе самого существования банка.
Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи. Но должны ли пользователи выполнять работу Quality Assurance? И почему банки готовы идти на репутационные риски ради Agile?
P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в российских банках. Когда я закончил писать эту статью, то зашел на сайт своего банка в Израиле, и тот оказался недоступен.
Очень печально, что такие псевдоэкспертные статьи выносятся редакторами на публику.
Весь посыл статьи, Agile не работает у больших компаний, потому что есть примеры фейлов. Во-первых, я бы подробнее разобрал эти фейлы, ну даже если принять их, то , во-вторых, назовите мне принципы/подход/методологию/процесс и Пр. , с которыми не было фейлов. С тем же вотерфоллом фейлов не меньше уж точно.
Ну вы сами себя послушайте? "Тестирование становится сложным"- это же прямое противоречие тому, что пишите сами. В вотерфолле тестирование на порядок сложнее, более трудоемкое и вероятность пропустить ошибку выше.
Да, есть задачи, которые аджайлом не покрыть- строительство атомой станции итерациями и "фаст фейлом" не построить, но не надо говорить про "все" большие корпорации, банки в том числе. Любую хорошую идею можно утопить.
Водопад иссяк, в этом сомнений нет. Однако Agile в комплексных проектах приводит к потере равновесия между частотой изменений и частотой тестов. Конечное качество продукта зависит пропорционально от этого равновесия. Компаниям, которые недовольны качеством, необходимо поддерживать равновесие, увеличивая частоту тестов.
Почему же? Если так случается, то ценность поставки "работающего продукта" теряется и это уже не agile, а "фигак-фигак-и в продакшн".