Иногда молодые команды разработки охватывает неразбериха.

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

У нас тоже была похожая история, но мы нашли свой путь.

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

Как всё было

Команда личного кабинета Яндекс.Кассы отвечает за удобство подключения новых мерчантов к Кассе и делает сервис выставления счетов. По меркам Яндекса, команда молодая — 4 из 6 разработчиков работают полгода или меньше, а я, руководитель проекта, пришёл в команду 3 месяца назад.

В первый день нового спринта команда собиралась вместе с product owner (далее — PO) и планировала спринт около двух часов. У такого подхода есть очевидные минусы:

1. Низкая проработка требований. PO не хватало времени, чтобы ответить на все вопросы. Мы либо брали такие задачи в спринт, либо просили аналитиков оценить задачу и откладывали её выполнение до начала следующего спринта.
2. Были ситуации, в которых о заинтересованных лицах вспоминали, когда спринт был в самом разгаре и нам срочно требовались какие-то доработки или решения от смежных команд.
3. Отсутствие управления рисками.

С их учетом появились требования к новому процессу:

1. Требования к задачам должны прорабатывать и владелец продукта, и все заинтересованные лица.
2. Внедрили dod (definition of done — это набор критериев, которые позволяют понять, сделано ли то, что было целью разработки) для каждой активности. Стали определять заинтересованных лиц, чтобы за неделю до начала нового спринта информировать их о ходе работ и собирать обратную связь.
3. Минимум встреч, чтобы сосредоточиться на текущем спринте. Ограничились двумя встречами в две недели по часу каждая.
4. Стали проводить регулярное внутреннее обучение по продукту в команде, так как на сегодняшний день один из ключевых рисков — это недостаток знаний о продукте.

Новые понятия

Мы ввели новые контейнеры (списки) команд:

Приоритет задач во всех списках, кроме первого, определяет PO.

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

Первая неделя

По клику — полная версия.

Понедельник

Product owner перемещает активности из контейнера «Список задач» в «Grooming», расставляет приоритеты и максимально понятно описывает Definition of Done.

PM проверяет активности в контейнере «Grooming» по чек-листу:

1. Нужны ли макеты для новых активностей и, если да, есть ли они?
2. Вошли ли все активности по самому важному проекту?
3. Указаны ли связи между задачами?

Если что-то не так, то PM общается с PO для уточнения деталей и уведомляет команду о том, что список «Grooming» актуализирован

Пример:

1. Возьмём задачу «Письма о выставленных ночью счетах отправляются с задержкой». Она была добавлена тестировщиком в конец списка «Grooming».
2. PO поднял эту задачу в списке.
3. PM проконтролировал, что активность по работе с контейнером со стороны PO проведена, и уведомил об этом команду.

Вторник

Команда знакомится с новыми активностями и пишет комментарии, вопросы и вносит предложения. PO автоматически получает все новые комментарии (мы используем Jira, поэтому это делать легко), и у него есть время подготовить ответы до завтра.

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

Среда

Проводим встречу с PO, который отвечает на вопросы команды. Цель встречи: зафиксировать DoD. По итогам встречи часть активностей перейдёт в контейнер «Defined», а часть — сразу в «Estimated», если сразу очевидно, сколько времени займёт эта активность. Определяем зависимости и заинтересованные стороны.

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

Четверг

PM отправляет заинтересованным сторонам список ближайших активностей из списка «Estimated» и «Defined» с просьбой посмотреть и дать свои комментарии.

Пятница

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

На задачу, которую мы показываем как пример, никаких комментариев не поступало, но в целом это выглядит так:

Обратная связь может прийти и через мессенджер.

Результатом первой недели являются активности, по которым точно понятно, что надо делать (dod определён), с учётом пожеланий от заинтересованных сторон.

Вторая неделя

Понедельник

Команда самостоятельно проводит оценку активностей в списке «Defined» и декомпозицию активностей в списке «Estimated». PO здесь не привлекается, потому что он отвечает за постановку задач со стороны бизнеса и в его обязанности не входит оценка того, как сделано что-либо из запланированного.

Вторник

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

Среда

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

Демо бывает внутреннее и внешнее.

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

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

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

Четверг

PO приоритезирует списки «Defined» (если во время выполнения спринта активности будут закончены ранее предполагаемого срока, то взять новые активности в работу можно будет из этого списка) и «Estimated» (активности из этого списка переходят в новый спринт).

Пятница

Происходит планирование спринта, в котором участвует команда разработки PM и PO.

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

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

Каждая вторая пятница — это завершение не только рабочей недели, но и спринта. Это день общения и обратной связи. Таким образом, понедельник новой рабочей недели начинается с ясных и оцененных задач, что тоже логично и комфортно для команды.

Выводы и дальнейшие шаги

С помощью данного процесса удалось наладить качественное взаимодействие между PO и командой, конфликты и недопонимания остались в прошлом. Улучшился климат в коллективе, и появилось чувство слаженной ритмичной работы. Конечно, проблем возникает ещё много, но экстренных и непредвиденных ситуаций, в которых команде или PM приходилось спасать проект, стало намного меньше.

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

1. Баги. Работу с багами тоже необходимо планировать. Появляющиеся баги мы не можем проводить по процессу планирования спринта, здесь необходима более оперативная работа. Мы думаем над тем, как это сделать.
2. Хотим сделать таблицу типовых рисков, чтобы их учитывать и снижать вероятность ошибок при реализации спринта.
3. Хотим при планировании спринта отталкиваться от цели спринта, чтобы удерживать фокус работы. Команда молодая, поэтому с этим есть сложности.

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