Спринт предмет занимает больше времени, чем ожидалось. Что нам делать?

Что нам делать, если элемент в схватке занимает больше времени, чем ожидалось? Я спрашиваю об этом, потому что я заметил элементы, которые разработчики пытаются завершить, поскольку это намного сложнее, чем первоначально предполагалось.

В такой ситуации мы должны

• убрать предмет из спринта обратно в каталог продукции, чтобы мы могли соответствовать графику спринта?
• перейти к более легкому спринту и оставить проблемный спринт до конца графика
• Обоснуйте при рассмотрении спринта, почему элемент не может быть завершен в текущем спринте заинтересованным лицам?

Как мы можем избежать такой ситуации в будущем? Это из-за отсутствия предварительного планирования или мы не пытались разбить элемент спринта на более мелкий элемент?

С «предметом», я полагаю, вы имеете в виду «задание».

Планирование оптимизма в программном обеспечении так же стара, как и само программное обеспечение. Хорошая вещь о схватке в том, что вы скоро столкнетесь с ней и создадите ее видимость: именно поэтому скорость команд основана на прошлых данных, а не на будущих оценках.

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

Что нам делать, если элемент в схватке занимает больше времени, чем ожидалось?

Предполагая, что под элементом вы подразумеваете историю, в конце спринта вы, как правило, возвращаете ее в очередь продукта (и, вероятно, планируете ее на следующую итерацию). Команда получает за это ноль очков в текущей итерации.

Другой вариант, если история достаточно большая, - это разрезать ее вертикально . Например, историю «поиск по каталогу продуктов» можно разделить на «поиск по категории» и «полнотекстовый поиск», но не на «форму поиска» и «результаты поиска».

Как мы можем избежать такой ситуации в будущем?

Нет простого прямого ответа на это. В Scrum вы делаете спринт-ретроспективы на каждой итерации, где вы обычно обсуждаете подобные вещи с командой. Есть много разных возможностей:

• У команды или некоторых членов команды плохая неделя
• Конвейеры вашей команды работают горизонтально (например, backend-> frontend-> QA)
• Истории слишком велики по ошибке
• Команда «золотит листы» историй, добавляя дополнительную работу, которая не является строго необходимой для завершения истории.
• Истории очень большие по природе, вам нужны более длинные спринты (маловероятно)
• Команда оценивает истории неточно (бессвязно)
• У проекта много технических долгов / гнилой кодовой базы, и ваша скорость слишком низкая
• Вы не измеряете и не оцениваете свою способность к спринту правильно (или вообще).

и т. д.

Вы говорите, что не закончите, но это не плохо, это просто данные.

«Познакомьтесь с графиком спринта» - не цель. Ваша цель - завершить истории пользователей. Временная шкала - это всего лишь инструмент, который поможет вам измерить и узнать, сколько работы вы можете выполнить в спринте.

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

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

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

Команда должна попытаться выполнить задачу как можно лучше, а затем в ретроспективе обсудить стратегии по этому вопросу в будущем. Если команда довольно плохо знакома с использованием Scrum, то это может быть частью определения начальной скорости команды. Некоторые команды могут подумать, что они могут набрать 20 очков, а некоторые команды могут набрать 60 очков, суть в том, насколько последовательно можно набирать одинаковое количество очков в каждом спринте.

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

То, что мы обычно делаем в нашей компании, когда задача начинает занимать больше времени, чем ожидалось, делит ее на более мелкие задачи.

Таким образом, мы не возлагаем всю вину на разработчика за медлительность, но мы также признаем, что задача была разработана неправильно.

Другая вещь может состоять в том, чтобы назначить задачу другому члену вашей команды разработчиков, чтобы ваш покойный разработчик не зарылся в дыру. И если задача действительно критическая, то XP может быть решением.