软件开发和团队管理

软件开发和团队管理

2大伤痛

软件开发了这么多年，也带了很多的团队，真的没什么心得，只

能说有点感慨。

软件开发到底难不难，这真的是一个问题，刚刚毕业的时候，觉

得做软件乐趣很大，困难很很小，结果呢，到现在还没有一个项目令

自己满意。既然不难做，但为什么就是做不好，这真的是一个揪心的

问题。

软件团队到底需要多少人，这已经不能称为一个问题，而是一处

伤痛，初出茅庐的时候也曾经认为一人一机就是软件，但遥望印度千

人团队，真心不知道他们在干嘛，为什么要那么多人，难道他们都很

苯？

如果说有什么心得•，还不如说我心中的2大伤痛，以搏一笑：

1.软件只需要开发就可以完成，团队只需要开发就可以组成。

2,软件出了问题是可以改的，而且不难改

软件就是开发

也许大家会笑，当事实上大部分人都会被这2个问题伤到，而且

伤了好多年。

软件只需要开发，这个看上去是一个很浅显的道理.，就像古龙式

的大侠那样，杀人就是用刀划过敌人的身体，就这么简单；是的，软

件开发就是把代码编写出来，编译运行，交给客户，的确就这么简单。

细细品位这第一个伤痛，我发现这个问题其实是看似偶然中的必然；

软件的最小组成就是代码，有了代码就有了软件的实体，有了实体就

可以认为完成了软件，这个是非常实际的想法。加上老板最关注的是

项目的成本和时间，那么为开发团队增加开发人员看似是最“有效经

济”的方法，一人开发一周，那么2个人最不济开发3天应该够了

把一一大家都会如此思考。

当然，软件开发还真的是神奇的所在，它的一个神奇之处就在于,

无论如何，软件的生产过程还是可以完成的，无论如何，在一定的时

间和努力之后，软件还是诞生了，他的诞生时候似乎是必然的，不可

阻挡的，那么我们还在担心什么呢。

软件没有失败

有人说，软件完成仅仅是万里长征第一步,还差的远呢,客户的要

求还远远没有结束.真正的修改还在后面.是的，软件开发的第二个

神奇之处就是，软件可以通过不断的修改来弥补以前的错误，不管你

提交的软件是100分还是20分，它都可以通过不断的修改而继续存活

下去，可以这样说，只要还能修改，软件就没有失败，那我们还担心什

么呢.

2大神奇法则

这里,我们引出了软件开发的2大神奇法则：

1.软件只需要开发就能进行,并且基本都能完成.

2.软件只要修改就可以存活,而且很少最终失败.

首先，我们必须感谢这2个神奇的法则，它大大降低了软件开发

的入行门槛，使得很多团队和个人，即使懵懂幼稚，即使身无长处，亦

能昂首踏入这个行业，以各种各样的姿态开始自己的职业生涯.

其次，这2个法则也深深的伤害了很多团队和个人，在进入这个行业

若干年以后,很多人发现,这2个法则所营造的就是一个迷魂阵,一个

无底洞；软件总能完成却从未结束;软件不会失败却从未成功；困惑

与当下的实践,迷茫于未来的发展.

我在担心什么

我在担心什么，其实我也说不太清楚；

首先,那些必然完成的软件没有给我和我的团队任何美妙的感觉,

做的好不好,是否可以算成功,这个问题几乎没有人可以回答,那么自

然也就没有答案了.

其次,永无止境的修改,最终的结果只能是伤痛，日积月累的疲惫

感，不断受挫的成就感,加上毫无希望的未来.几乎没有人会喜欢这

种"永不言败”的感觉，团队的崩溃和软件的摆烂,几乎是必然的结果.

最后，梦想和发展，几乎已成奢望，遥望欧美令人羡慕的先进开发方

式，展望自己30岁以后的发展空间，总是觉得那么遥不可及,对职业

生涯的希望已经到了破碎的边缘.

寻找突破

如何突破，无非是自身寻求突破和效仿先进模式；自身寻求突破

太过理想化,如果自己有这个能力，要突破早突破了，何必等到现在.

效仿他人先进模式是必然的，当也绝不能盲从：别人的先进模式是大

学毕业水平，而我们刚刚走出幼儿园，怎么学，学什么，并没有想象那

