Agile-методология: преимущества, изъяны, этапы внедрения, оценка эффективности

Если еще лет 10 назад Agile-методология казалась чем-то экзотическим (по крайней мере, в нашей стране), то сегодня это общепризнанный и широко применяемый стандарт управления проектами, доказавший свою высокую эффективность на практике.

«Гибкие» – ключевое понятие методов разработки, объединяющих семейство Agile. Легко подстроится под изменяемые условия и требования заказчика, просто устранить ошибки, так как работа ведется по блокам, в противовес каскадной системе, где задачи решаются постепенно, ступенчато.

О том, что собой представляет Agile-методология, как внедряется и оценивается эффективность системы, вы узнаете из нашего материала.

Суть методологии Agile

Agile является семейством методологий, предназначенных для гибкого управления проектами. Однако в этом случае не совсем верно использовать понятие «управление», скорее, Agile представляет собой способ командного взаимодействия, благодаря которому удается совместно создавать продукты.

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

Главные принципы Agile-разработки

Данный подход позволяет решить ряд неудобных вопросов:

  • Как добиться, чтобы задержка в работе одного отдела не мешала другим?
  • Как сократить сроки подготовки плана проекта, чтобы на данный этап не уходило до 30 % всего времени, выделенного на его реализацию?
  • Каким образом добиться соблюдения планов?

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

В результате стало очевидно, что нет смысла искать ответы на большинство некогда актуальных вопросов – про них нужно забыть и отказаться от породивших их понятий. Так поэтапная Waterfall-методология уступила место гибкой Agile.

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

Здесь реализуется известная мотивирующая формула: «Сделано» – это лучше, чем «идеально». Основное правило гибкой методологии разработки Agile состоит в том, чтобы реализовать первую функцию и начинать тестировать ее, создавая следующую, продолжая работать по этой же схеме.

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

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

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

Тогда как благодаря цикличности доработок появляются функции, на которые не хватило бы ресурсов при плановой работе.

Главные принципы Agile-разработки

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

Главные принципы Agile-разработки

  • Разделение на мини-блоки.

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

  • Небольшие кросс-функциональные команды.

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

  • Ограничение незавершенной работы по объемам.

Группы отвечают за задачи, которые можно решить за относительно короткий отрезок времени. Сокращение объема работы положительно отражается на общей продуктивности.

  • Автономность рабочих групп.

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

  • Достижение готовности.

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

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

  • Постоянная деятельность.

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

  • Прозрачность, применение досок со стикерами.

Данный подход в Agile-методологии позволяет кратко, при этом емко описать деятельность, зафиксировать достигнутый этап, оценить процесс глазами сотрудников, выявить причину трудностей, если они появились на пути.

  • Обратная связь от клиентов в конце цикла.

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

Команда методологии разработки Agile

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

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

Команда методологии разработки Agile

В системе существуют такие роли:

  • Владелец продукта. Не имеет представления о технической стороне работы, однако представляет продукт и его аудиторию в целом, видит задачи, для решения которых тот будет использоваться.
  • Координатор действий. Несет ответственность за процессы в команде, направляет потенциал членов группы.
  • Команда разработчиков. Занимается созданием технической составляющей.

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

Не стоит полагать, что методология проектного управления Agile заставляет программиста стать продавцом, а дизайнера превращает в маркетолога. Речь идет о том, что работники должны иметь базовое представление о смежных специализациях – этот подход называется t-shape.

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

Методы Agile – Scrum, Kanban, Lean

Среди всех методов гибкой разработки сегодня активно используются Scrum, Kanban, Lean. Также существует Scrumban, интересный метод, созданный на основе Scrum и Kanban.

Методы Agile

Нередко приходится сталкиваться с мнением, что методология Agile и метод Scrum – это практически одно и то же.

Термин «scrum» пришел из регби, где обозначает борьбу за мяч. Здесь разработка делится на спринты, продолжительностью от недели до четырех. Каждый спринт включает в себя несколько стадий. Первой являются ежедневные встречи по 15–20 минут, на которых члены команды обсуждают, что сделано и что планируется, а также возникшие проблемы.

Следующей стадией является разработка, после чего переходят к демонстрации, и далее следует ретроспектива. Во время последней команда решает, что можно улучшить. В процессе работы специалисты опираются на «backlog», то есть перечень требований к продукту. Также в группе существуют роли, однако отсутствуют должности.

