Иногда молодые команды разработки охватывает неразбериха.
Это случается в тот момент, когда они ещё не до конца разобрались, что такое эджайл; проджект и продакт спорят, кто из них кто, а задачи каждый ведёт сам по себе. Или все уже всё знают, но планировать спринты не получается — задачи не прорабатываются, демо и ретро проходят нерегулярно.
У нас тоже была похожая история, но мы нашли свой путь.
Это рассказ от команды личного кабинета Яндекс.Кассы, и подробнейшая инструкция для тех, кто хочет улучшить своё планирование.
Команда личного кабинета Яндекс.Кассы отвечает за удобство подключения новых мерчантов к Кассе и делает сервис выставления счетов. По меркам Яндекса, команда молодая — 4 из 6 разработчиков работают полгода или меньше, а я, руководитель проекта, пришёл в команду 3 месяца назад.
В первый день нового спринта команда собиралась вместе с product owner (далее — PO) и планировала спринт около двух часов. У такого подхода есть очевидные минусы:
С их учетом появились требования к новому процессу:
Мы ввели новые контейнеры (списки) команд:
Приоритет задач во всех списках, кроме первого, определяет PO.
Если в спринте законились задачи — член команды может взять в работу задачи из «Estimated» и будет точно понимать, что они полностью готовы к работе — бери и делай.
Product owner перемещает активности из контейнера «Список задач» в «Grooming», расставляет приоритеты и максимально понятно описывает Definition of Done.
PM проверяет активности в контейнере «Grooming» по чек-листу:
Если что-то не так, то PM общается с PO для уточнения деталей и уведомляет команду о том, что список «Grooming» актуализирован
Пример:
Команда знакомится с новыми активностями и пишет комментарии, вопросы и вносит предложения. 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 приходилось спасать проект, стало намного меньше.
Как и всё живое, наш процесс время от времени требует актуализации. Сейчас мы видим, что его стоит доработать в следующих направлениях:
Надеемся, что наш опыт поможет и вашей команде. Мы готовы обсудить наш подход в комментариях, ответить на вопросы или дать советы.
К сожалению, не доступен сервер mySQL