В этой статье расскажем, что такое методология Agile, чем полезна эта методика и как внедрить ее в работу.
Суть Agile: не метод, а философия
Agile — это прежде всего не конкретные практики, а философия гибкого управления проектами. Она включает в себя ориентацию на результат, готовность в любой момент вносить изменения в работу, а также тесное сотрудничество руководителей, команды и заказчика.
Один из главных принципов этой философии — частая выдача результатов клиенту. Для этого разработка разбивается на короткие циклы по несколько недель, итогом каждого из которых должен быть пусть еще сырой, но уже рабочий продукт. При этом команда постоянно оценивает все процессы и регулярно вносит корректировки в свои дальнейшие действия.
Подобный подход позволяет избегать лишней работы, быстрее выполнять задачи, а также достигать более высокого качества.
Реализовать на практике принципы, лежащие в основе философии Agile, можно по-разному. Для этого существует несколько методологий, включая Scrum и Kanban.
Откуда «ноги растут»: история Agile-манифеста
Предпосылкой к появлению Agile стало то, что программисты устали от традиционных подходов к разработке, в которых было слишком много бюрократии и жестких рамок. Это приводило к выполнению массы ненужной работы, затягиванию сроков, а также выходу из бюджета. При этом результат чаще всего не соответствовал ожиданиям заказчика.
Был нужен новый, более гибкий подход к организации рабочего процесса, который позволял бы экономить ресурсы и быстрее достигать результатов. В итоге в 2001 году группа американских программистов создала манифест Agile — небольшой документ с 12 короткими принципами.
Манифест включил в себя ключевые идеи новой философии: от гибкости процессов, постоянной коммуникации между всеми сторонами, а также частой поставки заказчику рабочего ПО до самоорганизации команды и упрощения ее работы.
Сегодня на этих принципах базируются все гибкие методологии, которыми активно пользуются как такие гиганты, как Google и Microsoft, так и большинство мелких стартапов. Более того, их используют не только команды разработчиков ПО, сайтов или игр. Эти принципы можно адаптировать для организации рабочего процесса практически в любом проекте, которым можно обучиться со скидкой, использовав промокод Productstar.
4 ценности Agile: не только для программистов
Все принципы из манифеста Agile можно свести к четырем основным ценностям:
- фокус на сотрудничестве между людьми;
- быстрые поставки рабочего продукта;
- готовности к изменениям;
- решение запросов заказчика.
Рассмотрим, чем полезна каждая из них чуть подробнее.
Люди важнее процессов
В традиционном подходе к управлению проектами на первом плане соблюдение инструкций, договоренностей и планов. Руководитель обычно появляется в начале с раздачей указаний и в конце с проверкой результата. А каждый специалист выполняет свою часть работы, передает эстафету следующему и не участвует в дальнейших процессах.
Если же работа строится по принципам Agile, главное — это люди, взаимоотношения между ними важнее строгого выполнения инструкций. Руководитель и команда вместе участвуют в разработке на протяжении всего цикла, все участники активно взаимодействуют друг с другом. При этом, хотя начальник устанавливает приоритеты, команде дается возможность самоорганизации. Исполнители сами выбирают, как выполнять работу, а также как между собой распределять обязанности.
Отношение к команде как к основе проекта, совместная работа, открытое доверительное общение, а также свобода управления мотивируют разработчиков работать эффективнее и сильнее чувствовать свою причастность к создаваемому продукту.
С этой первой ценностью, ставящей людей превыше процессов, связана еще одна: сотрудничество с заказчиком важнее условий договора. Команда активно взаимодействует с владельцем продукта и учитывает его правки, даже если они далеки от первоначальных договоренностей. Это позволяет достичь нужного клиенту результата.
Работающий продукт важнее отчетов
Раньше разработчики утопали в тоннах ненужных отчетов, что в итоге привело к созданию нового подхода к работе Agile. В согласии с ним важнее часто поставлять рабочее ПО клиенту, чем точно и подробно заполнять документацию.
Эта философия предлагает сократить до минимума любые лишние действия, упростить все рабочие процессы, а также минимизировать микроменеджмент. Нужно не усложнять проект чрезмерной бюрократией, а вместо этого стараться достичь технического совершенства и качественного дизайна продукта.
При таком подходе прогресс оценивается не по куче бумажек, потраченных часов или трудозатрат, а по тому, есть ли у вас на руках рабочий продукт. Несмотря на то, что отчетности уделяется меньше внимания, с аджайл получается гораздо лучше следить за успехами команды. Благодаря коротким рабочим циклам по несколько недель и регулярным обсуждениям вы лучше держите руку на пульсе проекта, а также быстрее достигаете результатов.
Готовность к изменениям важнее изначального плана
Строгое следование договору и жесткое планирование плохо работают в условиях, когда все очень быстро меняется. Agile учитывает, что в процессе совместной работы над проектом могут измениться требования клиента, конечная цель работы или способы ее выполнения.
Этот подход отличает гибкость процессов: команда постоянно оценивает свои действия, ищет, что можно улучшить, а также вносит корректировки. После каждого короткого рабочего цикла заново выполняется анализ и планирование с учетом новых требований. Кроме того, гибкость также проявляется в сроках выполнения проекта — всегда дается запас на задержки или изменения.
Адаптивность помогает быстро реагировать на изменения рынка или комментарии заказчика и быстро решать проблемы. В результате не нарушаются планы и сроки, а также достигается более высокое качество.
Как это работает: ключевые Agile-практики
В работе по аджайлу можно выделить три основные практики: итерации, или спринты, Daily Stand-up и ретроспективу.
Итерации (спринты): дробим грандиозное на шаги
В Agile работа делится на небольшие циклы длительностью от 2 недель. Их называют итерациями или спринтами. В начале каждой такой итерации проводится планирование и определяются цели, которых нужно достичь в текущем спринте. После этого участники команды распределяют между собой обязанности и приступают к работе.
В конце каждого цикла должен быть получен какой-то полезный результат, который обязательно показывается клиенту. Следующий спринт планируется на основании его комментариев.
Daily Stand-up: 15 минут против хаоса
Чтобы хорошо понимать, как продвигается проект, синхронизировать работу с коллегами, а также своевременно выявлять и решать проблемы, команда каждый день проводит короткую встречу. Такой Daily Stand-up длится не более 15 минут. На нем каждый из участников делится:
- что он сделал вчера для достижения цели спринта;
- что он планирует сделать сегодня;
- какие препятствия мешают достичь цели.
На этом мини-совещании команда обновляет график выполнения работ и включает в список задач или бэклог проблемы, которые требуют срочного решения. Это позволяет работать слаженно, а также не упускать из виду важное.
Ретроспектива: учимся на ошибках осознанно
В конце каждой итерации все, кто работают над проектом, собираются на более длительную встречу — ретроспективу. На ней за 1−3 часа команда с руководителем анализируют успехи и ошибки текущего спринта. В процессе обсуждения участники встречи вместе выявляют моменты которые можно улучшить, а также придумывают идеи, как это можно сделать. В результате такой встречи коллеги совместно создают план действий с конкретными шагами для внедрения улучшений.
Это помогает постоянно совершенствовать рабочие процессы, избегать повторения ошибок, повышать продуктивность, а также делать команду более сплоченной.
Scrum vs. Kanban: два лица Agile
На основании Agile созданы несколько методик управления проектами, таких как Scrum, Kanban, Lean или XP. Самые популярные из них — более строгий Scrum и более гибкий Kanban.
Scrum: дисциплина для сложных проектов
При использовании Scrum главный упор делается на четко структурированные спринты фиксированной длительности, каждый из которых обычно занимает от одной до четырех недель.
На практике методика действует следующим образом. Владелец продукта составляет общий бэклог проекта — список требований и задач, которые нужно выполнить для создания продукта. Расставив их в порядке приоритетности, он передает этот перечень команде разработчиков.
Команда распределяет задачи из общего бэклога на несколько этапов или спринтов, итогом каждого из которых желательно должен быть рабочий продукт. В конце каждой такой итерации проводится ретроспектива — анализ проделанной работы, пересматриваются задачи, а также создается бэклог, то есть список задач для следующего спринта.
При этом, помимо владельца продукта, отвечающего за бэклог, и команды разработчиков, реализующей задачи из него, в работе участвует Scrum-мастер. Этот специалист следит за тем, чтобы соблюдалась методология Scrum, а также помогает команде эффективнее ее использовать. В том числе он проводит различные встречи: от митингов для планирования спринта и дейли-стендапов до ретроспектив.
Эта методика управления проектами хорошо работает в независимых командах, самостоятельно управляющих спринтами без вмешательства извне. Она привлекательна тем, что позволяет пообещать клиенту конкретные результаты в конкретные сроки. Scrum лучше всего подходит для решения сложных длительных задач, поэтому ее часто используют команды разработчиков программного обеспечения.
Kanban: визуализируем поток задач
В Kanban нет таких жестко ограниченных спринтов. Главное в этом подходе — визуализировать рабочий процесс на доске, чтобы управлять общим потоком задач и загруженностью каждого члена команды.
Как это работает: физическая или виртуальная канбан-доска делится на колонки, например: «К выполнению», «В работе», «На проверке» и «Готово». Все текущие задачи добавляются на эту доску и по мере выполнения перемещаются по столбцам. При этом для увеличения эффективности рабочего процесса ограничивается количество задач, которые одновременно могут быть в одном столбике.
Отслеживая, как задачи движутся по доске, очень удобно управлять потоком работы. Сразу видно, какие из них еще никто не взял, какие уже в процессе, кто за них отвечает, где есть задержки
В Kanban сложнее планировать конкретные сроки выдачи результатов, чем в Scrum, так как рабочий поток здесь непрерывный, но это более гибкий и легкий во внедрении метод. Он отлично подходит для более простых или часто меняющихся задач, поэтому его активно используют команды, оказывающие услуги. Канбан-доски применяют в работе практически везде: от журналистики и логистики до медицины.
Ваш первый шаг: как внедрить Agile без боли
Если раньше вы никогда не использовали гибкий подход, например работая по waterfall-модели, резкий переход на Agile может оказаться непростым. Гораздо лучше постепенно проводить такую трансформацию.
С чего начать: пилотный проект вместо революции
Для начала нужно хорошо ознакомиться с принципами Agile, вникнуть, как работают главные аджайл-методологии Scrum или Kanban, какие практики и инструменты в них используются. Для этого компании, которые хотят перейти на гибкое управление проектами, обычно пользуются услугами коуча и проводят обучение для сотрудников.
После углубленного ознакомления с аджайл нужно выбрать, какую именно методологию использовать. Можно строго придерживаться определенного метода, взять из него на вооружение только отдельные практики или одновременно применить лучшее из Scrum и Kanban.
Но не нужно сразу же менять всю рабочую систему на Agile. Эксперты советуют протестировать выбранный метод на пилотном проекте, а лучше нескольких, и обсудить с командой и заказчиками, эффективен ли он. Например, в некоторых компаниях оказывается, что введение Kanban усложняет отношения с клиентами, требующими быстрого результата, и им лучше подходит Scrum или микс двух методологий. Или бывают случаи, когда одни практики приживаются, а другие — нет. К примеру, ежедневные стендапы одним командам помогают, а других отвлекают от работы.
Только после пилотного запуска, анализа того, что получилось, и устранения слабых мест можно переходить к постепенной трансформации работы над проектами по методике аджайл.
Инструменты: Trello, Jira, Miro — что выбрать
Для управления рабочими процессами, их визуализации и отслеживания их эффективности в Agile используются специальные инструменты. Чаще всего применяют такие сервисы, как Trello, Jira или Miro.
Trello — это простой инструмент для совместной работы на основе канбан, который отлично подходит для небольших проектов и команд, а также легок для освоения новичками. В нем можно создавать доски с информационными карточками и списками задач, а также назначать им сроки и исполнителей. Кроме того, в Trello есть много удобных дополнительных функций, плюс возможность интеграции с облачными сервисами, мессенджерами и другими приложениями.
Jira — более мощный и сложный инструмент для управления средними и крупными проектами. Он прежде всего используется в разработке программного обеспечения. Сервис объединяет в себе визуально похожие, но разные по наполнению доски Kanban и Scrum, а также позволяет создавать бэклоги, спринты и настраиваемые задачи. Кроме того, в нем есть гибкие отчеты и графики наряду с возможностью интеграции с 3000 приложений.
А Miro представляет собой сервис, который предназначен не столько для управления проектами, сколько для совместного планирования и визуализации идей. Он позволяет создавать доски, диаграммы, макеты или другие визуальные элементы, а также проводить обсуждения и мозговые штурмы в режиме реального времени, в том числе с использованием видео. Его часто применяют как дополнение к Jira.
Выбирать инструменты стоит исходя из типа проектов, размера команды и методологии Agile, которая будет использоваться в работе.
Если подытожить, принципы Agile важно понимать как руководителям компаний и опытным разработчикам, так и тем, кто только начинает свой путь в IT. Их можно внедрять в любые проекты, в которых важно оперативно реагировать на изменения или быстро выдавать результат.
Особенно методологии Agile эффективны для команд, занимающихся разработкой ПО и созданием MVP — минимально жизнеспособного продукта. Но их можно адаптировать для использования где угодно: от маркетинга, финансов или управления персоналом до здравоохранения, образования и производства.
