CSDN博客

img 10jqkA

国内软件工程手段(2003.1)

发表于2003/2/8 12:01:00  1248人阅读

 

 

国内目前软件开发项目组中可以采用的软件工程手段

 

 

 

 

 

 

 

 

 

 

 

huangjien@163.net

2003.1


 

国内目前软件开发项目组中可以采用的软件工程手段--- 1

1.       前言    4

2.       需求阶段    4

CCB(变更控制委员会) 4

需求评审,纳入基线-- 5

3.       项目计划阶段    5

选择合适的软件开发生命周期-- 5

划分阶段--小里程碑-- 6

决定工作产品和含中间工作产品-- 6

项目工作分解-- 6

估计-- 7

明确职责团队建设-- 7

约定沟通方式、渠道-- 7

约定开发纪律、规范-- 8

风险估计和预备应对计划-- 8

CCB评审项目计划-- 8

4.       设计阶段    8

周期性内部评审和走查-- 8

项目跟踪-- 9

变更控制-- 9

5.       编码阶段    9

重新进行工作估计,有必要时修订计划-- 9

标准制订和培训-- 9

周期性走查-- 10

周创建或日创建-- 10

项目跟踪-- 10

变更控制-- 10

版本控制-- 10

6.       测试阶段    11

制订返工标准和重申纪律-- 11

日创建-- 11

变更控制-- 11

版本控制-- 11

项目跟踪-- 11

7.       项目收尾    12

8.       其它    12

选择项目经理-- 12

执行-- 13

对目前流行技术的评价-- 13

 


 

1.     前言

为更好地开发软件,必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何,一个项目经理都应该可以在项目组中实行的一些手段和方法;当然,公司情况良好则有更加可行的、更多的方法可以选择;这里只讨论了最差情况下可以采用的方法。

本文按照最简单的瀑布模式的各个阶段分别列举了一些方法,在其他模式中应该也可以采用。

必须指出的是:这是对目前情况的一个分析和总结;本文(V1.0)的完成时间是20031月,有效期大概是半年。限于个人的认知有限,希望能够得到大家的指正和补充。计划每半年提出一个新版本,希望中国的软件工程技术能够快速地发展,让此文每次都有许多新东西。另外,这里所说的国内,当然指的是中国国内民营、私营、国有企事业单位和一些虽然有外资性质,但无外资软件企业开发规范、纪律和管理制度的“假外企”。因为很多外企的经验、方法虽然很好,但是没有相应的制度、文化支持,照搬是不行的。比如:微软的开发、测试同步进行,日创建等方法,虽然很好,可是只能借鉴,在小范围内实施;如果哪个企业的项目经理想全部照搬,那就要先想一想有没有微软那么多的钱、人和文化氛围。所以,本文不把微软、IBMHPMotorola等外企的方法作介绍;本着从实际出发的原则说,我们现在不具备全盘引进那些先进开发方法和经验的条件。《软件工程》上介绍的方法,只能有一小部分能够在国内的项目中部分地、有条件地使用本文就是要介绍目前这些方法或手段,和它们的使用特点以供大家选择。

2.     需求阶段

需求的管理应该是贯穿整个开发过程,往往最大的问题是变更失控。在需求获取、讨论、分析等阶段,可以采用的方法有:

CCB(变更控制委员会)

建立CCBchange control board)是需求管理的前提,否则需求管理将成为一句空话。

CCB必须包含客户方的决策人士,项目经理,项目经理的领导,关键设计人员,测试负责人,SQA.等,以5-7人左右为宜。

需求确认,发生变更等活动必须由CCB以会议形式批准。

CCB对整个项目有最高权力(不仅负责需求变更,还负责听取项目经理汇报、关键中间工作产品评审等重要决策)

这里需要着重说一下评审。评审是正规化开发的一个重要标志,目前常见的方式有:同行评审,团队评审,走查等。根据需要可以采用会议、

需求评审,纳入基线

原始需求必须形成文档,被CCB评审,然后纳入基线管理,所有变更都需要CCB评审。

该评审一般步骤:

项目经理提出被评审对象,指出受影响、被牵涉对象,评估影响(主要是带来的规模、工作量、成本),提出计划和计划执行人,举出可能风险;

CCB来决定是否同意或要求项目经理修改上述项;

之后,项目经理提交执行情况汇报。

最后,CCB指定代表或由SQA进行核实。

如果变更过小,过多,可以进行周汇总评审。

3.     项目计划阶段

项目计划是开发的指导或脚本,事实上,在每一个阶段开始时,都应该重新、小范围修订一下计划。

