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

Некоторые мысли:

• Они на самом деле не ошибки, они ничего не ломают
• Пользователи ничего не запрашивали, так как это низкоуровневая реализация, которая не влияет на них, но это облегчит долгосрочную разработку
• Если вы определяете функции как истории, которые повышают ценность для пользователей, хорошо, а) они этого не делают, поскольку пользователи не видят никакой прямой выгоды, но затем б) они делают, потому что они делают возможным будущее развитие / обслуживание, которое действительно добавляет ценность просто не сейчас

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

Это особенность.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

Он определен и запланирован и отслеживается, как и любые другие функции.

Если реализация этой функции не является достаточно ценной (для клиента или для вас) для ее планирования, это другая проблема.

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

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

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

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

Я бы назвал это задачей по обслуживанию. В любом проекте разработки существует множество таких задач, как настройка среды разработки / тестирования, сборка тестовых данных, объединение ветвей в SCM и т. Д. Ни один из них не наблюдается непосредственно пользователями, но невыполнение их регулярно приводит к ускорению разработки затраты и уровень ошибок в долгосрочной перспективе.

Тем не менее, может не потребоваться обрабатывать их как отдельные задачи (если только они не огромны, и / или вы не обязаны внедрять новые функции прямо сейчас). Обычно может быть лучше просто определить, когда новая функция требует рефакторинга / написания юнит-тестов и т. Д., И обрабатывать их как часть разработки новой функции. Это может быть легче объяснить как руководству, так и конечным пользователям (если они хотят знать, на что вы тратите свое время). Обновление: Кроме того, это помогает разработчикам сосредоточиться на значении рефакторинга. Ради рефакторинга легко увлечься рефакторингом, поэтому ИМХО полезно сосредоточиться на том, какую дополнительную ценность приносит конкретный рефакторинг с точки зрения клиента.

Я бы назвал это improvement.

Не ошибка, потому что ничего не сломано.

Ни особенность, потому что рефакторинг не будет просьбой вашего клиента. (потому что это работает!).

Большинство систем отслеживания поддерживают тип проблемы improvementпо умолчанию, в противном случае вы, вероятно, можете изменить типы в любом случае.