Agile: что это такое и где используется, принципы методологии

• Что такое Agile
• Манифест и принципы Agile
• Отличия Agile от других методологий
• Преимущества и недостатки Agile
• Где используют гибкие методологии
• Методы, средства и технологии управления проектами по Agile

Термин Agile употребляют в двух разных смыслах:

● Философия и система ценностей, которой придерживается команда. Тут речь не о конкретных инструментах и практиках, а скорее о принципах, по которым строится работа.

● Собирательное название нескольких разных гибких методологий, для которых общими являются ценности Agile.

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

1. Удовлетворение клиентов — приоритетная задача при разработке продукта. Клиенты должны своевременно и в полном объёме получать качественное программное обеспечение и его обновления.
2. Изменения в процессе разработки приветствуются. Гибкие процессы позволяют наделить продукт конкурентными преимуществами для клиентов.
3. Рабочее ПО нужно доставлять клиенту часто, в рамках 2–16 недель.
4. Руководители и разработчики должны трудиться вместе на протяжении всего рабочего процесса.
5. В основе проекта — мотивированные люди. Обеспечьте им необходимые условия работы, поддержку и доверие.
6. Лучший способ передачи информации в команде — личная беседа.
7. Основное мерило прогресса — работающее ПО. А не часы, трудозатраты и другие критерии.
8. Гибкие процессы — основа устойчивого развития. Они позволяют поддерживать нужный рабочий темп как на спринтерской, так и на марафонской дистанции.
9. Важно уделять внимание техническому совершенству и качественному дизайну продукта.
10. Важно сокращать до минимума лишнюю работу и не переусложнять проект и рабочие процессы.
11. Самые лучшие продукты рождаются у самоорганизующихся команд. Нет микроменеджменту, да — свободе управления.
12. Команда должна регулярно оценивать работу и корректировать своё поведение.

Из этих двенадцати принципов выделяют четыре ценности системы Agile:

● Люди и взаимодействия важнее процессов и инструментов.

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

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

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

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

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

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

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

● Большая вовлечённость команды. Отсутствие микроменеджмента, тесная работа с руководством и самоуправление помогают разработчикам работать эффективнее и видеть своё влияние на проект.

● Высокая скорость реакции на проблемы. Если появится баг — его можно быстро устранить в новом цикле. Не нужно полностью перекраивать проект, сдвигать сроки или откладывать исправление ошибки на потом.

● Минимум рутины. Разработчики тратят меньше времени на документацию и отчёты — то, что они обычно не любят больше всего.

Минусы:

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

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

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

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

● Сложности с внедрением. Если в компании работали по другой методологии, построить Agile может быть сложно. Потребуется отдельный сотрудник либо менеджер проекта, который хорошо разбирается в гибких методологиях. И переход может занять много времени.

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

Если говорить о сферах бизнеса, то изначально Agile создавали именно для применения в командах разработки ПО, игр и интерфейсов. Сейчас его используют Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe и большинство других IT-компаний, как гигантов индустрии, так и совсем мелких стартапов.

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

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

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

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

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

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

Валерия Данильченко, наставник Яндекс Практикума на курсе «Менеджер проектов»

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

Многие компании сейчас используют инструмент этой методологии — Kanban-доску, например Trello. Но на самом деле сама методология гораздо шире. Работа над проектом в ней состоит из шести принципов:

1. Визуализируйте все задачи на специальной Kanban-доске. Если появляется новая задача — сразу добавляйте на доску.
2. Ограничьте количество работы в процессе — в каждом столбике доски должно быть не больше определённого количества задач.
3. Управляйте потоком работы — отслеживайте, как задачи движутся по доске.
4. Используйте только явные правила добавления и движения задач, понятные всем участникам.
5. Вводите петли обратной связи — наборы встреч, помогающие лучше понимать процесс работы.
6. Улучшайте процессы везде, где это возможно.

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

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

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

В Яндекс Практикуме мы внедряли Kanban в сервисной команде, где как раз была очередь задач:

1. Визуализация прошла как по маслу. Задачи получилось чётко определить, и после визуализации команда сама увидела все узкие горлышки и была готова над ними работать.
2. Ограничить объём работы в процессе было сложнее, но с этим мы справились. Помогло то, что это была команда дизайна, — любой участник мог подхватить задачу в любом статусе.
3. А вот управлять потоком и приоритетами не получилось. Заказчики привыкли жить двухнедельными спринтами, и каждый хотел получить задачу срочно. Мы не могли понять, когда приносить задачу, чтобы всё точно успеть. Каждый заказчик повышал приоритет своих запросов, и всё разваливалось.

В итоге пришлось вернуться к чему-то похожему на Scrum. Остались двухнедельные спринты, но отдельные задачи кочевали из спринта в спринт. И заказчиков это устраивало — в итоге создавалось впечатление, что задача выполняется, и не кажется, что её приоритет понижен.

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