选择合适的软件开发生命周期

关于生命周期的选择上,一直有而且会有很多争议。目前,国内运用最多的是纯瀑布生命周期;个人的看法是:一定有更好的选择,但这是一个最安全、最少在实际中有争议的选择。

选择合适的生命周期的要点是:一定要有选择原因的陈述本项目的特点,团队特点,开发特点和公司或部门的特点;该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。

除了主流模式外,一些“轻量级“的方法也值得考虑,目前成熟的、有部分被使用的有:

XPExtreme Programming,也快变成“主流“了),要点是:communication,simplicity,feedback,courage

ADPAdaptive Software Development

Cystal

SCRUM

FDD

一般项目经理也许不会轻易采用这些不熟悉的模式,但了解一点,借鉴其中的一些好方法和思想则是应该的。

最糟糕的是没有选择任何模式,上来就Code&Fix;或者在进度压力下退化成Code&Fix

Code&Fix的发生,一定要项目经理负主要责任:一种情况是没有管理或管理无能;还有就是在编码或测试阶段需求变更失控;需求分析、设计失败的话,当然就只能Code&Fix了。

划分阶段--小里程碑

根据选定的生命周期模型,考虑到可以投入的人员,各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月,那么应该在每经过一个月左右选择合适的点作为小里程碑。

每达到一个里程碑时,项目经理应该提交本阶段工作报告,一般应该包括:

本阶段活动统计和估计的数值和它们差异的原因

工作产品完成情况

需求变更情况统计

问题及其解决情况的统计

总结优点和缺点,指出对下一步工作的影响

CCB听取该报告并评价该阶段工作。

小里程碑可以防止项目失控,使项目经理、项目组和其上的管理层能够正确认识到项目进展情况,并能协助项目开展、出谋划策,项目可视化好;避免项目发生大问题。

里程碑应该定义明确,有容易检查的结果,它只有完成/不完成两个状态,丝毫不能含糊。

决定工作产品和含中间工作产品

在最混乱的项目中,工作产品和中间工作产品都没有被明确定义,或者可以朝令夕改,随意添加或去除产品。决定工作产品和中间工作产品,是为了确定各个产品的重要性,计算其上的工作量以合理地投入足够的、合适人员来开发它。

项目工作分解

一般是将系统分解成模块甚至更细,要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定;一个忠告:开始做得细、做得认真,以后的工作都会相应容易很多。

一般人只分解产品。实际上,管理工作也应该分解的,而且也比较容易作。

工作分解的原则是:每个工作包必须分解到5工作日或一个工作周内,至少是即将进行的阶段的所有工作必须分解到这个标准;否则,项目跟踪无法进行而且项目容易失控。至于远期的工作,一时不能也没必要分解到如此地步,但是要尽可能大致分出一些工作段来。

估计

估计常常被忽略掉,因为估计的结果往往会严重超出预算,让人大吃一惊;或者是拍脑袋拍出来的结果过于空泛,不足依靠。而到了最后,结果又往往接近当初估计的数字。

估计应该每个阶段作为更新计划的一部分进行一次,每个新的估计都会更加准确。

估计应该选取有经验的人士参与,应该选择合适的方法。

估计的结果应该用于指导编制下一阶段的计划,即使不被正式接受,项目组也不应该忘记这些数字,时刻作为参照。“项目经理需要挺直腰杆,坚持他们的估算,确信自己的经验和直觉总比从期望派生出的结果要强的多”摘自《人月神话》。

目前的主要问题是缺少历史数据而使估计缺少依据,但我们不开始的话,永远都是这样。

明确职责团队建设

项目组人数超过7人,就应该考虑团队建设的事情了。

建立组织的终极目的,是确定沟通的渠道;限定职责范围和进行人力划分是为了控制无序、数量失控的交流;而不是为了让一些人领比我们高得多的工资。

根据项目特点和人员特点,应该选择合适的模式来组建团队进行开发,每个人都应该有明确的责任和工作。

最低限度,每个人都应该有明确的责任和工作。

约定沟通方式、渠道

建立沟通渠道这一条可以不成文,但要成规矩。沟通渠道应该开放,畅通。为每个人指定汇报的领导、汇报的周期、汇报的方式和越级汇报的领导、条件和方式。

