Agile: гибкий подход к разработке

Разбираем по полочкам

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

Разберемся в терминах

Часто, говоря об Agile, подразумевают Scrum, и наоборот. На самом деле, это немного разные вещи. Agile — это набор принципов, на основе которого и были созданы гибкие методологии, такие, как популярный Scrum или Kanban.

Agile — гибкий нелинейный подход к разработке, который состоит из коротких сессий — итераций.
Итерация — завершенный этап работы, который имеет конкретные задачи и ожидаемые результаты. По результатам итерации составляется план следующей.
Scrum — одна из самых популярных методологий разработки, построенная на основе Agile. Итерации в Scrum называются спринтами, они состоят из нескольких этапов: планирование спринта, составление бэклога, ревью (обзор результатов) и ретроспектива (анализ работы команды, может проводиться реже, чем ревью). Затем можно приступать к планированию следующего спринта.
Бэклог — список задач, которые нужно решить. Различают бэклог продукта и бэклог спринта. В отличие от классического технического задания, команда сама определяет очередность выполнения задач, исходя из приоритетов и своих ресурсов.
Kanban (канбан) — еще один метод Agile, который строится на визуализации. Задачи в Kanban размещаются по столбцам, каждый из которых соответствует статусу выполнения, например: «Нужно сделать», «В работе», «Выполнено». Возможно и другое деление. При переходе на следующий этап задача переносится из одного столбца в другой — так команда видит, в какой фазе находится разработка.
MVP — минимально жизнеспособный продукт, который удовлетворяет начальные требования пользователей. По Agile, нужно сначала создать MVP, протестировать его, и только потом дорабатывать в соответствии с глобальным планом.

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

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

Манифест и принципы Agile

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

Эти 17 разработчиков проповедовали разные подходы к разработке, но в одном они сошлись — нужно что-то менять, чтобы сделать процессы более гибкими. Так, во время отдыха на горном курорте, родился Agile Manifesto — главный документ методологии. Вот его принципы с кратким пояснением:

Высший приоритет — это удовлетворение потребностей пользователя. Главным становится не решение большого начальника, и даже не предположения разработчиков, а нужды реальных пользователей.
Изменения всегда приветствуются, даже на поздних стадиях разработки. Так можно обеспечить конкурентное преимущество продукта. Пока вы доводите до совершенства последний пункт объемного ТЗ, конкурент может выпустить на рынок свое решение. Гибкая разработка дает возможность быстро реагировать на изменения и перестраивать процессы.
Нужно работать короткими циклами, от пары недель до пары месяцев. Результатом цикла должна быть работающая модель продукта. Заказчикам важно видеть прогресс, а разработчикам — тестировать MVP среди пользователей. Работая короткими циклами, можно быстро вносить изменения и проверять другие гипотезы.
Для успеха проекта разработчики и заказчик должны ежедневно работать совместно. В создание продукта должны быть вовлечены все заинтересованные лица, а не только команда с проджект-менеджером во главе.
Разработчикам нужны доверие, поддержка и хорошие условия работы. Мотивация помогает создавать действительно стоящие продукты. Сами специалисты обычно «заряжены» на создание по-настоящему крутого продукта, но если заказчик не доверяет им, устраивает постоянные проверки или лезет в работу, это сводит мотивацию на нет.
Наиболее эффективный способ передачи информации — личная беседа. Не электронная почта, не переписка в мессенджере и не голосовые сообщения, а именно живой разговор поможет быстро донести информацию и разрешить возникшие вопросы.
Основной показатель прогресса — работающий продукт. Отчеты об эффективности, затраченные часы работы и другие показатели не имеют никакой ценности, если продукт не готов.
Команда и заказчик должны иметь возможность поддерживать постоянный темп работы в течение всего проекта. Часто проект по Agile становится долгоиграющим — требуется вносить доработки, или возникают непредвиденные трудности. Важно соблюдать баланс и не «выгореть» уже на первых этапах.
Основное внимание нужно уделять качеству проектирования и техническому совершенству. Эти показатели можно улучшать бесконечно, поэтому Agile предполагает не работу по шаблону, а изучение новых трендов и возможностей.
Необходимо стремиться к простоте процессов, к сокращению ненужной работы. Бюрократия, сложные бизнес-процессы и согласования убивают гибкость, делая проект громоздким.
Лучшая команда — самоорганизующаяся команда. Опытные специалисты сами знают, что, как и в каком порядке выполнять. Не стоит в это вмешиваться.
Нужно планировать регулярные встречи, где команда будет оценивать свою эффективность и принимать решения для ее повышения. По Agile, необходимо совершенствовать не только продукт, но и команду. Так инновации в разработке станут еще более мощными.

