产品开发总是伴随着技术负担，因为并非所有功能都可以在为实现此功能分配的时间内高效完成。这种方法有其优点和缺点，但是如果不消除技术负担，则向产品添加新功能将变得越来越困难。
如果您对我们如何学习使用技术债务感兴趣，那么欢迎光临。
一点理论
什么是技术债务？技术债务-如果不做，则会造成用户看不见的损坏（功能的手动配置，不可读/丢失的日志）。
用户看不到还清技术债务的结果，但是它将提高产品的质量（可靠性，安全性，开发速度，稳定性）。
每个人都走近他
当产品是新的时，那些。他几乎没有债务。因此，我们没有针对属于技术债务的任务的某种排名机制，就像开发人员自己的热情之外没有其他偿还机制一样。童子军原则与我们有关。实际上，事情并不那么乐观。
所有任务都是随机收集在一个板上的，很难理解特定任务的重要性。
. , — , - , .
- , , . - , , - 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), . , - , .
现在，除了将任务带入冲刺之外，一些小任务在其他任务的框架内也被关闭。
所以？
我们处于描述的最后阶段。现在就得出其成功的结论还为时过早，最主要的是要有一种机制，它可以使团队和产品受益。