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

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

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

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

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

Источник