12 принципов Agile на практике: как быть гибкими и создавать востребованные продукты

Подробно расшифровываем 12 принципов Agile на прикладных примерах: как с помощью гибкости оптимизировать работу команды.

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

Разберем подробно, как применять на практике 12 принципов Agile-манифеста.

Потребности клиента всегда на первом месте

Наивысший приоритет для разработчиков — удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного продукта.

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

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

Реклама 16+

Оцените финансовые показатели бизнеса, получите советы по их улучшению, прогнозируйте прибыль

Попробовать

Изменение требований приветствуется даже на поздних стадиях разработки

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

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

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

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

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

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

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

Чем раньше вы предоставите рынку минимально жизнеспособную версию продукта (MVP), тем быстрее сможете проанализировать, что именно нужно клиенту, и на основе этого построить дальнейшие планы по доработке продукта.

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

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

На протяжении всего проекта разработчики и представители бизнеса должны работать вместе

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

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

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

Над проектом должны работать мотивированные профессионалы

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

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

Они верят в идею продукта и мотивированы на его реализацию в лучшем виде.

Непосредственное общение — эффективный способ обмена информацией

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

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

Совместная работа также приветствуется, например, формат моб программирования: когда команда пишет код в режиме реального времени за одним компьютером (или подключаясь с помощью онлайн-инструментов).

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

Работающий продукт — основной показатель прогресса

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

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

Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм

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

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

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

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

Иными словами, сразу делай хорошо, чтобы потом не переделывать.

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

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

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

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

Простота крайне необходима

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

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

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

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

Лучшие архитектурные и технические решения рождаются у самоорганизующихся команд

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

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

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

Этот принцип заключается в постоянном совершенствовании. Всегда задавайте себе вопрос: а можем ли мы работать еще эффективнее?

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

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