Проект в стиле Agile: как методология «гибкого подхода» помогает выстраивать работу

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

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

Agile — что же это такое простыми словами? Основной фокус делается на гибких рабочих процессах и активном взаимодействии всех участников — заказчиков, разработчиков и клиентов. Задача Agile — дать необходимые методы и помочь создать гибкий продукт, открытый для дальнейшего развития и удовлетворяющий потребности пользователей, причем сделать это достаточно быстро. Благодаря такому подходу каскадный способ управления проектами, Waterfall (собрать требования — финализировать ТЗ — разработать соответствующий ТЗ продукт — запустить его — повторить цикл при необходимости изменений) заменяется на гибкую систему. Это позволяет быстро реагировать на изменяющиеся потребности заказчиков и клиентов и не «застревать» на определенных этапах, тормозя всю работу.

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

Четыре ценности, сформулированные создателями методологии Agile, были декомпозированы до 12 принципов, на основе которых строится реальная работа:

• Лучше всего оформить картинкой, чтобы не было плагиата — это цитата из манифеста.
• Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного продукта.
• Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
• Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
• На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
• Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
• Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
• Работающий продукт — основной показатель прогресса.
• Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый ход разработки.
• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
• Простота — искусство минимизации лишней работы — крайне необходима.
• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
• Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

Пользователь

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

Владелец проекта

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

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

Команда разработчиков

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

При необходимости члены команды могут брать на себя дополнительные сервисные роли:

• Лидер команды — человек, который не только координирует внутреннюю деятельность группы, но и отвечает за взаимодействие с владельцем проекта.
• Скрам-мастер обучает команду методике управления в стиле Agile, отслеживает прогресс, ищет «узкие места» в ходе разработки, пересматривает подходы к реализации проекта и отвечает за бэклог — список всех этапов, которые необходимо выполнить.
• Бизнес-аналитики отслеживают критерии эффективности разрабатываемого продукта и зачастую служат «переводчиками» между владельцем проекта и его непосредственными исполнителями, особенно в сферах, где необходимы узкоспециализированные знания и навыки. Например, в проекте «Продвижение нового продукта на рынке» именно бизнес-аналитик поможет сформулировать конкретные задачи и метрики, необходимые для его реализации.
• Размер команды, работающей по Agile, зависит от стоящих перед ней задач, но один из самых популярных подходов, придуманный создателем Amazon Джеффом Безосом, — «принцип двух пицц»: команда должна быть такого размера, чтобы ее можно было накормить двумя пиццами. Как правило, это 5-8 человек. Небольшие Agile команды позволяют обеспечить более эффективную коммуникацию, увеличивают доверие между ее членами и снижают страх ошибки.

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

Scrum

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

Работа по Scrum ведется спринтами — базовыми циклами по 1-2 недели, в течение которых команда разработчиков занимается реализацией пользовательских историй, отмеченных владельцем проекта как приоритетные. Каждая история разбивается на конкретные действия, которые необходимо выполнить, и для каждого действия назначается исполнитель. При этом работает заявленная в манифесте Agile идея свободы разработчика: исполнитель самостоятельно решает, как именно он будет выполнять задачу.

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

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

Scrum-митинг — оперативные встречи, на которых команда обсуждает статус задач и рассматривает «узкие места», замедляющие работу.

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

Ретроспективные встречи Agile — на них команда обсуждает, что было сделано хорошо и что нуждается в улучшении в следующих спринтах.

Kanban

Этот фреймворк подходит для постоянного улучшения уже существующих продуктов в рамках специализированных рабочих групп, когда изменения могут происходить практически каждый день. Он не предполагает цикличности и основан на потоковом методе решения задач: все задачи по реализации пользовательских историй размещаются на реальной или виртуальной Kanban-доске (например, с использованием специальных сервисов) в виде карточек, а затем перемещаются по стадиям готовности: «Надо сделать» (бэклог), «В процессе», «Сделано». Это позволяет организовать и визуализировать работу, скоординировать действия всех участников и минимизировать временные затраты на управление.

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

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