Марина Варасова – автор контента на сайте

Все привыкли, что «работать по скраму» значит разбивать процесс разработки продукта на фиксированные итерации – спринты. При этом многие забывают, что для эффективной разработки одних итераций недостаточно. Что нужно учитывать при работе по системе Scrum Важно понимать ценность всех составляющих Scrum-процесса и стремиться, чтобы каждая итерация была лучше и продуктивнее предыдущей. Окончание каждого спринта в Scrum предполагает прирост или изменение функционала продукта. Соответственно, нужно оценить эффективность прошедшего спринта и убедиться, что продукт развивается в нужном направлении. В этом помогает важный этап Scrum-процесса – Sprint Review. Около 77% команд, работающих в методологии Agile, используют практику Sprint Review на регулярной основе. Моя команда в Techstack – не исключение. Что такое Sprint Review Sprint Review – это мероприятие, которое проводят после спринта, чтобы проинспектировать инкремент (продукт, который команда успела произвести суммарно за все спринты) и проверить его готовность к потенциальному релизу. Sprint Review проводят перед ретроспективой. Оба этапа взаимосвязаны друг с другом единой целью – выявить сильные и слабые стороны. Но если в случае с ретроспективой речь идет об анализе работы команды, то Sprint Review направлен на анализ продукта. Во время Sprint Review анализируют ту часть бэклога продукта (перечень рабочих задач, расположенных в порядке важности, для команды разработчиков), которая вошла в этот спринт. Во время Sprint Review демонстрируют пользовательскую историю (юзерстори – составная часть бэклога, поясняющая, какой функционал нужно сделать для пользователя и какую ценность он для него несет) и новые функции продукта. Еще одна цель Sprint Review – получить обратную связь всех причастных к процессу разработки. Для этого на встречу собирается Scrum-команда, владелец продукта (Product Owner), а также заинтересованные лица (потенциальные пользователи), которых владелец продукта посчитал нужным пригласить. Scrum-мастер занимается организацией этой встречи, обеспечивает общность понимания целей собрания всеми участниками. При этом его присутствие необязательно. В своих проектах я не только организовываю, но и обязательно хожу на все Sprint Review. Поэтому в моем опыте есть примеры как отличных ревью, так и тех, которых даже хорошими назвать не получится. Плохой Sprint Review: причины провала Причин неудачи может быть множество. Опыт показывает, что к основным условиям для бесполезного Sprint Review относятся: Отсутствие временных рамок Растянутые, никем не управляемые обсуждения – то, что надо, если хотите вызвать у участников ощущение потерянного времени. Заинтересованные лица или конечные пользователи не приходят на Sprint Review Команда и владелец продукта уже видели этот функционал, поэтому вряд ли им будет полезно посмотреть на него еще раз. Важнее продемонстрировать его тем, кто заинтересован в продукте, но еще не знаком с новыми функциями. Юзерстори не соответствуют критериям приемки, но демонстрируется как итог спринта В начале спринта, перед формированием пользовательской истории, составляются критерии приемки. То есть тезисы, отмечающие, что именно должно быть реализовано, чтобы считать юзерстори готовой с точки зрения пользователя. Бывает, что неготовый функционал показывается как итоговый результат. Затем, в следующем спринте, команда доводит юзерстори до ожидаемого конца и показывает ее еще раз. Но теперь уже как по-настоящему готовую. Конечно, заинтересованные лица недоумевают, почему они вынуждены смотреть на одно и то же несколько спринтов подряд. Участники не готовятся к встрече Отсутствие заранее оговоренной повестки, подготовленного сценария и собранных в течение спринта метрик вряд ли приведет вас к продуктивному обсуждению. Бэклог продукта не изменился по итогам нескольких ревью Один из наиболее частых и ожидаемых результатов Sprint Review – изменение бэклога. Если же бэклог продукта не меняется, возникает вопрос о компетентности и вовлеченности участников. Нерелевантный состав участников Некоторые Scrum-мастера действуют по принципу «приглашаем всех желающих». И неважно, имеют они отношение к проекту или нет. В результате получают толпу людей, часть из которых находится вне контекста разработки и самого продукта. Дискуссия распадается на несколько потоков: кто-то хочет дать конструктивный отзыв, а кто-то из праздного любопытства задает абстрактные вопросы о продукте. Хороший Sprint Review: критерии успеха Обязательных составляющих хорошего Sprint Review не так много. На входе за успех отвечают: Наличие инкремента продукта Спринт должен иметь итог, который команда будет демонстрировать как результат работы. Команда представляет инкремент, стейкхолдеры и пользователи дают по нему обратную связь. Самый лучший способ показать реальный объем работ – наглядно продемонстрировать работу инкремента. Понимание цели спринта Цель – это общий ориентир для команды, который позволяет удерживать фокус на разработке продукта целиком, а не на отдельных функциях. Цель спринта устанавливает команда на планировании, а на Review оценивают, получилось ли у команды достичь этой цели. Заготовленный бэклог спринта Для оценки результативности спринта нужно иметь список юзерстори, которые команда взяла на себя обязательство выполнить. Собранные метрики Количественные показатели работы команды позволяют объективно оценить эффективность работы. К основным метрикам относятся: производительность команды; burn down chart; Say:Do Ratio; количество заведенных багов за спринт и многие другие. На выходе стоит обратить внимание на две вещи: Обратная связь заинтересованных лиц Все реакции обрабатывает владелец продукта и заносит в бэклог в виде новых приоритезированных юзерстори. Обновленный бэклог продукта По итогам Review может сместиться даже вектор развития продукта. Это свидетельствует о том, что продукт инспектируется и адаптируется под изменение рынка и ожидания пользователей. 4 шага к успешному Sprint Review: советы и лайфхаки Как сделать так, чтобы спринт ревью проходил с максимальной полезностью для всех участников проекта? Вот несколько лайфхаков из моего опыта. Шаг №1. Проводите демо Зачем демонстрировать результаты спринта клиентам? Объясню на бытовом примере. Представьте собаку. Представили? Мысленно опишите ее. Возможно, вы представили породу, размер, длину шерсти. Возможно, это абстрактная собака, а, возможно, та, которую вы лично знаете. Сколько бы раз я ни проводила это упражнение, люди описывают разных собак. Кто-то представляет мелких дворняжек, кто-то лабрадоров, кто-то свою личную собаку, и еще множество вариантов. Вы удивитесь, но с пониманием требований клиента командой происходит та же история: каждый представляет свою «собаку». Чтобы понимания требований клиента и команды синхронизировались, нужно проводить демо (наглядная презентация работы, выполненной за спринт). Бывают и обратные ситуации: когда клиент видит, какой продукт получается, он осознает, что это не совсем то, чего он хотел. Это не значит, что команда все поняла неправильно. Часто уже готовый функционал приводит к мысли о том, как можно улучшить конечный продукт. Шаг №2. Объясните команде, что изменения – это прекрасно У моих команд бывали случаи, когда после реализации и демонстрации функции клиент решал, что она все же не нужна, и просил ее убрать. Команда расстраивалась, особенно разработчики, которые непосредственно участвовали в ее создании. Это можно понять – столько труда, времени и желания сделать классный функционал стоит за этим кодом, который одним махом решили удалить. Но именно желание сделать классный функционал становится решающим аргументом, который мы можем использовать, чтобы утешить разработчиков и повернуть их внимание с разработки одной функции на создание продукта. Донесите до команды, что мы делаем продукт и хотим, чтобы он был удобен пользователям и востребован на рынке. Поэтому если пользователи дали отзыв, что им удобнее обращаться с продуктом как-то иначе, это достаточно хороший повод прислушаться. Шаг №3. Готовьтесь заранее Готовиться к ревью нужно по нескольким направлениям: Продумывайте, кто может привнести на встречу конструктив, а кто будет вне контекста и зря проведет время. Заранее присылайте повестку встречи, чтобы люди могли сами оценить полезность своего присутствия. Пропишите сценарий демо и проведите репетицию. Очень обидно, если результаты работы всей команды не получится оценить по достоинству из-за некачественной связи, отсутствия сценария и хаотичного переключения экранов. Еще печальнее, когда баги всплывают прямо на демо: функционал не работает, модератор теряется и от стресса забывает, о чем хотел рассказать. Собирайте метрики. Возможность оперировать измеримыми результатами позволит сделать корректные выводы и наметить пути для улучшения. Шаг №4. Пригласите на встречу конечных пользователей продукта В моей практике был проект, в котором на демо приходил владелец продукта и больше никого. Получалось, что он смотрел функционал, который уже видел по ходу спринта. В наших демо не было смысла, ведь по их итогу ничего не менялось. Однажды мне пришло в голову спросить, можно ли пригласить на демо конечных пользователей продукта. Сам продукт на тот момент еще не был в открытом доступе. Но уже была сформирована фокус-группа, которая общалась с владельцем продукта, но не общалась с командой. В следующий раз демо проходило уже с участием конечных пользователей, и эффект был потрясающим: команде было невероятно интересно и приятно видеть энтузиазм людей по поводу функционала, который мы разрабатывали. Стало очевидно, что он улучшит их жизнь и облегчит работу. Слова «спасибо» от людей, которые ждут результата твоей работы, очень мотивируют. После этой встречи у команды больше не возникало вопросов, зачем владелец продукта просит внедрить те или иные изменения. Реальные пользователи аргументированно объясняли, как проходит их работа и зачем, к примеру, нужно объединить два экрана в один. Что в итоге Работа Scrum-мастера похожа на работу дирижера. Нужно тонко чувствовать людей, тональность и мелодию процесса разработки. Каждая команда – это неповторимый оркестр, а каждое собрание – это важная репетиция основного концерта. Sprint Review – один из аккордов, который при серьезном подходе со стороны всех участников сделает мелодию более гармоничной. Научитесь умело организовывать людей, понимать аудиторию, хорошо владеть профессией и в результате получите прекрасную музыку. Клиент будет доволен конечным продуктом, пользователи получат решение проблемы, а команда будет гордиться своим вкладом.

No items found.