В мире продуктовой разработки важны гибкость и скорость обратной связи. Командам в ходе разработки приходится управлять множеством рисков и неопределенностью, связанных с бизнес- и технической неопределенностью.
Несмотря на попытку создавать лучшие планы, всегда в процессе возникают новые вводные, о которых мы не знали заранее. И если вовремя не адаптироваться, есть высокий риск прийти не туда. Именно для этого и создавался фреймворк Scrum.
В этой статье мы разберем наиболее важные элементы, которые позволяют балансировать предсказуемость и гибкость во благо доставки наивысшей ценности клиентам.
Спринт
Спринт — это фиксированный и стабильный временной промежуток для организации разработки и создания готового инкремента, который мы можем показать пользователям и заинтересованным лицам. Scrum ограничивает длину спринта одним месяцем, но чаще всего Scrum команды выбирают более короткую длину спринта. Здесь стоит ориентироваться на уровень неопределенности и изменений: чем выше неопределенность — тем меньше длина спринта.
Какую ценность несут спринты для бизнеса?
В первую очередь — это снижение риска потерь. Поскольку Scrum — это разработка в условиях неопределенности, то спринты помогают управлять этой неопределенностью путем планирования работы на короткий промежуток, в виде спринта и далее получая обратную связь, принимать решение, куда двигаться дальше.
Это не значит, что в Scrum отсутствуют долгосрочные цели и планы. Это лишь дает нам возможность адаптироваться часто и быстро сокращая риски.
С другой стороны, спринты дают большую предсказуемость результатов для бизнеса. Каждый спринт команда берет на себя обязательство сделать инкремент (завершенный кусочек продукта).
Ниже мы рассмотрим ключевые принципы работы Scrum команды, для доставки готового и ценного инкремента каждый спринт.
Регулярный продуктовый инкремент
Для чего нужен?
Бизнесу и Product owner важно понимать: то, что мы делаем — увеличивает ли ценность продукта, улучшает ли продуктовые метрики?
Если команда в спринт будет завершать работу частично — это приведет к накоплению технческого долга, более низкой прозрачности и отсутствии возможности протестировать новое приращение продукта на пользователях для определения его бизнес‑эффекта.
Поэтому, создавая готовый инкремент, каждый спринт мы даем возможность получить обратную связь и понять, влияет ли новый инкремент на ценность продукта или стоит от него отказаться или улучшить.
Клиенто‑центричные элементы в беклоге продукта
Если вы хотите, чтобы ваша команда научилась создавать законченный инкремент каждый спринт, который можно посмотреть, дать пользователям и сделать выводы на основе него, вам стоит начать с подхода к описанию элементов беклога.
В Scrum часто используются следующие подходы:
Пользовательские истории — описание требований языком пользователей, которые отражают их потребность. Я как «роль» хочу «потребность», чтобы «цель».
Job stories — это способ описания сценариев использования продукта, сосредотачивающийся на конкретной задаче, которую пользователь хочет выполнить.
Чем помогают эти подходы?
Во-первых, они фокусируют команду на решении проблемы или задачи клиента вместо реализации конкретной задачи.
Во-вторых, в критериях приемки и при обсуждении историй вы формулиурете образ результата.
В-третьих — задача у вас не считается выполненной, пока она полностью не завершена и не сделана вся работа в рамках истории. Это подстегивает командную работу на общий результат.
Цель спринта
Цель спринта — важный элемент Scrum команды, который обеспечивает фокус для всех участников и является главным приоритетом для команды на спринте.
Часто бывает, что на планировании спринта планируются задачи, однако не формируется Цель.
Это приводит к тому, что все сухо выполняют свои задачи без образа результата в конце. Очень часто в конце мы имеем выполненный набор задач, но не инкремент, несущий ценность для клиентов.
Какие преимущества цели спринта?
Во-первых, Цель спринта объединяет команду и все работают в одном направлении.
Во-вторых, Цель спринта определяет главный приоритет. Всегда мы делаем в первую очередь то, что касается Цели спринта.
В-третьих, при наличии Цели выше вероятность прийти к реальному результату — инкременту, нежели просто выполненному набору задач.
В-четвертых, цель спринта позволяет команде адаптировать план по ходу спринта, для того чтобы в итоге доставить ценность клиенту, а не просто слепо следовать плану. Так в ходе спринта узнаются новые вводные и уточнение плана становится нормальной работой Scrum команды в ходе проведения Daily Scrum. Ниже картинка, иллюстрирующая этот процесс.
Также на своей практике я замечал лучшую мотивацию и желание достичь цели у команды, когда есть хорошая цель на спринт. Они действительно лучше стараются, самостоятельно координируют свои действия, включают голову, а не просто выполняют задачи.
Хороший Scrum начинается с цели вокруг которой трудится команда.
Работа в спринте по движению к цели
Задача команды в спринт — не выполнить задачи, а достичь цели спринта. Это важно, так как по ходу спринта узнаются новые вводные и детали, которые нужно учитывать, чтобы достичь цели.
В ходе спринта у команды есть ряд событий:
Планирование спринта
Daily Scrum
Обзор спринта
Ретроспектива
Регулярный процесс PBR (Product backlog refinement)
Планирование спринта
На планировании спринта участвует вся Scrum команда, включая PO и команду разработки. Также могут привлекаться сторонние эксперты.
На планировании важно определить, что мы хотим сделать и как мы это сделаем.
Цель спринта — самый важный атрибут планирования. Цель спринта определяет, для чего этот спринт и чего должна достичь команда. Например — выпустить в релиз новую функциональность, повысить стабильность и качество работы приложения, отправить на ревью в сторы приложение и так далее.
На основе цели составляется план, однако нужно понимать, что в ходе спринта он может быть доуточнен, поэтому полностью загружать команду на планировании — плохой паттерн. Всегда в ходе спринта появляются детали, которые могут быть учтены, чтобы достичь цели. В этом и есть гибкость и ценность Scrum — что мы не просто делаем задачи, а всегда стремимся к новым целям в каждом спринте.
Daily Scrum
На ежедневной короткой встрече Daily Scrum команда планирует день и обсуждает препятствия. На этой встрече задача — внести изменения в план спринта и определить задачи на день, а также определить ключевые препятствия, которые мешают команде. Важно, что это не отчетная встреча перед Скрам-мастером или еще каким-то менеджером, а именно встреча для команды для планирования работы и синхронизации.
Обзор спринта
На этой встрече Scrum команда приглашает стейкхолдеров и даже пользователей, чтобы показать результаты работы за спринт.
Ключевые цели — получить обратную связь и обсудить следующие возможности в плане развития продукта.
Поэтому встреча делится на 2 части:
Демонстрация инкремента и сбор обратной связи и обсуждение
Обсуждение планов и следующих шагов
На встрече присутствуют как PO, так и вся команда разработки. И очень важно вовлекать на встречу Стейкхолдеров.
Ретроспектива
Регулярная ретроспектива спринта или взгляд назад помогают команде обсуждать препятствия, проблемы, неэффективности в процессах, которые помешали работе команды в спринте. И на выходе всегда рождается Action plan с действиями по изменению процессов, взаимодействия или другим улучшениям о которых договориться команда.
Заключение
Scrum позволяет создать предсказуемый и гибкий процесс работы команды по развитию продукта. Основная ценность фреймворка — это гибкость и фокус на результате. Это помогает развивать продукт в балансе с ожиданиями стейкхолдеров и обратной связи от пользователей и вовремя отказываться от ненужного.
Не забывайте про важные элементы фреймворка, и тогда будете получать пользу от Scrum.
А если понравилась статья, подписывайся на мой Телеграм канал, там найдешь еще больше пользы и инсайтов.
Больше про Scrum, другие фреймворки, а также подходы и лучшие практики управления продуктами и проектами можно узнать на онлайн-курсах Otus от экпертов-практиков. Подробности в каталоге.
24 декабря пройдет открытый урок, посвященный роли Product Owner. Он поможет получить чёткое представление об этой позиции и навыках, которыми он должен обладать. Если интересно, записывайтесь по ссылке.
Комментарии (2)
Thomas_Hanniball
22.12.2024 10:15Scrum – это работа спринтами, т.е. интенсивная работа над задачами в течение короткого промежутка времени. Любой спринт, например, в спорте, предполагает длительную фазу отдыха после окончания спринта. Но в Scrum ничего подобного нет, поэтому команды очень быстро выгорают из-за постоянных интенсивных нагрузок. Спринты хороши лишь в краткосрочной перспективе, например, чтобы закончить работу, когда до дедлайна осталось всего пару недель или месяц. Scrum же превратил спринты в долгосрочный марафон на выживание, в котором сжигаются целые команды.
Kanban не использует спринты, что позволяет команде работать в режиме непрерывного потока. Задачи выполняются по мере их поступления, и нет необходимости ограничиваться конкретными временными рамками. Команда может адаптироваться к изменениям более гибко и быстро, без необходимости подгонять работу под спринт.
В общем, рекомендую Kanban.
OlegZH
Самый важный и интересный вопрос — это вопрос о том, почему продукт должен развиваться. Почему в продукт нельзя сразу поместить все необходимые функции? Неужели нельзя привести примера разработки реального приложения и показать реальную пользу Scrum?