У меня есть вопрос о обзорной (демонстрационной) встрече спринта от Scrum, которая проводится в конце каждого спринта в сочетании с репозиториями и рабочим процессом git.
Я знаю, что незавершенная работа спринта будет помещена обратно в бэклог продукта. Это очень просто с кодовой базой, потому что незавершенная работа находится в отдельной функциональной ветке.
У меня возникает вопрос, когда владелец продукта отклоняет полностью созданную пользовательскую историю, которая уже объединена с веткой релиза.
Например, при создании страницы управления пользователями могут быть пользовательские истории про «просмотр всех пользователей» и «создание нового пользователя». «Создать нового пользователя» нуждается в обзоре, потому что это единственный способ добраться туда и иметь возможность его использовать. Таким образом, в процессе разработки обзорная пользовательская история разрабатывается и объединяется с веткой релиза, затем разрабатывается пользовательская история «создать нового пользователя», которая также объединяется обратно с веткой релиза.
Итак, когда владелец продукта отклоняет пользовательскую историю «создать нового пользователя»:
Как мы можем удалить только эту функциональность из ветки релиза?
Скрам — это совместный процесс между тремя определенными ролями (владелец продукта, скрам-мастер и команда разработчиков). У вас возникли проблемы с внедрением Scrum, потому что ваш владелец продукта не сотрудничает на протяжении всего процесса.
Скрам-команда (включая Владельца продукта) коллективно соглашается с целью спринта для каждого спринта, а также с определением готовности для историй или элементов невыполненной работы по продукту (PBI), которые будут выполнены в рамках спринта.
Работа считается «сделанной» или «не сделанной» в соответствии с этими критериями. Не существует рамочного положения об отклонении работы, отвечающей согласованным критериям. Тем не менее, есть возможности для многократного улучшения продукта, а также для проверки и адаптации процесса.
Обзор спринта — это место, где можно продемонстрировать всю работу, выполненную в течение текущего спринта. Это формальная церемония в рамках Scrum , имеющая конкретную цель:
Обзор Спринта проводится в конце Спринта для проверки Инкремента и адаптации Бэклога Продукта, если это необходимо. Во время Обзора Спринта Скрам-команда и заинтересованные стороны обсуждают, что было сделано в Спринте. Основываясь на этом и любых изменениях в Бэклоге Продукта во время Спринта, участники совместно работают над следующими вещами, которые могут быть сделаны для оптимизации ценности. Это неформальная встреча, а не статусная встреча, и презентация Инкремента предназначена для получения обратной связи и содействия сотрудничеству.
Обзор спринта не предназначен для принятия приращений или отчета о состоянии. Это просто способ совместной работы над дальнейшими действиями в рамках проекта, а также возможность участия заинтересованных сторон в итеративном проектировании и реализации продукта.
Владелец Продукта должен участвовать в Спринте. Он должен быть постоянно доступен для разработчиков, участвовать в ежедневных встречах и тесно сотрудничать со скрам-мастером, чтобы отслеживать выгорание, определение готовности и другие показатели, связанные с определенной целью спринта.
Если незавершенная работа не приведет к достижению определенной цели спринта, Владелец продукта может сотрудничать с командой, чтобы изменить объем или объявить досрочное прекращение и вернуться к планированию спринта. Во время Ретроспективы Спринта Владелец Продукта и Команда Разработки также должны сотрудничать, чтобы улучшить качество пользовательских историй, добавить приемочное тестирование в каждый Спринт как часть Определения Готовности или внести другие изменения в процесс, чтобы снизить вероятность неудачных Спринтов в будущее.
Однако работа, которая завершена в соответствии с определенной целью спринта и соответствует согласованному определению выполненной работы , считается завершенной независимо от того, что первоначально предполагалось владельцем продукта или заинтересованными сторонами.
Если приращение не соответствует цели спринта или определению готовности, работа не может быть отклонена. Тем не менее, обзор спринта — это место, где можно разработать, как итеративно двигаться к тому, чего на самом деле хотят заинтересованные стороны, теперь, когда они увидели, как то, о чем они просили, было реализовано. После этого Ретроспектива Спринта — это место, где можно определить улучшения процессов или коммуникаций, которые помогут Скрам-команде и организации лучше сотрудничать в будущем.
Стоит сделать шаг назад и подумать о том, чтобы в первую очередь избежать проблемы.
Обзор спринта не должен быть первым разом, когда Владелец продукта видит функциональность, созданную во время спринта. Их следует знакомить с функциональностью при первой же возможности, часто это происходит, когда она еще находится в стадии разработки . Обычно обзор спринта больше ориентирован на стейкхолдеров, которые не могут проводить столько времени, сколько Владелец Продукта проводит с командой.
Если Владелец Продукта наблюдает за созданием историй, маловероятно, что он вдруг отклонит их на обзоре спринта.
Также стоит отметить, что одна из целей создания пользовательских историй — сделать их независимыми друг от друга. Если история «создать нового пользователя» зависит от истории «просмотра всех пользователей», вы всегда будете подвергаться риску возникновения такой проблемы.
Хранить истории в секрете сложно, но возможно. Один из способов сделать это — использовать что-то, называемое «переключатель функций», где функцию можно включать и выключать независимо от других функций. В приведенном вами примере об отклонении истории «создать нового пользователя» можно использовать переключатель функции, чтобы отключить эту функцию, пока владелец продукта не будет доволен ею.
Наконец, если вы используете систему управления версиями, такую как Git, то можно многое сделать, чтобы откатить конкретную фиксацию функции, не выбрасывая другой код. Вы можете захотеть иметь ветки функций для каждой истории, которые регулярно объединяются с веткой релиза. Если возникает такая проблема, вы откатываете все коммиты в ветке релиза, связанные с историей, и откатываете все другие коммиты, которые произошли за это время.
Однако такой подход к управлению исходным кодом сложен, и в первую очередь предпочтительнее избегать этой проблемы.
Было бы очень полезно узнать, почему Владелец Продукта отвергает данную функцию так поздно. Ответ Барнаби Голдена в правильном направлении, но я не думаю, что он идет достаточно далеко.
Владелец продукта — это человек, который расставляет приоритеты по эпопеям, фичам и историям в Бэклоге Продукта. Теперь между историями могут быть технические зависимости, и команда должна убедиться, что владелец продукта признает это. Это происходит на собрании по планированию спринта, когда элементы извлекаются из бэклога продукта и помещаются в бэклог спринта.
Если история «просмотреть всех пользователей» имеет высокий приоритет, но имеет технические зависимости от истории «создать пользователя» с более низким приоритетом, то имеет смысл сначала реализовать зависимость, чтобы можно было доставить желаемую историю. Команда Разработки должна работать с Владельцем Продукта, чтобы обеспечить понимание этих технических зависимостей.
В ответе Барнаби Голдена также обсуждались переключатели функций, о которых недавно много писал Мартин Фаулер . Но я не думаю, что они должны быть необходимы, если ваш процесс является совместным. Команда Разработки и Владелец Продукта должны прийти к единому мнению относительно содержания Бэклога Спринта до начала Спринта. Затем на протяжении всего спринта владелец продукта должен следить за тем, чтобы проделанная работа соответствовала потребностям заинтересованных сторон. Не должно быть причин для удаления или добавления возможности переключения функции в конце спринта. Если необходимо переключение функции, это следует выяснить задолго до обзора спринта.
Томас Оуэнс
Тодд А. Джейкобс