_600x450_878.png)
Любой проект — от разработки приложения для iOS до вывода на калужский рынок новой ватрушки — превращается в ад, если им неправильно управлять. Бесконечные корректировки, согласования, переделки, новые идеи на середине проекта... Раньше всех эта ситуация надоела IT-сектору, где стали применять гибкие методы управления проектами, или подход Agile.
Теперь гибкий подход используется в самом разном бизнесе. Он помогает работать единой командой на гарантированный результат и постоянно совершенствовать продукт. В этой статье расскажем, что такое Agile, в чём суть гибких методов управления проектами и как они повышают эффективность работы.
Agile — что это такое
Понятие agile, или эджайл, происходит от англ. agile — «проворный». Это довольно удачная формулировка, ведь agile-команды более проворные: они стараются как можно раньше начать работу с минимальным требованиями и сроками, пока другие долго планируют, прикидывая сроки и бюджеты.
Чтобы получать обратную связь вовремя и не затягивать разработку, работу разбивают на этапы. Каждый этап, по сути, — отдельный проект, который включает следующие подэтапы:
- планирование,
- проектирование,
- разработку,
- внедрение,
- оценку.
Такой подход избавляет от лишней траты времени и даёт сконцентрироваться на выполнении конкретной задачи в ограниченный срок.
Этапы работы с проектом по Agile
Пример того, как выглядит agile-разработка проекта. Клиент заказал разработку мобильного приложения для интернет-магазина. На первом этапе делают базовую версию приложения с основными разделами меню и техническими возможностями, на втором — добавляют к нему элементы дизайна, на третьем — ставят каталог с товарами, на четвёртом — подключают платежные системы.
На каждый этап отводится жёстко ограниченное время. Результат, полученный за первый отрезок, — работоспособный вариант продукта, просто пока ещё ограниченный по функциональности. А на следующих этапах продукт только совершенствуют.
Преимущества и недостатки Agile
Agile — универсальная модель работы с проектом, и тем не менее она подходит не всем. Рассмотрим свои преимущества и недостатки эджайл-разработки
Преимущества
Команде легко сосредоточиться на задачах, потому что каждый этап разработки, по сути, — отдельный проект.
Удаётся раньше вывести продукт на рынок и вносить изменения прямо в ходе разработки, а не переделывать по завершении.
В классическом подходе Waterfall (Водопад) порядок работ чётко регламентирован. Приступить к задаче можно только после завершения предыдущей, а продукт считается готовым после выполнения всех задач.
Agile же позволяет процессу быть гибким и быстро адаптироваться к новым условиям. Как в компьютерных играх: Waterfall — сильный, но неповоротливый воин, а Agile — шустрый и эффективный разбойник.
Разница Waterfall и Agile
Недостатки
Можно утонуть в отчётах. Иногда при работе по методологии Agile на проектах нет документации, или она неактуальна. Изменений так много, что их просто не успевают вносить в документацию, либо за ней вообще не следят.
Легко увлечься улучшениями. Новые требования после нескольких итераций приводят к тому, что работа не двигается дальше. Заказчик и команда бесконечно улучшают то, что уже создано, и не переходят к следующим этапам разработки.
Нужно часто собираться на совещания и брейн-штормы. Встречи проводят внутри команды или с заказчиком. Это может отвлекать специалистов: созвоны или очные встречи занимают много времени, и работа идёт медленнее.
Этих проблем можно избежать, если в компании есть толковый проджект-менеджер. Мы уже рассказывали, как стать надёжным проджектом: где учиться, к чему готовиться и на какой доход рассчитывать.
Ценности Agile
Создатели Agile сформулировали четыре главных ценности методологии. И добавили к ним ремарку: говоря, что один элемент важнее другого, они не призывают отбросить то, что менее важно. Просто некоторые вещи они ценят больше. Ниже рассмотрим суть этих ценностей.
Люди и их взаимодействие важнее процессов и инструментов
В Agile нет места закостенелым «так надо» и «так принято». Инструменты и процессы служат команде, а не наоборот.
Сотрудники сами выбирают формат работы и инструменты, организуют процесс. Ответственность за результат возлагается на всю команду, а не на одного человека.
Работающий продукт важнее документации
Задача agile-команды — сделать готовый продукт, который понравится клиенту.
Согласно гибким методам, не нужно доводить продукт до идеала, чтобы его выпустить. Продукт выполняет основные функции? Значит, можно выпускать. А доработки — уже в следующих версиях.
Представим команду, которая разрабатывает блог о маркетинге. К предполагаемому времени запуска команда написала статьи, но не успела проставить теги для автоматической внутренней перелинковки. Так как команда следует Agile, она всё равно запускает блог, а в течение двух недель проставляет теги. Таким образом, команда быстрее получает осязаемый результат.
Сотрудничество с заказчиком важнее соблюдения формальных условий
Клиенту всегда важнее результат. Именно к нему должна стремиться команда, а не к тому, чтобы соответствовать требованиям в контракте. Важно всегда быть на связи с клиентом и принимать решения вместе с ним.
Готовность к изменениям важнее, чем следование плану
Agile предлагает действовать по ситуации, а не держаться за первоначальный план во что бы то ни стало. Иначе в итоге получится продукт, который никому не нужен.
Будущее невозможно предсказать, поэтому нужно быть достаточно гибкими, чтобы под него подстраиваться. Случиться может всё что угодно: дизайнер заболеет, клиент изменит ТЗ, менеджер уволится.
Представим команду, которая делает торты и пирожные. Один из популярных продуктов — шоколадный торт. Но когда шоколад дорожает на 50%, agile-команда вместо повышения цены находит новый рецепт. Оставляет шоколада в составе на 50% меньше, но добавляет новые компоненты: сгущёнку и заварной крем. В итоге цена остаётся прежней, а покупатели даже ничего не замечают.
12 принципов Agile
Работа по принципам Agile предполагает, что на протяжении всего проекта команда работает вместе с заказчиками, постоянно получая обратную связь.
Изменения требований приветствуются на любом этапе, даже на позднем. Главное — сделать качественный готовый продукт. Ведь это не только реализованная мечта клиента, это еще и хорошо выполненная работа, которая в будущем послужит залогом постоянного потока заказчиков, приходящих благодаря сарафанному радио и рекомендациям. Довольный заказчик — профессионализм и перспектива роста.
Ниже подробнее рассказываем о 12 принципах гибкой разработки ПО.
Наивысший приоритет — удовлетворение заказчика
Когда клиент доволен, все довольны. А клиент доволен тогда, когда получает то, что ему нужно, когда ему это нужно. В случае с разработкой — когда команда предоставляет ему работающее ПО в срок.
Изменения приветствуются
Изменения, которые пойдут на пользу продукту, не стоит откладывать на конец итерации. Лучше вносить их сразу, на любом этапе, особенно если уже решены все основные задачи.
Работающий продукт следует выпускать как можно чаще
Чем чаще, тем лучше. Так можно быстрее внедрять изменения. Например, чтобы добавить новые фишки в приложения, не нужно долго ждать нового релиза.
Поддержка контакта между командой и заказчиком
Когда участники процесса разработки регулярно и непрерывно общаются, результат получается быстрее и лучше. Становится ясно, что все говорят на одном языке и одинаково видят цель.
Мотивация сотрудников
Agile-команды действуют в комфортном ритме, без авралов и работы по ночам. Благодаря этому команда долго не распадается и не теряет эффективности.
Простота общения с командой и внутри неё
Никаких препятствий в общении, никаких регламентов и бюрократии. Лучший способ обмениваться информацией — разговаривать лицом к лицу, офлайн или по видеосвязи. Только так коммуникация между участниками процесса разработки будет прозрачной.
Самоорганизация и самоконтроль команды
Лидер команды не пытается контролировать всё. Он разрешает самостоятельно принимать важные решения, создаёт необходимые условия и не мешает процессу. Это повышает вероятность того, что продукт будет качественным.
Постоянный темп работы
Лучше планировать только то, что можно успеть сделать за определённый промежуток времени. При этом стоит опираться на предыдущий опыт команды: сколько времени уходило на выполнение такой же работы в прошлом или сколько задач команда успевает выполнить за определённый срок.
Точно не нужно перегружать разработчиков — это приводит к ошибкам, стрессу и выгоранию. А мы помним, что команда — главная ценность.
Максимальное упрощение решений, процессов и документации
Сложно — не значит эффективно. Поэтому принцип Agile предлагает делать меньше, но лучше. Например, при разработке сайта вместо 20 версий дизайна лучше сделать 5, но максимально подходящих заказчику и его целевой аудитории.
Упрощение касается и стандартных рабочих процессов — меньше отчётов и сопроводительной документации, бессмысленных совещаний.
Непрерывное улучшение
Всегда можно повысить эффективность команды. Для этого приверженцы гибких методов регулярно анализируют свою работу, профессионально развиваются и работают над улучшением продукта. Нет ничего плохого в том, чтобы выявить недостатки в работе проекта и оперативно их исправить.
Постоянный анализ и поиск возможностей оптимизации
Для анализа работы и существуют регулярные командные встречи — митинги, а также инструменты вроде журнала задач и досок проектов. Они позволяют по окончании спринта собраться всем вместе и определить, что вызвало проблемы. Возможно, в команде возник конфликт или использовались неудобные инструменты.
Работающий продукт — главный показатель прогресса
Для клиента важнее всего результат, и этот результат нужно показывать. Когда команда регулярно отправляет заказчику работающий продукт, у заказчика нет вопросов, кто чем занимался и каковы итоги итерации.
Методы Scrum и Kanban в Agile
Есть много подходов к проджект-менеджменту, основанных на Agile. Самые популярные из них — это Scrum и Kanban.
Scrum
Над проектом работает команда специалистов, чаще всего в ней есть product owner (владелец продукта) и scrum-master (модератор). Разработка делится на спринты: строго фиксированные периоды от 1 до 4 недель. Каждый спринт начинается с определения задач, а заканчивается подведением итогов. Участники команды каждый день встречаются и обсуждают промежуточные итоги.
Scrum хорош гибкостью — можно быстро оценить, туда ли идёт команда, и скорректировать направление. С ним проще контролировать этапы работы над большим проектом. Спринты удобно сравнивать между собой, чтобы оценивать эффективность и управлять ей.
Kanban
В методе Kanban нагрузка распределяется равномерно на всех участников, вся команда работает одновременно над одной задачей. Процесс работы поделён на стадии жизни задачи: планирование, разработка, тестирование, запуск. Чем быстрее выполнена задача, тем эффективнее работает команда.
Информацию о проекте визуализируют на электронных или физических досках — это позволяет видеть проблемы и вовремя их решать. Процесс работы прозрачен и открыт всем участникам: можно увидеть, если на каком-то этапе задача застопорилась или кому-то в команде нужна помощь.
Какие компании используют гибкую методологию
Мир
Метод Agile зародился среди разработчиков ПО и очень долго оставался в этой области. Однако в последние годы гибкую методологию начали применять в других сферах, от банков до производства печенья.
Сейчас Agile используют в работе крупные международные компании, такие как Google, Microsoft, Adobe, Netflix, Spotify, Oreo, Saab и многие другие.
Россия
В России Agile появился позже, но быстро прижился в IT-компаниях, а затем перекочевал в другие сферы. Им пользуются Сбербанк, М.Видео, ivi, 12Storeez и «АльфаСтрахование».
Книги об Agile
- «Scrum. Революционный метод управления проектами». Автор: Джефф Сазерленд. Книга от автора Scrum подойдёт для знакомства с методикой и расскажет, как повысить эффективность выполнения проектов.
- «Постигая Agile». Авторы: Эндрю Стеллман и Дженнифер Грин. Руководство по основным agile-методологиям: Scrum, Kanban, Lean и XP (eXtremal Programming).
- «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор: Стивен Деннинг. Рассказывает, как команды в крупных компаниях внедряют Agile на разных уровнях.
- «Канбан и “точно вовремя” на Toyota. Менеджмент начинается на рабочем месте». Сборник статей о внедрении Kanban на заводе Toyota в 1970-е годы. Базовая книга о методе kanban.
- «Путь скрам-мастера». Автор Зузана Шохова. Практическое руководство по системе scrum от опытного скрам-мастера. Рассказывает о том, как создать эффективную и производительную команду.
- «Agile: оценка и планирование проектов». Автор: Майк Кон. О том, как оценивать, планировать и управлять agile-проектами. В книге много практики, рекомендаций, графиков и методов.
Заключение
Сам Agile, безусловно, не панацея и подходит только для довольно зрелых в технологическом и организационном плане команд. Эта гибкая методология позволяет быстрее сдавать проекты, не затягивать дедлайны, постоянно совершенствовать продукт.
Существует множество методов управления, но это не значит, что придерживаться их нужно всецело и несмотря ни на что. Никто не мешает придерживаться только тех принципов, которые подходят вашему проекту и вашей команде.
