Как появился Agile?

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

Культура Agile — это набор ценностей и принципов, в совокупности определяющий подход компании к ведению бизнеса и производству продуктов.

Наш мир очень быстро меняется, как в целом, так и в ИТ-сфере. Понимание Agile меняется вместе с ним, поэтому мы не ставили перед собой цель рассказать обо всех аспектах этого явления. Эта статья повествует о причинах возникновения Agile, понимание которых позволит вам осознанно принимать решение о своём отношении к Agile и его практикам.

Современный мир представляет из себя непредсказуемую, быстро меняющуюся среду — VUCA world. Этот термин является англоязычной аббревиатурой, образованной от слов volatility — нестабильность, uncertainty — неопределённость, complexity — сложность и ambiguity — неоднозначность, двусмысленность.

Какие процессы мы можем наблюдать в современном мире?

• Глобализацию рынков, что означает возможность компаний захватывать зарубежные рынки
  
• Падение прибыльности инвестиций
  
• Обострение конкуренции, то есть увеличение количества товаров и предложений
  
• Нехватку кадров в информационных технологиях и приток людей по линии переподготовки, иными словами недостаточное количество компетентных специалистов
  
• Сверхбыструю сменяемость технологий (большое количество устройств и инструментов устаревают быстрее, чем мы успеваем к ним привыкнуть)
  

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

Развитие технологий происходит по так называемой S-кривой.

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

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

Практически весь XVII век в Европе ушел на то, чтобы перейти от первых изобретений парового двигателя до первого промышленного применения. В конце XVIII века вакуумная паровая машина Джеймса Уатта положила начало промышленной революции. Были созданы целые отрасли и научные школы, применение, характеристики и прибыли выросли экспоненциально. Массовые дальние грузоперевозки стали требовать угля и стали, предрекая закат конного транспорта.

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

Внимание изобретателей постепенно переходит к двигателям внутреннего сгорания. На то, чтобы пройти путь от первых демонстраторов до предела эффективности технологии на нефти и двигателях внутреннего сгорания нам понадобилось не 3 века, а уже только один. За этот же век конный транспорт окончательно перешел в разряд развлечений и занял свою узконаправленную сферу применения.

Когда технология выходит на плато, массовые инвестиции из неё перекидываются в проекты с новой идеей. И начинается разгон следующей S-кривой.

Обратите внимание на несколько самых известных векторов развития технологий, они имеют именно такую S-образную форму: уголь — нефть — атомная энергетика; зерно — дрова — уголь; паровая машина — двигатель внутреннего сгорания — турбина.

Эта теория объясняет бешеные скачки технологий. В том числе и у нас, в сфере ИТ.

Если вы посмотрите на даты выпуска какой-либо ИТ-технологии, то поймёте, почему трудно угнаться за их развитием. Обновления нотаций UML и BPMN, например, выходили практически ежегодно.

Чтобы использовать в работе, например, С++, java, php и другие технологии нужно регулярно прикладывать силы по их изучению. Вот таблицы выпуска новых версий:

Ни одна технология в итоге не отлажена на 100%.

Чтобы убедиться в этом, достаточно заглянуть в Bug Tracker какого-нибудь открытого проекта и увидеть значительное количество багов, которое там никогда не переводится.

Аналогично и с Agile. Посмотрите, к примеру, на понимание роли Scrum-мастера в фреймворке Scrum. С момента первого выпуска Scrum Guide каждые полтора года менялась даже такая ключевая вещь, как понимание роли scrum-мастера (смотрите статью Василия Савунова Scrum Master. История роли. Часть 1: до Scrum Guide — статья в блоге ScrumTrek, Scrum Master. История роли. Часть 2: Scrum Guide — статья в блоге ScrumTrek).

Ни одну технологию не удаётся освоить досконально. Команда пишет код, выходит новая версия языка программирования, библиотеки или чего-то еще. И вот уже оказывается, что некоторые вещи нужно делать по другому. Посмотрите на Django, React и любую другую технологию. Интервал выпуска новых версий большинства активно используемых ИТ-технологий составляет год-два. А часто и два-три раза в год.

Даже много и тяжело работающий инженер не в состоянии изучить досконально ни одну из технологий.

Это, в частности, порождает эффект молодой красноглазой студенческой команды, которая имела некоторую фору во времени на освоение новых трендов. Ребята приходят с модными инструментами и актуальными знаниями, поэтому первое время «стартаперы» действительно обгоняют «старпёров».

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

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

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

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

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

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

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

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

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

Поскольку рынок глобальный, то нормальным становится, например, когда китайцы что-то делают для американского рынка или белорусы что-то делают для немецкого рынка.

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

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

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

Вместо S-кривой мы получаем кривую с горбом избыточных инвестиций, которую иллюстрирует цикл зрелости технологий.

Что это меняет для нас, ИТ-шников?

Инвестиции переключаются быстрее, чем могли бы. Приходит топ-менеджер с чемоданом денег. Менеджеры нанимают или привлекают команды. Команды начинают срочно писать код. Менеджеры чудовищно давят по срокам (цикл очень сжат, мы должны успеть быстрее конкурентов). Рано или поздно начнется неизбежное падение, и очень многие уйдут с рынка. Мы потеряем инвестиции, а значит проект будет закрыт. Команды перейдут на другие проекты или в другие компании.

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

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

