O desenvolvimento do produto é sempre acompanhado de dívida técnica, pois nem todas as funcionalidades podem ser feitas de forma eficiente no tempo alocado para a implementação desta funcionalidade. Essa abordagem tem seus prós e contras, mas se a dívida técnica não for extinta, então adicionar novos recursos ao produto se torna cada vez mais difícil.
Se você está interessado em saber como aprendemos a trabalhar com dívida técnica, seja bem-vindo ao cat.
Um pouco de teoria
O que é dívida técnica? Dívida técnica - o trabalho, se não executado, incorre em danos invisíveis para o usuário (configuração manual de um recurso, logs ilegíveis / ausentes).
O resultado da quitação da dívida técnica não é visível para o usuário, mas aumentará a qualidade do produto (confiabilidade, segurança, velocidade de desenvolvimento, estabilidade).
Todo mundo pega o que está mais perto dele
Quando o produto é novo, aqueles. ele tem poucas dívidas. Por isso, não tínhamos algum tipo de mecanismo de classificação para tarefas que caíam em dívida técnica, assim como não havia mecanismo de reembolso além do próprio entusiasmo dos desenvolvedores. O princípio do escoteiro diz respeito a nós. Na verdade, as coisas não estavam tão animadas.
Todas as tarefas foram coletadas aleatoriamente em um quadro, onde era difícil entender o quão importante era uma tarefa específica.
. , — , - , .
- , , . - , , - code-review ( !)
- , , , , .
4 :
— . (0 — , , 5 — )
— . ( , , , ) (0 — , 5 — )
( , , ) (0 — , 5 — )
(0 — , 5 — )
story points, .
, TechDebt Value, ( , ).
X, Y Z. , — , X Y Z .
, , .
— . .
? , , .
, , .
?
, , story point — . , , , .
— , , 10-15 . - , .
.
, - . ( capacity), . , - , .
Agora, além do fato de que levamos as tarefas para o sprint, algumas pequenas tarefas são encerradas dentro da estrutura de outras tarefas.
Então?
Estamos na última das etapas descritas. É muito cedo para tirar conclusões sobre o quão bem sucedido ele é, o principal é que existe um mecanismo, ele funciona e beneficia a equipe e o produto.