В классическом Scrum есть три роли: разработчики, скрам-мастер и владелец продукта. Скрам-мастер отвечает за процессы, фасилитацию встреч, устранение блокеров и всё, что помогает команде работать эффективно.

Но что, если убрать скрам-мастера, а его обязанности распределить между участниками команды? Кстати, в ней нет и тимлида, который брал бы задачи на себя. Мы живём так уже несколько лет — и это работает.

Привет! Меня зовут Иван Зверев. Я — fullstack-разработчик в Додо, а эта статья — не учебник по скраму. В ней я расскажу о том, как может самоорганизоваться здоровая команда, если ей довериться, обозначить прозрачные правила работы и дать свободу экспериментировать с процессами. Всем такой подход не подойдёт, но в наших условиях он доказал свою эффективность.

О нас

Мы — команда разработки Code Monkeys юнита B2B Pizza в Додо: 5 разработчиков, 2 QA и продакт. Сейчас наш продукт — система оптимизации производства и доставки.

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

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

Наши «часики»

Вместо постоянного скрам-мастера у нас работает простая, но эффективная система — «часики». Это нарисованный циферблат, на котором мы отмечаем две ключевые роли спринта:

• фасилитатор. На него указывает стрелка;

• дежурный. На него указывает карта джокера.

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

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

Он принимает на себя «срочные прилёты» от других команд, проверяет пулл-реквесты, следит за метриками и реагирует на инциденты. Дежурный не берёт задачи из цели спринта, чтобы его можно было безболезненно отвлекать.

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

Планирование спринта

В начале спринта мы проводим планирование. Для этой встречи у нас есть чёткий план.

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

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

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

Нас часто спрашивают: «что делать, если мнения участников расходятся? Не превращаются ли встречи в бесконечные споры?» Да, обсуждение цели и критериев её достижения иногда бывает жарким и затягивается, но фасилитатор следит за регламентом. Такие дискуссии нужны — именно в них рождаются лучшие решения.

Как правило, в итоге удаётся убедить всех участников в правильности выбранного курса, а критически важные моменты мы обязательно обсуждаем и вместе находим решение. Финальное слово остаётся за продактом, но он всегда учитывает мнение команды.

Доска задач

Мы ведём задачи в Kaiten. Это удобный инструмент управления тасками, аналог Jira:

Доска спринта разделена на три уровня (lane):

1. Срочно — баги и инциденты с абсолютным приоритетом. Такие задачи выполняются as soon as possible.

2. Цель спринта — основной фокус команды на текущем цикле.

3. Хотелки — полезные, но не критичные задачи. Это то, что мы хотим сделать, но можем отложить до следующего спринта.

Задачи мы берём по принципу вытягивания (pull) из канбана. Как только разработчик освобождается, он выбирает самую верхнюю из подходящих ему задач.

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

Задачи перемещаются по колонкам:

• To Do — задачи, ещё не взятые в работу;

• Development — в процессе работы;

• Deployment — задачи на этапе деплоя в прод. Здесь могут быть задержки, если требуется релиз нескольких сервисов или другая сложная процедура;

• Post-production — проверка работы задачи в продакшене и мониторинг её состояния;

• Done — завершённые задачи.

Два стендапа в день

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

Нас часто спрашивают: «не жирно ли проводить два стендапа в день?» Нет, за счёт более частой синхронизации встречи стали короче. Лимит — 20 минут, и мы часто укладываемся быстрее.

А 2 раза по 20 минут? Всего 40 минут в день! Столько может занимать проводимый раз в день дейлик у команды из 8 человек. Но мы всегда в курсе ситуации — длинных и изматывающих «разгрузок мозга» на 1,5 часа мы избегаем.

Чек-лист стендапа

Стендапы проводит и модерирует фасилитатор спринта, на которого указывают часики. Он следит за таймингом и ведёт встречу по чек-листу.

Inbox

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

• берём в текущий спринт;

• откладываем в бэклог;

• или закрываем, если делать не нужно.

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

Оценка уверенности в цели спринта

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

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

Ретроспектива спринта

Ретроспектива — обязательная традиция в конце каждого спринта. Без неё никуда.

У нас нет ничего необычного: фасилитатор сам выбирает формат проведения. Обычно это классический формат «mad-sad-glad», но иногда мы посвящаем ретро одной конкретной теме, которая всплыла в ходе спринта.

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

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

В чём преимущества нашего процесса:

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

• устойчивость. Если кто-то уходит в отпуск или увольняется, команда продолжает эффективно работать без потерь;

• вовлечённость каждого. Каждый участник может влиять на продукт и процессы команды, а не «просто писать код».

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

Вместо итогов

Мы не претендуем на то, чтобы показывать «правильный» способ работы команды. Это не инструкция, а лишь рассказ о том, что получилось у нас.

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

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

Спасибо, что дочитали статью! Ставьте плюсики, если материал показался вам интересным, и делитесь им с друзьями. А чтобы быть в курсе последних новостей Dodo Engineering, подписывайтесь на наш Telegram-канал.