Инструкция: как перейти на agile

Об agile-подходе заговорили благодаря знаменитому Agile Manifesto, опубликованному в 2001 году. После этого прогрессивные компании начали переходить на гибкие методы разработки. Вы тоже можете перевести команду на agile. Эксперты курса Changellenge >> Польза составили инструкцию — следуйте ей и внедряйте!

Что такое agile

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

Agile-подход отличается гибкостью и особенно актуален в двух случаях:

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

Концепция Agile Manifesto включает четыре ценности:

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

Внедряем agile

Шаг 1. Спросите себя, зачем вам agile-подход

Гибкие методики могут повысить эффективность работы и сократить издержки. Но для этого нужно поставить четкую задачу, которую вы будете решать с помощью agile. Внедрять его ради того, чтобы соответствовать трендам, не имеет смысла: вы только расшатаете уже отлаженные процессы. Но если, например, в вашем отделе регулярно сдвигаются сроки или клиенты уходят от вас со словами «Мы хотели совсем другого», перед вами проблема. И agile поможет ее решить.

Шаг 2. Обсудите с командой переход на agile

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

Назначьте встречу и обговорите:

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

Шаг 3. Вместе с командой создайте список приоритетных задач

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

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

Шаг 4. Опишите единицы работы, необходимые для выполнения этих задач

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

На этом этапе должны высказаться все участники команды. Чтобы сделать обсуждение эффективным, можно использовать различные техники, например Scrum Poker. Ее цель — убедиться, что все, кто задействован в проекте, одинаково понимают задачу и согласны с алгоритмом ее выполнения. Механика следующая:

• Участники получают по колоде карт. На 11 из них — числа из последовательности Фибоначчи, еще на одной — вопросительный знак, а на последней — символ бесконечности. (Существуют также колоды с другой нумерацией, но мы рассмотрим самую простую.)
• Организатор встречи выносит задачу на обсуждение. Рассказывает, как считает правильным ее выполнять и какой цели она помогает достичь. Здесь важно мотивировать участников и ответить на уточняющие вопросы.
• Участники анализируют задачу и выкладывают на стол рубашкой вверх карту из своей колоды. Она показывает, как сотрудник оценивает задачу. Значения карт таковы:
  • 0 — задача простая или близка к завершению. Нет смысла выделять ей место в плане.
  • 1–3 — мелкие задачи.
  • 5–13 — задачи средней сложности.
  • 20-40 — крупные задачи.
  • 100 — глобальные задачи.
  • ? — у участника недостаточно информации.
  • ∞ — сверхглобальная по масштабности и важности задача.
• Карты открываются. Если мнения сильно различаются, обсудите их. Первыми высказываются те, у чьих карт самое низкое и высокое значение. Они делятся тем, как планируют решить задачу в такие сжатые сроки, и каковы риски.
• Второй раунд голосования с учетом обсуждения.
• Финальное решение.

Если вы не хотите искать колоды, используйте приложение Pokrex. По механике оно соответствует Scrum Poker, но не требует офлайн-встреч.

Шаг 5. Создайте трекер для отслеживания прогресса

Там необходимо фиксировать задачи. Удобнее всего использовать общественные онлайн-доски, доступ к которым есть у всех заинтересованных в проекте. Существует множество сервисов, которые предлагают такой функционал, мы рекомендуем Trello. 

Вести доски можно по методологии Kanban. Для этого нужно сгруппировать задачи по какому-то признаку. Самый популярный способ:

• To do — сделать.
• Doing — то, что сейчас в работе.
• Done — готово.

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

Шаг 6. Запланируйте задачи на первый спринт, используя единицы оценки

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

Шаг 7. Проводите ежедневные летучки

Это должны быть 5–10-минутные встречи, на которых команда фиксирует результаты и обсуждает возникшие проблемы. У каждого выступающего — не больше 60 секунд. За это время он должен рассказать:

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

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

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

Шаг 8. Проводите ретроспективные встречи после каждого спринта

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

• Что получилось.
• Что пошло не так.
• Что можно улучшить.

Так вы будете использовать весь накопленный опыт и постоянно налаживать процессы.

Как понять, что пора переходить на agile

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

Что может пойти не так

Безусловно, многое. Мы собрали несколько типичных проблем, с которыми сталкиваются команды на этапе внедрения agile-подхода:

• Участники против ежедневных летучек. Это нормально, ведь люди привыкли работать по определенной схеме и не хотят учиться заново. Не поддавайтесь и не отменяйте встречи — постарайтесь вдохновить коллег на участие и дать им войти в новую рутину. На курсе Changellenge >> Польза вы освоите методы мотивации команды и сможете убедить коллег в необходимости летучки. Но если после трех спринтов команде все еще будет неудобен этот формат, не настаивайте.
• Участники против внедрения agile в целом. Чтобы этого избежать, необходимо подключать команду к каждому этапу внедрения agile-подхода, обсуждать процесс и сразу отрабатывать негатив. Иначе появятся саботажники, которые будут снижать продуктивность всей команды. 
• Новая система оценки задач кажется сложной и непонятной. Вы руководитель команды, поэтому именно вы должны проследить, что все разобрались в том, что такое единицы работы и освоили матрицу «срочно — важно». Только в этом случае новая система будет помогать команде, а не мешать ей.
• Первый спринт комом. Переход на гибкую методологию сначала может привести к срыву дедлайнов и спорам. Но это не повод немедленно отказываться от agile-подхода. Соберите обратную связь, внесите улучшения, отработайте негатив и начинайте новый спринт. Только после трех спринтов, когда все участники освоят методологию, а недовольство непривычным уйдет, вы получите релевантные результаты.

Хотите познакомиться с agile-коучами и разобраться на практике, как внедрять гибкие методологии? Приходите на курс Changellenge >> Польза, где тренеры, которые работают с «МТС» и S7 Travel Retail, научат вас принципам agile и помогут внедрить его в команде!