За последние несколько лет гибкие методологии почти вытеснили традиционные способы разработки – полностью по принципам Agile сейчас работают две трети IT-компаний. Оправдались ли ожидания, какие возникают проблемы и куда всё движется? Предлагаем анализ существующего российского и зарубежного опыта работы по Agile и ответы на эти вопросы.

Несмотря на то, что Agile появился около 20 лет назад, более-менее активно применять его начали только в течение последних восьми лет. Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности. То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.

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

Как это работает?

Сегодняшний процесс разработки можно разделить на три этапа: написание кода, подготовка его к запуску и продакшен.

Традиционно целью Agile был первый этап разработки – написание кода. В конце далёких 90-х именно этот этап рассматривался как требующий улучшения и серьёзных изменений. Тогда же получила известность одна из наиболее распространённых имплементаций Agile — Scrum. Справедливости ради стоит отметить, что Scrum вышел в свет в 1986 году, за 15 лет до того, как был адаптирован для Agile в 2001 году.

Scrum приносит выборку того, что нужно писать, позволяет отследить процесс разработки, выявить недостачи и противоречия на начальных этапах. Без технического задания программист не знает, какой именно продукт должен получиться в результате. Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным. Другое дело, например, система биллингa. Программист не знает того огромного количества нюансов, которые необходимо учесть для корректной работы сервиса как регуляционных, так и маркетинговых, как, например, различные модели расчётных операций.

Пионерами Agile были маленькие компании, которые не боялись применять передовые технологии – им нечего было ещё терять! По понятным причинам написание кода в подобных организациях составляет основную часть процесса (процессы подготовки и запуска практически отсутствуют). Эффект был потрясающий! Однако через несколько лет применения традиционного Agile в более развитых организациях стали замечать, что проблемы, связанные с сокращением выпуска на рынок новых продуктов, не исчезли. Agile передвинул затор на следующий этап – на подготовку нового продукта к выпуску. Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.

С целью подготовки написанного кода для потенциального выпуска появился Continuous Delivery. Стоит обратить внимание, что выпуск не обязательно происходит сразу, а может быть задержан, например, для привязки к определённой дате в соответствии с бизнес-задачами. Такой подход позволяет добиться слаженной работы команды, автоматизировать все процессы и повысить скорость потенциальной отправки кода в продакшен. Однако качество продукта гарантируется только за счет автоматических тестов, так как приемочные проверки не справляются со скоростью поставки кода и зачастую используются как формальный этап. Конечно, сегодня такие автоматические тесты отдельных компонент, написанные зачастую самими разработчиками, обеспечивают правильное исполнение кода. Но ни сама методология, ни какие-либо существующие сегодня инструменты не обеспечивают корректную работу кода в более сложной среде – продакшене. Кроме того, не факт, что код будет выполнять необходимые заказчику функции и решать поставленные задачи.

Например, в июле 2015 после очередного обновления ПО были остановлены торги на Нью-Йоркской фондовой бирже. Этот сбой сотряс мировую экономику, в частности, снизил на 1% фондовый индекс США на весь день, а также затормозил переговоры Греции с ее кредиторами на целую неделю! Ещё один яркий пример – обновление системы продажи авиабилетов в компании «Дельта». После выпуска нового ПО в продакшен информация вообще перестала поступать в диспетчерскую службу. В результате авиакомпания отменила все рейсы и понесла существенные финансовые и репутационные потери. Несомненно, в обоих случаях многие проверки перед запуском были пройдены и, тем не менее, ещё многие были бы сделаны, если бы занимали меньше ресурсов и времени.

Пробел с обеспечением качества кода сегодня очень актуален и он будет постепенно заполняться. По оценкам Gartner, в ближайшие три года по крайней мере 75% IT–корпораций будут вынуждены развить автоматическое тестирование, интегрирующее бизнес-процессы. Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.

У кого это работает?

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

