Adicionei algumas histórias de usuários que endereçam alguma dívida técnica ao meu quadro do Pivotal Tracker. Devo considerá-los como características (mantendo meu nível de velocidade) ou como tarefas / bugs (diminuindo minha velocidade)? Entendo que, a longo prazo, não fará nenhuma diferença se eu fizer uma ou outra consistentemente, mas toda vez que adicionar uma história de dívida técnica, tenho que tomar a decisão.

Alguns pensamentos:

• Na verdade, eles não são insetos, eles não quebram nada
• Os usuários não solicitaram nada, pois a implementação de baixo nível não os afeta, mas facilitará o desenvolvimento a longo prazo
• Se você definir características como histórias que agregam valor para os usuários, bem a) eles não como os usuários não verá qualquer benefício direto, mas, em seguida, b) que eles fazem, porque eles fazem o futuro desenvolvimento / manutenção possível que não agregam valor, apenas não agora

Não estou decidindo se realmente devo fazer o trabalho, ou quando agendá-lo, apenas o que saber o que devo chamar de dívida técnica em minha ferramenta de gerenciamento de projetos e por quê.

É uma característica.

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

É definido, agendado e rastreado como qualquer outro recurso.

Se a implementação desse recurso não for suficientemente valiosa (para o cliente ou para você) para que ele possa ser agendado, isso é um problema diferente.

(Reembolsar) a dívida técnica não é um recurso , porque o cliente não está qualificado para tomar decisões sobre ela . Mais importante ainda, o cliente não pode decidir quando terminar e, além disso, depende totalmente de você para explicar os benefícios. É seu julgamento que existe uma dívida técnica, e cabe a você decidir como consertá-la e quando terminar. A dívida técnica está afetando sua velocidade (futura), não a percepção do cliente sobre o software. Se não houvesse dívida, você seria mais produtivo. E a velocidade que você está medindo até agora está errada, pois você deveria ter levado mais tempo para manter o código em forma.

Eu acho que você deve comunicar isso com seu cliente, mas não é algo que está sob seu controle. Você pode dizer algo como isto: 'Estamos pegando alguns atalhos até agora, que precisaremos corrigir. Isso significa que nossa velocidade diminuirá um pouco nas próximas iterações, mas isso é para garantir que tenhamos software sustentável a longo prazo. '

O trabalho contínuo no recurso do cliente também ajudará a manter seu foco na melhoria do software para o cliente, em vez de se tornar algum tipo de exercício acadêmico para encontrar o design perfeito (isso é algo com o qual pessoalmente luto algumas vezes).

IMHO uma tarefa para eliminar a dívida técnica definitivamente não é um recurso. Ele poderia ser inserido no departamento "bug", mas estenderia a definição de termos, pois novamente não resulta em mudanças de comportamento observáveis ​​pelos usuários.

Eu chamaria isso de tarefa de manutenção. Em qualquer projeto de desenvolvimento, existem muitas tarefas, como configurar o ambiente de desenvolvimento / teste, montar dados de teste, mesclar ramificações no SCM etc. Nenhuma delas é observável diretamente pelos usuários, mas a falha em realizá-las regularmente resulta em maior desenvolvimento custos e taxa de erros a longo prazo.

Talvez não seja necessário manipulá-los como tarefas separadas (a menos que sejam enormes e / ou você não esteja sob pressão para implementar novos recursos no momento). Geralmente, pode ser melhor apenas identificar quando um novo recurso requer refatoração / gravação de testes de unidade etc. e manipulá-los como parte do desenvolvimento do novo recurso. Pode ser mais fácil explicar aos usuários finais e de gerenciamento (se eles querem saber em que você gasta seu tempo). Atualização: Além disso, ajuda os desenvolvedores a se concentrarem no valor da refatoração também. É fácil se deixar levar pela refatoração por causa da refatoração, portanto, focar no valor agregado que uma refatoração específica traz da perspectiva do cliente é IMHO útil.

Eu chamaria isso de improvement.

Não é um bug, porque nada está quebrado.

Nem um recurso, pois a refatoração não será uma solicitação do seu cliente. (porque funciona!).

A maioria dos sistemas de rastreamento suporta um tipo de problema improvementpor padrão; caso contrário, você provavelmente pode alterar os tipos de qualquer maneira.