Слово Agile в современном мире уже стало практически нарицательным и применимым ко многим рабочим сферам, но начиналось все с разработчиков программного обеспечения: именно они в 2001 года собрались и создали манифест Agile, описывающий новые принципы организации проектной работы. Им удалось всего в 254 словах описать 4 ценности и 12 принципов нового подхода, который они назвали Agile, отталкиваясь от значения этого английского слова: «гибкий, ловкий, способный».
Ценности Agile
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
![](/upload/sprint.editor/ac5/x149xyuf1av7elkds1g8qkndsy5t37eu.webp)
Agile — что же это такое простыми словами? Основной фокус делается на гибких рабочих процессах и активном взаимодействии всех участников — заказчиков, разработчиков и клиентов. Задача Agile — дать необходимые методы и помочь создать гибкий продукт, открытый для дальнейшего развития и удовлетворяющий потребности пользователей, причем сделать это достаточно быстро. Благодаря такому подходу каскадный способ управления проектами, Waterfall (собрать требования — финализировать ТЗ — разработать соответствующий ТЗ продукт — запустить его — повторить цикл при необходимости изменений) заменяется на гибкую систему. Это позволяет быстро реагировать на изменяющиеся потребности заказчиков и клиентов и не «застревать» на определенных этапах, тормозя всю работу.
Управление в стиле Agile во многом построено на итерациях, позволяющих определять цели на конкретные циклы работ, сверяться с заказчиками на промежуточных этапах и при необходимости оперативно вносить изменения в работу. Это позволяет найти баланс между тремя ключевыми критериями: удовлетворенностью клиента, скоростью и качеством.
![](/upload/sprint.editor/8b6/rj8qdie4k5nptxj1djn3g3vsho5qi8jt.webp)
Принципы организации работы по Agile
Четыре ценности, сформулированные создателями методологии Agile, были декомпозированы до 12 принципов, на основе которых строится реальная работа:
- Лучше всего оформить картинкой, чтобы не было плагиата — это цитата из манифеста.
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного продукта.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый ход разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
![](/upload/sprint.editor/b09/ztvoxdl02kwfq23y01mtorrv233wf0ad.webp)
Эти принципы Agile отлично подходят для создания принципиально новых продуктов практически в любой сфере, начиная с разработки ПО и заканчивая маркетинговым продвижением, поскольку основаны не на конкретных процедурах и шагах, а на верхнеуровневых ценностях. Свобода исполнителей не противоречит необходимости постоянно «сверяться» с требованиями бизнеса. Наоборот, она позволяет при необходимости быстро адаптировать продукт, опираясь на его идею, а не на формальные требования и протоколы.
Наши команды разработчиков продуктов, таких, как сквозная аналитика и смарт-компоненты модуля IP-телефонии, также придерживаются принципов Agile.
Мы уже отправили вам первое письмо с подборкой лучших материалов
Роли в системе управления проектами по методу Agile
Пользователь
Базовая разработка и управление этим проектом в соответствии с методологией Agile начинается с определения целевой аудитории — пользователей, для которых создается продукт, и формулирования ключевых проблем, возможностей и ценностей, значимых для этой аудитории. Это может быть несколько групп пользователей, для каждой из которых формируется свое описание.
Владелец проекта
Именно владелец проекта — одна из ключевых фигур в Agile — отвечает за формирование портрета пользователя и списка его потребностей. Он фильтрует идеи на соответствие ключевому видению проекта и собирает обратную связь, позволяющую вовремя корректировать ход работ, а затем вместе с командой разработчиков, работающих по методикам Agile, делает все необходимое для реализации этого видения.
Владелец также разбивает видение проекта на пользовательские истории Agile — своего рода направления работы, каждое из которых описывает целевую группу пользователей, их проблемы и потребности, а также связанные с этим возможности и ограничения. Пользовательские истории расставляются по приоритетности и обсуждаются с командой разработчиков.
Команда разработчиков
Группа исполнителей, включающая в себя представителей с разными навыками и умениями, необходимыми для реализации проекта. Одно из ключевых требований, которые предполагает Agile-подход — в команде должны быть представители разных направлений, чтобы создать объемное представление о целях и задачах готового продукта. При этом роли должны быть достаточно четко распределены, чтобы каждый участник понимал, какие задачи он выполняет и для чего это необходимо.
При необходимости члены команды могут брать на себя дополнительные сервисные роли:
- Лидер команды — человек, который не только координирует внутреннюю деятельность группы, но и отвечает за взаимодействие с владельцем проекта.
- Скрам-мастер обучает команду методике управления в стиле Agile, отслеживает прогресс, ищет «узкие места» в ходе разработки, пересматривает подходы к реализации проекта и отвечает за бэклог — список всех этапов, которые необходимо выполнить.
- Бизнес-аналитики отслеживают критерии эффективности разрабатываемого продукта и зачастую служат «переводчиками» между владельцем проекта и его непосредственными исполнителями, особенно в сферах, где необходимы узкоспециализированные знания и навыки. Например, в проекте «Продвижение нового продукта на рынке» именно бизнес-аналитик поможет сформулировать конкретные задачи и метрики, необходимые для его реализации.
- Размер команды, работающей по Agile, зависит от стоящих перед ней задач, но один из самых популярных подходов, придуманный создателем Amazon Джеффом Безосом, — «принцип двух пицц»: команда должна быть такого размера, чтобы ее можно было накормить двумя пиццами. Как правило, это 5-8 человек. Небольшие Agile команды позволяют обеспечить более эффективную коммуникацию, увеличивают доверие между ее членами и снижают страх ошибки.
![](/upload/sprint.editor/bce/2rv96onr1of4dzugfxxhpsj5075rst0l.webp)
Инструменты Agile
Agile предлагает для гибкого управления проектами ряд фреймворков, которые можно использовать для повышения эффективности взаимодействия между всеми участниками. Два самых популярных фреймворка — Scrum и Kanban.
Scrum
Отлично подходит для разработки нового продукта, еще не представленного на рынке. Позволяет быстро его внедрить и оперативно вносить необходимые доработки и изменения.
Работа по Scrum ведется спринтами — базовыми циклами по 1-2 недели, в течение которых команда разработчиков занимается реализацией пользовательских историй, отмеченных владельцем проекта как приоритетные. Каждая история разбивается на конкретные действия, которые необходимо выполнить, и для каждого действия назначается исполнитель. При этом работает заявленная в манифесте Agile идея свободы разработчика: исполнитель самостоятельно решает, как именно он будет выполнять задачу.
В течение спринта необходимо организовать несколько встреч, помогающих сформулировать конкретные задачи, отследить ход их выполнения и оценить успешность их реализации.
Планирование спринта — встреча, на которой владелец проекта представляет ключевые пользовательские истории, а команда разработчиков определяет, сколько она сможет выполнить в течение спринта.
Scrum-митинг — оперативные встречи, на которых команда обсуждает статус задач и рассматривает «узкие места», замедляющие работу.
Обзор спринта — встреча по окончании цикла, задача которой — представить владельцу проекта результаты работы и получить от него подтверждение выполнения задач. Эта встреча также дает обратную связь, позволяющую скорректировать работу в следующих спринтах.
Ретроспективные встречи Agile — на них команда обсуждает, что было сделано хорошо и что нуждается в улучшении в следующих спринтах.
Kanban
Этот фреймворк подходит для постоянного улучшения уже существующих продуктов в рамках специализированных рабочих групп, когда изменения могут происходить практически каждый день. Он не предполагает цикличности и основан на потоковом методе решения задач: все задачи по реализации пользовательских историй размещаются на реальной или виртуальной Kanban-доске (например, с использованием специальных сервисов) в виде карточек, а затем перемещаются по стадиям готовности: «Надо сделать» (бэклог), «В процессе», «Сделано». Это позволяет организовать и визуализировать работу, скоординировать действия всех участников и минимизировать временные затраты на управление.
Ограничений по количеству позиций в колонке бэклога нет — сюда попадают все задачи, которые необходимо сделать для реализации Agile-проекта. Для каждой задачи указывается приоритет, который может меняться в зависимости от изменяющихся условий и требований. Приоритетные задачи всегда стоят в верху бэклога и берутся в работу первыми: исполнители выбирают карточку в соответствии собственными навыками и переносят в следующую колонку.
Колонка «В процессе» на Kanban-доске, как правило, разбита на несколько второстепенных колонок, обозначающих определенные этапы работы над задачей: например, «сбор информации», «анализ», «проектирование», «дизайн», «разработка». Здесь всегда есть ограничения по количеству задач (WIP-лимит), чтобы регулировать нагрузку команды и избежать простоев. При этом на карточек указаны имена исполнителей, что позволяет оценить загруженность конкретного человека и увидеть, может ли он взять в работу дополнительные задачи.
Плюсы и минусы разработки по методу Agile
Плюсы | Минусы |
Гибкость и быстрая реакция на ошибки. Благодаря коротким циклам разработчики имеют возможность отслеживать недочеты в работе и оперативно их устранять, а при необходимости — внести изменения в дальнейшую работу. Лучшее понимание текущих потребностей бизнеса. Постоянный контакт между всеми участниками Agile позволяет на практике создать актуальный продукт для текущей ситуации, внедрить его и дорабатывать при поступлении новых вводных. Вовлеченность команды и отсутствие рутины. В методологии управления проектами, основанной на принципах Agile, заложено большое доверие к разработчикам, а значит, и большая возможность мыслить out of the box — вне привычных шаблонов, что приводит к большей креативности в разработке. Кроме того, это позволяет минимизировать количество формальных отчетов. | Отсутствие структурной работы. Agile предполагает гибкий подход в управлении проектами, однако это может привести к созданию продукта, который сильно отличается от первоначальной идеи. Ход разработки может быть сложно контролировать и отслеживать его эффективность. Высокие требования к человеческим ресурсам. Все участники должны быть максимально вовлечены и способны мыслить креативно, и заменить их (например, в случае увольнения ключевых сотрудников) может быть непросто. Необходимость постоянно держать руку «на пульсе». В отличие от более традиционных моделей управления проектами, в Agile не получится выдать объемное задание и через несколько месяцев принять готовый результат — необходимо быть полноценным участником на протяжении всего хода разработки. |