建议在项目中开展项目日志,周报制度,具体的方式方法可以参考PSP,TSP。该制度的要点是:日志首先是对自己负责,不能作为评价员工的依据,它是属于成员“开放的隐私“。如果要求每天填满8小时工作,这样的日志没有任何意义;事实上,在本人的项目组中,根据日志,一般没有人每周投入工作的时间超过35小时,平均只有28小时左右当然,你依然可以看到他们每天都很忙碌的样子,有时还有加班呢。别的人可以不纪录日志,但项目经理一定要纪录,就像船长一样每天记航海日志。

周例会制度是本文推荐最有可行性的软件开发管理手段。每周用1-1.5小时左右,每个人简要汇报本周工作和下周计划的工作,工作中的问题和难点,这时,他会得到整个项目组的建议和帮助;项目经理可以印证了解到的项目进展情况;团队气氛由此加强。如果还有很多富余的时间,项目组可以讨论一下开发技术、技巧,进行一些技术交流。

总之,沟通不足是软件开发中很大的问题,而且越是大项目就越严重。

约定开发纪律、规范

没有规矩,不成方圆。项目组一定要有一些纪律,不能完全依靠自律。

这方面,有公司文化、氛围积淀为基础是最好,否则就应该制订一些规矩了。

这也是保持团队的重要组成部分。

至于开发规范,根据项目不同而有所不同,要点是:必须有,哪怕不完美!

而且,应该开诚布公,尽早公示。

风险估计和预备应对计划

风险估计应该每个阶段都进行一次,一般是根据风险列表,大家一起来估计。

其实也是让大家充分认识到项目的处境和潜在的困难。

这件事,做了总比不做好。

CCB评审项目计划

项目计划必须得到CCB会议形式的认可,否则一定会有这样那样的问题!

4.     设计阶段

周期性内部评审和走查

在这个阶段,周期性内部评审和走查的目的更多是为了交流,检查模块间是否能够协作、是否有矛盾和遗漏,作为平时非正式沟通的一个强有力的补充,大家取长补短,集思广益,几个人的脑袋总比一个脑袋强;第二个目的是质量控制。第三个目的才是控制进度。

根据上述特点,评审自然应该采用会议方式,也许会有人觉得冗长、拖沓,浪费了一些人不必要的时间;但是该方式的效费比非常好,是值得的;至于组织会议的人,一般是项目经理,应该多动脑子,调动大家的积极性。有人会提出使用checklist的方式,本人的经验是:该方式削弱了沟通量,而且需要良好的制度的支持,否则容易走形式。

 

项目跟踪

项目计划制订后,项目跟踪工作就要开始了。跟踪表应该每周填写,这样项目中的问题会被及时发现;而且最好不要用project跟踪,而是自己制作一张或寻找合适的软件。一般是根据项目计划制订,有下列内容:任务包,计划的规模、工作量、进度,实际的规模、工作量、进度,二者的误差以及原因分析。

任务包完成的百分比应该如何填?可以采用的标准是:如果只是听成员汇报,没有100%完成的都是0%,是0-100原则;听了成员汇报,自己简单察看过工作产品的,是0-50-100原则;仔细检查过的,可以参照成员的汇报,按0-25-50-75-100原则填写。如果一个5工作日的工作包,上边写着完成43%,那是一点意义也没有的。

项目跟踪的结果用于分析项目进展情况、里程碑报告,务必真实。

变更控制

变更控制的具体手段请参照需求阶段的原则。在本阶段,一般只是开发人员发现需求不合理,或相互设计矛盾而要求变更。一些非基线变更的控制不需要那么严格,意思是不需要CCB评审,但项目经理要根据实际情况决定是否召集项目组内相关人员的评审。

同时,应该在这个阶段让大家养成遵守变更规定的习惯。

5.     编码阶段

重新进行工作估计,有必要时修订计划

进入到编码阶段,对项目的认识已经非常清晰了。根据设计,甚至可以计算出未来的代码行数。重新进行工作估计,可以更好地分配人员到合适各人技术特点和兴趣的方面,提高项目组的积极性;同时,可以使管理层清晰认识到项目进展的真实情况,做出正确的决定或避免他们做出错误的决定。

 

标准制订和培训

编码的标准在现在已经逐渐趋向统一,但是仍然有必要在项目组中推行或制订编码标准。

统一的编码标准,可以使项目组内可以容易地互相协助、交流,为走查、测试等工作奠定良好的基础。

编码标准制订后,首先要进行项目组内培训。不过与其说是培训,不如说是讨论和统一认识,建立未来强制执行和检查的前提。(不教而诛谓为虐,教而后诛谓为化)

周期性走查

根据经验和一些统计数字,走查的效果要优于测试。

