Sprint planning: remember this is a sprint, not a marathon

Планирование спринта: помните, что это спринт, а не марафон

Опубликовано 27.02.2018
Автор Алексей Кривицкий

Оригинальная статья Эшли-Кристиан Харди: Sprint Planning: Remember it’s a Sprint, not a Marathon.

Статья переведена с английского Еленой Максимовой.

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

Планирование спринта - это ограниченная по времени встреча в начале спринта, на которой Команда и Владелец Продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте.

Как правило, встреча делится на две части: "Что?" и "Как?".

Что?

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

Как?

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

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

Как это выглядит?

Alt Text

Частые проблемы

  • Владелец продукта сам определяет и решает, какая работа будет завершена
  • Беклог продукта не актуален, не приоритезирован или не готов к обсуждению
  • В конце планирования все слишком детализировано, и вся работа уже распределена по исполнителям (эту проблему трудно преодолеть)
  • Никто не понимает, что означает статус "Готово"
  • Встреча слишком длинная
  • Встреча не включает участников в процесс
  • Некоторым людям сложно проявляться
  • Неподходящая среда, команда не чувствует поддержки или безопасности
  • Нет доверия или уважения с обеих сторон
  • Команда не понимает, для чего нужна эта встреча

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

Alt Text

Чек-лист для подготовки к успешному планированию

  • Мотивированная команда
  • Хороший контакт и доверие между ВП и командой.
  • Если ВП не доверяет выводам команды, встреча быстро станет упражнением по избеганию вместо диалога о работе. Команде важно видеть ценность встречи и преимущества планирования. Если есть какие-либо сомнения ‒ процесс рухнет
  • Встреча проходит в установленное время.
  • Она не должна быть слишком длинной и утомительной, потому что тогда теряется ценность
  • Проведена подготовительная работа, часто в формате встреч по уточнению беклога.
  • ВП гарантирует, что существует здоровый, поддерживаемый и приоритезированный беклог
  • Истории в верхней части беклога, которые должны входить в следующий спринт, разбиты на небольшие части, чтобы команда могла их обсудить и запланировать
  • Скрам-мастер убедился, что участвуют все члены команды: Владелец продукта, Скрам-мастер, разработчики, тестировщики, администратор базы данных - каждый, кто является частью команды разработчиков. Другие заинтересованные стороны могут присутствовать только в качестве наблюдателей, не прерывающих процесс.
  • Каждый участник должен чувствовать свою ценность на встрече, иметь возможность поделиться своим видением
  • Решения о работе принимаются командно.
  • Если ВП принимает все решения о работе и ее выполнении, команда будет чувствовать, что это пустая трата времени.
  • Консенсус по поводу метода оценки и разбивки работы. Story Points или Planning Poker - команде нужно договориться о методе оценки, чтобы работать согласованно.

Длительность

Alt Text

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

  • Однонедельный спринт - 2 часа
  • Двухнедельный спринт - 4 часа
  • Спринт длинной в 1 месяц - 8 часов

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

Цели

Alt Text

Задача встречи - сформулировать цель спринта. Ее можно представить в форме беклога спринта. Беклог спринта - список приоритезированных задач, которые команда берется завершить до конца спринта. Здесь важно помнить о командных критериях готовности (Definition of Done).

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

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

Структура встречи

Alt Text

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

Производительность команды:

  • Достаточно взять среднее последних 3 спринтов, как руководство
  • Обсудите часы доступности команды, отпуска, режим работы членов команды
  • Помните, что спринты не бывают одинаковыми!
  • Не пытайтесь быть слишком детальными - это бесполезная трата времени, т.к. количество неизвестных слишком велико
  • Команда все равно согласовывает объем работы
  • Оставьте некоторое время для решения пока неизвестных вопросов и проблем.
  • Так команда получает больше свободы действия.
  • Проще добавить работу в спринт, если у вас хорошо проработан беклог, чем убрать ее.

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

Разбивка задач

