纳入基线管理的经验原则
发布于 2024-10-03
1171
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
基线管理原则摘要
原则1:所有交付客户的成果,包括文档、代码、可执行程序以及购买的可复用构件都应该被纳入基线管理。
原则2:任何影响对外承诺的配置项,例如项目的阶段计划,都必须被纳入基线,以便进行有效管理。
原则3:所有对交付产品有显著影响的文档和资料,特别是关键的工程文档如需求和设计文档,都应该加入到基线中。此外,区分主动变化和被动变化,特别是主动变化必须被包含在基线之内。
原则4:仅有变化的文档才需要纳入配置管理,而不变的文档通常不加入基线。
这些基线管理原则的优先级是递减的,并且由项目组的配置管理员和项目经理共同负责确保这些原则得到实施。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 829.8K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
我说CMMI之七:需求管理过程域
我说CMMI之七:需求管理过程域先讲讲需求管理的含义。何谓需求管理?需求管理就是管理需求的一致性。这里讲的需求指什么?指的产品与产品构件需求,对于软件而言通常就是软件需求规格说明书(SRS)。在CMMI模型中将需求分成了2类:客户需求,产品与产品构件需求。客户需求是采用用户的术语表达的,用户验收的依据,一般是由客户提出需求,由开发人员记录、描述、整理下来。客户需求是平衡了客户的需要、期望、约束和接口需求后的结果。产品与产品构件需求是采用开发人员的属于表达的,是开发方验收的依据。产品与产品构件的需求是基于客
软件项目策划时常犯的12个错误
大概总结了一下,有时间再展开详细论述吧: 1 任务的颗粒度悬殊太大 2 任务的识别不全面,如: 没有识别出计划(PP,PPQAP,CMP,MAP等)评审的任务 没有识别出来计划修订的任务 模块间集成的任务没有识别出来 3 只做了工作量估计,没有做规模估计 4 只凭1或者2个人的经验进行估计,没有采用规范的估计方法 5 没有计划偏离的控制阀值 6 没有获得项目组成员对计划的承诺 7 在schedul
如何确定测试的重点?
测试投入不足是大多数项目都面临的棘手问题。在此前提下,如何最大限度的提升软件的可靠性呢?本文给出了一个简单框架,帮助组织与项目组定义自己的测试策略、测试重点。
和任老师聊聊质量工作
2019年10月12日在厦门有某公司的6位质量管理同仁一起共进晚餐,席间讨论多个话题。10月14日,这些有心的朋友整理了问答记录,我做了简单修订,摘录如下:SQA感觉成天统计数据,没什么意义?统计数据可以,对于SQA来说,要掌握数据分析方法,从数据中找出规律,得到结论,有明确的结论来影响大家。有数据,必须有结论,这样才能充分发挥数据的价值。比如...
案例:非功能性需求的设计
很多项目组在设计文档中仅仅是把非功能性需求的描述拷贝到设计文档的非功能性章节。因此特地设计了两个简单的需求给大家参考,希望能够引导设计人员重视非功能性需求的设计。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线