Kanban в рамках Agile-методологии зародился в Японии и является продолжением философии бизнеса Кайдзен и «Тойоты».

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

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

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

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

Если сравнивать гибкие методологии Agile Scrum и Kanban, то последний метод имеет такие отличия:

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

Kanban предполагает визуализацию всех деталей работы, для чего применяется доска со стикерами, надписями. Либо могут использоваться task-менеджеры, такие как «Trello», где фиксируются задачи, этапы и их статус.

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

Это не метод в чистом виде, а способ мышления, свод правил, рекомендаций. Данная философия бизнеса и подхода к разработке, созданная в рамках Agile-методологии описана в книге Эрика Риса «Lean startup» и Масааки Имаи «Кайдзен».

Lean предполагает:

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

Отдельно стоит сказать о Scrumban. Это сочетание Scrum и Kanban в рамках методологии разработки Agile. С одной стороны, группа реализует спринты, а с другой использует канбан-доску с целью визуализации процессов.

Отличия методологии Agile от Waterfall

Если говорить кратко, то последовательная разработка по каскадной методологии, или Waterfall, использовавшаяся до Agile, выглядит таким образом:

  1. Формируются требования к продукту, создается техническое задание или ТЗ.
  2. Задачи воплощаются в коде.
  3. Проводится тестирование.
  4. Готовый продукт внедряется в работу.

При данном подходе допускается возврат к предыдущим этапам, если очевидно, что по техническим причинам задача невыполнима. Однако пересмотр ТЗ относится к чрезвычайным ситуациям – в норме продукт должен отвечать изначально сформулированным требованиям.

Отличия методологии Agile от Waterfall

Если сравнивать методологии проектного управления Waterfall vs Agile, то во второй актуальные потребности пользователя важнее, чем исходные установки. ТЗ может корректироваться даже в разгар разработки, так как гибкость предполагает отсутствие предварительного генерального плана, а ПО пишется экспромтом.

Проще понять Agile-методологию на примере: группа разработчиков занимается созданием аудиоплеера. Они уже подготовили основу программного кода, куда входит интерфейс и базовый функционал. Программа успешно воспроизводит MP3, WAV и OGG-файлы, однако клиентам важно проигрывать CD-диски и быстро управлять устройством при помощи горячих клавиш.

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

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

Этапы внедрения Agile-методологии

Во многих компаниях все еще активно используют последовательную разработку, поэтому переход к гибкой методологии управления проектами Agile становится достаточно болезненным. Это объясняется такими факторами:

  • Во-первых, нужно отказаться от иерархии и сделать так, чтобы участники в равной степени отвечали за итоги работы.
  • Во-вторых, при переходе к итеративной разработке важно, чтобы каждый этап вносил в продукт что-то новое. Первые месяцы компания будет страдать от инерции плановой разработки.
  • Третий вызов – сложность объяснения клиентам или вышестоящему руководству новых принципов работы и преимуществ использования Agile-методологии.

Этапы внедрения Agile-методологии

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

  • люди важнее инструментов;
  • качество продукта важнее документов;
  • взаимодействие с заказчиком важнее контракта;
  • готовность к изменениям важнее заранее продуманного плана.

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

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

Обычно ответ на данные вопросы может дать только специалист в данной сфере.

Далее в компанию приглашают человека, обладающего знанием методологии Agile и опытом работы с ней. Он демонстрирует подход, объясняет смысл спринтов, действий, функции членов команды и принципы их взаимодействия. Теперь можно приступать к созданию рабочей группы, распределять роли, задачи, обязанности, подбирать аналитические инструменты, методы отчетов.

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

Метрики оценки эффективности методологии гибкой разработки

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

Метрики оценки эффективности методологии гибкой разработки

