2009年4月26日星期日

跟踪团队的技术债

在开发的时候你碰到了一段散发着恶臭的代码,“这段重构有点棘手,要想把这段代码整理干净至少要花半天时间,打个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,从而使团队有能力小步的完成这些技术任务。

这些想法是上周的回顾会议中得到的,也将在项目进行实践,如果可以的话,希望能把项目中的一些数据发布出来,相信会非常有趣。

6 条评论:

Pavan 说...

Yup. I haven't seen any concrete data about something like this myself. It would be very interesting to see this.

Xiaoming 说...

有几个小问题:
1.分析和估算重构方案大概有多大的工作量呢?
2.将重构方案形成文档有多大的工作量呢?
如何将此部分工作和商业价值相结合,更好的向业务部门解释?

kai 说...

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的的变化可视化出来。

taowen 说...

把Tech Debt单独建卡基本上都不会排到计划之中。我一般是把重构放到下一个相关的story里做。而且不要声张,声张了就被发现了。在开始做story之前,先把重构做完再开工做story。重构这种东西,喊得越想,越没有人敢去做。声音越小,做起来越容易。两个人在story开工之前,把要做的重构列一个check list,然后一个个勾掉就足够了。

胡凯 说...

同意,小的重构是可以这么作的,有时候我们所做的操作比较大,严格的讲已经不是重构,而是重写了,这样的工作量很难放在任何的一个故事中,如果不作,这写不良结构又不断的托我们的后腿,所以迫切需要这样一种和manager share understanding 并讨价还价的方法

edison.kuo 说...

1.技术债产生的原因?
2.如何减少技术债?
3.技术债肯定会存在的,有无合适的方法在不影响进度的情况下偿还技术债?比如增加“偿债人”——另一个开发人员?