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


12

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

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

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

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

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

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

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

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

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

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

Ответы:


5

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

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

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

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

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


4

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

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

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

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

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


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

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

1

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

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

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

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


0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.