Но есть часть компаний, где полноценно адаптировать гибкие методологии пока не удаётся – результатов либо нет вообще, либо они не соответствуют ожиданиям бизнеса. Например, ING и Citibank считаются самыми продвинутыми в банковской сфере по части адаптации Agile. Однако далеко не все отделы этих финансовых гигантов работают по гибким методологиям. На Agile перешли, в основном, те подразделения, которые занимаются поверхностными оболочками, мобильными приложениями или другими передовыми разработками. Иными словами, отделы, не связанные с основными бизнес-процессами, сбой которых может поставить под удар годовые доходы и привести к краху всей корпорации.

То есть в тех областях, где цена ошибки очень высока, компании пока опасаются что-то менять. Да, они понимают, что Waterfall себя изжил и, работая по-старому, можно в какой-то момент остаться далеко позади от конкурентов и всё потерять. Они бы и рады перейти на новые методы работы, но пока риски гораздо выше, чем потенциальная выгода от нововведений. Кроме того, зачастую необходимы большие вложения, чтобы перевести бизнес на гибкие методологии и далеко не факт, что всё сразу заработает хорошо. Это касается в первую очередь тех компаний, где большинство бизнес-процессов построено на ПО, написанном десятки лет назад на языках программирования, не столь модулярных, как Java, Scala, GO и пр.

Но те компании, которые пытались внедрить Agile и не получили ожидаемых результатов, всё больше и больше проявляют недовольство. Им обещали, что после имплементации гибкой методологии КПД увеличится, а time-to-market и вместе с ним затраты на производство сократятся. Однако ожидаемого эффекта не возникает, так как код выходит быстрее и всё больше и больше проблем появляется на продвинутых этапах разработки. КПД в некоторых случаях повышается, однако заметного сокращения затрат не происходит. Но чаще всего случаются откаты из продакшена, которые бьют по времени достижения целей, бьют по time-to-market и стоят очень дорого, так как исправление багов в продакшене требует гораздо больших затрат ресурсов разработчиков. Цена ошибки возрастает не только из-за позднего обнаружения, но и из-за высокой скорости разработки. Этот эффект можно сравнить с турбулентностью в потоках, когда скорость потока превышает максимально допустимую для данной среды.

Всё это привело к тому, что в последнее время появился большой спрос на инструменты, позволяющие решить эти проблемы и всё-таки добиться Agile-эффекта.

Как повысить эффективность?

Облака очень активно развивались в последнее десятилетие и частично открыли шлюзы для проведения тестирования в больших масштабах. Однако проблема полностью не была решена – несмотря на все преимущества, облачные технологии относительно дороги. Кроме того, не всегда просто построить необходимые среды проверок в cloud. Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.

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

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

На чем стоит и куда движется Agile

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

В дальнейшем это смещение будет сдвигаться ещё дальше влево, ещё ближе к программистам – то есть все проверки, включая интегральные и стрессовые, будут производиться предельно близко к источнику изменений и к моменту изменения. Это обусловлено необходимостью баланса между частотой изменений и частотой тестов.

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

Таким образом, чтобы повысить Agile-эффект, необходимо в первую очередь реализовать два условия:

1. Появление возможности для запуска бизнес-тестов без особых затрат,
2. сдвиг интегрального и бизнес-тестирования как можно ближе к источнику изменений.
И, конечно же, нужны эффективные решения для мониторинга качества работы приложений в реальных условиях.

Когда наступит «золотой век» Agile?

С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов. Сегодня поле деятельности этих методологий не ограничено командами разработчиков. Гибкие процессы успешно внедряются практически во все отделы IT и даже бизнес руководствуется стандартами Agile. Среди наиболее известных можно отметить Scrum, Scrumban, SAFe, ScaleAgile@Spotify, Continuous Delivery, Lean, Prince2 Agile и многие другие.

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

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

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

Решив эту проблему, в последующие 5 лет гибкие методологии откроют себе путь в оставшуюся треть корпораций, которые до тех пор не осмелятся переводить разработку на более современный, но рискованный лад.

Автор:

Источник