走查要以统一的编码标准为基础,反过来,统一的编码标准也是通过走查而在项目组中建立起来的。本人的经验是:开始时,安排每周2次走查,每次1小时,只检查一个人的一个功能,重点是编码标准,其次是BUG;大家可以通过走查学习他人的优良风格,改正自己的不足;两周后整个项目组基本上风格就统一了,这之后就应该把重点放在程序功能上,其次是BUG

周创建或日创建

这是微软的看家法宝。推荐在可能的情况下可以考虑使用。特点是占用至少一名高级人员,并且作息、沟通时间难以确定;能够更快地发现问题,更好地控制进度。国内企业这方面的经验好像不多,成功案例不多。

项目跟踪

项目跟踪在本阶段较容易,因为量化的东西比较多,虚的东西比较少。基本方法与上个阶段相同。通过跟踪,已经可以看出那些模块在上个阶段没有设计好。

跟踪要有分析,分析有了结果要有行动。

变更控制

在这个阶段,一般是开发人员在实现时发现一些设计错误而要求变更;这时,就要求项目经理严格把关,与设计人员、开发人员一起研究是否真的需要变更,还是实现者没有领会设计者的意图。如果需要变更,则要谨慎地研究影响范围,评估损失。

在这个阶段的中、后期,随着部分产品逐渐成形,客户会提出变更要求;此时要注意原则,同时要搞好关系,当然,首先是原则—CCB同意变更。

版本控制

事实上,版本控制在项目一开始时就应该展开,但未必所有的项目组都能够做到,能做好的就更加寥寥无几了。但在编码阶段,则最好要进行版本控制了,良好的控制机制可以减少很多无用功,甚至避免一些灾难。

良好的版本控制不是来自好的版本控制工具软件,而是版本变更控制的制度以及因此形成的良好习惯。建立一个成文的规定或规范并保证它的实行,才能使版本控制不流于形式。

如果进行了版本控制,则建议推行MISRA Rule 10-- 不得残留被注释掉的废代码。

常用的版本控制工具有VSS,CVS,rational套件中的clearcase也很好,只是会用会配置的人目前不多;UNIX下开发时,它自带的SCCS也是很好用的。

6.     测试阶段

制订返工标准和重申纪律

一个糟糕的程序总是会不断地被要求修改,测试工作大部分是由少数几个程序或个别程序员完成的程序引起的。不断地修改的产品无论改多少次都不会变成好产品。

因此,应该制订程序返工标准,一个可以参照的值是15BUG/1000Line。达到了这个标准,直接删除该程序,要求程序员重写;新程序再次达到这个标准时,就换人。而且,应该严格执行这条规定前提是:该规定在编码阶段就通知了大家。

日创建

测试阶段的日创建简直是被迫进行的,特别是在初期;否则测试简直进行不下去。

但是注意不要丧失原则,为了赶进度破坏了版本控制。

变更控制

测试阶段是客户提出变更最多的时候,注意不要丧失原则,要坚持CCB评审。必要的变更是必须进行的,但是要仔细评估其影响。匆匆进行的变更既破坏了规矩,也往往破坏了产品。记住一句名言:如果厨师做菜的时间长了,那是因为他想把菜做的更好。

版本控制

如果在这个阶段没有一个良好的版本控制行动的话,测试工作一定会有一种混乱的感觉;而且,这是日创建的前提。

项目跟踪

项目跟踪在这个阶段是最困难的。因为事情往往琐碎而且交织在一起。项目经理既当裁判,又作记分员,还要是教练、队长,必要时还要亲自上阵。一个好的产品,在测试阶段一定不会一团糟的。

但是,需要坚持项目跟踪;积累这个阶段的数据,才能真正评价项目、项目组每个成员、项目采用的技术(包括管理技术)优点和缺点,为公司、个人积累起经验。所以,虽然这个时候项目经理很忙、很累、有很多重要的事情要处理,但还是应该坚持项目跟踪。

7.     项目收尾

项目收尾时应该进行项目总结,主要是评价项目产品、采用的技术、管理方法、优势、缺点和项目组每个成员。

通过项目跟踪获得的数据可以作为评价的基础,但是不能做量化的评定(分级或者打分),只能是定性的评价一个尽量详尽的文字说明。总结的目的是面向未来的新项目,而不是惩戒某些人,定量的评价对于下一个全新的任务基本上没有任何帮助。

如何能够正确地评价和使用人,依然是一个管理学难题。

8.     其它

选择项目经理

