Чтобы не строить управление каждым проектом с нуля, разработаны методологии — единые стандарты постановки задач, распределения времени и применения инструментов. В современной разработке наибольшей популярностью пользуется целое семейство методологий — Agile.
Что такое Agile
Agile, или Agile software development, — это гибкий подход к управлению проектами по разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Термин Agile употребляют в двух разных смыслах:
● Философия и система ценностей, которой придерживается команда. Тут речь не о конкретных инструментах и практиках, а скорее о принципах, по которым строится работа.
● Собирательное название нескольких разных гибких методологий, для которых общими являются ценности Agile.
Как правило, для гибкого подхода Agile характерна работа короткими итерациями по две-три недели. Внутри каждой итерации собрана серия задач: анализ, проектирование, непосредственно работа и тестирование. После каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла.
Подход Agile возник после того, как в сфере IT устали от излишней бюрократии и строгости. Разработчики поняли, что создавать инновационные продукты по старым строгим методологиям просто нельзя, поэтому в 2001 году в американском штате Юта 17 разработчиков со всего света собрались и подписали манифест о новых передовых принципах разработки, которые и легли в основу Agile.
Манифест и принципы Agile
Манифест Agile
опубликован в интернете, с ним может ознакомиться любой. Он не содержит конкретные инструменты или подходы, а описывает именно принципы Agile. Они описаны для разработки ПО, но применяются и в других сферах бизнеса.
Всего принципов двенадцать:
- Удовлетворение клиентов — приоритетная задача при разработке продукта. Клиенты должны своевременно и в полном объёме получать качественное программное обеспечение и его обновления.
- Изменения в процессе разработки приветствуются. Гибкие процессы позволяют наделить продукт конкурентными преимуществами для клиентов.
- Рабочее ПО нужно доставлять клиенту часто, в рамках 2–16 недель.
- Руководители и разработчики должны трудиться вместе на протяжении всего рабочего процесса.
- В основе проекта — мотивированные люди. Обеспечьте им необходимые условия работы, поддержку и доверие.
- Лучший способ передачи информации в команде — личная беседа.
- Основное мерило прогресса — работающее ПО. А не часы, трудозатраты и другие критерии.
- Гибкие процессы — основа устойчивого развития. Они позволяют поддерживать нужный рабочий темп как на спринтерской, так и на марафонской дистанции.
- Важно уделять внимание техническому совершенству и качественному дизайну продукта.
- Важно сокращать до минимума лишнюю работу и не переусложнять проект и рабочие процессы.
- Самые лучшие продукты рождаются у самоорганизующихся команд. Нет микроменеджменту, да — свободе управления.
- Команда должна регулярно оценивать работу и корректировать своё поведение.
Из этих двенадцати принципов выделяют четыре ценности системы Agile:
● Люди и взаимодействия важнее процессов и инструментов.
● Работающий продукт важнее точной и подробной документации.
● Сотрудничество с заказчиком важнее условий договора.
● Готовность к изменениям важнее следования изначальному плану.
Многие из этих принципов и ценностей сейчас кажутся очевидными, но в начале 2000-х они были практически инновационными, потому что тогда было принято строго следовать договору, планировать всё на годы вперёд, вести подробнейшую документацию и уделять больше внимания именно инструментам, а не людям.
Материал по теме:
Проджект-менеджер: всё, что нужно знать о профессии и о том, как её получить
Отличия Agile от других методологий
В первую очередь важно понимать, что Agile — это семейство методологий с общими принципами, но инструменты и подходы к работе у каждой методологии из этого семейства свои. Поэтому сравнивать Agile с другими методологиями напрямую не совсем корректно.
Но если говорить не об основных инструментах, а именно об основополагающих принципах, у Agile есть несколько отличий от классических строгих методологий вроде Waterfall:
- Конечная цель работы в любой момент может измениться, и это нормально. Более того, к этому даже нужно стремиться, так как за несколько месяцев разработки цели и требования клиентов просто не могут остаться теми же в условиях постоянно меняющегося мира.
- На аналитику и планирование нужно тратить меньше времени, поскольку позже их потребуется проводить снова. Лучше уделить больше внимания техническому совершенству продукта.
- В результате каждого небольшого цикла должен получаться готовый продукт, пусть и без некоторых функций.
- Новые требования к продукту обязательно должны быть учтены и добавлены в следующих рабочих циклах.
- Сроки проекта должны быть гибкими, с запасом на задержки и изменения.
- Руководитель должен на протяжении всего цикла принимать деятельное участие в работе команды, а не приходить в начале с требованиями и в конце с ревизией.
Другие отличия лежат уже в конкретных практиках и инструментах, которых мы коснемся дальше.
Преимущества и недостатки Agile
Плюсы:
● Гибкость и открытость к любым изменениям. Можно быстро внести новые требования заказчика, оперативно ответить на действия конкурентов, работать в условиях неопределенности.
● Сниженные риски провала. Тестирование, анализ результатов и общение с заказчиками есть в конце каждого цикла, так что можно быстро понять, что что-то идёт не так, и исправить это. Ситуации, что в конце получился никому не нужный продукт, точно не возникнет.
● Устойчивость к срыву сроков. Их можно гибко адаптировать в зависимости от того, растянулась ли разработка какой-то фичи. В том числе можно отказаться от каких-то функций прямо в процессе работы, чтобы в срок выпустить готовый продукт.
● Большая вовлечённость команды. Отсутствие микроменеджмента, тесная работа с руководством и самоуправление помогают разработчикам работать эффективнее и видеть своё влияние на проект.
● Высокая скорость реакции на проблемы. Если появится баг — его можно быстро устранить в новом цикле. Не нужно полностью перекраивать проект, сдвигать сроки или откладывать исправление ошибки на потом.
● Минимум рутины. Разработчики тратят меньше времени на документацию и отчёты — то, что они обычно не любят больше всего.
Минусы:
● У проекта нет чёткого плана и структуры. В конце может получиться совсем не то, что в начале. Это минус скорее для заказчиков, которым важна определённость и чёткое следование определённым требованиям. Например, для государственных компаний.
● Потребность в тесном общении. Заказчику нужно постоянно общаться с командой, обновлять требования, смотреть промежуточные результаты.
● Завязанность на команду. В процессе работы сложно бывает сменить разработчика или руководителя, так как его придется погружать в подробности всех прошлых циклов и в уже отработанные процессы.
● Слишком большой фокус на мелочах. Иногда за обновлением, дополнением и исправлением функций можно потерять глобальную цель проекта, удариться в доработку мелочей и забыть о главном.
● Сложности с внедрением. Если в компании работали по другой методологии, построить Agile может быть сложно. Потребуется отдельный сотрудник либо менеджер проекта, который хорошо разбирается в гибких методологиях. И переход может занять много времени.
Где используют гибкие методологии
Agile — идеальный подход для стартапов и небольших проектов на заказ. Тогда большинство минусов сходят на нет — отсутствие структуры не мешает, заказчик сам заинтересован в тесном общении, команда редко меняется, а внедрение занимает меньше времени.
А вот если проект масштабный и тянется долгие месяцы, минусы уже выходят на первый план и мешают реализовать проект так, как нужно.
Если говорить о сферах бизнеса, то изначально Agile создавали именно для применения в командах разработки ПО, игр и интерфейсов. Сейчас его используют Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe и большинство других IT-компаний, как гигантов индустрии, так и совсем мелких стартапов.
Но потом преимущества Agile оценили по достоинству другие компании. Сейчас отдельные принципы этого семейства применяют практически везде, а иногда и всю работу выстраивают по гибкой проектной методологии Agile.
Гибкие методологии Agile — стандарт для большинства современных проектов. На курсе Яндекс Практикума «Менеджер проектов» мы знакомим студентов с популярными вариациями этой методологии, разбираем основные инструменты и учим вести проект от старта до завершения. Записаться на бесплатную часть можно уже сейчас.
Зарабатывайте, управляя проектами
Освойте профессию с нуля за 6 месяцев, научитесь вести переговоры и строить отношения с клиентами. Пройдите бесплатную вводную часть курса «Менеджер проектов», чтобы попробовать себя в новой роли.
Методы, средства и технологии управления проектами по Agile
В семейство Agile входит несколько разных гибких методологий управления проектами, которые ещё называют методами управления. В России наибольшей популярностью пользуются две — Scrum и Kanban.
Scrum
Сначала владелец продукта, обычно заказчик, формирует набор требований к продукту. Он передаёт его разработчикам. Те делят работу на этапы — спринты, обычно длиной от одной до четырёх недель. За один спринт команда выполняет конкретный пласт работ, который приводит к результату — цели спринта. Работы берутся из бэклога проекта — списка этапов, которые необходимо выполнить. На его основе составляют бэклог спринта.
В идеале цель спринта должна быть атомарной, то есть на выходе нужен готовый к использованию продукт. После спринта проходит обзор и ретроспектива, при необходимости пересматриваются задачи, а потом формируется бэклог для нового спринта.
Выполнять задачи и не отклоняться от цели помогают события: ежедневные синки, приоритизация, работа с бэклогом, планирование. За всем этим следит scrum-мастер — он помогает команде договариваться и планировать. Подробно все это описано в Scrum-гайде — главном документе методологии.
Примерная схема ведения проекта по Scrum
Scrum хорошо работает в условиях неопределённости, но требует отсутствия внешних зависимостей. Вы должны полностью сами управлять спринтом — как только появляется другая команда, которая может повлиять на результат, всё ломается.
В отличие от многих других гибких методологий семейства Agile, Scrum дружит с квартальным планированием и отчётами. Он позволяет обещать бизнесу конкретные результаты в чёткие сроки.
Большинство команд берут отдельные принципы Scrum, хотя редко используют его целиком. Здесь кроется проблема — легко упустить важное, что-то сломать и потом думать, что Scrum не работает целиком. Хотя на самом деле причина в том, что не хватило какого-то конкретного инструмента или принципа. Поэтому важно тестировать разные комбинации подходов и примерять их к своему бизнесу.
Валерия Данильченко, наставник Яндекс Практикума на курсе «Менеджер проектов»
«В одном из стартапов, где я работала, мы использовали Scrum. Это была работа над внутренним продуктом — мы собрали команду с необходимой экспертностью и не зависели от внешних факторов. Для себя мы поставили ограничение — делать релиз в конце спринта, раз в три недели. В Scrum требований к обязательному релизу в конце спринта нет, но мы решили его добавить. В итоге знание того, что, если не успеем за три недели, релиз придется откладывать, помогало — мы тщательно декомпозировали и приоритизировали, а в момент релиза все вместе накидывались на проверку задач. Так у нас получился Scrum четко по Scrum-гайду.».
Kanban
Многие компании сейчас используют инструмент этой методологии — Kanban-доску, например Trello. Но на самом деле сама методология гораздо шире. Работа над проектом в ней состоит из шести принципов:
- Визуализируйте все задачи на специальной Kanban-доске. Если появляется новая задача — сразу добавляйте на доску.
- Ограничьте количество работы в процессе — в каждом столбике доски должно быть не больше определённого количества задач.
- Управляйте потоком работы — отслеживайте, как задачи движутся по доске.
- Используйте только явные правила добавления и движения задач, понятные всем участникам.
- Вводите петли обратной связи — наборы встреч, помогающие лучше понимать процесс работы.
- Улучшайте процессы везде, где это возможно.
Пример Kanban-доски
Kanban гораздо мягче, чем Scrum. Он позволяет начать с того, что есть сейчас: взять принципы, уже присутствующие в компании, и постепенно их улучшать. Теоретически его можно совместить даже с другими методологиями, например с Waterfall.
Но нужно понимать, что сделать доску и вывесить на неё задачи — ещё не Kanban. Остальные принципы тоже нужно соблюдать, чтобы от методологии была реальная польза.
Недостаток Kanban в том, что он плохо согласуется с квартальным планированием. Задачи в нём выполняются единым потоком, и сложно назначить конкретные сроки и предоставлять чёткие результаты и отчёты. Требуются отдельные усилия менеджера команды.
В Яндекс Практикуме мы внедряли Kanban в сервисной команде, где как раз была очередь задач:
- Визуализация прошла как по маслу. Задачи получилось чётко определить, и после визуализации команда сама увидела все узкие горлышки и была готова над ними работать.
- Ограничить объём работы в процессе было сложнее, но с этим мы справились. Помогло то, что это была команда дизайна, — любой участник мог подхватить задачу в любом статусе.
- А вот управлять потоком и приоритетами не получилось. Заказчики привыкли жить двухнедельными спринтами, и каждый хотел получить задачу срочно. Мы не могли понять, когда приносить задачу, чтобы всё точно успеть. Каждый заказчик повышал приоритет своих запросов, и всё разваливалось.
В итоге пришлось вернуться к чему-то похожему на Scrum. Остались двухнедельные спринты, но отдельные задачи кочевали из спринта в спринт. И заказчиков это устраивало — в итоге создавалось впечатление, что задача выполняется, и не кажется, что её приоритет понижен.
Можно было сделать иначе — изнутри поставить процесс по Kanban, а наружу транслировать двухнедельные циклы. Потому что, не считая проблем с коммуникацией наружу, внутри команде было комфортно работать именно по Kanban. У такого подхода даже есть отдельное название — Scrumban. Нахождение таких компромиссов и наилучшее применение инструментов из разных методологий — как раз задача менеджера проекта.
Дайджест блога: ежемесячная подборка лучших статей от редакции
