Shell's Home

Aug 5, 2010 - 1 minute read - Comments

代码过程管理

无论是做产品,还是做项目,无可避免的要碰到代码过程管理的问题。这个问题主要是平衡产品质量,生产速度,开发投入的关系,并且设法增大乘积。

通常来说,质量,速度,投入三者是互相矛盾的,有的时候还要加上风险。质量越高,速度越快的生产过程,其投入也就越高。但是这几个关系并非单纯的并行替换关系,正如人月神话中所说的,人月这个单位暗示人和月是可以互换的,但实际不是。项目中主要碰到的问题往往是,在控制质量不变的情况下,增加投入不能提高速度。在控制速度不变的情况下,减小投入不能降低质量。偶尔,我们想方设法找到了一个方式,能够很好的满足质量-速度-投入的三元平衡,但是时灵时不灵,这就是风险元的问题了——通常情况下我们不会碰到。

作为平衡三者的起点,你不能从项目/产品的开始才考虑这个问题,而是必须从招聘/团队组建的时候开始考虑。一个不靠谱的人就会破坏整个团队,所以在招聘的时候,保持宁缺勿滥的思想。通常的项目/产品并不需要一堆天才,你只要一堆能够良好执行计划的员工就行了。靠谱的人的有几个要点,能够比较好的进行沟通,良好的计划制定和执行能力,大量的编码训练。有的时候我们往往以工作年限来衡量一个人的编码训练,实际上编码训练和工作年限并没有特别大的关系。好的项目经理/产品经理,应该能从编码的设计和实现中,嗅出编码训练的程度。

坚持只招聘合适的员工,事实上是以增大人力资源成本来解决速度-质量问题。因此通常只会被用于质量不变的情况下,增加投入提高速度。不幸的是,要实行这个步骤往往必须在项目的开始前进行计划。因此项目的正确做法不是添油战术,而是减油战术。减油战术的要点是强迫项目使用它天然能够使用的最多人手,使得项目处于人力资源相对充足的状况。再设法控制每个人的工作周期,不要让被分配的人做和他特质不吻合的工作。例如程序员完成编码后,不要让他去做文档/测试的工作,而是提前撤出项目。如果项目顺利,逐步撤出闲置人手组建其他项目,并保持项目依旧按时完成。如果项目仍旧不顺利,至少我们做到了我们能做的最快速度。

同时,这个战术涉及另外一个问题。我们都知道,越大的项目,需要的人手越多。而越多的人手,每增加一个人所能提高的效益就越低(俗称边际降低)。因此,平衡三者的另一个要点是切分项目,使其拥有完美的边界。假如一个系统,我们需要12个人工作半年。我们将其切分为两个相对独立的子系统,每个系统分配六个人,通常不用半年就可以完成项目。正常来说,项目所需资源随着复杂度增加往往是三次方到四次方增加的,而项目切分有助于使得前者随着后者线性增加。切分的优劣只取决于其边界的清晰程度和复杂程度,和需要多少人手,如何分配等等问题皆不相关。

在完成上述几个步骤后,我们就拥有了完美完成项目的一个起点,合适的成员,充足的人手,适当的边界。不幸的是,通常我们无法做到这么完美,成员不都是适当的,人手是不足的,需求是修改的,所以边界是模糊的。那么在整个代码过程中,我们依旧有一些可以做的事情。

首先是问题的早期发现,方法是代码规范,单元测试和交叉检查(cross check)。通常建议将人手编排成水平交错的一个环,按照顺时针方向,由一个人检查另一个人的代码。交叉检查有三重目的,帮助新手学习编码,抑制不小心和设计失当所造成的错误,当其中一个人无法工作时有人可以接手其工作。虽然这将付出一定时间,但是可以比较好的在前期发现和控制问题。同时,按照逆时针方向,编写另一个人的单元测试代码。单元测试有助于隔离问题范围,减少在实现中的一些无聊问题。

其次是问题的快速沟通和持续聚焦在工作上。强迫所有人每天写下需要处理的问题(todo list),然后每天勾掉解决的问题。这方法可以从各种GTD书籍上看到细节。同时,每天召开快速例行会议。将当天处理掉的todo list,碰到的问题和解决方法读出来。快速的沟通方便在早期把握员工的心不在焉,同时也方便其他员工发现潜在的可能与其相关的问题。

最后就是快速文档和后期文档相结合。在项目过程中提倡快速文档,即写下某个问题相关的精简描述和姓名,方便其他人联系你即可。在项目完成后,逐步补充文档,细化条目成为完整的文档。