Помимо этого, создатели Agile обозначили 4 ценности своего подхода:

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

Александр Стихарев

основатель сервиса для управления проектами Shtab.app и digital-агентства stik.pro

— Времена, когда генеральный директор был единственным источником правды и знаний, прошли. Современные руководители собирают в команду специалистов, которые сами генерируют и реализуют идеи. Это не только принцип Agile-подхода, но и так называемая стратегия Bottom-up, которой мы придерживаемся в разработке командного трекера задач. В этой стратегии, как и в Agile, на первом месте — потребители. Они задают планы работ для разработчиков. Например, пользователи пишут в нашем комьюнити, что им не хватает в сервисе, как бы хотелось, чтобы работала та и иная функция. А команда берет это в бэклог, и приступает к задаче. Только при таком гибком подходе к разработке можно сделать продукт для людей

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

Agile vs каскадная разработка

Большинство представляет себе управление проектом как пошаговый, дисциплинированный процесс с четкой постановкой целей и утвержденным планом. Такой подход логичен — практически все процессы в нашей жизни строятся по этому принципу. Например, поставив цель по изучению иностранного языка, мы выбираем методику и покупаем инструменты (курс, приложение, рабочие тетради). Затем мы движемся по намеченному плану, отмечая контрольные точки успеха. Обзор пройденного материала дарит нам уверенность, а репетиторы или экзаменаторы могут легко оценить объем наших знаний.

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

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

Кстати, о тех.заданиях. Если продукт сложный, то полное ТЗ может содержать 200−300 страниц — ни один специалист не сможет его полностью осмыслить и запомнить. В процессе точно возникнут вопросы, сложности и потребуются неучтенные в техническом задании доработки. Все это нужно будет вносить в ТЗ, заново согласовывать и следить, чтобы правки не противоречили принятым ранее решениям. В общем, каскадная разработка для IT — это долго, дорого и не факт, что получится, как надо.

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

Отличия между Agile и каскадным подходом

	Каскадный подход	Agile
Цель проекта	Неизменна — она утверждается перед началом работ и прописывается в ТЗ	Может измениться, если для этого будут весомые причины (результаты пользовательского тестирования, конкурентный анализ, глобальные изменения рынка и т.д.)
Сроки проекта	Четкие — команда должна обязательно уложиться в сроки, независимо от внешних обстоятельств	Гибкие — срок каждого этапа определяется по результатам предыдущего
ТЗ	Полное и подробное, с учетом всех планируемых функций	Вместо ТЗ команда работает с бэклогом — списком приоритетных задач. Подробно расписываются только текущие задачи, остальные просто заносятся в общий план
Процесс разработки	Линейный — сначала полностью разрабатываем продукт, потом тестируем, потом анализируем	Результатом каждой итерации должен быть законченный продукт — с работающими функциями, протестированный и проанализированный
Отношение к изменениям	Желательно ничего не менять и следовать ТЗ	Изменения приветствуются — они делают продукт лучше
Отношение к ошибкам	Негативное	Ошибки — нормальный путь развития проекта, они подсвечивают слабые места и совершенствуют бизнес-процессы
Роль заказчика/руководителя	Формировать требования, принимать готовый продукт	Формировать цели, участвовать в разработке
Роль разработчиков	Выполнять задачи заказчика	Принимать решения по наилучшей реализации задач, предлагать идеи по совершенствованию продукта

