如何在组织内成功运用项目管理最佳实践培训 -精简1天版.ppt

* * * * * * * * * * * 用来做质量管理的钱，以丰田公司油门脚踏板事件为例，本田公司汽车的破坏测试为例 * * * * * 1、评审之前准备充分，并提前1周发给与会人员待评审的资料，确保与会人员有时间提前看完资料并带着问题来。 2、待审文档齐备包括评审规范和评审标准（什么算通过和什么算不通过），最好有评审的Checklist。 3、会议参与角色全面，该来的相关角色一定要来，如项目经理、产品经理、测试经理和销售等。 4、可以平均每页需求或设计文档都需要找到1~2个问题。需要发现足够多的问题。 5、与会人员提出的疑问都需要有最终解决的方式。（阶段评审的结束标志） 6、会议一定要有结果或决议，并需要参会人员确认并签字。 7、凡事涉及到需求和设计文档中内容描述模糊的地方，需要具体分析其所对应的业务场景和流程，做到进一步清晰细化，确保内容的一致性和完整性。 8、讨论结果或决议需要认真落实，对大家共识的问题需要有直接负责人跟进，并设置目标完成时间和检查方法。 9、如果评审的问题过多，按照评审标准，达到二次评审提交时需要进行二次评审。 10、针对设计评审，还需要考虑非功能性需求是否都在设计上有所体现，并有多个可选设计方案进行比较和分析。并且，需要在设计评审上进一步论证方案中的假设或约束条件是否还存在。 11、最终评审报告需要签字，报告内需要对需求进行偏差分析或设计上的重大缺陷进行论证，必要时需要最终和客户确认。（最终评审的结束标志） * 1、测试路径所对应的代码行覆盖率的百分比，最好80%，甚至是90%以上。 2、平均一个软件功能点的User Case至少有几个（4-6）Test Case。 3、测试数据的边界（Boundary）需要有不同的覆盖（利用业务流程图，判断业务流程和数据是否完全覆盖）。 4、评审通过后的测试计划中要求的非功能性需求的测试都需要做（比如，压力测试，并发测试）。 5、考虑测试功能点的级别，并做到充分的回归测试（测试用户常用的功能或凭经验制定回归测试的范围）。 6、基于历史数据，平均每千行代码的Bug发现的数量进行比较分析，比如平均1000行代码有2个Bug,2万行代码应该找到40个Bug。 7、测试验收标准的明确和可衡量，这个在需求和设计文档中就需要有明确的规定。 8、建立独立审查开发和测试的结果的机制，比如PMO或第三方执行独立审查，确保测试的充分性。 * * * 规格上下限：客户或合同规定、超出产品不合格 控制上下限：PM和相关干系人确定、超出过程失控，但是产品合格 以如何向上沟通举例，15个通常项目管理问题举例 * * 变更经审批后，要先记录变更结果，更新项目文件，然后通知受影响的干系人，才能带领团队执行变更。 * 此处介绍需求分析的方法 * 软件架构常常表现为分层的层次结构，将架构的结构描述为一组视图(View),每个视图关注不同的部分。 基础视点为通常需要关注的内容。交叉试点是不同干系人关注的不同内容。 以上框架中每个视点的描述应包括下列条目： 描述：该视点的概要描述； 利益相关者关注点：该视点处理的利益相关者的关注点； 利益相关者：该视点处理的利益相关者； 工作产品：由该视点定义的视图所引用的工作产品； 技术要素（可选）：应用该视点时引用的技术要素； 举例说明：一个或多个例子； 检查列表：当需要检验和确认架构或与利益相关者一起复审架构时可以考虑的一个或多个问题。 ? 架构师在做架构设计时可以通过对架构描述框架进行必要填充来分解架构设计的关注点和工作产品，实现架构的最终交付设计。 * * * 此处举华润和政府的需求管理流程 * 此处举合同关于需求变更的规定 * 此处举合同关于需求变更的规定 * * * 应该是第二象限，80%的工作应该是重要不紧急的事情 * 进度是开始时间和结束时间，工期是从开始到结束的一段时间 工时=工期x资源单位。 工期是任务的时长，工时是资源的时长，当一个任务分给一个人做，工时等于工时。 * 里程碑是一个时间点，用来排列活动顺序。 强制性里程碑通常是合同要求的，比如强制的交货日期 选择性里程碑通常是根据经验设置的，用于项目状态的监控。 * * * 不可以，里程碑的达成与否，与项目的绩效息息相关 * * ADFKL2+5+4+4+3=18 （18-4=14） BCDFKL3+2+5+4+4+3=21 （21-4=17） BCEKL3+2+0+4+3=12 BCEHL3+2+0+5+3=13 BGHL3+7+5+3=18 D changed from 21 to 18 , C is correct * 1、关键路径是项目中时间最长的活动顺序，决定着可能的项目最短工期。在进度网络图的各条路径中，总工期最长的那一条或那几条； 2、关键路径不考虑任何资源限