Постигаем гибкие методологии: что такое Agile и почему все хотят по нему работать

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

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

Что такое методология Agile

Agile (Аджайл) — это философия и семейство гибких методологий для управления проектами и разработки ПО.

Главные особенности подхода:

• гибкость;
• скорость;
• прозрачность рабочих процессов;
• постоянное общение: с заказчиком, клиентом и сотрудниками внутри команды.

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

Как правило, итерации длятся 2–3 недели и разделяются на пять этапов:

1. Анализ.
2. Планирование.
3. Выполнение.
4. Тестирование.
5. Релиз продукта.

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

История появления метода Agile

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

Метод Agile — достаточно молодой. Он появился в начале 2000-х годов. До этого широко использовалась каскадная методология разработки ПО — Waterfall.

Чтобы понять суть Waterfall, можете представить водопад. Вода (задачи проекта) стекает вниз по ступеням водопада (этапам проекта) и в финале попадает в водоем (созданный продукт).

Обычно работа по Waterfall состоит из таких этапов:

1. Анализ требований.
2. Проектирование.
3. Разработка.
4. Тестирование.
5. Поддержка созданного ПО.

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

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

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

Но если говорить о разработке полезного и инновационного ПО, то всё не так радужно.

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

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

Разработчики посовещались и поняли — хватит это терпеть. Чтобы создать альтернативу традиционной модели, в 2000 году в штате Юта собрались 17 разработчиков и сделали Agile-манифест.

Принципы и ценностиAgile

Основные принципы Agile отражены в специальном манифесте — всего их 12.

1. Клиент всегда на первом месте. Главная задача Agile-команды — удовлетворить потребности заказчика. Делается это благодаря быстрой и частой поставке ПО на рынок.
2. Положительная реакция на изменения продукта. Важно понимать, что рынок постоянно меняется. Чтобы создать инновационный продукт, команда может изменять ПО на любом этапе разработки.
3. Продукт стоит выпускать регулярно. Это нужно для сбора фидбека от целевой аудитории и постоянного совершенствования ПО. Частота выпуска может варьироваться, но классикой для Agile считается срок от 2 недель до 2 месяцев.
4. Разработчики и заказчики работают вместе. Постоянное общение помогает оперативно решать проблемы и находить неожиданные функции. Для этого в Аджайл есть специальные встречи — каденции.
5. Над проектом должны работать мотивированные профессионалы. Простая истина: чтобы работа была сделана хорошо, нужно нанять не просто экспертов своего дела, но и предоставить им комфортные условия, инструменты и оплату.
6. Лучший способ передать информацию — пообщаться. В Agile стараются свести на минимум общение через менеджеров и владельцев продукта. Лучше всего общаться друг с другом напрямую и решать вопросы по мере их возникновения.
7. Главный показатель успеха — работающий продукт. Agile-разработка — не про строгую документацию. Самое главное — быстро предоставить клиенту продукт с нужным ему функционалом. Приведем пример. Представьте, что команде нужно сделать крабовый салат, но у сотрудников закончилась кукуруза. Согласно Agile, лучше отдать клиенту салат без кукурузы, чем не отдать вовсе.
8. Гибкие методологии разработки программного обеспечения помогают поддерживать ритм. Проще говоря, команда будет постоянно развиваться и только наращивать темп работы.
9. Важно уделять внимание технической стороне проекта. Agile — про постоянное движение. Поэтому каждый новый проект — это возможность попробовать что-то новое и улучшить рабочий процесс или продукт.
10. Чем проще, тем лучше. Не нужно усложнять и пытаться вместить в продукт всё и сразу. Возвращаясь к примеру с крабовым салатом, в него, как и в ПО, можно добавить огурец, рис, капусту и красную икру. Но нужно ли это вашему клиенту? Лучше сделать простой вариант и добавить новые фишки позже.
11. Лучшие команды — самоорганизованные команды. Сработанная команда профессионалов может предложить более качественные решения, чем эксперты извне.
12. Сила в аналитике. Этот принцип заключается в постоянном совершенствовании. Работая по Agile, стоит всегда задавать вопрос «А можно ли сделать еще лучше?». Ответить на него и подлатать слабые места помогут отчеты о выполненных задачах.