И вот мы оказываемся в VUCA-world, нестабильность которого можно показать как череду кривых хайпа новых технологий. Постоянная смена контекста, в котором мы живём, порождает неопределённость и неоднозначность.

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

Все эти перемены ярче всего отражаются в IT-отрасли, где и зародился Agile. Если посмотреть на индекс Nasdaq, можно заметить, что ближе к рубежу тысячелетий был подъём инвестиций в IT-отрасль, а затем последовало резкое падение.

Нынешний подъём IT-сферы связан с распространением по миру интернета (53% населения Земли) и с распространением мобильных технологий (107% мобильных устройств на человека). Пока индекс находится в растущей фазе, но где-то обязательно будет обрыв, приток инвестиций не будет бесконечен.

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

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

Быстро выходить на рынок и быстро адаптироваться к его обратной связи

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

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

Нанимать тех, кто сможет адаптироваться к постоянно меняющимся технологиям

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

Кроме того, нельзя досконально знать все возможности какого-то языка программирования или другого инструмента, как и нельзя знать досконально все его изъяны.

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

Стабилизировать цикл производства ПО

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

Agile предлагает бизнесу в первую очередь принципы гибкости разработки, а основным инструментом для этого является циклическая поставка с постоянным обучением через опыт (ключевым проводником усвоения опыта в Scrum, например, выступают ретроспективы).

Максимально ускорить производство

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

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

Кто-то узнает принцип, сформулированный Кентом Беком ещё в 1983 году: Make It Work Make It Right Make It Fast.

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

Решать проблему выгорания сотрудников

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

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

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

Относиться к людям как к ценнейшему ресурсу

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

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

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

В знаменитом манифесте Agile всего четыре пункта, причем они достаточно очевидны.

1) Люди и взаимодействие важнее процессов и инструментов

Разумеется, скажете вы. Пока у вас маленькая команда, процессы вам вообще не нужны. С ростом сложности проекта важность процессов повышается. Компания не должна игнорировать их, иначе рискует превратить разработку в хаос.

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

2) Работающий продукт важнее исчерпывающей документации.

Большинство людей не очень любит бумажную работу. Ходят слухи, что Agile позволяет ее избежать. Но не любить писать что-то бесполезное — это совершенно нормально. И если у вас всего одна ночь, то нужно принять решение, на что ее потратить: доработать и выпустить версию или дописать документацию? Как и любой человек в здравом уме, вы выберите первое. Означает ли такое решение отказ от документации при штатной работе или от ее выпуска постфактум? Нет. Говорит ли нам Agile «расслабься, не надо ничего писать»? Тоже нет. Для компании выпустить работающий продукт на рынок — это первейший приоритет.

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

3) Сотрудничество с заказчиком важнее согласования условий контракта

Есть два диаметрально противоположных подхода к оплате проекта заказчиком: контракт с фиксированной ценой (Fixed time) и контракт с оплатой выполненных работ (Time and materials).

Модель Fixed Price предполагает, что сроки и бюджет на разработку проекта утверждается перед стартом работ, а риски за несвоевременное выполнение работ ложатся на исполнителя. Командам, работающим в подобных условиях, не поможет никакой Agile. Это нормально, пытаться дотошно согласовывать детали и не идти на уступки, перекладывая ответственность в таком случае.

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

Делать по такой схеме крупные проекты чрезвычайно трудно, но иногда другого способа просто нет (например, в государственных компаниях или в компаниях с планированием бюджета на пол года и год вперед). Использование мышления Agile и в таких проектах вполне возможно, но ценность «Сотрудничество с заказчиком важнее согласования условий контракта» в таком случае не работает.

Тем не менее, существуют проекты с другим подходом (Time and materials), где заказчик оплачивает выполненную вами работу, а значит несет часть рисков в случае, если сделано что-то не то, что самом деле нужно. Или заняло слишком много времени, а значит и денег. Здесь команда может построить прозрачные отношения, в которых именно взаимодействие с заказчиком будет стоять на первом месте, а не написанные в контракте требования.

Но даже это не означает, что фиксировать ничего не нужно. Просто заключите новый контракт, если старый перестает соответствовать действительности.

4) Готовность к изменениям важнее следования первоначальному плану

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

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

И в то же время Agile никак не отрицает важность планирования. Оно важно. Но вы должны быть готовы перепланировать все заново. Такова жизнь.


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

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

Agile объединяет методики и подходы к управлению бизнесом, командами, продуктами, с помощью которых компании:

• Фокусируются на нуждах и целях клиентов (то есть знают потребителя, а не делают продукт наугад)
• Упрощают организационную структуру компании и процесс (чтобы максимально ускорить разработку)
• Выполняют работу короткими циклами (что позволяет быстро получить обратную связь или скорректировать неудачные процессы)

Для команд Agile стал глотком определённости, позволяющим не выгореть на работе и обуздать противоречия в команде за счёт общих ценностей и культуры, которые команда знает, понимает и принимает.

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

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

Эта статья подготовлена Гасраталиевой Анной и Карповой Анастасией на основе вебинара Сергея Нужненко. Мы раскрыли лишь часть этого доклада, поэтому, если вы хотите узнать подробнее о влиянии мировых трендов на ИТ-команду, понять суть противоречий между сотрудниками в нашей сфере и разобрать принципы Agile, чтобы принимать осознанно принимать решения в ответ на очередное изменение среды, рекомендуем посмотреть вебинар Сергея.