Как вы модифицируете доставленную пользовательскую историю?

TL;DR

Если вы представили пользовательскую историю в предыдущем спринте, а затем вам нужно изменить ее в новом спринте, что вы делаете?

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

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

Рефакторинг против новой работы и доработки

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

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

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

Всегда есть исключения

Из каждого правила есть исключения. Вот некоторые примеры:

1. Новая работа, необходимая для текущей цели спринта, может быть обнаружена во время спринта и может оправдать досрочное завершение и возврат к планированию спринта.
2. Выплата технического долга, когда у вас нет других историй, над которыми можно было бы работать, — это хорошее использование времени.
3. Попутный рефакторинг (или даже улучшение) чего -либо во время работы над готовой функцией на практике часто допустим, но это очень тонкая грань, которая часто приводит к бритью яков и отнимает ресурсы у историй, которые команда взяла на себя в течение спринта. Не делай этого.
4. Истории, которые не находятся на критическом пути к Цели спринта, могут быть заменены, изменены или исключены из области действия при активном сотрудничестве Владельца продукта без запуска досрочного прекращения. Это продвинутая техника, которая может легко привести к неприятным последствиям, поэтому не полагайтесь на нее.

Scrum и другие agile-фреймворки не должны быть смирительной рубашкой. В системе достаточно гибкости, чтобы приспособиться к вариациям и крайним случаям. Тем не менее, команде действительно необходимо освоить базовые принципы, прежде чем пытаться нарушать такие принципы, как YAGNI , или обходить формальные средства контроля области действия, иначе она рискует превратить свою структуру в ScrumBut или его вызывающий сбой эквивалент.