Alt Text

  • Определите критерии готовности (DoD). Это устраняет конфликты и дает прозрачность процесса. "Готово" должно значить потенциальную поставку продукта.
  • Обсудите все задачи, чтобы получить представление о работе и ее выполнении: создание скриптов, рефакторинг, интеграция кода, тестирование и автоматизация, исправление багов, техническое обслуживание.
  • Не слишком привязывайтесь к процессу оценки, это всего лишь предположение, а не обязательство.
  • Частая ошибка на этом этапе - хождение кругами.
  • Не привлекайте отдельных членов команды к ответственности за оценку. Команда не должна бояться оценивать.
  • Не стоит сравнивать относительные оценки с фактически затраченным временем (если нет существенных различий, но тогда это нужно вынести на командную ретроспективу).
  • Вся команда владеет беклогом спринта, поэтому не распределяйте задачи по исполнителям.По опыту я знаю, что если это происходит, тогда одни и те же люди постоянно получают одну и ту же работу. Это плохо, потому что тогда вы развиваете «специалистов» в своей команде, а обмен знаниями и развитие становятся ограниченными. Совершенно нормально иметь специалистов, пока они обмениваются знаниями с командой, но нет ничего хуже, чем один человек, который несет знания и ответственность за конкретную часть кода, а затем он уходит - забирая эти знания с собой.
  • Цели спринта достигает вся команда. Поскольку у вас есть список приоритетов, то если одна задача выполнена, член команды может предложить помощь другим, если нужно; или перейти к следующей по приоритету задаче.
  • Используйте Story Points как способ относительной оценки. Тут вы сравниваете задачи их по сложности, а не по времени. Разработчику проще сказать «эта задача в 3 раза сложнее, чем та», а не «эта задача займет у меня около 4 дней». Не смешивайте Story Points с часами, тогда люди просто пытаются конвертировать Story Points во время, а затем Story Points вообще теряют свою ценность.
  • Согласовывайте размеры ваших задач. Хороши задачи, которые занимают не более 1 дня; их преимущества:
    • разработчикам проще планировать рабочий день,
    • повышается эффективность, если задачу можно начать и завершить в тот же день,
    • небольшие задачи дают более полное представление об объеме работы,
    • можно сократить "узкие горлышки" процесса,
    • атомарные задачи можно было делать параллельно. Задачи, зависящие друг от друга, - будут вызывать проблемы и провоцировать "узкие горлышки".
  • Создавайте только те задачи, которые требуют выполнения; разработка, тестирование, документация, демо и т. д. ... Не вносите в них работу Владельца продукта или командные встречи.
  • Если вы не уверены в задаче, создайте “зазор”. Он нужен для проведения исследования.
  • Не планируйте 8-часовой рабочий день, даже если команда нанята на это время. В действительности команда не работает 8 часов подряд. «Эффективность» хорошей здоровой команды - около 70% рабочего времени, поэтому я планировал 6 часов в день, т.к. в течение дня происходит много всего: встречи, обеденный перерыв, выяснения деталей с ПО, короткие перерывы.

Рабочая среда

Alt Text

Среда

Команде важно чувствовать себя в безопасности, понимать, что нормально не знать всего прямо сейчас. Agile весь состоит из адаптации, подстройки и обучения. Должно быть ощущение сотрудничества, поддержки, любопытства и драйва. Команда не должна бояться задавать вопросы, высказываться. Команде важно чувствовать уверенность в том, что они действительно могут поставить и какие взять на себя обязательства; и если у них есть какие-то сомнения или возникают риски, отнеситесь к ним всерьез. Очень важно, что последнее слово о поставке остается за командой, а не Владельцем продукта.

Автономия команды

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

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

Активное слушание

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

Взаимное уважение

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

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

Вопросы

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

Процесс

Если вы используете физическую Kanban доску, предложите команде самостоятельно выписать свои стикеры, повесить их на доску и расставить приоритеты, опять же, это хороший способ развивать самоорганизацию. Используйте время встречи для обновления своего инструмента, будь то физическая Kanban доска, Jira или TFS. Во-первых, каждый сможет увидеть план, согласиться на него и начать работу. Во-вторых, хорошо, когда каждый понимает процесс. Тогда, если Скрам-мастер болен, то члену команды несложно подменить его.

Завершение встречи

Alt Text

Планирование спринта ограничено во времени, заканчивайте его вовремя. Даже если фактически планирование еще не закончено, важно начать работу, продолжение встречи не поможет завершить пользовательские истории. Совершенно нормально не знать всех деталей, это развивает гибкость!

Иногда команде необходима смелость сказать «Ок, этого достаточно, мы не знаем всех деталей, но будем изучать оставшиеся и приспосабливаться по пути». Быть гибким - значит экспериментировать, изобретать, и старт работы дает команде шанс сделать это!

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


Бонус - скрайбинг статьи от Алёны Серпецкой:

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

Все, что вы хотели знать про LeSS - в первом выпуске Agile Friday

Недавно мы решили, что пришло время делать крутой и эксклюзивный контент. Поэтому в декабре мы запустили Agile Friday - видеопередачу, в которой Евгений Лабунский, управляющий партнер Scrum Ukraine, будет общаться с крутыми экспертами в сфере Agile на самые горячие темы. В них мы будем говорить …

Читать статью

©2017 - 2018 Scrum Ukraine. All rights reserved