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

Источник статьи здесь: http://dou.ua/lenta/articles/agile-love/

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

Попробуем разобраться в вопросе — почему же заказчики так любят Agile?

Оставим технические подробности, и переключимся на нечто более важное — на явные и скрытые ожидания клиента. Именно они, а не рациональные рассуждения и точные расчёты, зачастую определяют выбор способа работы (увы). Итак:

Во-первых, Agile — это дешево.

• Не нужен проектный менеджер (зачем? Мы же Agile!).

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

• Не нужно тратиться на документирование. Нет, оно, конечно, будет… какое-то… пусть, в конце концов, программисты сами описывают, что они делают — они же умные.

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

В-третьих, Agile — это безопасно. Не нужно принимать на себя ответственность за решения. Сегодня я хочу одного, завтра — другого, и это нормально. Передумал — не проблема. Выбросить реализованное в корзину — запросто! Новое не налезет на то, что сделано на данный момент, и вообще приводит к краху системы? Это еще с чего вдруг? Зачем же ВЫ тогда ТАК писали код?

В общем, с какой стороны ни глянь, Agile — очень удобная система работы. Оптимальная ли? Это, как говорится, зависит. Говорю сразу: я знаю, что Agile работает. Не просто уверен — я ЗНАЮ. Так как он реально работал в некоторых проектах, в которых я сам участвовал.

Но работает он только тогда, когда соблюдаются хорошо всем известные условия:

• Небольшая, коллоцированная, кроссфункциональная команда высококлассных специалистов (до 9 человек).

• Реальная вовлеченность заказчика, его постоянная готовность к работе с командой.

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

Часто ли соблюдаются эти требования? Увы. Нечасто. А честно говоря — редко. Весьма и весьма.

Во-первых, сплошь и рядом команды распределены, удалены друг от друга, заказчик за океаном и не сильно горит желанием работать с командой (у него бизнес, знаете ли). Их размер достигает нескольких десятков человек, работающих над параллельными потоками задач. Их координация находится на весьма низком уровне (Scrum of Scrums, ага).

Во-вторых, кроссфункциональные команды высококлассных профессионалов — это скорее мечта, чем реальность. В большинстве команд люди разнятся по техническому уровню и мотивации. И рады бы взять только высококлассных самомотивированных профи, да только «на десять девчонок по статистике девять ребят» :). Шутка.

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

• Уже никто не знает, как программа устроена в целом (что-ж вы доки не писали? Ай-яй-яй!).
• Часть людей уходит, новые приходят и долго не могут разобраться в продукте.
• Масштабируемость и производительность продукта исчерпаны, и без жесткого рефакторинга и проработки архитектуры (страшное слово) — с места не сдвинуться.

• Добавление новых фич требует все больше времени из-за нелинейного роста сложности продукта.

• Разработчики все громче и громче матерятся на качество кода. Это все бы ничего (пусть терпят, они же САМИ его писали), да вот беда — могут и уйти со словами «не могу так говнокодить, заказчик сам не знает, чего хочет». И новых набрать — непросто и затратно.

• Мотивация людей, вынужденных часто работать «на корзину», закономерно снижается. Это факт. Кто там чего про «вы должны быть всегда готовы к изменениям?». Ага, должны. Мы вообще много чего должны — зарядку там по утрам, зубы на ночь и т. д. Человеческая психика — штука неумолимая, и ее так просто не обманешь и не пересилишь. Доказано, что работа на корзину — один из главных демотиваторов для профессионала. Это не обсуждается.

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

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

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

И все это как-то работает.

[От редакции: для полноты картины мы решили взять несколько комментариев у практиков Agile.]

Алексей Солнцев, Delivery Manager в Infopulse:

По-правде, в статье всё перевёрнуто с ног на голову. В первую очередь, заказчики любят Agile за счёт скорости вывода продукта или его новой версии на рынок. Во-вторых, те из них, кто когда-то встречался с процессами управления изменениями и такими понятиями, как «Change Request, Impact Analysis, Change Control Board», понимают, насколько дешево им может обходиться внесение изменений в требования, если они будут играть по правилам Agile.

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

Артем Сердюк, ScrumMaster и Agile Coach компании ISM Ukraine:

Если клиенты вмешиваются в выбор процесса (а им и кроме этого есть, чем заняться), в дело вступают не «предрассудки», а ценности: то, что для заказчиков важно в ИТ-проектах. А важна для них надежность, предсказуемость, стабильность. Любой стандартный процесс разработки для заказчика лучше, чем бардак. Неважно, как это называется — Scrum, RUP или CYADD, до тех пор, пока команда выполняет обещания и есть ощущение контроля, клиенту глубоко плевать на процесс.

Другое дело, что Scrum, который мы в этом случае внедрили, — ни в коем случае не Agile-процесс. Agile-процесс — это процесс, который рождается по ходу разработки. Повторю: не продукт эволюционирует (заказчик сам не знал, чего хотел), а процесс. Те правила, которые есть на старте, не работают и все время меняются. Роли меняются. Длина итераций меняется. Только очень-очень базовые вещи остаются… да и то не всегда.

В той среде, о которой говорит автор (кросс-функциональная команда профессионалов, и все в одной комнате, включая заказчика), Agile-процесс не нужен! Все стабильно, все правила известны — к чему тут адаптироваться? Будет работать абсолютно любой процесс.

А вот когда у вас распределенная команда, разница с клиентом в 12 часов, новая для него и для вас предметная область — вот тогда процесс будет и правда Agile. Эксперименты, провалы, эксперименты, успехи. И этот Agile ненавидят как заказчики, так и команды разработки, потому изобретение нового — это постоянный стресс, это невыносимо. Но Agile — единственный известный нам способ работать в таких сложных и непонятных условиях. Поэтому так и работаем.