Я работаю в проектной команде из 4 разработчиков, включая меня. Мы долго обсуждали, как справиться с дополнительной работой, которая возникает в ходе одного рабочего элемента.
Эта дополнительная работа - это обычно вещи, которые немного связаны с задачей, но не всегда необходимы для достижения цели предмета (это может быть мнение). Примеры включают, но не ограничиваются:
- рефакторинг кода, измененного рабочим элементом
- код рефакторинга рядом с кодом, измененным элементом
- реорганизация большей области кода вокруг билета. Например, если в элементе вы меняете одну функцию, вы понимаете, что теперь весь класс можно переделать, чтобы лучше учесть это изменение.
- улучшение пользовательского интерфейса в только что измененной форме
Когда этой дополнительной работы мало, мы не против. Проблема в том, что эта дополнительная работа вызывает существенное расширение предмета за пределы первоначальной оценки характерных точек. Иногда пункт с 5 пунктами фактически берет 13 пунктов времени. В одном случае у нас было 13 пунктов, которые в ретроспективе могли составить 80 или более.
В нашем обсуждении есть два варианта, как справиться с этим.
Мы можем принять дополнительную работу в том же рабочем элементе и списать ее как неправильную оценку. Аргументы для этого включали:
- Мы планируем "заполнение" в конце спринта, чтобы учесть подобные вещи.
- Всегда оставляйте код в лучшей форме, чем вы его нашли. Не проверяйте половину работы.
- Если мы оставим рефакторинг на потом, это сложно запланировать и, возможно, никогда не будет сделано.
- Вы находитесь в лучшем ментальном «контексте», чтобы справиться с этой работой сейчас, так как вы уже глубоко в коде. Лучше убрать это с пути сейчас и быть более эффективным, чем потерять тот контекст, когда вы вернетесь позже.
Мы рисуем линию для текущего рабочего элемента и говорим, что дополнительная работа уходит в отдельный тикет. Аргументы включают в себя:
- Наличие отдельного билета позволяет получить новую оценку, поэтому мы не лжем себе о том, сколько на самом деле очков, или не должны признать, что все наши оценки ужасны.
- Спринт "padding" предназначен для неожиданных технических проблем, которые являются прямыми препятствиями для выполнения требований билета. Он не предназначен для дополнительных предметов, которые просто «приятные».
- Если вы хотите запланировать рефакторинг, просто поместите его в начало списка.
- Мы не можем должным образом учесть этот материал в оценке, поскольку он кажется несколько произвольным, когда он возникает. Рецензент кода может сказать, что «те элементы управления пользовательского интерфейса (которые вы на самом деле не изменяли в этом рабочем элементе) немного сбивают с толку, вы тоже можете это исправить?» это похоже на час, но они могут сказать: «Хорошо, если этот элемент управления теперь наследует от того же базового класса, что и другие, почему бы вам не переместить весь этот (сотни строк) код в базу и не переписать все это» , каскадные изменения и т. д.? И это занимает неделю.
- Он «загрязняет место преступления», добавляя в билет несвязанную работу, делая наши первоначальные оценки характеристик бессмысленными.
- В некоторых случаях дополнительная работа откладывает регистрацию, вызывая блокировку между разработчиками.
Некоторые из нас сейчас говорят, что мы должны принять решение об отсечке, например, если дополнительный материал меньше 2 FP, он идет в том же билете, если он больше, сделайте его новым.
Поскольку мы используем Agile всего несколько месяцев, каково мнение всех более опытных ветеранов Agile здесь о том, как с этим справиться?