上一篇文章说到了“2条主线和4个步骤”;那么顺理成章的,我的软件开发和团队“最小模型”就是6人模型。在展开6人模型以前,我必须阐明以下几个观点作为6人模型的总则:
l 首先,我之所以要用6人而不是6角色,就是想暗示我认为6人各自独立的必要性,而反对合并和兼职(虽然我对兼职也有一定的理解――请查看以后的章节:金刚合体和巨人肩膀),我认为6人可以不必全程参与,但不要合二为一。
l 6人是最小模型,6人缺一不可,缺一则伤及软件质量的根本,或者说,软件质量会减低到我能容忍的极限以下,但是否达到我的质量标准不等于软件成功的标准,这个大家要有清楚的认知。
l 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
loading