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

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

来源：来自提问帖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的水平部分的人。