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