在开发的时候你碰到了一段散发着恶臭的代码，“这段重构有点棘手，要想把这段代码整理干净至少要花半天时间，打个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，从而使团队有能力小步的完成这些技术任务。
这些想法是上周的回顾会议中得到的，也将在项目进行实践，如果可以的话，希望能把项目中的一些数据发布出来，相信会非常有趣。
博文