Для большей части проектов достаточно четырех направлений метрик:

  1. Производительность – это метрики Velocity и WIP. Стоит оговориться, что первая может применяться не для любого проекта, поскольку измеряет число выполненных за итерацию задач, а они неравнозначны. Метрика Work-in-Progress оценивает лимит задач на разных стадиях – чем этот показатель выше, тем хуже.
  2. Прогнозирование – используется метрика C. Здесь определяется количество идеальных часов, доступных на следующий спринт. Таким образом команда понимает, сколько у нее времени на работу, насколько эффективно выполнены задачи, как спланировать их число для спринта.
  3. Качество – для его измерения применяют индекс стабильности требований. Данный показатель вычисляют по формуле: (Общее число оригинальных бизнес-требований + Количество требований, поменявшихся до этого времени + Количество добавленных требований + Количество требований, от которых успели отказаться) / (Общее число оригинальных требований). Метрика используется для разных видов методов в рамках Agile-методологии и позволяет понять, сколько времени ушло на задачи.
  4. Ценности – всегда рассчитываются индивидуально в соответствии с форматом проекта. Так, у стартапа «AirBnb» метрикой, устанавливающей конечную ценность продукта для людей, стало число загруженных качественных фотографий. Рост их количества соответствовал увеличению аудитории.

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

«Подводные камни» Agile-методологии

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

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

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

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

Это связано с тем, что Agile требует быстро справляться с проблемами, используя для этого самые простые подходы.

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

Есть эксперты, которые видят в Agile способ улучшения готового продукта, а не методологию создания нового. У гибкого подхода немало как сторонников, так и противников.

Результаты внедрения методологии Agile в России

В нашей стране эту методологию начали применять уже после того, как она распространилась в остальном мире. Сейчас она широко применяется в IT-секторе, ретейле, банках, онлайн-сервисах, сфере промышленности. Например, именно ее использует компания, занимающая разработкой ПО, «First Line Software», сеть «М.Видео», сервис доставки «Dostаевский», онлайн-кинотеатр «IVI», бренд «12 Storeez» и концерн «НМЛК».

Результаты внедрения методологии Agile в России

Ежегодно «ScrumTrek» изучает использование методологии Agile в России, причем в 2020 году было опрошено свыше тысячи организаций из 80 городов. Исследование дало такие результаты:

  • География: 41 % компаний находится в Москве, 14 % приходятся на Петербург, 6,4 % – Пермь, 5,5 % – Казань и Иннополис (IT-кластер), 5,4 % – Новосибирск.
  • Отрасли: IT – 42 %, финансы – 18 %, промышленность – 8 %, ритейл – 7 %, телеком – 4,8 %, энергетика – 3,2 %, консалтинг– 2,8 %.
  • 33 % респондентов пользуется гибкими подходами в проектах, осуществляемых в рамках компании, и в процессе оказания услуг клиентам.
  • 41 % применяет S Показатель снизился за год на 7 % и на 9 % по сравнению с 2018 годов. 23 % используют Kanban, что на 8 % больше, чем за год до этого, и на 13 %, чем в 2018 году. Иными словами, второй метод становится таким же популярным, как Scrum. В мире его можно встретить в три раза реже, чем на территории нашей страны: за год цифра изменилась с 5 % до 7 %. Применение Scrum поднялось с 54 % до 58 %.
  • 60 % фирм сразу пользуются рядом подходов, причем доля собственных или комбинированных Agile-методик доходит до 30 %.
  • 22 % компаний уверены, что достигли в Agile высокого уровня знаний, а это на 9 % больше, чем в 2019 году.

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

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

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

Agile-методология является прекрасным решением для стартапов, но от нее стоит отказаться крупным компаниям, в которых есть сложная структура, а все процессы уже отлажены. Последним больше подойдут методы с элементами данной методологии, так как их легче масштабировать. Это могут быть SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

Однако в IT-сфере добиться высокой эффективности также позволяют инженерные практики, вроде DevOps. Речь идет о методе работы, предполагающем активное взаимодействие участников между собой и взаимную интеграцию процессов.

Провести тестирование новой идеи и при этом отказаться от прохождения всех этапов разработки позволяют Customer Development, Design Thinking и иные подходы.

Существует и более широкий метод на основе Agile-методик – «Business Agility», то есть «гибкость в бизнесе». Он стал популярен не больше трех лет назад и предполагает быстрое создание, выпуск ПО, возможность в короткие сроки подстроиться под внешние перемены, гибкость при целеполагании, распределении ресурсов.

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

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

ReklamaPlanet
Оцените автора
( 1 оценка, среднее 5 из 5 )
ReklamaPlanet
Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.