配置管理是个“小怪兽”

客户需求,将软件开发的管理诉求推上新高度

那么按照这个逻辑,软件研发的管理,也应该越来越厉害才对啊~ 

然鹅……很多初级的软件项目管理问题,仍然困扰着我们。细想想,为啥大家嘴上一直说“管理很重要”,行动上却又不愿意为此投入呢?一张图告诉你!

软件过程改进管理的转折点

我一直在想,在项目管理的众多领域里,到底哪一个,可以快速反应出管理改进的好处呢?项目经理帮我找到了答案。

项目经理最怕需求变更和人员管理

这挺让我欣喜的,这正好论证了我们建立的PM核心能力架构的双支柱——过程能力和领导能力。

软件的需求哪有不变的,为啥需求变更让人如此“害怕”呢?控制变更的“变更过程”从概念上讲是比较简单的,但执行起来却复杂的很——因为需求变更驱动设计变更,设计变更影响代码,后面,测试可能发现进一步变更的问题,导致原始需求的变更……即使小规模的项目,参与变更的人员和工作量都大的惊人,如果不进行有效的管控,将引发不计其数的各种问题。

既然变是恒常,除了佛系一点,还能咋办?

配置管理与软件生命周期

变更是引入配置管理最为重要的原因。不能停止变更,就只能管好变更。变更的发生通常很“任性”,这就基本上明确了配置管理的跨度,将伴随整个软件生命周期。

由于配置管理,覆盖到了整个软件生命周期的全部重要产出,因此,它还能解决很多其他常见问题,比如:

-       需求、设计、编码、测试等工作产品的不一致性

-       无法找到软件的前一版本

-       产品升级和维护的时候,找不到软件的相关资料

-       编码未经测试,就集成到软件中,导致整个系统崩溃

-       谁都可以获取项目资料

-       ……

列举的这些小问题,看起来都很“低级”,但小问题,一样要命。就是不久前,一个做大数据平台的同鞋跟我抱怨。项目组刚花了大量的精力修复了一个高难度的bug,测试也通过了,上线后,居然原来的bug又出现了。活见鬼!项目经理的电话都快被客户打爆了。大家又搞了三天才明白,原来是版本弄错了……

配置管理可以通过协调项目中不同人员的工作产品,来帮助我们降低这些问题发生的风险。

对于配置管理的定义有很多种,我选择了Wayne A. Babich在著作Software ConfigurationManagement: Coordination for Team Productivity中的定义。

“协调软件开发使得混乱减到最小的技术,叫做软件配置管理。它是一种标识、组织和控制变更的技术,目的是使错误达到最小并最有效地提高生产效率。”

Babich除了对配置管理做了准确的定义之外,还说明了配置管理之于提高软件开发效率的好处。虽然这本书已经相当久远了(写于1986年),其对于配置管理基本概念的阐述,今天看来,仍是经典。

实操层面,我们应该参考能力成熟度模型集成CMMI里,对配置管理的实践建议。毕竟CMMI来源于全球顶级软件企业的优秀实践集成。

综合以上,对配置管理做一个系统梳理:

配置管理的目的:在软件项目生命周期中,维持工作产品的完整性和一致性,减少由配置问题引起的混乱,提高软件开发生产率,降低成本。

配置管理的核心:管理变更

配置管理的关键实践:

-  最简易的配置管理——版本控制

-  配置管理策划

-  软件项目中到底什么应该受控?——配置项

-  符合项目需求的配置管理系统

-  建立和发布Baseline

-  配置管理真正的核心过程——跟踪和控制变更

-  软件开发过程的“库存盘点”——配置项状态报告

-  配置和QA的深度合作——配置审计

配置管理既然能够完整覆盖整个软件生命周期,以及所有重要的工作产出,可见配置管理并不是配置管理员一个人的事,而是与所有项目成员息息相关。它通过工作产出,将过程管理与人员管理关联起来。真的不能小看它哦~ 不然……

 

【项目管理好文推荐】

 

PM根本不是PM,你造吗?(PM核心能力框架)

千万不要相信“只要进度”这种鬼话,质量才是PM安身立命的根本

放下技术,是PM迈出的第一步……

PM过程能力成熟度2级

从PM到非洲酋长,得人心者得天下

凡奉首页    管理实践    CMMI管理实践    配置管理是个“小怪兽”
创建时间:2018-10-19 00:00
收藏