ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 规范不仅仅是文档模板——“走出项目管理的泥沼”之“研发规范”话题(转)

规范不仅仅是文档模板——“走出项目管理的泥沼”之“研发规范”话题(转)

原创 Linux操作系统 作者:urinator 时间:2007-08-15 00:00:00 0 删除 编辑
规范不仅仅是文档模板——“走出项目管理的泥沼”之“研发规范”话题
最近读《IT经理世界》,刊登了这样一篇文章:《下班后你的公司还值多少钱?》,文章开头讲了这么一个小故事:一位软件公司的老总感慨地说:“做软件公司,最痛苦的事情是下班之后,你发现自己的公司除了几台电脑外,几乎什么也没有了。因为公司最值钱的资产都在每个程序员的脑子里,这些人一旦离开,公司的资产就等于零”。

这不是偶尔的现象,目前还有不少公司,时刻担心某些员工的流失,直接导致工作的延续和完善出现断层,影响公司收益。难道脑力劳动就只存在于头脑中吗?如果真是这样,人员流动率相当高的IT行业,怎么可能做长寿公司?只能是昙花一现而已。不,不应该是这样的。

以上述的软件公司为例,装在程序员脑子里的公司重要资产有哪些?软件包括源代码,发布版本,和相关资料,这些资产通过一定的操作,都可以转化成为固化资产。如果研发人员的文档与代码是一致的,那么交接工作会顺畅得多;如果前期的设计文档足够详细和清晰地表达了上层设计的思路,那么下一级设计或者实现不会因为人员变更而受到较大影响;如果随机资料与发布版本一一对应,并且完备地描述其细节,那么设计人员的离开并不能增加太多维护工作的难度。然而,这些都是如果。在一家国内知名公司的办公区内,墙上贴着这样的条幅:“人人都痛恨别人不写文档,人人自己都不愿意写文档!”这就是原因,导致脑力劳动成果总是保留于无形。

怎么解决这个问题?“没有规矩,无以成方圆”,制定研发规范,将无形的脑力劳力劳动显式化。研发规范,主要是为了细化研发过程,便于流程度量、改进和控制。除了上述的留住公司的无形资产之外,另有一个重要的目的:规范化不同人员的表达方式,减少不必要的信息沟通,提高交流的效率。

如何制定研发规范?各个公司根据各自的经验,和参考国内国际相关标准,都会有自己的一整套系统规范。如软件项目,从项目立项阶段提交项目立项报告,可行性报告;到系统设计方案,详细设计报告,测试规程,以及各种评审报告等等。其模板也多种多样,很多介绍项目管理的书籍或者文章上,还专门有介绍如何编写某某报告的指导,不可谓不详细。

规定了这样的一套研发规范,是不是研发过程真的就规范起来,总裁不必再担心下班后的公司不值钱呢?很多公司不是这样。这是因为研发规范不仅仅包括这些各种各样的“文档模板”,更重要的是操作规范。例如,不同研发阶段应该完成什么样的操作、出具什么样的文档才算结束?这些操作又有什么样的要求?这就是流程规范。所以完善的研发规范应该由一系列的流程组成,每个流程包括一些相关操作,和输入输出。

如图1所示,我们以软件中的编码阶段为例,详细介绍其研发规范。

1. 流程输入
软件的编码阶段,比学校里的学生想象的复杂得多。首先需要输入详细设计文档,这是上一个流程,“详细设计阶段”的输出产物。而编码规范,则按照不同的语言组织,规范某种语言的使用和交流方式,最常见的要求是规定其注释的百分比。这两种规范一般是公司规范。

2. 复查
编码完成之后,需要作者进行复查工作,如果发现故障,需要立即修复故障;否则可以进入下一步操作。
在编码之后加入的复查阶段,让很多人不理解,因为大家没有在编译之前再读一遍自己代码的习惯,总是希望编译器来代替自己查错。不错,已经有许多改进的编译器可以查出全部的语法故障,和一部分语义故障;但是最好的编译器也只能查出85%的故障,所以为了尽量早地发现故障,作者自己的复查是有价值的。妄图借助后续的同行评审来弥补没有自己复查的人,忘记了自己才是作品的构思者,才最清楚自己想要表达什么,这是任何别人代替不了的。
不过,如果研发规范在操作这一步骤中面临很大的推进困难,也可以调整此操作到编译之后,但是取消是不提倡的。
复查也同样需要规范的指导,即代码复查表。这张表的制定需要更多的实时性,它一般是根据软件团队对某一种语言的运用程度而定制的,甚至个人也可以根据个人掌握情况来调整。检查表的有效程度,可以用此阶段的发现故障数量,与整个研发过程的故障数量之比度量,因此它依赖于后期的质量检测,如果在前期制定时有经验丰富的工程师参与,将会降低延迟修复故障而造成的成本。
从图中可以看出,代码复查可以进行多次,理论上依赖于作者对完成代码的质量信心,不过一般更依赖于作者的勤勉和负责程度,需要团队领导和质量经理经常督促。

3. 编译
这是个没有争议的操作,基本上所有的代码版本库的入库要求中,都包括了“代码编译通过”。这个阶段同时需要提交《程序配置清单》,为了同行评审的方便,有时还需要在每个代码文件的属性中标明,是新建的文件还是修改的文件。

4.代码的同行评审
这是CMM的要求,按照PR(同行评审)的流程规范进行,并且修改故障和提交评审报告,以及故障记录。同行评审一般不需要循环进行,除非代码质量很差,一次评审不能按照要求通过。
代码经过同行评审,即可进入调试阶段。

5.流程输出
编码阶段的输出,除了代码直接用于调试之外,还有很多的评审报告、记录报告,主要用于项目回顾。

文档是珠,操作为线,连贯成流程,制定完善的流程规范是让研发规范化的第一步,认真地按照其进行操作,才是研发规范真正起到作用的关键。老板们如果担心自己的公司下班后不那么值钱,与其一门心思担心员工频繁跳槽,不如一边分析员工不稳定的原因,一边花些精力好好研究一下如何规范化研发操作,才能双管齐下,稳操胜券。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7942439/viewspace-21325/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-12-06

  • 博文量
    3870
  • 访问量
    1813919