么简单.

不去了解先进模式是闭门造车,必然失败.

不根据本身团队情况是盲目改革,必然失败.

软件开发有其规律,最小模式绝对不是"两把菜刀闹革命”，没有办法

获得最低资源要求,就不要改革.

如果你的改革不能形成有效的积累模式，就不要改，改革为的是将来

不断壮大而不是现在解决一时疑难，没有发展通道的改革还不如不

改.

CMMI2,1还是1.5?

首先说个老实话,软件开发是没有什么所谓最小模式的；如果可以我

并不希望去尝试所谓的最小模式；现在开开1-2万的二手小车是没

办法,并不代表我愿意一辈子开这种车.

CMM13认证要求最少有20人参加，其实是给出了一个硬性的指标,要

保证CMMI3所能达到了质量要求，大部分流程域是不能裁剪的，那么

就要保证有足够的资源去做正确的事情.

也许是我没有赶上好时节，我所经历的项目和团队，还真的没有单个

20人的规模,不过团队是小但也是要活下去的，不管如何,生活还必须

继续，软件还是要完成.

也许小团队一定要上CMMI3还是好高鹫远了，那么我们来看看CMMI2,

但CMMI2也不是省油的灯，里面竟然已经包括了QA管理，配置管理，

需求管理和度量管理，这些东西已经不是5个人以下的团队能够运

作的了，这4项工作我认为至少增加3-5人的辅助管理量，加上与之配

套的开发团队成员，整个规模保守估计应该在10T5人以上，说老实

话，对于一般的软件公司，这个规模也有点勉为其难.

怎么办，再减？CMM1初级是完全“懵懂”模式,几乎所有团队都可以

达到,这里我就不加说明了，那么CMMT2似乎已经就是最底限度，小于

10人的团队真的与CMMI无缘吗?那些过程域真的是一个都不能再剪

吗？这个CMMI专家们是没有答案的，唯一的途径，只能靠自己去摸索

一就像怀揣了卜2万还想开车的吊丝们，唯一的办法就是自己到二手

车市场去淘.

于是乎,对这个介于CMMI2和CMMI初级之间的”最小模式”的探索开

始了.

首先我必须说明我个人的3点看法：

1.“最小模式”是我个人容忍的最底限度,如果这个都达不到,我个人

认为你不是在做软件,而是在玩软件；也许有其他的高手也认为我的”

最小模式”是在玩软件，同理.

2.“最小模式”的软件质量必然低于CMMI2标准,软件开发没有侥幸,

减价不减量的好事情从来都是没有的，当然我个人认为“最小模式”

的质量还是可以接受的，否则我就是误人子弟了.当然有可能只是我

接受，大家还需要自行判断.

3.“最小模式”是给现行的，迷茫的，一些小团队们一个建议，一个起

点,我还是希望大家能从这里起飞而不是终止,正如我开头说的那样,

没有人愿意一辈子做所谓的”最小模式”，人总是要有理想的，・2万

的车刚工作开开是可以理解的，一辈子开是要被人鄙视的.

2条主线,4个步骤

如果说真的存在一个最为简单的模型，我认为软件的开发过程必须存

在2条主线和4个步骤。

2条主线就是管理和技术。

4个步骤就是需求,设计,开发和测试。

2个主线是双轨，4个步骤是车厢。无轨车子无法行驶，无车一一这

就不谈了，这个就没意义了。

这里需要说明的是，4个步骤仅仅是软件执行过程的内容，其关注点

是软件开发的生命周期而不是项目，项目的运作还需要更多的考虑，

就像火车的行驶，需要出站和进站的过程，行驶过程还需要监控，这

样才能保证安全。项目的运作我们暂且不提，我们就说软件开发，看

看我们最少需要点什么内容。

管理

管理是什么，如雷贯耳到不需要解释了；项目管理，开发管理，团队管

理，这些名词都是耳熟能详.我认为3个人以上的团队就需要管理，

不说别的,就是让3个各自为战的程序员能够在规定的时间，规定的

技术做出规定质量的软件，这个就很像一个神话故事了.一句话,管

理者不可或缺，目前软件的规模越来越大,孤胆英雄或者喋血双雄式

的开发团队已经非常少见了，那么绝大部分团队都必须存在“管理者”

