实施了CMMI的项目周会和里程碑会议应该如何开？

项目周会过程
	问题1：你的工作是否和原计划有偏差？
	问题2：具体会有哪些偏差？
	问题3：偏差的数据记录在哪里，保存在哪里？
	问题4：数据的来源是什么？
	问题5：谁来检查这些数据？谁来记录这些数据？
	问题6：记录的数据跟谁汇报？
序号	原计划	现实情况	执行情况	最终结果	现在要求出具的证据
1	按照一个项目正常的流程开始做，做需求 做剪裁、做估算、做计划
2	对照WBS的工作分解，禅道每周录入工作任务	没做	录入的任务时间不正确	不能发现工作任务之间的逻辑关系
3	项目经理根据录入的工作任务关闭禅道的任务	没做	项目经理通报工作任务	录入禅道的任务是否和WBS有偏差，不清楚	检查每个文档的出具时间、文档中任务花费的工时 （评审、培训、QA检查、CM管理）
4	项目经理完成任务工作检查后，得到项目的偏差数据，然后填表	没做		工时统计不正确、工作分散无法聚集到一起，CMMI2级都达不到	工时偏差的证据是不是禅道里面记录有
5	QA汇报过程检查和产品检查、各种评审的问题、工作量，度量与分析的结果。	没做	现场进行QA审计，耗散大量的人员会议时间	工时统计不正确，偏差统计不出来
6	CM汇报配置项状态和基线发布、变更情况、工作了，度量与分析的结果。	没做		配置项状态报告没有记录WBS 调整后的文档变化情况	文档提交的时间、版本、作者、审批、QA检查、评审
7	需求工程师汇报需求调研的过程， 用户需求和需求规格说明书的跟踪情况、工作量、度量分析结果。	没做		工时和提交的文档时间不匹配。需求跟踪没有任何依据。	是否项目组评审、QA审计和王炜做的技术检查
8	设计工程师汇报软件设计花费的工时， 提交的文档和时间，是否通过评审	没做		工时偏差统计不出来	是否项目组评审、QA审计和王炜做的技术检查
9	开发工程师汇报编码花费的工时， 产品版本的集成情况，汇报需求跟踪情况	没做		开发人员不清楚集成过程， 无法回答问题，并且这个问题没有能够及时被项目组发现	是否项目组评审、QA审计和王炜做的技术检查
10	测试工程师汇报测试的工时， 产品的缺陷情况，汇报需求跟踪情况	没做			是否项目组评审、QA审计和王炜做的技术检查
	会议分为：项目周例会、项目里程碑会
	会议准备
	1.会议前PM、CM、DE、TE、QA各自去准备开会需要的报告，报告的内容见《CMMI3项目文档一览表》。 比如：QA的工作，根据WBS计划安排，QA做过程审计、产品审计，出相关检查表和检查报告。禅道系统中录入自己本周的工作任务，计划工时和实际工时。 注意：里程碑会议和周会每个人要准备的报告是不一样的。
	2.周会议期间内的工作任务已经录入完成，并标识任务的状态是否完成。
	3.WBS已经设置了基线，并且有CM保存了基线的版本。
	周会召开
	1.会议上各个成员去汇报自己本周的工作成果，出具文档或者代码成果（检查文档的撰写时间、撰写文档花费的工时、撰写人这些都对不对）。
	2.项目经理决定是否工作任务完成，并关闭工作任务。在WBS上更新任务完成的时间、花费的工作量、实际完成工作的人员（要更新WBS达到统计工作量、成本、进度偏差的目的）。
	3.QA协助项目经理在会议上，填写每周的《项目数据跟踪表》的工作量统计、进度偏差、会议记录。
	4.项目组成员协助项目经理填写《项目风险管理报告》、《项目问题跟踪表》。
	5.CM核对本周配置项的提交情况、是否评审、是否QA已经进行了检查，保存本周的《配置项状态报告》。
	6.本周会议结束后，本周的度量分析结果提交到svn保存。
	7.随机从问答系统中，抽取几个问题询问各个角色，回答不出来，现场无法给出答案的问题，将问题记录下来。
	8.本周的工作成果已经检查无误，且已经达到基线发布的条件，然后由CM完成基线发布申请表、基线发布报告。
	9.一周的工作会议结束后，再进入第二周的会议。
	里程碑会议召开
	1.里程碑会议是将各个阶段的数据进行汇总，因此要准备各项需要准备的报告、录入禅道的信息要完整并且经过了项目周会的检查。
	2.里程碑会议期间，项目经理要安排人员填写各类度量与分析的表格，QA确定要填写的度量与分析表格，并进行模板的分发。
	3.为减少大家的工作量，本周召开了里程碑会议，就可以不再做本周的项目周会，在WBS上面将周会标注为XXX里程碑会议即可。
	4.里程碑会议发现的问题、风险同样需要记录到《项目风险管理报告》、《项目问题跟踪表》。
	5.上个里程碑如果进度、成本、资源、问题较多，需要回顾上个里程碑的数据，以及发现的问题、风险是否解决。
	6.里程碑会议结束后，QA检查数据度量与分析表是否填写完成，需求跟踪是不是也做完了，然后提交到配置库保存。
	7.CM发布基线。
	会议例外情况处理
	1.会议过程中，发现WBS中的时间或者任务有问题。
	解决方案：
	a.如果是发现任务的时间、人员、交付物不正确，没有发布基线时，可以立即修正，然后通知CM进行更新，项目成员下载最新版本。
	b.基线已经发布，将累计错误修订后的版本保存好，然后申请WBS的变更。 WBS的变更不引起计划基线变更时，可直接变更WBS，不变化基线版本。 WBS的变更引起计划基线变更，CM计划、QA计划、MA计划、总体计划修改完成后，CM重新发布计划基线。
	c.实际的工作任务多出WBS时，保存过基线的WBS可以直接增加任务，并记录任务的信息。
	d.进度、成本的偏差大于或者小于某个值，项目要进行风险的管理，严重超标，可能是计划做的不对，要修改WBS和项目计划，重新发基线出来。
	e.实际任务完成情况和原计划有偏差，属于正常情况，只要度量分析的结果不超过规定的值，原计划可以保留继续使用。超过规定值后，由项目经理决定是否沿用原计划，还是做计划的变更。
	2.与会人员没有做会议准备，比如禅道的任务没有录入完，某个报告没有做等。
	a.准备的内容是否差的太多，取消会议，另外安排时间。要记录是谁未完成什么工作导致会议不能进行。
	b.准备的内容可以现场完成，会议继续。