Метод Agile – это гибкий подход к управлению проектами, который предполагает их дробление на более мелкие части и работу над этими частями в течение коротких циклов – спринтов. Кроме того, Agile-команды тесно сотрудничают, что позволяет всем быть в курсе мельчайших изменений и быстро приспосабливаться к ним, не теряя производительности и не затягивая сроки. В этой статье мы расскажем, что такое методология управления проектами Agile, для чего она предназначена, какие этапы в ней можно выделить и какие результаты она дает.
Какие задачи решает методология Agile
Разные фреймворки в методологии AGILE
Роли и участники команды в AGILE
Какие задачи решает методология Agile
Быстрое предоставление ценности заказчику. Короткие циклы работы и постоянный контакт между участниками команды помогают видеть прогресс, обмениваться обратной связью и быстрее идти к конечной цели – рабочей версии ПО.
Адаптация к меняющимся требованиям. По сути, вся методология управления проектами AGILE создана именно для этого: чтобы компания не превратилась в тяжеловесную бюрократизированную структуру, где каждое отступление от первоначального плана долго согласуется и затягивает процесс. Задачи в Agile могут меняться каждый спринт, а команда использует петли обратной связи и ретроспективы, чтобы учиться на своем опыте и улучшать процессы.
Повышение качества результата. Agile-команды тестируют будущее приложение или сервис на протяжении всего процесса работы, а не только в конце. Кроме того, они разбивают проект на более мелкие и управляемые части и проводят частые релизы, что упрощает поиск и устранение багов и дефектов.
Улучшение коммуникации. Ценность Agile для бизнеса еще и в сплочении команд: сотрудники часто общаются по проекту, могут самостоятельно принимать решения, сообщать о проблемах, предлагать изменения и вовлекать заказчика и другие заинтересованные стороны. Инструменты для этого – ежедневные встречи, планирование спринта, анализ и ретроспективы спринта.
Повышение мотивации сотрудников. Команды в этой системе работы более автономны, несут прямую ответственность за свои результаты и более прозрачны как для заказчиков, так и для коллег. Они быстрее учатся на чужом и своем опыте, могут в любой момент видеть результаты своей работы и свои достижения. Это создает высокую вовлеченность в проект.
Манифест и принципы Agile
Манифест Agile – это перечень принципов и ценностей гибкой разработки ПО, который создала группа разработчиков в 2001 году.
Вот 4 ценности Agile:
- Личность и взаимодействие важнее процессов и инструментов. Это означает, что Agile-команды ценят человеческое общение больше, чем жесткие процедуры;
- Рабочее ПО важнее исчерпывающей документации. Важнее как можно быстрее предоставить заказчику функциональный продукт, чем готовить множество документов или бездумно следовать плану;
- Сотрудничество с заказчиком важнее договора. В Agile ценится работа с заказчиком как с партнером;
- Реагирование на изменения важнее следования плану. Способность справляться с неопределенностью и изменениями важнее, чем следование жесткому первоначальному плану.
Кроме того, у гибкой методологии Agile есть 12 принципов, которые основываются на ценностях, описанных выше, и касаются практических моментов работы. Вот краткое изложение основных принципов Agile:
- Высший приоритет – это удовлетворение потребностей заказчика за счет создания функционального ПО;
- Изменения требований – это хорошо, даже на поздних этапах разработки;
- Работающее ПО нужно поставлять в короткий срок – от нескольких недель до нескольких месяцев;
- Заказчики, менеджеры и разработчики должны ежедневно работать вместе на протяжении всего проекта;
- Члены команды разработки в Agile должны быть высокомотивированными. Для этого им нужно обеспечить комфортные условия работы и поддержку;
- Самый эффективный метод передачи информации в Agile-команде – это общение лицом к лицу;
- Работающее программное обеспечение является главным мерилом прогресса;
- Применение принципов управления проектами в Agile – залог устойчивого развития. Заказчики, спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы неограниченное время;
- Нужно постоянно уделять внимание техническому совершенству и хорошему дизайну продукта;
- Крайне важна простота, которая помогает ускорить работу и не зацикливаться на мелочах;
- Команды должны быть самоорганизующимися. В них рождаются лучшие архитектуры, требования и проекты;
- Команда регулярно обдумывает, как стать эффективнее, а затем корректирует свое поведение в соответствии с этим.
Этапы работы по Agile
Этапы в Agile могут варьироваться в зависимости от того, какой конкретно фреймворк выбран командой (о них поговорим чуть ниже), но в общем виде все их можно описать следующим образом.
Этап 1. Планирование
Заказчик составляет техническое задание – описание назначения, целей продукта, нужных результатов и сроков выполнения. Внутри команды проекта назначаются роли и распределяются обязанности. ТЗ должно быть не только четким, понятным и выполнимым, но и адаптируемым к изменениям, которые могут произойти в будущем. Часто на этом этапе Agile-проекта закладывается бэклог – список всех функций, которые нужно реализовать. Впоследствии какие-то задачи из него будут исчезать, а какие-то добавляться.
Этап 2. Проектирование
Команда разрабатывает архитектуру и дизайн продукта, используя принципы простоты, модульности и повторного использования. Это еще не разработка! Этот этап Agile-проектирования обычно включает большую исследовательскую работу: изучение целевой аудитории, создание прототипов, коммуникацию между разработчиками, Product Owner’ом и заказчиком.
Этап 3. Разработка
Всё начинается с прототипа – первого образца готового продукта, который показывает главные функции и интерфейс. Прототип может иметь низкую или высокую детализацию, в зависимости от цели и ресурсов команды. Его согласует команда и клиент, а затем прототип превращается в рабочее приложение, программу или сервис. Этап разработки в Agile делится на спринты, которые обычно длятся от 1 до 4 недель. Каждый спринт имеет свою цель и конкретные результаты, которых нужно достичь по итогу.
Этап 4. Тестирование
Разработчики, тестировщики и специалисты по контролю качества тестируют готовый модуль или блок на разных уровнях, используя различные виды тестов: функциональные, нефункциональные, регрессионные, юзабилити и т.д. В методике управления Agile команда также применяет непрерывное тестирование и непрерывную интеграцию, чтобы обеспечить высокое качество продукта.
Этап 5. Обратная связь
На этом этапе методологии Agile команда получает обратную связь от заказчика и пользователей, учитывает ее и вносит необходимые изменения в продукт или бэклог. Специалисты проводят регулярные обзоры своей работы с заказчиком и демонстрируют результаты спринтов.
Этап 6. Запуск
Конечный результат – это программный продукт, который передают заказчику или выкатывают для пользователей. Обычно релиз сопровождают документацией и обучением для юзеров. В дальнейшем продукт может обновляться или модифицироваться в зависимости от изменения потребностей заказчика или рыночных условий.
Разные фреймворки в методологии AGILE
Фреймворки, или методы, Agile – это немного отличающиеся друг от друга подходы внутри методологии. Расскажем только об особенностях основных фреймворков, так как в главном они довольно похожи и следуют принципам Agile-манифеста.
Scrum. Это метод организации работ со спринтами длительностью 1-2 недели. Ключевые элементы Scrum – это короткие дневные встречи, планирование спринта, ретроспектива и обзор спринта.
Kanban. В этом фреймворке делают акцент на визуализации рабочего процесса для максимизации выполняемых задач без перегрузки специалистов. Задачи обозначают карточками на специальной доске, чтобы показывать их статус и прогресс.
DSDM. Здесь делают акцент на создании продукта в срок и в пределах бюджета, уделяя очень много внимания начальным исследованиям – реализуемости, применимости, экономической целесообразности.
Extreme Programming (XP). Это фреймворк, который ставит во главу угла скорость разработки, отзывчивость и качество кода. Он включает в себя такие инженерные практики, как написание тестов перед программированием, парное программирование и непрерывную интеграцию.
Роли и участники команды в AGILE
Роли в Agile-команде – это специальные функции, которые выполняют разные участники проекта. Вот основные из них:
- Заказчик – это представитель бизнеса или клиента, который определяет требования к проекту и принимает решения о его разработке и приоритетах;
- Владелец продукта (Product Owner) – это член Agile-команды, который отвечает за видение продукта, управление бэклогом, приоритизацию задач и повышение ценности продукта для заказчиков и юзеров;
- Scrum-мастер или Agile-коуч – это сотрудник, который организует эффективное управление Agile-командой. Он помогает другим следовать принципам Agile-манифеста, координирует встречи и т. д.;
- Члены команды разработки в Agile – это программисты, тестировщики, UX-дизайнеры, технические писатели и другие специалисты, которые выполняют основную работу по созданию готового продукта. Вопреки распространенному мнению, эту роль в Agile играют далеко не только разработчики;
- Заинтересованные стороны – это люди, не входящие в команду, но имеющие интерес или влияние на результаты проекта (пользователи, менеджеры, акционеры и др.).
Пример внедрения AGILE
Давайте разберем пример применения методологии AGILE в конкретной компании – Ticketland. Это сервис по продаже билетов на концерты, в театры, на соревнования и т.д. В один прекрасный момент он столкнулся с рядом проблем в своей работе:
- устаревшее ПО и сложная система его замены;
- медленная разработка и наличие проблем в новых продуктах;
- сосредоточенность ключевой информации о продуктах в руках нескольких сотрудников и потеря данных при их увольнении;
- текучка среди разработчиков и др.
Для решения этих проблем Ticketland решил внедрить методологию Agile. Вот как компания применила основные принципы Agile:
- рассталась с традиционными руководителями, вместо них в каждой команде назначили и обучили Product Owner’ов;
- внедрили ретроспективы – встречи, посвященные анализу ошибок и выявлению направлений работы;
- начали оценивать предложения по фичам и функциям с финансовой точки зрения;
- приняли 3 принципа принятия новых людей в команду: наличие знаний и умений, мотивация работать именно в этой компании, соответствие ценностям компании;
- ввели кросс-дисциплину t-shape для получения знаний в смежных с основным полем деятельности сотрудника областях;
- начали рассматривать каждое обновление с точки зрения пользовательских историй;
- перешли с монолита на микросервисную архитектуру.
Переход на принципы Agile-управления позволил Ticketland решить обозначенные в самом начале проблемы, успешно нарастить штат и обороты, войдя в Forbes с оценкой компании в 84,2 млн долларов.
Разница Agile и Waterfall
AGILE и Waterfall – это противоположные подходы к управлению проектами.
Waterfall («водопад») – это традиционный метод, основанный на линейной и последовательной работе по шагам, установленным до старта проекта. Следующая стадия работы не начинается, пока не закончится предыдущая. По сравнению с Agile, Waterfall требует очень тщательного предварительного планирования и строгого соблюдения первоначального объема работ, иначе сроки рискуют непредсказуемо затянуться.
Agile отличается от Waterfall тем, что она более гибкая. В ее основе лежит не линейная работа, а итеративный обновляющийся процесс, деление проекта на более мелкие части и выполнение спринтами. Декомпозиция задач в Agile помогает гибко адаптироваться к изменениям и не так тщательно планировать все в начале.
Плюсы и минусы AGILE
Преимущества Agile
Гибкость при изменениях. Это главное преимущество Agile и DevOps – еще одной популярной гибкой методологии. Их часто используют вместе при разработке ПО. В Agile новые условия, вызовы или требования – это не угрозы всему проекту, а возможность совершенствоваться. Команда может быстро реагировать на действия конкурентов, изменение потребностей заказчика или рыночных условий.
Качество. В конце каждого короткого цикла есть анализ результатов и тестирование, что помогает сразу понять, какие есть проблемы и что еще требует доработки. В конце работы продукт получается актуальным и отлаженным.
Скорость. Тайминги в методике можно адаптировать к процессу работы, то есть увеличить или уменьшить время на реализацию того или иного функционала, вовсе отказаться от каких-то второстепенных опций. Это преимущество использования Agile помогает не срывать сроки релизов.
Культура сотрудничества. Плюс Agile для коллектива в том, что здесь нет тех, кто только отдает приказы, а кто только их выполняет. Все сотрудничают со всеми, каждый выполняет свою часть работы, поощряется самоорганизация. Agile также помогает создать доверительную атмосферу в отношениях с заказчиком за счет регулярного обмена информацией о ходе работ.
Мотивация и вовлеченность. Метод предоставляет сотрудникам больше инициативы, возможностей и ответственности, меньше контроля свыше, чем классический Waterfall. За счет этого они лучше понимают свою роль в проекте и больше в него вовлекаются.
Недостатки Agile
Частый выход за рамки. Пожалуй, это главный недостаток Agile-методологии. Отсутствие жесткого контроля и плана может привести к тому, что продукт в итоге получится совсем не таким, как было изначально задумано. Во многих проектах это критично. При неправильном распределении ролей и функций, неверном понимании принципов Agile весь процесс работы может привести к срыву сроков или испортить продукт.
Конфликты в команде. Важна высокая заинтересованность в проекте со стороны всех членов команды, заказчика и высшего руководства. Если они не поддерживают ценности Agile, это может привести к сопротивлению, конфликтам или провалу проекта.
Сложность обучения. Серьезный минус Agile с точки зрения бизнес-процессов состоит в том, что период внедрения методики после какой-либо другой устоявшейся системы – очень стрессовое время для коллектива. Сотрудников нужно обучить приемам и инструментам методики, а сами они должны иметь достаточную квалификацию, способности к самоорганизации и позитивный взгляд на Agile.
Все эти преимущества и недостатки Agile нужно четко осознавать перед внедрением методики в компании, чтобы не получить хаос вместо оптимизации сроков и налаживания бизнес-процессов.