这个穿针引线的角色.但很多场合下，大家对管理者都有偏见,大家都

认为这是一个闲职,工作量估计比我们的公务员还低，不就是发个通

知，买个晚饭的人吗.所以大部分管理都是以兼职的身份而存在，最为

常见的是，技术高手顺便管理一下即可.我想说的是，管理的工作其

实非常的繁重,也非常的关键,管理对软件的质量，时间，团队,能力和

最终成功与否,起到了至关重要的作用，

管理不但要有,而且要专职,没有专职管理的团队就是没有司机的车,

我真的建议你不要上去.

技术

技术,这个太简单了，没技术能做软件吗，团队有大有小，但里面的开

发人员谁没有2把刷子.所以,技术是最不是问题的问题.真的是这样

吗.

这里,我需要提出另外一个概念一构架,构架是什么，软件开发者都有

自己的看法,大家也知道构架师是一个了不起的岗位，也成为了很多

软件人的梦想.构架是什么，我的理解就2个字:驾驭.能驾驭的技术

就是构架,不能驾驭的技术仅仅是理论.构架代表的不仅仅是技术本

身，而是对技术的理解,领悟,经验和积累，就像开客车的司机,他不但

要有特殊的驾照,还需要有多少年，多少路的客车经验,如果什么都没

有仅仅是会开车,这里面的风险就足够毁灭一次长途旅行.

构架和驾驭有3方面的问题需要考虑：

首先是深度和广度：构架必须涵盖项目开发所有的问题,请注意是所

有，任何开发中的问题最好都已经有一个成熟的方案来应对.这也许

是一个很高的要求，但我们必须要明确这是我们构架发展的方向.比

如说，这个项目某个问题没有好的解决方案，那么下一个项目就有了，

若干项目以后,构架的深度和广度就能有很大的提高.其实不管是什

么等级的问题，就必须有成熟的方案而不是留给开发人员自我发挥,

比如Web项目，不仅仅是性能,安全,报表这些高级问题需要解决方案,

就一些基础问题如转页，Session,上传等等都必须有成熟的思路;这

就是广度和深度和含义；很多人热衷与遇到问题找谷歌百度,而且谷

歌百度的确也找的到临时方案，这里暂不提临时寻找方案对项目进度

造成的冲击,我就说一点，很多梦寐以求的构架帅，难度就是谷歌白度

一分钟就能取代的吗,其中奥秘大家一想便知.

其次是统一：这个是很明显的问题，构架必须统一，开发团队里面的

每个人,其技术路线都是不同的,对构架的理解也不同，但一个项目的

构架必须统一，统一才能驾驭和控制，统一才能保证项目质量的水平

一致.构架的广度对统一有很大的影响，广度越大,每个人自我发挥的

余地就小，统一的部分就多，构架就越容易驾驭.这里多说一句，很多

新手程序员对既定的构架压缩自己的发挥空间非常的反感,我这里要

诚心的告诉这些新人,构架定义良好的团队是你的福音，一个让新人

随意发挥的团队才是真正的坑爹，切记.

最后是积累和培训：构架绝对不是只存在于当下项目，当下团队的产

物，没有一个构架师可以在他的第一个项目就形成一个"惊天地泣鬼

神”的构架，构架需要在大量的项目中不断的积累和提高;另外构架绝

对不是一人或者一群人的专属，离开了特殊的人或者群体，构架应该

依然有强大的生命力，这就是培训I,构架应该便于向各种各样的后人

传授,传授的越快越便捷,构架的成熟度越高.

需求

需求就是要明确做什么，明确了做什么才能作对；但软件是一个很神

奇的东西，不知道要做什么就开始做了这个几乎是经常发生的事情。

不知道要做什么也能做完这个也不是什么稀奇的事情。

需求不仅仅是一个业务的东西，更是一个共识和契约；需求不可能穷

尽，客户想要的一定比我们能做的更多，而开发团队则要求一个稳定

而合理的范围。

面上的需求虽然也是需要点技巧的，但大部分人还是能够理解并交流

的，这些需求大多流于客户需求范畴，就是搞清楚客户想要什么样的

软件。而需求的问题常常发生在2个方面：可实现性和稳定性。说

白了，需求最终还是要技术拍板能不能做，另外还需要客户和开发团

队达成共识，做到什么范围为止；不知道大家有没有发现，可实现

性和构架有很大的关系，而稳定性则需要博弈，这里就需要管理者的

协调，当然这里还有商务问题，这个就不在本文的范围以内了。

设计

设计就是我们应该怎么做，我们的软件是什么风格的，什么套路的。

开发者经常忽视设计而相对重视需求，原因很简单，开发者不能决定

需求，但可以决定设计，因为设计是技术范畴的东西，但这就恰恰是

设计的问题所在。

第一个问题是设计的合理性，这是大家常常忽略的问题，因为合

理性不仅仅是技术问题还是需求问题，大多数项目中，客户的需求常

常延伸到设计，尤其是界面和用户体验。所以原型确认被越来越多的

提上议事日程，在需求阶段就加以解决，甚至作为需求的身份出现。

这是一个问题.

另外一个问题是设计的统一，因为设计是技术范畴，那么开发者

几乎人人可以设计，比如增删改页面，毕业生都会做，但大家的风格

必然各不相同，但一个软件必须有统一的设计，而且要统一所有的细

节，这个问题就必须在设计阶段给予解决。很多时候会出现形似神不

似的问题，细节设计问题防不胜防，造成软件大问题不多，小问题遍

地的尴尬局面，面对严格的客户，这样的软件难称专业。想到这里就

不难去理解，小日本为什么要写那么罗嗦的设计文档了。

开发

开发是大多数软件人的看家本领了，但事实上大部分人并不是太会

编程，或者在学会编程以前就去做其他事情了。

开发注意2个问题：自律和自检。

首先看你有没有规范，就是你写的代码有没有套路，最明显的标

记就是注释。这里面的问题大部分人都有自己的心得，我就点到为止。

第二个问题是开发的自检，流行的方法是CodeReview和单元测

试，CodeReview需要第三方的介入，比如双人编程，而单元测试需

要编程以外的能力，这些都需要人力和时间的投入，所以也常常被人

忽略。开发的自检不仅仅是为了公司和项目，也是为了自己，大家可

以反思下，从自己开始编程以来，编程能力提高了多少，都是如何提

高的，就能体会我这句话的深意。

测试

测试是验证软件的正确性，当然主要是需求的一致性，不过很多

测试都会忙于侦测代码的漏洞，这个其实是在为整个开发团队买单，

包括构架人员。

也许，对于一个真正的开发人员来说，真的不需要测试了，他的代码

基本是完美的；但我还是想说，还是给我一个测试吧，古诗云“不识

庐山真面目，只缘身在此山中”；再神奇的开发都不能完全发现自己

代码的问题，更何况，软件是需要用另外一个视角去审核的。

测试的东西说老实话我也没有太多深入的研究，我只是想告诉大

家一个好的测试人员是开发者的守护者和老师。据说微软用资深开发

做测试，这个估计就是极致的模式了吧。

6人模型

上一篇文章说到了“2条主线和4个步骤”；那么顺理成章的，

我的软件开发和团队“最小模型”就是6人模型。在展开6人模型以

前，我必须阐明以下儿个观点作为6人模型的总则：

1首先，我之所以要用6人而不是6角色，就是想暗示我认为6人

各自独立的必要性，而反对合并和兼职（虽然我对兼职也有一定的理

解一一请查看以后的章节：金刚合体和巨人肩膀），我认为6人可以

不必全程参与，但不要合二为一。

16人是最小模型，6人缺一不可，缺一则伤及软件质量的根本，或

者说，软件质量会减低到我能容忍的极限以下，但是否达到我的质量

标准不等于软件成功的标准，这个大家要有清楚的认知。

16人具有各自的专业领域，各自有独特的方向和技能。也许我们

的团队暂时找不到6个绝对合适的人，但我们必须承认这是我们的方

向。

哪6人？他们需要会什么并做什么？

1.管理者

2.构架者

3.需求者

4.设计者

5.编码者

6.测试者

管理者

遵循管理主线的团队领导，引领航行的舵手和船长.

管理者需要软件项目管理的技能。

管理者是“闲职”吗，答案肯定是否定的，我们不扯PMP9大领域,

5个环节，我们也不扯CMMI关于各种管理的长篇大论，我就指出我

认为管理者不得不做的4件事情，大家来看看我们需不需要这个管理

