Экспресс-гайд по Agile: в чём суть гибкого подхода к разработке и как он работает

Такое ощущение, что сейчас термин Agile не использует только ленивый – где нужно и где не нужно. Причём, нередко под ним подразумевают всё, что угодно, что хоть как-то выходит за рамки привычной «стандартной» разработки. О том, в чём суть Agile и как он работает, в своём корпоративном блоге рассказала scrum-студия Sibirix.

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

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

• Scrum – одна из самых популярных методологий разработки, построенная на основе Agile. Итерации в Scrum называются спринтами, они состоят из нескольких этапов: планирование спринта, составление бэклога, ревью (обзор результатов) и ретроспектива (анализ работы команды, может проводиться реже, чем ревью). Затем можно приступать к планированию следующего спринта.
  
  

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

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

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

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

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

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

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

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

2. Изменения всегда приветствуются, даже на поздних стадиях разработки. Так можно обеспечить конкурентное преимущество продукта. Пока вы доводите до совершенства последний пункт объёмного ТЗ, конкурент может выпустить на рынок своё решение. Гибкая разработка даёт возможность быстро реагировать на изменения и перестраивать процессы.
   
   

3. Нужно работать короткими циклами, от пары недель до пары месяцев. Результатом цикла должна быть работающая модель продукта. Заказчикам важно видеть прогресс, а разработчикам – тестировать MVP среди пользователей. Работая короткими циклами, можно быстро вносить изменения и проверять другие гипотезы.
   
   

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

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

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

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

8. Команда и заказчик должны иметь возможность поддерживать постоянный темп работы в течение всего проекта. Часто проект по Agile становится долгоиграющим – требуется вносить доработки, или возникают непредвиденные трудности. Важно соблюдать баланс и не «выгореть» уже на первых этапах.
   
   

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

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

11. Лучшая команда – самоорганизующаяся команда. Опытные специалисты сами знают, что, как и в каком порядке выполнять. Не стоит в это вмешиваться.
    
    

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

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

• Люди и взаимодействия ценнее, чем процессы и инструменты;

• Работающий продукт ценнее, чем объёмная документация;

• Сотрудничество с заказчиком ценнее, чем согласование контракта;

• Реакция на изменения ценнее, чем следование плану.

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

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

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

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

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

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

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

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

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

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

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

• Более эффективная разработка. Ресурсы команды не конфликтуют с запросами заказчика, а в центре всегда конечный пользователь и его потребности. Так вероятность создать по-настоящему востребованный и качественный продукт выше.
  
  

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

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

• Гибкие сроки. Можно сместить дедлайн, если реализация какой-либо функции занимает больше времени, чем планировалось. И, наоборот, можно отказаться от каких-то опций, чтобы выпустить продукт раньше.
  
  

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

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

• Возможность бесконечного масштабирования. Дорабатывать и совершенствовать продукт по Agile можно бесконечно – просто нужно вносить доработки в план следующей итерации. Кстати, многие IT-продукты так и работают – мобильные приложения, операционные системы, мессенджеры постоянно обновляются.

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

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

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

• Перфекционизм. Постоянно совершенствуя продукт, есть риск никогда его не выпустить. В Agile нет чёткого маркера, когда можно считать продукт готовым.
  
  

• Сложности при передаче проекта другой команде. У каждой команды – свои принципы работы по Agile, в которые нужно вникать. А если новая команда предпочитает линейный подход, всё становится ещё сложнее. В результате, заказчик вынужден постоянно работать с одной командой, даже если она его уже не вполне устраивает.
  
  

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

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

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

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

1. Достаточно ли ответственны и самостоятельны ваши сотрудники?

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

3. Сможет ли команда регулярно общаться с клиентом и между собой?

4. Ориентированы ли члены команды на пользу для общества, или только на выполнение задач и денежное вознаграждение?

5. Могут ли разработчики быть гибкими, быстро внедрять изменения, тестировать их, а при необходимости – менять направление работы?

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

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

• Формирование. На этой стадии требуется повышенное внимание со стороны проджект-менеджера или руководителя. Члены команды будут постепенно вливаться в новый режим и определять свои роли в нём. Важно ненавязчиво, но жёстко руководить процессами.
  
  

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

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

• Производительность.Вдохновлённые и замотивированные, члены команды готовы работать и показывать наилучшие результаты.

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

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

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

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

• Что такое Agile. Чем он отличается от классического подхода.

• Какие текущие проблемы он поможет решить.

• Какие преимущества он даст.

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

• Что нужно сделать сейчас, какие планы на будущее.

• Какие новые роли и инструменты появятся в команде.

• Как мы будем решать конфликты.

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Sibirix.

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».
biz360