迭代管理

上一篇 / 下一篇 2014-05-28 10:42:59 / 个人分类：总结

迭代管理
等级3		3级：自适应项目管理
	查检项		满足?	访谈参考问题
*参照标准*	需求优先级可以以迭代为单位进行调整。			1、计划的精细程度？整个项目只有一个计划，还是每个迭代都有计划？ 2、计划有多长？几个月，还是几个星期？ 3、在项目进行中发现业务重心发生转移，如何应对？ 4、交付是否分为若干次发布？ 5、迭代计划谁来参与制定，根据什么制定？ 6、每个迭代多长？周期固定么？ 7、项目状态报告如何获取？ 8、如何更新进度？你如何了解项目进度？ 9、迭代是否交付可工作的软件，是否交付价值？ 10、团队成员是否熟悉迭代流程和Story流程？ 11、迭代中的Story能否独立测试？ 12、是否有有效的可视化管理手段？ 13、团队成员是否有迭代的意识？ 14、是否有风险管理机制？ 15、如何处理需求变更？
3.3.1	迭代内部发现有需变更（story优先级及交付顺序），并及时调整需求列表和迭代计划		√
3.3.2	研发人员结合业务开发主动质疑并推动向正确的需求澄清及变更，并跟踪调整		√
3.3.2	一个或几个story（业务应用场景）进行验收并发布状态报告		X
3.3.3	定期的项目状态报告发布		X
满足迭代管理 - 等级 3?		是否自适应项目管理，持续业务参与？	X
等级2		2级：项目状态报告反映项目路径
	查检项		满足?
*参照标准*	固定长度的、短迭代周期，有足够的自动化收集的数据支持迭代计划制定，项目成员共同参与迭代计划会议。每个迭代交付价值。
3.2.1	迭代前提前识别变更（story优先级及交付顺序），并及时调整需求列表和迭代计划		√
3.2.2	迭代计划的制定基于团队生产率、需求估算等因素决定的。		√
3.2.3	迭代前明确该轮迭代的需求、计划及风险		√
3.2.4	迭代结束对需求进行验收，发布迭代状态报告		√
满足迭代管理 - 等级 2?		项目状态报告是否反映项目路径，迭代变更管理？	√
等级1		1级：决策视角是迭代长度
	查检项		满足?
*参照标准*	决策视角是一个较短的时间窗，通常不超过3个星期。需求以能在此时间窗内完成的方式表达。 6wG ^n}M0
3.1.1	定期审视，明确该期间内的需求		√
3.1.2	间隔期间的需求变更、风险等在定期审视时才统一决策执行，发布该时间窗的版本状态		X
3.1.3	需求列表、风险跟踪等定期维护刷新		√
3.1.4	刷新发布计划时进行根据当前需求优先级进行需求列表的调整		√
3.1.5	在需求列表中注明需求得优先级、工作量、难度级别对用户带来得受益等		√
满足迭代管理 - 等级 1?		是否有计划内和计划外风险意识，短交付周期？	√
等级0		0级：按发布做计划
	查检项		满足?
*参照标准*	按发布做计划。
3.0.1	已知的变更到某一个阶段点才能执行		X
3.0.2	计划中未考虑变更控制，需求变化了临时应对		X
3.0.3	没有明显的应对风险和变更的措施		X
3.0.4	一个发布通常不超过3个月		√
满足迭代管理 - 等级0?		是否应激式风险应对和变更控制？	√
等级-1		—1级：缺乏灵活性、长周期交付
	查检项		满足?
*参照标准*	计划的制定跟团队生产率、需求估算等因素无关。计划决策视野是整个项目的长度。
3.-1.1	有正式的变更控制规范但执行僵化，已知的变更到交付的时候才能统一执行		X
3.-1.2	开发（能力或流程）中只能适应少变更或不变更，否则对版本影响巨大		X
3.-1.3	变更会让版本交付周期变的很长或不可预知的交付时间		X
3.-1.4	项目开始就制定整个项目周期的计划，并且计划执行僵化，到项目结束才审视项目的交付是否合乎要求		X
3.-1.5	风险、变更等管理意识僵化，只对计划内的风险预防，计划外的风险、变更即使识别在项目整个周期内不会跟踪管理（项目范围有大的变化，并不是及时调整，而是等项目结束后才统一审视发现不符合要求）		X
3.-1.6	需求列表、风险跟踪表等整个项目期间无需维护		X
满足迭代管理 - 等级 -1?		固定的项目计划，缺乏灵活性？	√