[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } } ]
{ "author_name": "Редакция vc.ru", "author_type": "self", "tags": ["\u043a\u043e\u043b\u043e\u043d\u043a\u0430"], "comments": 123, "likes": 49, "favorites": 35, "is_advertisement": false, "section_name": "default", "id": "20942", "is_wide": "1" }
Редакция vc.ru
40 500

Жертвы 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. Справедливости ради стоит отметить, что такие проблемы существуют не только в российских банках. Когда я закончил писать эту статью, то зашел на сайт своего банка в Израиле, и тот оказался недоступен.

#Колонка

{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления