软件开发和团队”最小模式”初探2－6人模型（上）

6人模型

上一篇文章说到了“2条主线和4个步骤”；那么顺理成章的，我的软件开发和团队“最小模型”就是6人模型。在展开6人模型以前，我必须阐明以下几个观点作为6人模型的总则：

l 首先，我之所以要用6人而不是6角色，就是想暗示我认为6人各自独立的必要性，而反对合并和兼职（虽然我对兼职也有一定的理解――请查看以后的章节：金刚合体和巨人肩膀），我认为6人可以不必全程参与，但不要合二为一。

l 6人是最小模型，6人缺一不可，缺一则伤及软件质量的根本，或者说，软件质量会减低到我能容忍的极限以下，但是否达到我的质量标准不等于软件成功的标准，这个大家要有清楚的认知。

l 6人具有各自的专业领域，各自有独特的方向和技能。也许我们的团队暂时找不到6个绝对合适的人，但我们必须承认这是我们的方向。

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

1.       管理者

2.       构架者

3.       需求者

4.       设计者

5.       编码者

6.       测试者

管理者

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

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

管理者是“闲职”吗，答案肯定是否定的，我们不扯PMP  9大领域，5个环节，我们也不扯CMMI关于各种管理的长篇大论，我就指出我认为管理者不得不做的4件事情，大家来看看我们需不需要这个管理者。

1.       时间管理：计划告诉大家要做什么，监督了解大家正在做什么，做了多少；审核保证大家的工作已经完成。告诉我，如果没有管理者，谁知道，大家需要做什么，现在做了多少，未来什么时候做完。

2.       沟通管理：软件开发不是独立存在，有随时要求更多的客户，有期望永远大于实际的高层，每天都有不同的人希望了解，交流和变更软件开发的内容和进程，这些交流工作交给只愿意带着耳机闷头开发的人合适吗。

3.       团队管理：3人成党，4人成帮，人的问题总是比代码复杂的多，无论组织个小型的饭局，还是解决每个人的烦恼，这里总需要一个协调人的存在。

4.       风险管理：软件开发有风险吗，有，而且大到任何人无法相信，从来没有按时完成的软件计划，从来没有符合需求的软件产品；那么谁来带领大家未雨绸缪，在风险到来前做好一切准备，把风险的影响降到最低，只能是管理者。

构架者

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

构架者需要精通项目相关技术，并具有相当的应用经验，能够选择和驾驭相关技术给出项目的合理解决方案。并且该解决方案可追踪，可执行，可培训。

首先构架者需要了解一定规模的该领域的相关技术，以便于根据不同项目要求进行选择，构架者需要有足够的技术储备。

技术选择了还不够，构架者需要对其的可执行性具有相当的把握，自己都不会，奢求其他人无师自通？最典型的构架笑话是，大家就按某某构架自己做把，自由发挥，如果大家利用一个构架都没有你来的透彻，那么你为什么不能先行消化，让大家少走弯路，减少质量损耗；反之，如果有人对构架的理解比你还高一筹，那么为什么让你来当构架者。

最后构架不能仅仅考虑能否实现，还需要考虑延伸属性，比如性能，稳定，并发等等问题。这个就需要积累，非一日之功。

需求者

需求是软件存在的理由,满足需要是软件成功的主要标准,需求者是原始需求的发掘者，并加以整理和抽象，成为软件的需求.

         在整个6人模式中，管理者应该是完全的非技术人员（虽然很多管理者是技术出生，但在我的模型里面他的技术职能几乎没有）；而需求者是对半开，为什么怎么说，需求者分2个阶段。

l 需求挖掘－客户交流

l 需求开发－系统分析

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

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

需求人员需要从客户那边挖掘（请注意不仅仅是记录，因为很多客户不了解自己的实际需求），然后抽象，分析并设计出一个软件的雏形，给设计者提供前置范围。同时，需求者需要在构架者的帮助下，基于自身一定的技术功底，保证所设计的软件系统架设在可执行的技术构架之上。

设计者

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

具有软件具体表现的设计能力，他是系统分析的后续和细化，但为什么不让需求者进一步细化设计，这个理由我后面会说：如果没有设计者，设计也不会消失，而是向需求或开发两端转移，一般是向开发转移，设计和需求或开发合并会出现什么问题，这个我后面会详细阐述。

很多公司的美工会成隐性的软件设计者，这个是有道理的，因为界面和人机互动的确是软件设计最关键的一环。但我认为设计者最好还是具有一定的技术背景，无任何技术背景的设计者会给开发者带来不小的困扰，所以我比较建议美工仅仅作为设计者的一个外部资源来调用。

编码者:

软件的最终实现者。

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

测试者

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

可以这么说即使需求－设计－开发环节是无懈可击的，测试者的作用依然是存在的，不同角度的需求验证对软件的质量起到定海神针的作用，况且，无懈可击的开发流程，更象是一个神话，不是吗？

测试人员，需要具备测试的相关的工具和方法，他的主要责任是验证需求的一致性，但很多时候他们会参与到技术纠正里面去，如果出现了这种情况，他们就更显得不可或缺，因为如果没有他们，软件的质量将会如何？

软件团队的标准和缺陷

由上，我们可以得出一个软件团队的标准：

有没有管理

有没有特定的构架

有没有专业的需求人员

有没有中层设计师

有没有开发（这个不会没有）

有没有测试的最终防线，

以此6点，来了解一个软件团队有没有最基本的配备。

 

这些条件都极大的影响到了软件的质量和项目的成败。那么如果达不到这些标准，是否软件就没办法开展了呢，事实也不完全是这样的，除了开发以外，软件可以在缺少其他5人的状态下完成，因为软件开发是一项神奇的活动――请参考我的《引论-谈下我的软件和团队之路》，但缺少任何一人，对软件会造成什么缺陷呢，请让我慢慢分解：

无管理：整个开发是无序状态的，开发团队不受控制难于了解，难以了解项目的计划和进度，无任何信息输出，大部分风险都无法回避和减轻，各种团队矛盾难以化解。

无构架：项目的技术风险无法欲知，很容易进入技术雷区，即使勉强度过也很容易留下隐患；每个开发的技术无法统一，造成项目技术选择混乱，即使侥幸完成项目，该会在项目的维护过程中吃尽苦头。最后一点，团队的水平永远无法提高。

无需求：软件会迷失于开发者的自我想象，而大部分客户都没有确认需求的习惯，大家都希望做完了再看，看完了再改；而最后的结果是，导致开发成果与客户预期偏差太大，大量修改返工，成本时间增加，程序员无穷压力，导致团队陷入泥潭，最终崩溃。

无设计：设计常常有实际开发者独自完成，其质量，内容完全决定于个人，质量水平，设计标准无法统一，使得项目出现风格迥异，瑕疵不断的尴尬局面，虽然可能不伤及根本，但难以称专业。另外开发和设计具有互斥性，设计繁复必然导致开发困难，大多数开发人员，在个人技术弱点和技术难点上，常常趋利避害，简化设计以减轻自身压力，造成设计需求服从于开发需求，本末倒置。

无开发：这个大家都很清楚是不可能的，不加累述。

无测试：智者千虑，必有一失；说的是即使开发者具有极强的自律和自检能力，也需要一个审核者的辅助，何况一个连测试都不具备的团队，其开发的自律和自检能力不容乐观，没有测试大部分结局只能是错误百出。

 

下面我会陆续推出以下章节：

金刚合体和巨人肩膀： 讨论不足6人的一些权益方法和我的看法

简易团队构建指南： 围绕6人模式，来设想构建一个简单的开发团队。

6人模式还仅仅是起步： 总结和一些感想。

http://www.cnblogs.com/zergcom/archive/2012/08/02/2619770.html