Чуть позже разработчики объединили смысл манифеста и выделили 4 ценности Agile.

1. Люди и взаимодействие важнее процессов и инструментов. Конечно, хорошие условия для работы также важны, но на первом месте всегда будет общение и сплоченность команды.
2. Работающий продукт важнее строгой документации. Это не значит, что в Agile нет документов. Но если сотрудник стоит перед выбором доработать ПО или заполнить отчет, приоритет всегда будет отдаваться первому.
3. Общение с заказчиком важнее четкого ТЗ. На встречах в приоритете будет обсуждение продукта и его функционала, а не условий договора и прописывания каждого шага в техническом задании.
4. Открытость к изменениям важнее начального плана. Гибкость и адаптивность — ключевые качества Agile-команды.

Agile-менеджмент: преимущества и недостатки

Конечно же, Agile — не волшебная таблетка для проектов. Как и другие методологии разработки ПО, подход имеет ряд плюсов и минусов.

Плюсы

Открытость к изменениям. Из-за гибкости команда может оперативно реагировать на изменения и вносить их в продукт.

Низкие риски провалить проект. Так как работа разбита на итерации с регулярным тестированием, сбором фидбека и аналитикой, вероятность заметить проблему и быстро ее устранить гораздо выше.

Маловероятный срыв сроков. В Agile-подходе дедлайны для задач устанавливаются «с запасом» на задержки и внезапные изменения.

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

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

Минусы

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

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

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

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

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

Где используются гибкие методологии

Хоть изначально Agile использовался в разработке ПО, игр и интерфейсов, сегодня методологию можно применять где угодно: для работы HR, SEO-специалистов, копирайтеров, бухгалтеров, фотографов, парикмахеров, маркетологов и др.

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

Чтобы понять, подойдет ли Agile вам, посмотрите в таблицу:

Инструменты гибкого управления проектами

Прежде чем перейти к Agile-инструментам, стоит разграничить термины «философия», «методология» и «фреймворк».

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

Сами по себе гибкие методологии не дают алгоритмов, инструментов и приемов. Поэтому Agile — это философия, которая отвечает на вопрос «Что важно?». В основе Agile лежат 12 принципов из манифеста.

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

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

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

Таких фреймворков достаточно много, поэтому мы расскажем про самые популярные: Скрам, Канбан и Скрамбан.

Scrum и Agile

Scrum (Скрам) — это фреймворк, с помощью которого можно реализовать Agile-философию. В основе метода — разделение работы на небольшие порции — спринты, они же итерации. Обычно спринты длятся 2–3 недели. Они нужны для быстрой поставки продукта клиенту.

Обычно Scrum используют в небольшой команде, а участникам присваиваются специальные роли, например:

владелец продукта — заказчик или его представитель;
scrum-мастер — сотрудник, связующий заказчика и команду. Именно он выстраивает процесс работы и контролирует соблюдение Agile-принципов;
разработчики — команда с различными навыками, которая формируется для проекта.

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

Kanban и Agile

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

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

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

👉 Подробнее про Канбан-метод.

Scrumban и Agile

Некоторым командам не подходят перечисленные фреймворки в чистом виде. Поэтому разработчики берут нужные элементы из Scrum и Kanban, чтобы «смиксовать» их между собой. Так и появился фреймворк Scrumban (Скрамбан).

Например, команда может работать по Скрам и разделять работу на итерации, но визуализировать их на Канбан-доске.

Главное про Agile

• Agile — это философия о гибкой разработке продуктов.
• В 2000-х годах разработчики создали Agile-манифест, в котором собрали 12 принципов. Позже появились 4 ценности.
• Agile-модель была создана в противовес таким традиционным, линейным моделям, как Waterfall.
• Отличительные особенности Agile: гибкость, скорость, прозрачность рабочих процессов и общение.
• Agile отлично подойдет для проектов с высокой неопределенностью.
• Для повторяющихся проектов, в которых важно строго придерживаться ТЗ, гибкие методологии не будут так эффективны.
• Изначально Agile использовался для разработки ПО, интерфейсов и игр, но сегодня может применяться в любой отрасли.
• У Agile есть множество фреймворков. Самые популярные из них: Scrum, Kanban и Scrumban.
• Чтобы успешно внедрить Agile в работу, главное — разделять его философию.