在开发的时候你碰到了一段散发着恶臭的代码，“这段重构有点棘手，要想把这段代码整理干净至少要花半天时间，打个patch的话马上就能解决，手里的故事不能再拖了，但是这段代码也不能放过。”，和Pair商量后，你们创建了一个Dev Card，在上面清清楚楚的写下了这段代码问题所在和大致的重构步骤。然后飞快的完成了故事。
几天以后，你对项目经理说有一段代码需要彻底清理，项目经理皱着眉头看了看计划:
”现在它还能工作，不是么？“
”是，可是…“
“这边还有两个bug，优先级很高，客户已经抱怨了。高优先级的必须首先完成，等我们有时间的时候再清理它吧，怎么样？”
“嗯，好吧…”
这段代码于是继续留在代码库里。这样的故事每天都发生着，”有时间“自然是从未发生过，有一件事开始折磨项目经理：不知道从什么时候开始团队开发速度变慢了，项目计划变的更紧了。
这些遗留下的Dev Card, 就是一笔笔技术债，和其他的债务一样，团队需要为此支付”利息“：这些未完成的技术任务会让添加功能、修复缺陷变得越来越困难，团队的开发速度也因此不断下降。
开发人员总在抱怨没有足够的时间来让代码闪闪发光，为什么Dev Card不能像像Story Card一样受到重视呢？ 关键是Story Card姓$，每个人凭直觉便能认识到它们的价值。而Dev Card的价值一方面不是真金白银那般来得直接，另一方面只有专业的开发人员才能意识到它们的价值，然而对于$的迟钝却阻碍了开发人员认识到Dev Card究竟所值几何，在和项目经理、客户的谈判中如何能不败落？
和Story Card一样，如果我们对于Dev Card做出合理的估算，就可以在使用burn down图跟踪Story的同时，使用burn up图来跟踪每个迭代所增加的Dev Card的点数，结合开发速度的下降，所有人都可以直观的认识到Dev Card的价值，进而帮助项目经理和客户做出更合理的，符合可持续发展的计划。
那么对于Dev Card的大小不清楚怎么办？ Spike，和Story一样，需要对技术问题进行摸索，做到对工作量心中有数，这样的Spike，一方面可以帮助团队找到最佳的解决方案，另一方面可以使用Dev Card的估算值与开发经理、客户share understanding.
与Story Card的处理原则一样，如果一张Dev Card过大，开发者需要将其变为若干较小，便于估算的Dev Card，从而使团队有能力小步的完成这些技术任务。
这些想法是上周的回顾会议中得到的，也将在项目进行实践，如果可以的话，希望能把项目中的一些数据发布出来，相信会非常有趣。
Yup. I haven’t seen any concrete data about something like this myself. It would be very interesting to see this.
有几个小问题：
1.分析和估算重构方案大概有多大的工作量呢？
2.将重构方案形成文档有多大的工作量呢？
如何将此部分工作和商业价值相结合，更好的向业务部门解释？
1. 采用和Story通常的估算方式，由于Dev通常对于Dev Card需要进行的步骤比较了解，做出的估算更精确。
2. 重构方案形成文档的代价可以忽略不计，Dev Card上提及的重构方案更多的是描述出当前代码中的问题，大致的思路，并非每一个类甚至每一个方法，更多的是备忘录的作用。
3. 关于价值方面，有几个数据很有意思，第一是每个iteration完成的Story的点数，第二是完成这些点数会新增加多少点Dev Card（技术债），第三是团队Velocity的变化。从短期看，可以存在技术债增加的同时，Velocity增加的情况，这就像在银行中借钱会短期增加你的购买力一样，但是如果技术债不偿还，从长期看，Velocity一定会下降。当我们把时间轴放长，我们会得到这样的数据：
总共的技术债： x点
Velocity的变化： -y点
-y点的数据可能是当前迭代和上个release的平均迭代速度比较得出的结果（也可以是上个月，上个季度）
Dev可以以此数据向项目经理解释x的技术债会导致每个迭代损失y点数的速度，每点的价值大家都很清楚，这样，我们可以将x点技术债的价值通过velocity的的变化可视化出来。
把Tech Debt单独建卡基本上都不会排到计划之中。我一般是把重构放到下一个相关的story里做。而且不要声张，声张了就被发现了。在开始做story之前，先把重构做完再开工做story。重构这种东西，喊得越想，越没有人敢去做。声音越小，做起来越容易。两个人在story开工之前，把要做的重构列一个check list，然后一个个勾掉就足够了。
同意，小的重构是可以这么作的，有时候我们所做的操作比较大，严格的讲已经不是重构，而是重写了，这样的工作量很难放在任何的一个故事中，如果不作，这写不良结构又不断的托我们的后腿，所以迫切需要这样一种和manager share understanding 并讨价还价的方法
1.技术债产生的原因？
2.如何减少技术债？
3.技术债肯定会存在的，有无合适的方法在不影响进度的情况下偿还技术债？比如增加“偿债人”——另一个开发人员？
我觉得做为项目经理必须考虑到这种情况的出现，实际上这种情况确实是在增加项目开发的风险。
>>产生的原因
没有时间，没有时间修改这部分的代码
没有危机感，作了一个As Simple As Possible的设计之后，只注意了现在的设计是可用的，没有留意到设计中潜在的问题。
没有能力，意识不到这段代码的问题
没有意愿，意识到了，懒得作。
>>如何减少技术债
这是个有意思的话题，要想减少技术债第一必须要能识别技术债，第二，必须要能够有决心消除技术债。
对于第一点，我个人觉得目前比较有效的方案是，定期举行一个会议，在这个会议中，每个开发人员提出目前代码库中什么地方最让他觉得恶心，大家一起看看，有没有思路进行改进，然后记录下这个问题。
对于第二点，正是我这篇博客试图表达的思想。
你的问题很好，多交流。