Обработка «связанной» работы в рамках одного гибкого рабочего элемента

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

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

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

Когда этой дополнительной работы мало, мы не против. Проблема в том, что эта дополнительная работа вызывает существенное расширение предмета за пределы первоначальной оценки характерных точек. Иногда пункт с 5 пунктами фактически берет 13 пунктов времени. В одном случае у нас было 13 пунктов, которые в ретроспективе могли составить 80 или более.

В нашем обсуждении есть два варианта, как справиться с этим.

1. Мы можем принять дополнительную работу в том же рабочем элементе и списать ее как неправильную оценку. Аргументы для этого включали:

   • Мы планируем "заполнение" в конце спринта, чтобы учесть подобные вещи.
   • Всегда оставляйте код в лучшей форме, чем вы его нашли. Не проверяйте половину работы.
   • Если мы оставим рефакторинг на потом, это сложно запланировать и, возможно, никогда не будет сделано.
   • Вы находитесь в лучшем ментальном «контексте», чтобы справиться с этой работой сейчас, так как вы уже глубоко в коде. Лучше убрать это с пути сейчас и быть более эффективным, чем потерять тот контекст, когда вы вернетесь позже.

2. Мы рисуем линию для текущего рабочего элемента и говорим, что дополнительная работа уходит в отдельный тикет. Аргументы включают в себя:

   • Наличие отдельного билета позволяет получить новую оценку, поэтому мы не лжем себе о том, сколько на самом деле очков, или не должны признать, что все наши оценки ужасны.
   • Спринт "padding" предназначен для неожиданных технических проблем, которые являются прямыми препятствиями для выполнения требований билета. Он не предназначен для дополнительных предметов, которые просто «приятные».
   • Если вы хотите запланировать рефакторинг, просто поместите его в начало списка.
   • Мы не можем должным образом учесть этот материал в оценке, поскольку он кажется несколько произвольным, когда он возникает. Рецензент кода может сказать, что «те элементы управления пользовательского интерфейса (которые вы на самом деле не изменяли в этом рабочем элементе) немного сбивают с толку, вы тоже можете это исправить?» это похоже на час, но они могут сказать: «Хорошо, если этот элемент управления теперь наследует от того же базового класса, что и другие, почему бы вам не переместить весь этот (сотни строк) код в базу и не переписать все это» , каскадные изменения и т. д.? И это занимает неделю.
   • Он «загрязняет место преступления», добавляя в билет несвязанную работу, делая наши первоначальные оценки характеристик бессмысленными.
   • В некоторых случаях дополнительная работа откладывает регистрацию, вызывая блокировку между разработчиками.

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

Поскольку мы используем Agile всего несколько месяцев, каково мнение всех более опытных ветеранов Agile здесь о том, как с этим справиться?

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

Agile плохо справляется с последними, потому что не задумывался как ответ на эти в основном технические проблемы и проблемы.

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

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

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

Красный, Зеленый, Рефакторинг. Это объем отдельного рабочего элемента. Напишите провалившийся набор тестов, охватывающий область изменений, укажите минимально необходимую сумму для прохождения теста, затем выполните рефакторинг, чтобы он соответствовал стандартам кодирования, в то же время проходя тесты. Все три из этих шагов являются обязательными; вы не можете закодировать решение, пока не определите проблему; если вы будете выполнять рефакторинг при написании строки кода, вы непременно будете нарушать YAGNI, но если вы не станете позади себя и рефакторинге после прохождения тестов, по определению вы несете технический долг что вам в конечном итоге придется погасить.

Учитывая это определение и его соблюдение, 5-указатель, который оказывается 13-указателем, был ошибочной оценкой. То, что вы рассматриваете как рефакторинг, вероятно, больше похоже на реструктуризацию; Вы должны были реорганизовать довольно значительную часть кодовой базы, чтобы новые функции были включены понятным и понятным способом. Это обычно указывает на неспособность команды понять общий будущий путь развития, что привело к тому, что что-то было реализовано очень просто на предыдущей итерации, когда в конечном итоге требовалось быть очень ТВЕРДЫМ. Лучшее взаимодействие между BA и PM, которые знают, что дальше в отставании, и командой разработчиков, которая в основном сосредоточена на текущем спринте, может смягчить это. С другой стороны, эта история выявила большой объем технического долга, понесенного в прошлом развитии, и это просто догнало команду. Более совершенные процессы проверки кода, в дополнение к лучшему концептуальному знанию шаблонов проектирования и общего будущего пути проекта, могут помочь уменьшить такие случаи.

Следует иметь в виду, что рефакторинг - это «неидеальная» работа. В Agile SCRUM задачи оцениваются в «идеальных часах»; то есть, количество часов, потраченных наполовину на написание совершенно нового кода, который никогда не существовал и расширяет базу возможностей проекта. 8-часовой день разработчиков может реально иметь только 5 идеальных часов; иногда вы можете рассчитывать на 6, особенно в «натянутом» проекте, где команда действительно напевает. Рефакторинг или возврат назад и внесение изменений, которые не влияют на функциональность проекта, но которые улучшают кодовую базу другими способами, являются неидеальной работой, как и планирование, проектирование, коммуникация, проверка, перерывы или технические простои. Помимо технических простоев, неидеальная работа важна, но не делает успехов в глазах владельца продукта.

Таким образом, при условии, что рефакторинг не удваивает фактические потраченные часы, следует ожидать определенного объема работы по рефакторингу, когда вы оцениваете в идеальных часах. Скажем, потому что я не знаю точно, как калибруется шкала очков вашей команды, что 5-указатель эквивалентен одной идеальной неделе разработчика или примерно 25 идеальным часам. Эта цифра 5, которая превратилась в 13 (более двух недель разработки в одном и том же масштабе), является поводом для некоторого ретроспективного анализа того, что стало причиной сложности. Возможно, кодовая база не нуждалась в таком большом количестве рефакторинга, как это было на самом деле, возможно, большой объем технического долга накопился без ведома команды, которая должна была быть решена, чтобы заставить работать новые функции,

В альтернативной вселенной давайте представим, что 5, рассчитанное в идеальных часах, стало 7 (~ 35 часами) на основе фактических часов, потому что вам потребовалось 10 часов дополнительного рефакторинга, чтобы поместить новый код и некоторые предыдущие биты в правильно сформированный шаблон. дизайн архитектуры. В этом случае дополнительное количество находится в пределах «разрыва» между идеальными и общими часами в течение количества дней разработчиков, которые должна была занять история. Так что, как менеджер проекта, я бы назвал 5, который стал 7-ой, разумной оценкой и пошел дальше.

Очки истории - это оценка относительной сложности данной пользовательской истории. Похоже, вы используете сюжетные очки, чтобы сказать, что это займет X человеко-дней / часов. Вместо этого стремитесь к двум целям

1. Разбивайте истории до тех пор, пока они не окажутся в согласованном диапазоне (3, 5 или 8 баллов)
2. Предположим, что история включает в себя любой рефакторинг, необходимый

Со временем это даст вам базовую линию для скорости. Каждая 5-балльная история не займет столько же времени, сколько остальные, но средняя скорость за спринт (сколько сюжетных баллов может набрать команда) будет постоянной.

Беспокойство о том, сколько времени займет конкретная история, контрпродуктивно. Оценки усредняются только по объему историй одинакового размера (IE 5 указатель может занять немного больше времени из-за рефакторинга, но вы получаете выгоду от этих усилий на связанных).

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

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

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