Product development is always accompanied by technical debt, because not all features can be done efficiently in the time allocated for the implementation of this feature. This approach has its pros and cons, but if the technical debt is not extinguished, then adding new features to the product becomes more and more difficult.
If you are interested in how we learned to work with technical debt, then welcome to cat.
A bit of theory
What is technical debt? Technical debt - work, if not done, incurs damage invisible to the user (manual configuration of a feature, unreadable / missing logs).
The result of paying off technical debt is not visible to the user, but it will increase the quality of the product (reliability, safety, development speed, stability).
Everyone takes what is closer to him
When the product is new, those. he has little debt. Because of this, we did not have some kind of ranking mechanism for tasks that fall into technical debt, just as there was no mechanism for repayment, other than the developers' own enthusiasm. The Boy Scout Principle is about us. In fact, things were not so rosy.
All tasks were randomly collected on one board, where it was difficult to understand how important a particular task was.
. , — , - , .
- , , . - , , - 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), . , - , .
Now, besides the fact that we take the tasks into the sprint, some small tasks are closed within the framework of other tasks.
So?
We are at the last of the described stages. It is too early to draw conclusions about how successful it is, the main thing is that there is a mechanism, it works and benefits the team and the product.