软件开发和团队”最小模式”初探2-6人模型(上)

2016-11-21 00:00:00 by 【6yang】, 1121 visits, 收藏 | 返回

6人模型

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

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

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

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

6人?他们需要会什么并做什么?

1.       管理者

2.       构架者

3.       需求者

4.       设计者

5.       编码者

6.       测试者

管理者

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

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

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

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

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

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

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

构架者

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

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

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

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

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

需求者

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

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

需求挖掘-客户交流

需求开发-系统分析

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

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

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

设计者

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

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

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

编码者:

软件的最终实现者。

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

测试者

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

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

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

软件团队的标准和缺陷

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

有没有管理

有没有特定的构架

有没有专业的需求人员

有没有中层设计师

有没有开发(这个不会没有)

有没有测试的最终防线,

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

分享到:
share

    图片原图

    loading

    loading