Командная работа в Agile

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

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

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

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

Преимущества Agile

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

Недостатки Agile

Конечно, ни одна методология не может быть идеальной, и Agile — не исключение, и не стоит внедрять ее просто потому, что так сейчас модно. Вот ее недостатки:

Отсутствие четкого и предсказуемого результата с самого начала. Принцип Agile — ориентация на пользователя. Но иногда нужно создать продукт именно так, а не иначе, с определенным количеством функций и в рамках согласованного бюджета.
Высокая вовлеченность заказчика в проект. Agile предполагает ежедневный контакт заказчика с разработчиками — конечно, можно сократить количество контактов, но все равно заказчику все время нужно быть на связи и сохранять вовлеченность в проект. Это сложно сделать, если заказчик загружен другими проектами или часто ездит в командировки.
Перфекционизм. Постоянно совершенствуя продукт, есть риск никогда его не выпустить. В Agile нет четкого маркера, когда можно считать продукт готовым.
Сложности при передаче проекта другой команде. У каждой команды — свои принципы работы по Agile, в которые нужно вникать. А если новая команда предпочитает линейный подход, все становится еще сложнее. В результате, заказчик вынужден постоянно работать с одной командой, даже если она его уже не вполне устраивает.
Большое количество совещаний. В идеале, команда устраивает совместные совещания с заказчиком каждый день, затем — в конце итерации, а по методологии Scrum дополнительно собирается на ретроспективу. Сюда же добавляются регулярные совещания и брейнштормы внутри самой команды. Все это дает очень много информации и идей. В результате, бэклог разрастается до невероятных размеров, а времени на разработку остается меньше.
Отсутствие дисциплины. Agile подходит только ответственным разработчикам, которые умеют самостоятельно планировать и организовывать работу. Некоторым специалистам сложно работать без четких рамок и алгоритмов — зачем стараться и допиливать очередную функцию, если можно перенести ее в следующую итерацию? Излишне расслабленная обстановка, отсутствие жесткой критики, снисходительное отношение к ошибкам — все это не лучшим образом действует на тех, кто привык работать под более строгим руководством.

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

Как внедрить Agile в команде

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

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

Достаточно ли ответственны и самостоятельны ваши сотрудники?
Сможете ли вы обеспечить доверительную атмосферу, где каждый может поделиться конструктивной критикой, а старшие специалисты — помочь младшим?
Сможет ли команда регулярно общаться с клиентом и между собой?
Ориентированы ли члены команды на пользу для общества, или только на выполнение задач и денежное вознаграждение?
Могут ли разработчики быть гибкими, быстро внедрять изменения, тестировать их, а при необходимости — менять направление работы?
Есть ли у вас достаточно ресурсов и времени, чтобы сохранять постоянный темп разработки и тестировать множество гипотез?

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

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

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

Перейдем к непосредственному алгоритму внедрения Agile

1. Выберите методологию. Наиболее популярный — Scrum, по нему написано много статей и обучающих пособий. О нашем опыте мы рассказали здесь.

2. Обсудите методологию с командой. Расскажите о принципах гибкого подхода, познакомьте команду с терминологией, ответьте на вопросы.

План обсуждения Agile с командой:

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

3. Составьте список задач. Для этого хорошо подойдет матрица Эйзенхауэра. Определите приоритетные задачи.

4. Оцените сроки выполнения задач. В классическом подходе руководитель ставит сроки, а команда изо всех сил пытается успеть. В Agile специалисты сами оценивают временные затраты, исходя из своего темпа и загруженности. Также можно использовать Planning Poker.

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

6. Составьте список задач для первой итерации, исходя пунктов 3 и 4. Каждый член команды должен получить свой список. Он должен сам решить, как выполнять задачи.

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

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

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

Где используют Agile

Конечно, главная и «родная» сфера для Agile — это разработка программного обеспечения. Но его успешно внедряют и в другие процессы — например, маркетинг, дизайн, управление финансами, HR.

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

Понять, подходит ли конкретная сфера для внедрения Agile, можно по матрице Стейси.

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

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