Agile появился еще в 2001 году — это был ответ на устаревшие подходы к управлению проектами, которые не позволяли быстро запускать продукты и адаптироваться к изменениям. С тех пор прошло больше двух десятилетий. Сейчас Agile используют и крупные корпорации, и маленькие стартапы по всему миру. Но, несмотря на такую популярность, Agile всё ещё вызывает вопросы — в чём его практическая польза и зачем он вообще нужен.
Проверьте, подходит ли Agile вашему проекту
Прежде чем разбираться, что такое Agile и какие инструменты он предлагает, полезно сначала понять, насколько эта методология подходит для вашей ситуации. Предлагаем воспользоваться моделью Кеневин (Cynefin framework), которая делит рабочие контексты на четыре типа доменов, — характеров ситуаций — и позволяет понять, с каким именно вы имеете дело.
Простой домен — это ситуация, в которой причинно-следственные связи существуют и очевидны всем. Например, чтобы попасть на работу к определённому времени, нужно рассчитать время выхода из дома с учётом расстояния до офиса, пробок и погоды. Можно заранее прикинуть, сколько это займёт, и даже успеть заехать за кофе.
Следующий домен — сложный. Причинно-следственные связи тоже есть, но нужно быть специалистом, чтобы их увидеть. Как например при выборе телевизора среди десятков чёрных одинаковых прямоугольников.
Третий тип — запутанный. Здесь причинно-следственные связи есть, но они не очевидны даже для экспертов. Они становятся понятны только постфактум — после того, как команда уже что-то попробовала и увидела результат.
В последнем, хаотическом домене причинно-следственные связи либо не существуют, либо их невозможно обнаружить. И первое, что нужно сделать — выйти из этого состояния и вернуться в более управляемую среду.
Если задачи в проекте относится к простому или сложному домену — скорее всего, можно обойтись без Agile. Но если ситуация постоянно меняется и причинно-следственные связи появляются только после нескольких попыток получить результат, как в запутанном домене, то для таких случаев лучше всего подойдут именно гибкие подходы.
Кажется, что если всё заранее продумать — пообщаться с заказчиками, написать подробные бизнес-требования, то команда реализует именно то, что в них написано, и результат получится таким, каким его запланировали. Но в любом проекте всегда что-то идёт не по плану. И agile-подход это учитывает. Как говорят отцы этого подхода: «Мы не знаем того, чего мы не знаем».
Что такое Agile
Теперь, когда понятно, где применяется Agile, попробуем дать определение этому понятию. Мы уже говорили, что agile-манифест был подписан больше двадцати лет назад — именно он и стал единственным определением. Все остальные трактовки, которые могут встретиться, лишь передают общий смысл:
«Аджайл — это набор методов и практик, которые продолжают формироваться в наши дни и не противоречат ценностям, описанным в Agile-манифесте».
То есть, это не методология сама по себе, а некое мировоззрение, в основе которого лежат 4 ценности.
Люди и их взаимодействия важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий договора.
Реагирование на изменения важнее следования первоначальному плану.Не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
А уже для того, чтобы транслировать это мировоззрение в свою работу, в Agile существуют различные практики. Наиболее часто встречаемые, которые обычно объединяют под понятием Agile, — это Scrum, Kanban и различные масштабируемые фреймворки. Именно их чаще всего имеют в виду, когда говорят об Agile.
Как Agile помогает быстрее получать результат
Гибкие методологии оказались применимы в различных контекстах, и вышли далеко за рамки изначального использования, поэтому всё больше компаний постепенно открывают для себя Agile. Он актуален везде, где требуется гибкость, командная работа и быстрая адаптация к изменениям — это понятно из модели Кеневин.
Работа над проектами и созданием продуктов в Agile-среде строится короткими итерациями — от одной до четырёх недель. В каждом таком цикле команда берёт на себя ограничённый объём задач, чтобы в конце получить работающий результат. Это может быть отдельная функция или минимальная версия продукта, которую уже можно использовать, тестировать или показывать пользователям.
В отличие от традиционных подходов к управлению проектами, Agile позволяет не тратить время на долгие согласования и планы, а сразу проверять идеи на практике и на ходу вносить изменения.
Откуда берутся команды в Agile
Добиться такой гибкости помогает один из Agile-принципов — переход от функциональных отделов к кросс-функциональным командам, которые полностью берут на себя ответственность за результат.
Agile-команда — это группа специалистов, которые работают над конкретным проектом или продуктом с использованием гибких методологий. 5-8 человек вполне достаточно, чтобы оперативно решать вопросы внутри команды и не тратить время на согласования с кем-то извне. Именно команда, а не внешние менеджеры, отвечает за результат. Участники сами договариваются, как лучше выполнять задачи, и не обращаются за одобрением к руководителям или в другие отделы.
Это называется самоорганизацией.
Обычно в команду объединяют людей с разными компетенциями, чтобы они могли вести проект от начала и до конца.
Роли в Agile
В Agile у каждого в команде есть своя зона ответственности — роль. Чтобы понять, какие именно функции выполняет каждый участник, проще всего обратиться к Scrum. Это один из самых популярных фреймворков в Agile, но роли, характерные для Scrum-команд, можно использовать и в других подходах.
Начнём с Владельца продукта (Product Owner) — это человек, который отвечает за продукт. Он ведёт список всех задач — бэклог продукта — и отвечает за то, чтобы результат работы команды приносил максимальную ценность. Он постоянно на связи с заказчиками, — чтобы понимать их ожидания, и с командой — чтобы направлять их усилия на создание ценности для пользователей.
Следующая роль — скрам-мастер (Scrum Master). Это наставник для команды, он помогает участниками договариваться между собой, и следит за соблюдением практик Scrum. Его главная цель — чтобы команда могла сосредоточиться на выполнении задач и развитии продукта, и не отвлекалась на организационные проблемы. Возможно, вам подойдёт роль скрам-мастера, если вы уже интересуетесь тем, как внедрять Agile и настраивать процессы в команде. Мы собрали в одной статье, чем занимается скрам-мастер, какие навыки нужны, чтобы им стать, и с чего начать, если хотите попробовать себя в этой роли.
И разработчики продукта — те, кто напрямую создаёт продукт. Это программисты, дизайнеры, тестировщики и другие специалисты.
Хотя у каждого в команде есть своя зона ответственности, внутри Agile-команды нет начальников. Все члены команды равноправны, участвуют в обсуждениях и предлагают идеи по улучшению продукта.
Как Agile помогает адаптироваться к постоянными изменениями
У традиционного подхода есть два ограничения, которые снижают его эффективность при создании продукта.
Первое — продукт нельзя начать использовать, пока он не будет полностью готов. И всё это время заказчик вместе с пользователями не получают никакой ценности.
И второе — когда работа наконец завершена и готовый продукт появился, может оказаться, что это не совсем то, что было нужно.
Agile как раз и решает эти проблемы. Благодаря Владельцу продукта команда регулярно общается с заказчиком, получает обратную связь и сразу вносит изменения, не дожидаясь окончания проекта. А каждая итерация заканчивается появлением нового инкремента продукта, который уже можно использовать или протестировать.
Agile даёт возможность сосредоточиться на том, что важно прямо сейчас — выпустить минимальную версию продукта (Minimum Viable Product, MVP), собрать обратную связь, и на её основе двигаться дальше.
Как заинтересовать руководство в переходе на Agile
Переход на Agile может многое изменить внутри компании — сделать процессы прозрачнее, ускорить запуск новых идей и упростить взаимодействие между командами. Но всё это будет работать только в том случае, если руководство поддерживает изменения.
Лучше всего начать с небольшого пилотного проекта. Например, предложить небольшой группе сотрудников попробовать поработать по Scrum или Kanban и на коротком отрезке времени — скажем, на пару недель — протестировать идею, получить обратную связь и показать результат руководству. Живые примеры изнутри всегда убеждают гораздо лучше, чем любые презентации. У нас есть интересный кейс внедрения Scrum в аппаратной разработке — там сотрудники говорили: «Железо — это не код, его нельзя просто переделать за пару дней». Тем не менее, после перехода на Agile команда стала быстрее исправлять ошибки, обновила линейку продуктов, и главное — процесс стал более предсказуемым.
Когда вы показываете, что команда за короткий срок добилась результата и сделала что-то полезное, а кто-нибудь из руководства приходит на демо, задаёт вопросы и интересуется тем, что сделала команда — это снижает сопротивление остальных сотрудников и помогает изменениям прижиться.
Как внедрить Agile в своём проекте
Совершенно не обязательно сразу переводить всю компанию или отдел на Agile — можно оставить его внутри небольшой части организации. Даже в рамках пилота стоит помнить, что приоритеты по ходу работы могут меняться — и это нормально для гибкого подхода. Вместо того чтобы заранее составлять подробный план со сроками, этапами и объёмом задач, как это было принято раньше, лучше сосредоточиться на ожидаемых результатах и том, как вы будете их отслеживать.
Повторим, что Agile лучше всего подходит для проектов с комплексными задачами, где не существует простого решения. Начать можно с внутреннего тренинга по основам Agile для выбранной команды. А чтобы понять, кто в неё войдёт и как лучше организовать работу — стоит пригласить Agile-коуча. Он поможет выяснить, что мешает двигаться вперёд, оценит, насколько получившаяся команда готова брать на себя ответственность, и подскажет, какие подходы подойдут именно в вашей ситуации.
Идеи Agile подхода кажутся разумными и хочется попробовать их у вас?
Поможем выстроить процесс так, чтобы результаты появлялись быстрее, команда делала то, что действительно нужно клиенту, а вы были довольны скоростью работы, качеством и вовлеченностью ваших сотрудников..