者。

1.时间管理：计划告诉大家要做什么，监督了解大家正在做什么，做

了多少；审核保证大家的工作已经完成。告诉我，如果没有管理者，

谁知道，大家需要做什么，现在做了多少，未来什么时候做完。

2.沟通管理：软件开发不是独立存在，有随时要求更多的客户，有期

望永远大于实际的高层，每天都有不同的人希望了解，交流和变更软

件开发的内容和进程，这些交流工作交给只愿意带着耳机闷头开发的

人合适吗。

3.团队管理：3人成党，4人成帮，人的问题总是比代码复杂的多，

无论组织个小型的饭局，还是解决每个人的烦恼，这里总需要一个协

调人的存在。

4.风险管理：软件开发有风险吗，有，而且大到任何人无法相信，从

来没有按时完成的软件计划，从来没有符合需求的软件产品；那么谁

来带领大家未雨绸缪，在风险到来前做好一切准备，把风险的影响降

到最低，只能是管理者。

构架者

遵循技术主线的团队领导，软件开发最终还是技术活，技术高低决定

软件的层次高低。

构架者需要精通项目相关技术，并具有相当的应用经验，能够选择和

驾驭相关技术给出项目的合理解决方案。并且该解决方案可追踪，可

执行，可培训。

首先构架者需要了解一定规模的该领域的相关技术，以便于根据不同

项目要求进行选择，构架者需要有足够的技术储备。

技术选择了还不够，构架者需要对其的可执行性具有相当的把握，自

己都不会，奢求其他人无师自通？最典型的构架笑话是，大家就按某

某构架自己做把，自由发挥，如果大家利用一个构架都没有你来的透

彻，那么你为什么不能先行消化，让大家少走弯路，减少质量损耗；

反之，如果有人对构架的理解比你还高一筹，那么为什么让你来当构

架者。

最后构架不能仅仅考虑能否实现，还需要考虑延伸属性，比如性能，

稳定，并发等等问题。这个就需要积累，非一日之功。

需求者

需求是软件存在的理由，满足需要是软件成功的主要标准，需求者是

原始需求的发掘者，并加以整理和抽象，成为软件的需求.

在整个6人模式中，管理者应该是完全的非技术人员（虽然很多

管理者是技术出生，但在我的模型里面他的技术职能几乎没有）；而

需求者是对半开，为什么怎么说，需求者分2个阶段。

1需求挖掘一客户交流

1需求开发一系统分析

需求挖掘需要的是交流能力，逻辑能力。

而系统分析，需要的是逻辑能力和软件设计，分析和一定的技术功底。

需求人员需要从客户那边挖掘（请注意不仅仅是记录，因为很多客户

不了解自己的实际需求），然后抽象，分析并设计出一个软件的雏形,

给设计者提供前置范围。同时，需求者需要在构架者的帮助下，基于

自身一定的技术功底，保证所设计的软件系统架设在可执行的技术构

架之上。

设计者

承上启下，软件最终形态的创造者，同时也是需求的监督者和编码的

指导员.

具有软件具体表现的设计能力，他是系统分析的后续和细化，但为什

么不让需求者进一步细化设计，这个理由我后面会说：如果没有设计

者，设计也不会消失，而是向需求或开发两端转移，一般是向开发转

移，设计和需求或开发合并会出现什么问题，这个我后面会详细阐述。

很多公司的美工会成隐性的软件设计者，这个是有道理的，因为界面

和人机互动的确是软件设计最关键的一环。但我认为设计者最好还是

具有一定的技术背景，无任何技术背景的设计者会给开发者带来不小

的困扰，所以我比较建议美工仅仅作为设计者的一个外部资源来调

用。

编码者：

软件的最终实现者。

编码者的能力和事务我这里不加累述了。大家都是对于开发都不陌

生。

测试者

软件质量的守护神,需求,设计和编码的监督者.

可以这么说即使需求一设计一开发环节是无懈可击的，测试者的作用

依然是存在的，不同角度的需求验证对软件的质量起到定海神针的作

用，况且，无懈可击的开发流程，更象是一个神话，不是吗？

测试人员，需要具备测试的相关的工具和方法，他的主要责任是验证

需求的一致性，但很多时候他们会参与到技术纠正里面去，如