|
配置管理之纠结
“纠结”这个词现在很流行，正如前些年的“郁闷”。每个人或多或少都有纠结的事情，我现在纠结的是：配置管理是什么（What）、在哪里（Where）、怎么做（How）？ $ K! H' N; A. K p4 M+ V
配置管理英文是ConfigurationManagement，简写就是CM，从业人员多是女士，更准确的说是女孩子，所以你可以开玩笑称之为Cute Model，那么软件配置管理SCM可以理解为Sexy Cute Mode，不信你可以看看从事配置管理的女孩子基本上都是很漂亮的靓丽的脾气很好的。SCM还可以理解为Solo CM，经常是一个人演奏的音乐会。CM还可以是ClimbingMountain的简写，你也可以理解为做配置管理的人不是和其他大队人马一起走阳关大道，而是一个或寥寥几个在爬山。从事这个职业注定很多时候要孤独、要寂寞，你在爬山途中时常隐于山林而外人不知你在哪里、在做什么，很多时候你都是一个人在战斗。上山容易下山难，从事CM职业时间越长，更换到其他职业的难度越大。 # ^; J& L0 \+ V6 I
+ `- p8 \4 L% B3 | r. S' _
一般说CM在国内的企业里就是指SCM，不过在我下面的描述里，SCM专指软件配置管理，CM专指产品管理。软件也是一种产品，那么SCM就是CM的一个特殊领域。 4 Z5 H: B& {- A
SCM ：董越的大作《未雨绸缪》里对SCM 有了详尽的描述，在此不再罗嗦。个人感觉每种SCM 工具都有存在的价值和适合的领域。但对于一个公司来讲，统一工具和工作方式带来的总体成本是最低的。工作方式要高效，然后尽量简单。如果软件工程师感觉不到SCM 的存在，而公司的软件资产又得到很好的保护，那SCM 一定做得很好了。有人说SCM 的工作很多时候是在划线，那是因为并行开发的需要。线多线少、哪里该画哪里不该画，没有固定的标准。如果有就是：保证软件资产安全的前提下、不影响效率，能少则少。
CM：很多公司的产品中既包含有软件、还有硬件，还有一大堆的用户文档。怎么对这种产品做配置管理？产品的定义可以很广：有形的，无形的。可以是硬件，可以是软件。可以是最终的要出售的，也可以是项目的活动集合。总之，要把公司的资产都分门别类管理好，在其生命周期各个阶段保持准确的状态。文档要依附于具体的产品或者部门，也应该有版本管理的策略。 * V. p) H9 C! r( L }* A
PLCM ：产品生命周期管理，包括产品管理和产品研发。CM 是PLCM 的一部分或者一个领域。PLCM 里还有其他的学科，例如：计划与控制产品生命周期、价格管理与商业包装、市场与终端客户分析、产品与方案市场化、需求分析、外包管理、产品信息、产品数据处理、项目计划与控制、系统定义与分析、软件设计、硬件设计、集成与测试、产品维护等等。无论哪个领域，好的经验要总结、然后再整理推广，形成良性循环，最终提高公司的产品管理与研发的整体运作效率。
BP ：BusinessProcess 。一个公司要运作正常，除了产品管理、产品研发，还需要战略决策，客户管理，业务支撑部门等等。
依据上面的分析，可以看到配置管理是什么What ：公司资产管理，在哪里Where ：SCM<CM<PLCM<BP ，至于怎么做How ：实践、总结、推广、再实践、再总结、再推广。 # J; o9 G6 {9 Q0 h+ N, C6 A& D
1 a6 J+ R o# s$ j- m7 T c: Y9 v3 n- [# P! L' T, E" i8 V; Y# u0 Z
SCM与CM的区别及联系
前面说到，SCM是软件产品的配置管理Software CM，那么两者有什么区别与联系呢？（这里以一个纯软件产品来举例） 一句话：SCM更关注于软件作为产品正式提交前的软件开发过程管理，CM更关注于软件作为产品提交时及后期维护的产品状态管理。即SCM与CM在整个软件生命周期里关注的期间不一样。SCM更偏重于开发过程，CM更偏重于固定里程碑时软件产品的状态。 5 }1 [/ M& u2 }/ ?# t/ N4 L
通常来说，配置管理数据库分为开发库DevelopmentObjects、受控库Deliverables、产品库Distribution Deliverables。那么SCM主要负责开发库里源代码的版本管理与受控库可运行程序的生成，CM主要负责产品库里产品的信息管理。 开发库：正在被开发的对象；没有被发布的对象；支持开发过程 受控库：被发布的对象 产品库：管理可以对外发布的对象；发布对象数据库；是受控库的一个子集
把SCM做好并不那么简单，但把它做复杂却是相当容易：可以把一个小的开发项目的SCM策略生搬硬套成标准的模型，图形很美观，程序员很痛苦。既然SCM人员要管理两个数据库，那么他/她的主要任务是：
; {) G5 r! x# O7 W b- 开发库版本管理策略
- 受控库管理策略，这里可能需要CM的协助
- 从开发库到受控库的Build过程，这涉及到怎么做Build，这里也有非常多的话题，象自动化编译、增量集成等等
CM人员管理的产品库要满足如下条件： 机密性：只有有权限的人才可以访问 完整性：保证产品信息的准确性和完整性 可靠性：提供信息和相关资产的访问 那么SCM与CM是怎么沟通的呢？看下图： 系统架构师Systemarchitect 《======》 产品配置管理员ProductCM || ||( Y! `, e. e3 T& c0 Y" ]" r
软件配置管理员SoftwareCM 《======》 开发工程师Developer
0 f: M; p. K: h, L! a# P
曾经想到过配置管理的6个层面，从下到上：
# u% l+ e- M9 Y$ G' B- SCM工具的使用。比如说大公司经常用到的版本管理工具ClearCase，缺陷管理工具ClearQuest，如果成为这方面的专家也是很不容易的。
- SCM与其它开发工具的集成。比如代码库ClearCase、缺陷及变更库ClearQuest、开发环境IDE、需求管理库RequisitePro、测试代码库Test Manager等等集成在一起，可以提高协同及开发效率。关于工具的集成，最好选用一家公司的产品，否则后期工具之间集成的开发成本与维护成本非常高。
- 自动化Build与测试：有很多工作可以自动完成。比如说编译验证：有新的代码进入开发库，马上触发一个新的Build。然后完成+ f* v g1 Z# e7 q" {7 C2 R/ Y7 D
一些基本的自动化测试。Build Forge是个相当庞大的系统，很多时候不如用一些简单的、上手快的，比如Hudson等。 - SCM与CM的统一。既然CM是管理公司资产的，就要对软件开发过程中的中间代码状态（Label）做统一标识。代码要分层次：系统System级的、组件Component级的、单元Unit级的，等等。软件代码也要有统一的版本变化策略，可以与其它产品统一制订。
- 公司级CM要统一：这涉及到怎么统一定义产品、文档的分类，状态的变化规则。产品库与文档库一定要集中统一管理，不要冗余，公司所有人看到的都是一致的状态数据（如果被赋予权限的话）。
- 公司的基本标准Basic Standards要制定好，例如：文档的处理与版面布局；产品的分类、编号与命名；信息与文档的分类、编号与命名；产品与文档的编号和分类的规则；产品处理及其文档管理；标记与追踪规则；元数据、术语、缩写；等等。
9 i" W9 s9 ^/ t+ W: r: `
从这6个层面我们可以看到一个公司广义的配置管理可以涵盖：软件版本管理工具的使用SCMTools->软件版本管理工具与其它开发工具的集成SCM ToolsIntegrated with other Development Tools->Build自动化Automation->软件配置管理与配置管理的统一SCMAlign with CM->公司级的统一的配置管理规则CMRules->公司级的基本标准Corporate BasicStandards。把各个方面都做好了，配置管理对整个公司的价值就体现出来了。 " m' N- c6 d q8 N9 Y* i: e3 O
7 j; S6 l0 _6 z: h' ?$ N9 C) |
八大处公园位于北京西山风景区南麓，有八座古寺(灵光寺、长安寺、三山庵、大悲寺、龙泉庙、香界寺、宝珠洞、证果寺)，“八大处”由此得名。八座古刹和著名的“十二景”分别承载着博大精深的中国佛教文化和中国文人文化，同时也构成了八大处独具魅力的核心旅游资源和旅游景观。
产品研发管理，很多时候就是管理各类信息与数据，这里列举八个相对比较重要的信息数据库，简称产品研发管理之八大处。这些信息数据的准确性与是否高效很大程度上体现了产品研发管理的成熟度。很多企业在产品研发过程中，经常进度延迟、费用超支、质量上不去，根本原因就在于管理能力之不足，但又找不到切入点。( L* z0 N0 H% C* m1 G! ^# C! E; v
通常我们说产品研发涉及到需求、设计、实现、测试等阶段。这里不讲软件工程、项目管理、质量控制，也不讲CMM的过程域与关键实践，容易一头雾水。本讲座尝试从理解“八大处”入手，正确管理每一类信息数据，从而提高整个产品研发的效率。
, I* A/ X2 @9 `. ~
【文档管理库】产品研发过程中，几乎所以的角色都要写文档，比如：需要说明书、设计文档、产品发布说明书、测试说明书、测试报告、用户手册，等等。要求：文档分类、版本变化规则、文档评审流程，等等。: j. ~, z4 i" N# [* u
6 I% G" K% L9 m; a& X
【产品信息管理库】产品从最初的雏形、到提交给客户、以及后期运营维护、淡出市场，是一个不断成熟再到衰退的过程。在此过程中，要定义在各个里程碑时产品的状态。要求：产品生命周期定义、产品分类、产品状态定义，等等。6 I3 Y- o& f' _% ^5 _6 k
& ~( J7 [7 q( W& V4 v0 {- T5 d1 k: M
【代码配置管理库】软件在产品中的比重越来越大，代码的变化比一般的文档要快，而且代码之间的逻辑结构是相互依赖的，所以一般要有专门的代码管理工具来保存代码的版本变化以便回溯。要求：配置项定义、基线计划、代码版本变化规则、发布管理、基线变更规则，等等。
% `* L) }/ h8 F% _
【需求管理库】产品的需求最初来自于客户的描述，需要进行细化转换成技术化工程化的语言。要求：需求的收集及客户的反馈、分解、细化、追踪，等等。 9 D$ I+ q& c6 g: _7 G
【变更管理库】变更管理一般是针对需求变化的。客户的需要是不断变化的，而且趋势越来越快。这种变化会影响到设计、实现、测试，如果控制不好，项目就可能被拖入变更的泥潭，不能自拔。要求：变更流程合理、可控、可预见，等等。) }4 n. K# X1 `& I) w9 L# {
' t3 T4 E" s$ h
【缺陷管理库】既然研发的产品是一个不断成熟的过程，缺陷就在所难免。缺陷可能来自于测试人员、开发人员、设计人员，等等。要求：缺陷流程要易用、合理、角色分工清晰，等等。
+ b% {8 |) Z' k- ?7 | X% Y$ c/ r& V
8 i& K/ Y. N8 v- D
【客户反馈管理库】产品提交给客户后，在运营维护过程中，客户会提出对产品的意见及建议，相应的会有此类问题的解决方案。要求：与客户的交流渠道通畅、快速，解决方案要集中管理、可重用、不断完善，等等。 ' g7 r3 ~9 n' ^$ ]2 k
【测试用例管理库】测试人员要对产品进行测试，必然要有很多测试用例、测试场景。要求：与需求能对应、与缺陷可关联，等等。
“八大处”作为产品研发支撑系统，并不是彼此孤立的，信息数据是应该可以在不同系统中间流动的。研发项目应该集中精力在项目本身，仅仅是“八大处”的使用者。那么对“八大处”集成有什么要求呢？; p* t* o) L7 N- Z4 u
9 A, a7 z- y& s+ u# C% z
公司要统一管理：信息要共享/ |4 O& {8 g; u: @6 m! j
各个库之间的联系与集成：数据可以流动
数据可追踪：需求->设计->实现->测试->缺陷
数据反向追踪：缺陷->测试->实现->设计->需求+ z {. Q0 G+ l( b
缺陷引入分析：引入缺陷的薄弱环节；缺陷分类与趋势分析
里程碑检查表：输入与输出检查& L5 A& g* d/ F: C. W5 R3 u4 c8 E
代码复查：提高代码质量与可读性
代码质量等级：完备的等级评测标准
。。。* U4 T! z, m" v& s& |
上一篇：配置管理的绩效考核
下一篇：配置管理的三大误区 | 
[复制链接]
service@step365.com
0571-87357690
狗仔卡
发表于 2012-4-10 10:05:14
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