当前,国内软件项目一般都采用项目经理负责制(虽然其实他负不起这个责任),而项目经理也确实是项目中最重要的人,甚至可以说是项目的灵魂。如此看来,项目经理如何选择就是非常重要的了。

目前,已经有一些公司的项目经理从开发人员中分离出来,专门进行项目管理工作,这里是指相对从前只是从开发人员中“随便”选择水平较高的人员当项目经理的办法而言。

不可否认,项目经理专业化是一个趋势,但目前国内的项目经理仍然要求对负责的项目有较高的业务、技术综合水平;这一点,许多国外企业只怕也没有很好解决。现在的项目经理主要有这样几类人员:自己感觉精力、技术跟不上的或者是需要升职、转行的资深(年长?)的技术人员;从“高手”中挑出的,有时是被动地落到这个位置的;或者是有相关证书的。显然,这些人并不一定都适合成为项目经理;这种情况的存在,只说明了目前选拔或挑选项目经理制度的缺失,随意性很大。

曾经参加过一次关于项目经理应具备何种条件、技能的讨论。条件很容易就列出了一大堆:懂管理,人际交往能力强,技术水平高,业务精通… …可是回过头一想:有这么多好本事,干吗还做项目经理?或者是项目经理的待遇至少要向总裁看齐才对。

个人的观点是:项目经理应该对项目采用的技术有整体认识,足以做出重要问题的判断和执行检查工作,否则就有被架空的可能;头脑中有管理的概念并把管理当作最重要的任务;懂得一些管理的方法和手段,关键是要对项目有“想法”;还有,不能是项目组或公司里令人讨厌的人之一;最后,当然是他自己也愿意当这个项目经理才行。

有些较大的公司曾做过这样一种尝试:把所有项目经理集中到一个部门管理,有项目来则选择一个合适的负责,他可以从别的项目经理甚至部门领导哪儿得到协助。这有点儿象普鲁士军官团的结构。军队由两个部分组成:参谋总部和作战部队;参谋总部做出决策,交由派驻部队的现场指挥官执行。如果参谋部能团结认真,协调一致,则至少大部分决策是正确的;否则,部队就成了“一群由绵羊领导的狮子”。从目前尝试的结果看,效果明显的不多。但本人认为问题在于该部门太强调计算考评、绩效,组织过于松散和各自为战,内部沟通不足,没有发挥团体的力量。这种方法能有效弥补目前项目经理在管理和经验上都不足的弱点,仍然值得尝试。

执行

以上介绍的方法的采用,要坚从项目组、公司的实际出发;超越公司、项目组实际情况、实际组织架构的使用,效果很差。

方法一经采用,就要认真执行,不要走形式;走形式只会徒然增加工作量,在小组中产生负面影响。可以不拘泥于形式、名称,而更多地考虑实用。如:CCB对大家来说都比较新,但其实以前的开发中都有项目领导组、项目总控组、协调组这些组织,可以不改名,而让这些组织发挥CCB的作用关键是发挥需求控制、项目决策的作用。叫什么名字有什么要紧呢?在本人的项目中,项目组只有一个CCB,但它决不仅仅是一个变更控制委员会,还是项目协调组,顾问团,项目监控组,它帮助项目经理进行决策、提供建议、提出批评并承担了一部分责任。一句题外话:CCB中一定要有反对派,一团和气是没有用的,而项目的领导者也应该有容忍反对意见的雅量。

方法在项目组中推行,不能只是发布一下命令这么简单这是最低能的管理。一条命令得到执行有两种可能:一是原来就有执行这种任务的习惯,二是有明显“利益“驱动接受命令者去完成该命令。如果要推行上述方法中对于项目组和公司都是“新”的方法时,要充分考虑如何推动其开展,并且要准备在方法无效时果断结束它。

对目前流行技术的评价

对于现在流行的一些新东西,如:PMP,PSP,TSP,CMM,RUP,XP,UML等新方法和概念,要深刻地思考和谨慎的实践,不是所有的东西都可以照搬套用。比如PSP的运用,就发现绝大多数程序员连0级都不能坚持完全做好(包括本人),这可能牵涉到公司文化或我们的民族文化的问题;而CMM2级许多公司还勉强,3级简直就是天方夜谭;UML经过这一年在国内的实践,证明它确实能给SA以很大的帮助,可是这一套东西太大了,能够完全掌握并有机会在实践中成功运用的人太少,其适合大项目、新项目的特点又限制了使用范围,而且需要培训整个项目组来认识、运用UML,代价相当高,要慎重考虑。

0 0

相关博文

我的热门文章

img
取 消
img