ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 配置管理:文档配置库不是历史的垃圾堆

配置管理:文档配置库不是历史的垃圾堆

原创 Linux操作系统 作者:szandrew 时间:2009-07-18 10:34:40 0 删除 编辑
文档配置库不是历史的垃圾堆
--王珏原创

    现在“配置管理”基本已经充分的普及了,差不多我遇到的每一个项目组建立了自己的“配置库”,配置库一般也都包括两部分:代码配置库,以及文档配置库。但 遗憾的是,我常常发现大家对于代码配置库的利用还是比较有效的(可能使拜IDE中集成的配置管理所赐吧),而文档配置库基本上就是“历史的垃圾堆”。
    本文 主要说说文档配置库存在的问题以及改善方法----注意,这里不讨论代码配置库。文档配置管理最容易的犯得错误就是不知道“项目的配置需求”,因而出现下 列“重形式,轻内容”的情况。
  1. 重要的文档都没有进入配置库(判断文档是否重要的标准是:是否经常阅读这些文档;是否经常被其他文档引用)
    • 比 如:一个项目的背景资料,这个项目是为了落实什么“想法”。这个“想法”对于任何进入项目的人来说都是极好的“入门教材”----它浅显易懂;项目实施过 程中,又是极好的“紧盯项目目标的工具”----它是当之无愧的项目目标(参见:);对于“大国企的项目”,可以根据这个“想法”仔细的去琢磨其“表面的 项目目标下的”深层的“政治目的”。
    • 比如:需求分析,概要设计的中间产品,如“思路”的演进;大家关于某一个问题的讨论的过程以及结论;常常在我的项目中最重要的文档是:
    • 比如:关于一些开发工具、数据库、应用服务器的安装、配置以及使用的技巧。这些类似于“学习笔记”的东西,这可以避免大家一遍一遍反复的上网查询。甚至能有效的营造出一个“学习型团队”的氛围,而促进团队凝聚力。
    • 比 如:“新人入门”。我曾经做过一个项目,人员流动非常厉害(主要是公司总是借人给我用,过不到2、3个月就抽走,又换新人来----危害不在这里说了)我 为了应付反复对“新人”说重复的话,在我们的文档配置库中专门建立一个“新人入门”,包括“项目目标的简单说明”、“项目需求的简单说明”、“项目配置库 的使用”、“开发环境建立的步骤”等等。
  2. 文档配置库成为历史的垃圾堆。
    • 进入配置库的都是些“格式一流”,“内容三流”的文档,如:。
      • 需求规格说明书:由于需求规格说明书太大,导致产品人员疏于更新(更新成本太高);研发人员懒得去读(太长了,而且那种可以理解的文字水平,是在没有兴趣读写去。文档工程师显然没有《昆虫记》作者法布尔对事物的描述水平)。 (参见:需求相关:需求管理如何管)需求规格说明书的价值主要体现在:1、大家都离职了,下一波冲上来的工程师用来对项目“扫扫盲”;2、研发、测试人员“扯皮”用,用来指责需求工程师----“你看,你的需求说明就是这么写的,因此这个责任不关我的事”。
      • 概 要设计文档:为了通过评审,概要设计文档“抽象”的外行看了“看不懂”,内行看了“全是放之四海皆准的东西”。反正后期的研发工作和这个概要设计没什么直 接关系。更为奇怪的是:概要设计多半处于“架构师”之手,而架构师在做完“架构设计”就会被公司抽调到其他更为重要的地方去了(参见:技术相关:我们需要什么样的架构师?),这个概要设计文档入库的意义可能就在于此吧。
      • 以及测试用例、编码规范这些等等
    • 进入配置库的都是一些经过“评审”且板上钉钉的文档:配置管理有一个很重要的目的就是“管理变更”,有变化才需要管理,也才有管理的难度和复杂度。项目中,不经常需要修改的文档,也正是不重要的文档。
  3. 配置管理人员和项目组割裂。
    • 大 多数项目组的配置管理员一般都是由精通“配置管理软件”的人员来担当的。当这个角色不了解这个项目真正有价值的文档是什么后,就出现了很多项目组出现的问 题:项目组为了避免“配置管理上的麻烦”而把最不经常变换的东西提交给“配置管理员”;而配置管理员也就稀里糊涂的把这些东西当成“宝贝”置入配置管理 库。
  4. 建设“文档配置库”的目的是消极的,而不是建设性的。
    • 大家都有一个很奇怪的想法,就是把文档纳入配置库,是为了避免事后的“扯皮”,以及确定“谁该对某件事情的失败而负责任”。而忽视了配置管理最根本的:为什么需要对“变更进行”管控。
  5. 配置库的“过度管理”导致整个配置库的失效。
    • 说的配置管理,似乎大家都非常重视“变更”的管理,很多公司专门成立了SCCB(软件变更配置委员会)。一次变更要经过:1、变更请求;2、SCCB审核;3、配置管理员开放权限并备案;4、发生变更。流程看起来很美,问题是:
      • 首先,SCCB很多时候是由领导组成的,本身既不了解项目,也没有时间去了解项目中哪些文档需要变更、可以变更。这时谁的嘴巴大,领导就听谁的了。
      • 流程的复杂性导致那些真正重要的文档----需要经常变更的文档,不敢进入配置库。每变更一次都要走一遍流程,谁受得了?
  6. 针对项目组的配置管理培训则“重工具,轻内容”
    • 其实很多项目组也都重视对于配置管理的培训,但培训中所强调的是VSS,CVS,CleanCase等工具的使用与维护,而对于什么内容该入库,什么内容有价值却没有一个衡量标准。

    而针对上诉问题的改善的更本性方法就是:改变“重形式,轻内容”为“重内容,轻形式”。
  1. 关于称职的配置管理人员:配置管理工作的角色有两部分构成:
    • 能够判断项目中文档重要性的人,主要“抓内容”----一般来说就是“项目经理”。
    • 能够保证配置库的有序的人,主要“抓形式”。督促项目组成员养成良好“配置管理习惯”的人员。
    • 在选择配置管理人员的时候,不必看其是否做过配置管理工作。我常常的方法是,考察这个人对于MP3的收集水平(只要有“收集”的爱好就可以)。大量MP3的收集整理和配置管理有异曲同工之妙,对于mp3目录的组织;文件的更新都能反映一个所谓“配置管理人员”的内在素质。
    • 由于其常常需要和“人”打交道,需要其沟通能力,以及耐心,远比其所谓的对于配置管理工具的熟练使用要重要的多(很多时候,项目组中的那个文档工程师的小MM,就是一个不错的选择)。
    • “抓内容”和“抓形式”角色的分开,既能够解放项目经理对于琐碎小事的分心,也有利于项目经理整体把握项目真正有价值的“内容”。
  2. 关于对于有价值内容的判断:(我的经验)
    • 经常“想去变更”的文档就是最有价值的文档:比方说“各种列表”,如需求跟踪列表,Bug跟踪列表等。
    • 经常“需要去看”的文档就是最有价值的文档:比如“用例图”;系统架构图
    • 那种涉及复杂逻辑的文档:这些文档常常容易搞混淆,而且过段时间就忘记了:比如客户的“业务处理流程”等等
    • 常常在项目组中提及的文档:项目组在开会、或者讨论时候常常提及的东西,比如涉及到项目背景,技术背景相关的那些文档,甚至包括软件的的配置、安装、维护技巧等。
  3. 关于配置“管理”本身:
    • 流程要简单:配置管理的核心目的是为了把大家纳入到配置管理过程中来,因此简单的流程是大家“心甘情愿接受配置管理的”的良方;而通过“高压”、“处分”“罚款”等方法都只能适得其反。着这里想想“三个代表”也是有益的(参见:过程相关:实行CMM要以“三个代表”为指导思想)。
    • 工具要易用:对于配置管理工具的选择,完全没有必要追求“高”“新”“尖”。项目组成员大家都用过的工具,大家都愿意接受的工具就是最好的工具。记住“内容比形式更重要”。


Link URL: http://blog.sina.com.cn/s/blog_592060b50100cpr3.html

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

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2009-07-18

  • 博文量
    18
  • 访问量
    25998