Должен ли технический долг быть запланирован как функция или рутинная работа (или ошибка)?

19

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

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

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

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

Ребекка Скотт
источник
1
Связанные: softwareengineering.stackexchange.com/q/348860/110531
Джонсон

Ответы:

17

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

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

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

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

Стивен А. Лоу
источник
1
Ага. Фантастический ответ. Я не думал об историях, написанных с моей точки зрения, но это имеет смысл для меня, особенно как внутреннего разработчика, так как я тоже должен выступать в роли клиента. Благодарность!
Ребекка Скотт
5
Я должен не согласиться. С этой точки зрения практически все - даже настройка моей IDE или получение учетной записи SCM - будет выглядеть как «фича» ...
Петер Тёрёк
2
@ Питер - Не обязательно. Настройка вашей IDE - неизбежное усилие; другие вещи просто попадают в категорию «вещи, которые делаются». Но замена фреймворка или чего-то совсем другого. Бизнес должен знать о том, что вы собираетесь делать, о пользе для них, и им должно быть разрешено расставлять приоритеты по сравнению с другими работами. Таким образом, это особенность во всех смыслах.
фунтовые
4
Конечно, функция должна повысить ценность продукта? Рефакторинг не добавляет такой ценности, он просто позволяет разработчикам работать над этим более эффективно и снижает вероятность ошибок. Добавленная стоимость от такого рода вещей будет вторичным эффектом. Называя эту функцию, можно было бы просто представить ее так, чтобы владелец продукта мог с большей вероятностью расставить приоритеты.
Дэвид Нил
3
-1 Невыполнение вашей работы никогда не должно рассматриваться как особенность.
Мартин Уикман,
18

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

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

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

Яап
источник
Согласился с этим. Это не особенность, потому что это не забота клиента, и это не то, о чем они должны знать (по моему опыту, когда клиент осознает, что вы реорганизуете / исправляете код для погашения технического долга, они считают, что это тратит впустую свое время). и деньги , так что лучше они вообще не знают, что ты это делаешь).
Уэйн Молина
+1 Это тоже правильная точка зрения на проблему. Мне нравится рассматривать его как функцию, потому что тогда он прекрасно вписывается в обычные механизмы планирования и отслеживания. Это сложно объяснить клиенту.
Стивен А. Лоу
+1, это единственный ответ, который проясняет, как вычисление скорости станет неправильным, когда вы будете считать «задачи технического отдела» особенностями.
Док Браун
15

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

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

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

Петер Тёрёк
источник
1
Я согласен с тем, что рефакторинг по устранению технического долга должен быть включен, когда этого требует новая функция, но я читаю этот вопрос как погашение технического долга независимо от того, требуется ли ему новая функция или заранее.
Стивен А. Лоу
@ Стивен, это тоже была моя интерпретация. Привязка технической окупаемости долга к соответствующей функции - это всего лишь предложение.
Петер Тёрёк
3

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

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

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

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

Уэсли ван Опдорп
источник