Почему Agile губит крупный бизнес и помогает малому

Автор: head

Дата: 11.01.2017

Сегодня многие компании повально переходят на работу по гибким методологиям и, разом отказавшись от привычной и проверенной Waterfall, внедряют, почти не глядя, Agile. Это не просто модно — это инновационно, и это же реально работает во многих крутых компаниях. По Agile работают в Кремниевой долине, Facebook, Google, Uber. Да и в России на него подсаживаются не только ИТ-компании, но и Министерство образования и Правительство Москвы.

Успех Agile

Существует четыре ценности Аgile:
1. Люди и коммуникации важнее процессов и инструментов.
2. Рабочий продукт важнее исчерпывающей документации.
3. Взаимодействие с заказчиком важнее проработки деталей контракта.
4. Готовность к изменениям важнее следования плану.

Agile — это действительно передовая и эффективная методология. Но, как говорится, что русскому хорошо, то немцу смерть. Так и Agile. Если стартапам  достаточно двух-трех недель, чтобы перейти на Agile.  То с крупными компаниями дела обстоят иначе. Возьмем к примеру глобального поставщика телекоммуникационных систем. Компания была на грани срыва поставки нескольких проектов обновления ПО общей стоимостью более $1 миллиона. Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены.

Это не случайность — Agile отлично работает в стартапах, маленьких командах, но на больших проектах, как правило, приводит к большим проблемам: отсрочкам запуска на месяцы и даже полному провалу

Почему это происходит? При разработке по Agile все делается двухнедельными спринтами — в продакшн отправляются небольшие изменения.

На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее.

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

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

Да, вышеупомянутые Google, Facebook и Uber — это большие компании. И да, они тоже подвержены «болезням» Agile — время от времени все мы это видим сами или читаем жалобы других пользователей — вчера сервис не работал полдня, сегодня был недоступен полчаса и так далее. Но в этих компаниях цепочки работают почти безупречно, и в случае возникновения проблем команда устраняет их очень быстро. Хотя сейчас проблем становится все больше, и даже в условиях четко отлаженной коммуникации сроки их устранения увеличиваются.

Agile-провалы больших компаний

Agile очень привлекателен, и перед ним не смогли устоять не только российские банки, но и многие крупные мировые бренды. И почти все они потерпели неудачу или даже хуже.

Например, в июле 2015 года торги на Нью-Йоркской фондовой бирже были остановлены на четыре часа. Первоначальная версия сбоя основывалась на кибератаке, но проблема оказалась всего-навсего в баге во время очередного обновления. Сложно даже представить, во сколько миллиардов обошлись эти четыре часа простоя центра мировой торговли.

Ладно брокеры — сейчас потеряли миллиард, потом заработали два. Но у авиакомпаний совсем другая история. Примерно так же после банального обновления ПО авиакомпании «Дельта» информация перестала поступать в диспетчерскую систему, и все рейсы пришлось отменить. И здесь, кроме прямых убытков, у авиакомпании возникли репутационные проблемы.

Негативные отклики о работе Agile конечно есть. Сколько людей, столько и мнений. 

«Когда распоряжение поступает сверху в административном порядке, в духе: «С понедельника мы Agile», это не работает, и, конечно, вызывает негатив у людей», - говорит Дмитрий Емельянов, Scrum-мастер в Альфа-Лаборатории.

Agile – это не про то как работать меньше, это про то как работать эффективно. Люди втягиваются, и им нравится так работать. Просто потому что они любят свой продукт и хотят его сделать реально классным, чтобы их пользователю было приятно им пользоваться, чтобы в AppStore ставили 5 звезд. Разумеется, проще работать по-старому. Обычно негатив по поводу Agile  идет от людей, которые не готовы меняться. А вообще, Agile можно только заразить, и он точно должен идти снизу и встретить одобрение сверху, а не наоборот. Стать Agile это кардинально сменить образ жизни. Agile – это то, что на кончиках пальцев, это просто нужно чувствовать. Применять данный метод можно везде. И если человек говорит, что Scrum в его продукте не работает, значит, он пока еще не умеет выделять главную ценность своего продукта. Люди привыкли думать и жить решениями, а нужно учиться жить целями. Если мы хотим построить мост, то мы просто возьмем и построим мост. Если мы захотим построить его по Scrum, то скорее всего в первой итерации это будет рыбацкая лодка, которая перевозит людей. Потому что главная ценность продукта в том, чтобы пользователи (жители) могли оказаться на другой стороне реки. Цель достигнута, бизнес ценность уже есть, а дальше мы можем развивать продукт, при этом он уже себя окупает. Мост, возможно, мы и не построим. Плохо ли это? Да, если мы просто хотим построить мост. И очень хорошо, если мы хотим помочь людям, которые не могут перебраться на другую сторону реки.

Пожалуй, самый громкий провал применения Agile — это запуск известной американской системы медицинского страхования Obama Care

Суть проекта заключалась в предоставлении бесплатных страховых полисов для определенных категорий граждан США.

Чтобы получить право на этот полис, нужно заполнить анкету на сайте и дождаться решения от соответствующих служб. Естественно, сразу после запуска на сайт повалили тысячи и тысячи желающих бесплатной медицины, которые заполняли и заполняли анкеты. Но вот беда — они анкеты заполняли (а анкета там ого-го — кто подавал на получение американской визы, думаю, может себе представить), но не могли их отправить — падал сервер.

Obama Care «полетела» примерно через полгода после запуска. Для того, чтобы все заработало, пришлось пригласить внешнего специалиста-консультанта, который смог оценить картину целиком и, начав с конца — с продакшена, постепенно собирал части системы воедино и все-таки добился слаженной работы.

Ловушка Agile

Agile вполне успешно решает проблему Time Delivery. Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта. В случае Obama Care, и это типичный случай, над проектом работало много людей — несколько больших групп — программисты, специалисты, которые отвечали за работу серверов, представители страховых компаний и другие. И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело.

Стартапам это не грозит, но большие проекты точно попадут в ловушку. Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность, в отличие от Waterfall, где за качество продукта отвечают специально обученные люди. Кроме того, при использовании гибкой методологии проверка качества должна быть максимально автоматизирована, чтобы вся работа уложилась в короткие сроки двухнедельного спринта.

Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). И после этого процесс проверки занимает по времени от нескольких месяцев до полугода.

Из главных принципов Agile вытекают и главные проблемы

Разумеется, все мы знаем, что нет ничего хуже коллективного бессознательного. Ответственность за качество продукта нивелируется, и крайнего здесь нет. Также необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента. В результате проверяются отдельные части программы, а не все приложение в целом.

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

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

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

 

теги

присоединяйтесь к нам в соц. сетях

© 2016 “АПИТ”. Все права защищены

рассылка

Хотите следить за нашими новостями и событиями? Подпишитесь на нашу рассылку!

читайте также

Андрей Карабанов о Customer Development: как создать продукт, который купят

Дмитрий Емельянов: зачем руководителям нужны Agile и Scrum?

Спин-офф проекты: особенности формирования и отличия от стартапов

Самый маржинальный бизнес: в каких сферах наценка в 2000 процентов стала нормой?

комментарии

Оставить коментарий