{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

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

0
93 комментария
Написать комментарий...
Семен Смирнов

Статья не дает ответа на вопрос, какая связь между Agile и отсутствием тестирования бизнес-критичного функционала при релизе

Ответить
Развернуть ветку
Anatoly Shein

Голый Agile говорит об автоматических тестах и скорости изменений, чтобы починить быстро то, что завалилось в продакшн. Он не дает инструментов для быстрого тестирования бизнес-критичного функционала.

Ответить
Развернуть ветку
Ivan Trechyokas

Коли зашёл разговор о тестах, то мне как тестеру было бы интересно получить пару ответов:

1) "Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены." (с)
- А чем эти тесты занимались раньше, как и что они тестировали до этого момента?
- Что понимается под "реальной базой данных"? Если это база с прода, то что мешало сделать копию и тестировать на ней изначально?
- Как проверялась работоспособность продукта? Ведь это основная ценность agile.

В целом крайне похоже на историю с водопадом, когда люди делали-делали, а потом начинают тестировать и понеслось...

2) "По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше."
На сайте говорится "They have 24 times faster recovery times and three times lower change failure rates." - что относится к fail/success самих билдов больше, чем количеству багов в билде (если я умею английский и осознал смысл происходящего).
(ваша ссылка https://puppet.com/resources/white-paper/2016-state-of-devops-report)

Статистика в общем-то говорит о влиянии DevOps практик на результат команд, судя из названия статьи, а не сравнивает Waterfall и Agile. Насколько я понял, интернет говорит, что "DevOps + waterfall != love", и вряд ли где-то это реально работает вместе. А следовательно данная статистика скорее всего говорит о том, как разнятся данные в самих Agile компаниях, что частично подтверждается формулировкой наиболее продуктивные и наименее продуктивные в этом пункте "High-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times."

О DevOps + waterfall:
https://techbeacon.com/devops-waterfall-dont-waste-your-time

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

Да, работы прибавляется. Но она пропорциональна изменениям в релизе. Не уверен про уменьшение количества проблем в 3 раза - о чём я писал в п.2. Разница в скорости поставки выглядит правдоподобной.
Если говорить о проблемах в этих "небольших изменениях" - то QA в силу размера изменений достаточно быстро даёт фидбек разработчикам, которые всё ещё в контексте проблемы, что приводит к более быстрым фиксам и меньшим постэффектам, но всякое бывает и зависит от сложности кода.
Следовательно вопросы таковы:
- почему в данной моделе тестирование стало особняком от деятельности команды, так как в Agile нет отдельного этапа тестирования, там говорится о доставке продукта? Да и в Agile в команде разработки есть "член команды", там нет выделенной роли QA. Она разделена между всеми членами команды и одним "эекспертом в этой области", если он есть.
- почему число 60, являясь результатом работы QA службы, становится показателем нагрузки на неё же?
- тестеры вполне себе могли не успевать проверить сисетму в waterfall, так как на этапе разработки/интеграции у разработчиков возникали проблемы, что отъедало время тестирования. А менеджеры принимали решение провести сколько успеем, что бы войти в бюджет. Где принципиальная разница?

4) "Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов." (с)
и "Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность..." (с)
- почему эти высказывания противоречат друг другу?

5) "И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело."
- Почему пробелемы в коммуникациях стали проблемой только в Agile?
В Agile нет как-такого деления "своя работа" - у всей команы есть продукт "obama care", и то что никто ни разу не попробовал его запустить целиком до окончания разработки - это как раз не Agile. Ибо у них не было рабочего продукта (главная ценность и показатель прогресса в Agile) практически до конца разработки. Пока это выглядит как waterfall - каждая команда собрала требования, "реализовала свою часть хорошо", а потом оказалось, что всё не работает. Нет той пресловутой проверки "работоспособности продукта" на каждом этапе.

6) "В моей практике таких проблем не было ни в одном из многочисленных стартапов, однако случалось практически в каждом большом проекте."
Так в этом-то и дело, в маленьких проектах код проще, взаимодействия не такие страшные как в большом проекте. Там бы и "ковбойский стиль программирования" отлично бы работал.

7) "Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз."
Agile говорит, что проверять надо постоянно работоспособность продукта, а не работоспособность компонента.
- проблема в понимании тестирования, а не в Agile.

8) "А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента."
- Почему вы решили, что Agile запрещает создавать тесты более высоких уровней: интеграционных и системных? Что бы добиться высокой скорости - рутинную работа автоматизируют, но то, то автоматизация заключается исключительно в unit тестах это проблема конкретной команды\ проекта\ компании. Видимо они не слушают тестеровщиков или изрядно на них экономят. Но это никак не связано в Agile напрямую, скорее как и везде "авось и без них справимся, все же код писать умеем".

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

В общем, вся статься похожа на кране забавный пример того, как кого-то начал делать старые дела на новый лад, назвал это Agile (ну ведь не waterfall же? а если не он, то получается это уже Agile!), и при этом у него так как все проблемы скатываются к тому, что:
- Если проект работает не по waterfall, то стиль его работы автоматически подпадает у вас под определение Agile. А это не так! Смотрите видео
(Как понять, что Agile работает | https://habrahabr.ru/company/oleg-bunin/blog/309878/ )
- Никто не понимает, что такое Agile - но все по нему работают =)
- Все считают, что привычки и mindset людей при добавлении стендапов моментально меняется - а вот и нет.
- вместо продукта в целом, команды\проекты думают только о своём компоненте (в общем-то, как и в Waterfall). Тестеры же всё равно проверят в конце!
- тестирование реализовано кусочно: unit тесты уже хорошо, но всё ещё не достаточно. Проблема всех и вся.
- P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в Agile компания. +__+

Ответить
Развернуть ветку
90 комментариев
Раскрывать всегда