项目范围管理六个过程 范围管理( 三 )


1628年8月10日,还没来得及离岸的瓦萨号在一场大风暴后开始倾斜,随后慢慢恢复平衡,但随后又向右舷倾斜 。岸上的人都傻眼了 。瓦萨号的下甲板正慢慢入水,船体开始摇晃下沉 。瓦萨号在众目睽睽之下沉没了 。
范围控制
控制范围,不是改变需求,不是用显示器砸老板,而是保证范围的正确改变 。对于可能的、合理的范围变更,要积极分析是否有价值,尽量为高价值的需求变更创造条件 。
在分析范围变更时,需要重点关注对项目价值、项目策略、项目质量、项目周期、产品目标成本等的影响 。在变更时,还需要考虑:项目中需求的冗余和错误,新技术引入带来的风险,以及连锁的需求变更 。
CCB(变更控制委员会)在CMMI(能力成熟度模型集成)中是“变更控制委员会”的意思,也是配置控制委员会的意思 。
CCB可以由一个小组或几个不同的小组持有,他们负责决定应该应用哪些建议的需求变更或新产品特性 。典型的变更控制委员会也将决定哪个版本纠正哪个错误 。当建立包括硬件和软件项目的CCB时,它还应该包括来自硬件工程、系统工程、制造部门或硬件质量保证和配置管理的代表 。
CCB是系统集成项目的所有者权益代表,负荷决定接受那些变更 。CCB由许多参与项目的成员组成,通常包括用户的决策者和实施者 。建行是决策机构,不是经营机构 。通常,建行的工作是通过评估的方式决定项目是否可以变更,但不提出变更方案 。
对正式基线(需求基线、概要设计基线、详细设计基线、代码基线、测试基线和操作基线)的更改必须由项目团队的CCB审查和批准 。正式基线,例如客户需求和操作基线 。基线的正式控制机构是CCB,CCB的主席通常是组织中的高级经理 。在项目期间建立的开发基线,例如设计和代码基线以及测试基线,是由项目经理和/或项目技术负责人非正式控制的 。
对于初创团队,需求变更也应该是:有制度,有记录,有讨论,有跟踪;而不是随意更改 。否则,船还没出海就沉了 。
范围验收
在项目结束时,或者中间节点,你可以检查项目已完成部分的可交付物的过程 。可以根据需求跟踪表或需求跟踪矩阵进行检查 。
方法:可以是评审、内部测试、客户测试、实验验证、访问测试、认证测试等活动的集合 。
总是要看我们做的是不是客户想要的 。
最后祝各位老板好 。
提醒一句,如果工程师会空武术、跆拳道、截拳道、中国功夫,在就业上就成了劣势 。找工作的时候,注意隐藏这些经验或者技能 。
【项目范围管理六个过程 范围管理】

推荐阅读