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

Жертвы 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 вытекают и главные проблемы

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

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

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

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

Источник