Работая в сфере IT, невозможно не столкнуться с терминами типа Scrum (скрам) и Agile (аджайл/эджайл). Но именно из-за того, что они постоянно на слуху и вроде бы все знают, что это такое, появляется масса недопониманий. Как говорил Марк Твен, «все проблемы не от незнания, а от уверенности в собственном знании». И к пониманию Agile в среде HR-специалистов это относится в полной мере.

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

И начнем мы, вопреки ожиданиям, с описания «негибкой» системы разработки: как строился процесс создания ПО еще несколько лет назад? С чего, как говорится, все начиналось?

Waterfall, или «Водопад», — традиционный подход к работе над ПО. Для него характерна последовательная разработка: первый этап, второй, третий и т.д. Каждый следующий начинается только после того, как закончился предыдущий.

Преимущество «Водопада» заключается в том, что мы можем более-менее точно рассчитать стоимость разработки и сроки ее завершения.

Основной же минус — при долгосрочном планировании мы рискуем получить на выходе технически и морально устаревший продукт.

Вот как схематически выглядит Waterfall-методология разработки:

В стародавние времена, когда производственные и бизнес-модели не менялись годами, каскадная разработка была вполне оправданна. Сегодня же бизнес не может отдать в разработку глобальную задачу и вернуться за результатом, скажем, через полгода. За это время бизнес-идея может потерять свою актуальность, технологии — измениться, кризис — грянуть (привет, ковид!), биткоин — упасть. Поэтому на смену «Водопаду» пришли так называемые гибкие методологии.

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

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

В 2001 году 17 представителей различных концепций разработки программного обеспечения собрались на горнолыжном курорте в штате Юта и составили Agile-манифест. Этот документ закрепил основные принципы и ценности гибкой разработки. На его можно прочитать более чем на 50 языках, а также ознакомиться со списком авторов, которые его составили. На русском манифест выглядит следующим образом:

«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условия контракта.
• Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева».

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

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

Как выглядит Agile:

Гибкие методологии требуют развития soft skills у IT-специалистов. Если при каскадной разработке программист имел возможность длительное время работать в одиночку и никто его не трогал, то в условиях аджайла с регулярными планерами, демо и код-ревью ему необходим навык эффективного общения и работы в команде.

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

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

В семейство Agile входят следующие методологии: Scrum (скрам), Kanban (канбан), XP, Scrumban (скрамбан). Каждая из них имеет некоторые особенности, которые важно знать, если вы нанимаете персонал под проект.

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

Команда разработки проводит ежедневные 5–20-минутные митинги (совещания), которые позволяют отслеживать ход проекта, быстро выявлять возникающие проблемы и оперативно на них реагировать.

Kanban — еще одна гибкая методология. Основные принципы канбан были унаследованы от подхода, разработанного на заводе Toyota в 1950-х годах. Особенности этой методики заключаются в том, что разработка визуализирована: разделена на задачи, этапы их выполнения маркируются специальными отметками. Количество работ, производящихся одновременно, ограничено. Измеряется и оптимизируется время на выполнение одной задачи.

Extreme Programming, XP. Если описанные выше методологии применимы не только в разработке ПО, то XP — это подход, созданный специально для IT-бизнеса. Его идея проста: взять лучшие практики из других гибких подходов и довести их до экстремально высокого уровня. Например, в рамках данной методологии используется парное программирование: два разработчика на одной машине пишут одну фичу и регулярно (раз в несколько минут) меняются местами. Когда один пишет код, второй его анализирует.

Здесь возникает вопрос, как соотносятся Agile и Scrum. Мне очень понравился ответ, который я увидел где-то на просторах Facebook: примерно так же, как газировка и кока-кола.

Важно понимать, что далеко не во всех компаниях внедрен чистый Scrum или Kanban. Зачастую компания пишет, что работает по скраму, когда у них тупо итерационная разработка, а все прочие условия скрама не соблюдены. Кроме того, на рынке появляются всякие гибридные варианты, которые создают компании. Тот же Сберджайл, например (думаю, не стоит объяснять, в какой компании он применяется, да?).

Развитие гибких систем разработки привело к появлению таких специалистов, как, например, Agile Coach (аджайл-коуч) и Scrum Master (скрам-мастер). Они знают, как создавать, запускать и выстраивать процесс гибкой разработки. Причем их функционал в основном не технический: их сильная сторона — soft skills, за счет чего они становятся одновременно и преподавателями (обучают технологии гибкой разработки), и фасилитаторами (облегчают общение внутри команды), и специалистами по устранению системных препятствий на пути к реализации и продвижению продукта, и выполняют много других функций, благодаря чему проект «едет» в соответствии с принципами Scrum или Agile.

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