敏捷开发一千零一问系列之三十七:进度与质量的冲突

本文是敏捷开发一千零一问的第三十七篇。(栏目总目录

来源:来自提问帖http://blog.csdn.net/cheny_com/article/details/7564388#reply20楼

问题:

我有一个问题,众所周知敏捷实施中,每个task的时间是团队自己定的,才能保证团队有效的高质量完成,这是不是和客户要求的deadline冲突了呢,团队自己定的时间如果过多就会影响准时的交付,而如果不影响交付,必然会产生加班以至于质量问题。在实际中怎么去协调这个呢?

回答:

总则上讲,就是牢记一句话:进度是质量之敌,质量是进度之友

因进度而损失的质量是不可挽回的,很多人说以后再改好就是了,但我见到最多的就是要末不改,要么扔了重新来。

因质量而损失的进度是可以挽回的,因为后期(等等会重新定义“后期”)没有Bug,代码又能复用,如果还比别人慢,就没道理了。

但具体做的时候,还是要注意一些事情的

1. 快速收益

刚才提到一个词,叫做“后期”,这是个很矛盾的词,因为一定要把“后期”“提前”。也就是说,不能为了质量而质量,无视进度的需求而盲目搭建庞大的底层库和平台。

在松结对编程系列(http://blog.csdn.net/column/details/agiledeptcheny.html)的L型代码结构的几篇文章中提到,底层库(L的水平部分)必须是为了上层应用(L的垂直部分)而出现的。

真正的高手,如果给他一个很急的活,让他“随便做”,做完之后,会发现代码很漂亮,完全符合“不急的活”的标准。这是因为在高手眼中,高质量的就是快速的,两者都是一样的,否则就不称之为高手。

高手做完“很急的活”之后会说这么几句话:“因为……,所以我没考虑……的情况;”“另外,性能上……”;“还有就是……”而不能这么说:”这堆代码你看不懂是因为……“”为了打字快点,这个变量被叫做a……“”以后这段代码可能会拆成10个函数……“

因此实际上,编写高质量的底层库不花费额外的时间;真正花费时间的是“需求镀金”,就是做了额外的事情,本系统,或者现在,不需要的内容

2. 管理整个团队

高手如此,新手就不然了,他们是真的会干出萝卜快了不洗泥的活的。

这个在松结对编程系列(http://blog.csdn.net/column/details/agiledeptcheny.html)中有比较多的描述了,就是让高手监督、指导新手的工作。

这里边可能有几个误区:

2.1 高手很忙,有时间监督、指导新手吗?

招聘徒弟这件事情,必须是由高手驱动的,不能塞给他一个徒弟。而高手去招聘徒弟的时候,必须招收一个自己每天付出1小时的指导时间,新手能回报2小时的工作量的徒弟,否则就别招。如果这两者都做不到,可能是师傅水平还不够高(没有高到能用新人的水平),或者徒弟招的不合适(没有”好“——不是”高“——到能被师傅带的水平)。

2.2 新手天天”复用“高手的代码,自己学不到东西怎么办?

我见过的工作了很久但水平奇烂的程序员(包括95~01年这六年中间的我),无外乎两种情况:一,自己埋头编程,从来没见过什么是好代码;二、人生三大憾集于一身(遇良师不学,遇好友不交,遇良机不握)

高手在试用期期间(徒弟是他找来的),要迅速判断新手是一还是二。如果是一,利用调用代码的机会传授一下编程方法;如果是二,送回社会以待天时。

2.3 新手拖累高手怎么办?

还是2.1的思想,高手要以完成项目为目标,而不要以带徒弟为目标。因此,应该循序渐进地招徒弟,培养徒弟。

换言之,师傅招徒弟这件事情,很像L型代码结构。没有一个徒弟是为了培养而招聘来的,都是为了更快地完成工作才找来的;否则就是团队级别的”需求镀金“了。

3. 保持专业性

人类天生尊重专家,而蔑视奴才。

若我们的专业性说服自己:”保证质量才是快速完成这个项目的真正方法“,那么就要坚持它;若不能坚持,则说明我们还没有真正把客户的价值放在首位,而只是把”自己当下千万不要担当责任“放在首位了。

毕竟客户,以及老板,最后的目标都是快速拿到好的产品,而不是聘用一堆唯命是从的奴才。

所以如果我们能在最终(这个最终,也是和之前的”后期“一样,不要遥遥无期的那种,要快)证明我们是正确的,自然而然他们就会被说服了——因为按他们的进度蛮力编码的团队最后都陷入泥潭,唯有这个开始有点固执己见的团队的产品是最好的,还有比这更能说明问题的吗?

我还没见过因为坚持专业性被开掉的人,但是的确见过无视客户的进度,只为自己心目中的”理想“而工作的人被开掉的。后者就是完全将质量和进度对立起来,忽视L的垂直部分而过度追求L的水平部分的人。

敏捷开发一千零一问系列之三十七:进度与质量的冲突

上一篇:【笔记】go语言--(Slice)切片的概念


下一篇:AOP-操作术语