Хабрахабр

Как спланировать двухнедельный спринт

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

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

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

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

Как всё было

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

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

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

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

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

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

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

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

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

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

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

Понедельник

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

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

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

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

Пример:

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

Вторник

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

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

Среда

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

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

Четверг

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

Пятница

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

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


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

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

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

image

Понедельник

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

Вторник

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

Среда

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

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

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

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

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

Четверг

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

Пятница

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть