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

Деякі думки:

• Вони насправді не помилки, вони нічого не ламають
• Користувачі нічого не просили, тому що низькорівнева реалізація не впливає на них, але це спростить довгострокову розробку
• Якщо ви визначаєте функції як історії, які додають цінність для користувачів, а) вони не є, оскільки користувачі не побачать ніякої прямої користі, але потім б) вони роблять це, оскільки вони роблять можливим розвиток / обслуговування, що надає додаткові значення, просто не зараз

Я не вирішую, чи потрібно насправді виконувати роботу, чи коли її планувати, я просто те, що мені знати, як я повинен називати технічну заборгованість у своєму інструменті управління проектами, і чому.

Це особливість.

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

Він визначається і планується і відстежується, як і будь-які інші функції.

Якщо реалізація цієї функції недостатньо цінна (для клієнта чи для вас), щоб вона коли-небудь була запланована, це вже інша проблема.

(Погашення) технічної заборгованості не є особливістю , оскільки клієнт не має кваліфікації приймати рішення . Найголовніше, що клієнт не може визначитися, коли він закінчиться, і крім того, клієнт повністю залежить від вас, щоб пояснити переваги. Ви вважаєте, що існує технічна заборгованість, і ви вирішуєте, як це виправити і коли ви це зробите. Технічний борг впливає на вашу (майбутню) швидкість, а не на сприйняття клієнтами програмного забезпечення. Якби не було боргу, ви були б більш продуктивними. А швидкість, яку ви вимірювали дотепер, неправильна, оскільки вам слід було витратити більше часу, щоб зберегти код у формі.

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

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

Завдання ІМХО усунути технічну заборгованість, безумовно, не є особливістю. Його можна перенести у відділ "помилок", але це буде розтягувати визначення термінів, оскільки знову ж таки це не призводить до змін поведінки, що спостерігаються користувачами.

Я б просто назвав це завданням з обслуговування. У будь-якому проекті розробки є багато таких завдань, як налаштування середовища розробки / тестування, збирання тестових даних, об'єднання гілок в SCM і т.д. витрати та рівень помилок у довгостроковій перспективі.

Хоча, можливо, не потрібно впоратися з ними як окремими завданнями (якщо вони не є величезними, та / або зараз ви не відчуваєте жодного тиску для впровадження нових функцій). Зазвичай може бути краще просто визначити, коли нова функція вимагає тестів на рефакторинг / запис блоків тощо, і обробляти їх як частину розробки нової функції. Це може бути простіше пояснити як керівництву, так і кінцевим користувачам (якщо вони хочуть знати, на що ви витрачаєте свій час). Оновлення: Крім того, це допомагає розробникам зосередитись і на значенні рефакторингу. Легко захоплюватися рефакторингом заради рефакторингу, тому орієнтуватися на те, яку додаткову вартість приносить конкретний рефакторинг з точки зору клієнта, IMHO корисно.

Я б назвав це ан improvement.

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

Ні особливість, оскільки рефакторинг не буде запитом вашого клієнта. (бо це працює!).

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