Ничего не найдено. Попробуйте еще
Как эффективно планировать спринты и справляться с форс-мажорами: пошаговый план от scrum-тренера
-
АвторАлёна ЧеркасоваПродолжает осваивать Scrum -
ЭкспертРоман ДорошенкоПрофессиональный Скрам-тренер от компании Scrum.org и партнёр Scrum.ru
Scrum — фреймворк, который помогает разрабатывать сложные продукты и проверять гипотезы. Однако на практике команды могут разочаровываться в этом подходе — часто из-за того, что допускают ошибки в работе с ним. Например, при подготовке спринтов. Вместе со scrum-тренером, партнёром консалтинговой компании Scrum.ru Романом Дорошенко разобрались, что нужно учесть при планировании спринтов и как успешно справляться с форс-мажорами
Роман Дорошенко — консультант по организационному дизайну и целеполаганию.
Профессиональный scrum-тренер от компании Scrum.org, сертифицированный эксперт целеполагания от OKR Institute. В прошлом разработчик и владелец продукта. Фанат продуктового менеджмента, количественной аналитики и инженерных практик.
Помогает большим организациям развернуться лицом к клиенту и заработать на этом.
Что такое спринт и зачем он нужен
Спринт — это один из элементов фреймворка Scrum, который представляет собой фиксированный промежуток времени для выполнения работ. Так, спринт помогает ограничить риск, который может понести владелец продукта. Например, если спринт длится 4 недели, то в случае неудачи убытки составят только месячную зарплату сотрудников и издержки за это время, а не весь бюджет на разработку продукта.
Оптимальная длина спринта — до месяца. Каждый бизнес определяет её индивидуально, в зависимости от того, какой риск готов понести. Например, для кого-то это может быть две недели, а для кого-то четыре. Чем длиннее спринт, тем выше риск.
Многие компании считают, что при планировании спринта в Scrum важнее всего реализовать как можно больше фичей, чтобы получить кусочек кода продукта. Это неверно, поскольку в таком случае команда просто увеличивает количество функций — при этом часть из них может быть не нужна пользователям.
На самом деле весь спринт состоит из двух частей:
- Time to market — время от идеи до разработки продукта
- Time to learn — время для обучения.
Последнее помогает проверить, нужна ли фича целевой аудитории, что изменить в продукте и в каком направлении двигаться. Для этого нужно собрать метрики и получить обратную связь от пользователей. После этого команда возвращается к первому этапу и корректирует продукт с учётом полученных знаний.
Часто проблемы в использовании Scrum происходят из-за непонимания, как должен проходить спринт
Спринт реализует 3 из 12 принципов манифеста Agile (тезисы, которые сформулировали эксперты в области IT в 2001 году для управления работой по проектам).
1. Главный приоритет — удовлетворить потребности клиента через быструю и непрерывную поставку ценностей продукта
Это означает, что через каждый фиксированный промежуток времени мы получаем обновлённую рабочую версию продукта. Такой подход помогает ограничить продуктовые и технологические риски. Другими словами, через спринты мы можем понять, что продукт работает и он нужен пользователям.
2. Работающий продукт нужно выпускать в релиз как можно чаще — от двух недель до двух месяцев, выбирая более короткий срок
Так, работа спринтами помогает быстро получить обратную связь и проверить гипотезу. Например, на раннем этапе можно увидеть, какие функции нужны пользователям, а какие нет. В этом случае результат работы — это знание, которое быстрее помогает найти лучшее решение для продукта.
3. Работающий продукт — это главный показатель успеха
В конце спринта важно получить не просто кусок кода или контента, а продукт, который решает задачи клиента.
«Такой подход можно сравнить с игрой в морской бой. Даже если мы промахиваемся, то при следующем ходе у нас возрастает шанс попасть в цель. Ведь в пустую клетку мы дважды стрелять не будем. Чтобы дешевле «промахиваться» в продуктовой разработке, работа ограничена короткими спринтами», — рассказал партнёр консалтинг-компании Scrum.ru Роман Дорошенко.
Как организовать эффективное планирование спринта
Чтобы создать продукт, недостаточно одного спринта. Это всегда будет цепочка итераций, которые идут друг за другом. Разберём, какие шаги нужно сделать для подготовки к первому спринту, если команда только начала работу.
Шаг 1. Ставим цель и формируем понимание продукта
Важно определить, какой результат нужно получить в итоге. Это могут быть среднесрочные или долгосрочные цели, которые можно оценить конкретными метриками. Например, компания разрабатывает систему денежных переводов между странами. В этом случае целью может быть количество клиентов, объём транзакций через систему.
«Перед разработкой продукта необходимо провести хорошую работу по исследованию рынка и изучению аудитории. Также нужно оценить, можно ли создать решение в рамках ограничений, которые у нас есть — например, доступных людей, бюджета, законодательных документов», — рассказал Роман Дорошенко.
Шаг 2. Формируем product backlog (бэклог продукта)
Когда есть цель и понимание продукта, необходимо определить, какие шаги помогут его создать. Это определяет владелец продукта (Product Owner). Он выступает связующим звеном между командой разработки и рынком. Все шаги заносятся в бэклог продукта — по сути, это список задач с приоритетами. На каждом таком шаге команда получает ценность продукта, которая помогает достигнуть конкретную цель.
«В первую очередь проводят проверку гипотез и их тестирование. Например, чтобы изучить спрос аудитории, создают лендинг и привлекают туда первых клиентов. Если пользователь оставляет заявку, оператор может её обработать вручную. На примере той же системы денежных переводов можно, например, открыть небольшой счёт для клиента и помочь ему перевести деньги с помощью сторонних сервисов, чтобы завершить пользовательский опыт», — пояснил Роман Дорошенко.
Шаг 3. Уточняем, как будет работать продукт
Команда разработки делает это самостоятельно через PBR (Product Backlog Refinement). Это активность, которая помогает детально понять, оценить и упорядочить элементы в бэклоге продукта. Для этого на встречу с командой приглашают заказчика, для которого разрабатывают продукт. Все участники могут задать вопросы с точки зрения разных компетенций. В этом случае получится всё прояснить на одной встрече и приступить к разработке.
«Часто компании считают, что эффективнее не собираться всей команде с заказчиком, а общаться с ним через одного аналитика. Разберу на примере, почему это не так. Чтобы уточнить детали и составить техническое задание, аналитик сначала идёт к заказчику, а затем передаёт всю информацию разработчику. У последнего могут возникнуть вопросы, с которыми нужно снова возвращаться к заказчику. Всё это занимает время», — рассказал Роман Дорошенко.
Общение с заказчиком через одного человека на практике менее эффективно, чем совместная встреча: к разработке продукта, скорее всего, приступят не тогда, когда всем и всё будет понятно, а когда начнут поджимать дедлайны
Шаг 4. Формируем план спринта
Когда у команды появилось понимание, с чего начать создание продукта и как именно он должен работать, следует приступать к декомпозиции — процессу разбивки сложных элементов бэклога на меньшие задачи, которые можно сделать в рамках одного спринта. При этом в конце должен быть конкретный результат. Например, если команда работает над системой переводов денег на международные счета, не должно быть задач «сделать бэкенд» или «провести тестирование». Правильнее поставить такие: «перевод денег с ручной обработкой через сторонние сервисы», «перевод денег с ручной обработкой через свои сервисы», «перевод денег с автоматической обработкой».
Далее идёт расстановка приоритетов — этим занимается владелец продукта. Чтобы определить план на спринт, оценивают, что команда успеет реализовать за одну такую итерацию — например, за две недели.
Дополнительно в ходе спринта стоит актуализировать бэклог, чтобы заранее подготовить задачи на следующий спринт. Такая стратегия позволит тратить на эффективное планирование спринтов в дальнейшем не больше часа.
Вместо заключения: как справляться с форс-мажорами во время спринта и оценить его эффективность
Product Owner управляет бэклогом продукта, а разработчики — бэклогом спринта. По сути, форс-мажор — это новая задача, которая неожиданно может возникнуть во время разработки. В этом случае нужно пересмотреть перечень задач на спринт: что-то придется убрать, чтобы справиться с форс-мажором. Решение принимает команда разработчиков вместе с владельцем продукта.
Чтобы оценить эффективность спринта, нужно ориентироваться на ранее поставленную цель. Каждая итерация продукта должна приближать команду к желаемому результату.
«Я считаю, что в качестве основной метрики должна быть всё-таки прибыль. Мы постоянно инвестируем средства в разработку продукта — соответственно, должны хотя бы выходить в ноль в конце одного или нескольких спринтов. Такой подход может быть актуален для нового продукта. В идеале же работающая версия зарабатывает деньги, иначе нецелесообразно вкладываться в его дальнейшее развитие», — заключил Роман Дорошенко.
Подпишитесь на рассылку МТС Линк Медиа
Каждую пятницу присылаем самые интересные статьи об эффективной работе и коммуникациях в онлайне на почту