В Scrum следует ли разделять резерв на функциональное и техническое отставание или нет?

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

• Во-первых, мне кажется более логичным иметь отдельное техническое отставание, в которое сами разработчики могут добавлять чисто технические элементы, такие как: мы могли бы улучшить производительность в этом методе, в этом классе не хватает некоторой технической документации, ... Имея одно отставание, все разработчики всегда должны проходить через владельца продукта, чтобы их темы были добавлены в очередь, что кажется дополнительной, ненужной работой для владельца продукта.
• Во-вторых, если у вас есть владелец продукта, который фокусируется только на чисто функциональных элементах, чисто технических элементах (таких как отсутствующая техническая документация, код, который разрушается и должен быть подвергнут рефакторингу), классы, которые всегда создают проблемы во время отладки, потому что у них нет стабильная основа и должна быть реорганизована, ...) всегда заканчиваться в конце списка, потому что «они не обслуживают клиента напрямую». Имея отдельное техническое отставание и время, затрачиваемое в каждом спринте на эти чисто технические элементы, мы можем функционально улучшать приложения, а также поддерживать их работоспособными внутри.

Каков наилучший подход? Одно отставание или два?

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

Я хотел бы добавить свой голос тем, кто рекомендует одно отставание для каждого продукта. Создание еще одного невыполненного задания является рациональным ответом, но на самом деле оно просто избегает основной проблемы: почему владелец продукта не отдает приоритет техническим элементам над элементами функций? Вы должны сосредоточиться на решении этого, а не работать вокруг него. Вы можете , например, использовать технику 5 Whys , чтобы попытаться понять суть вещей.

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

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

То, на что вы ссылаетесь, обычно называют «техническим долгом». Иногда бывает трудно понять, как работа по техническому долгу вписывается в процесс разборки так же, как это делают дефекты.

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

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

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

Даже «чисто технические» предметы должны иметь практическую ценность для пользователей (и, следовательно, для владельца продукта), чтобы иметь право на отставание в спринте. Ваша задача - объяснить преимущества этого для владельца продукта и убедить его / ее в добавленной стоимости, которая оправдывает стоимость. И этот процесс заставляет вас самостоятельно обдумать эти проблемы и выбрать технические изменения, которые принесут наибольшую пользу проекту с наименьшими усилиями.

Я согласен со всеми ответами выше. В разгар коммерческой реальности ПО будет продолжать отдавать предпочтение функциональным историям, а не техническим. Часто к разочарованию команды. Команда должна воздерживаться от технических историй без какой-либо пользовательской ценности (кому небезразлична оптимизация, если скорость не является проблемой?) И научиться видеть некоторые другие технические задачи, подразумеваемые функциональными историями. «Определение выполненного» также играет большую роль. Остальные функциональные истории остаются в резерве для приоритетов.

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

Например, рефакторинг кода: должен быть сделан, когда это приносит пользу разработке продукта. Не раньше (команда не должна предполагать, в каком направлении будет развиваться продукт) и не позднее, когда он уже превратился в технический долг. Пересмотр дизайна также может быть частью DoD.

Я согласен с MelR. Если есть что-то «техническое», нам нужно посмотреть, почему мы это делаем - или даже каковы краткосрочные и долгосрочные причины и следствия (для пользователя)?

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

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

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

Тогда есть тема «оставить вещи немного лучше, чем мы их нашли», чтобы уменьшить долгосрочный технический долг, и можно ли это сделать как часть небольших историй в каждом спринте, не оказав слишком большого влияния на более широкий проект?

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

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

Если ваша история о создании экрана входа в систему, например, вам придется рассмотреть вопрос о создании базы данных, если она еще не создана.

Я не вижу проблемы в создании с ПО задач, в которых ИТ-команда является пользователем. Если задача может быть понята ПО и может быть оценена с точки зрения ценности для бизнеса, то да, у вас есть способ создать своего рода технические истории. Вы просто используете систему.