文章探讨了在敏捷开发过程中如何通过迭代评审和回顾会议来适应调整，以实现价值交付。团队展示评审工作产品，基于故事点计算速度和评估性能。同时，利用燃尽图等工具监控进度，强调不应跨团队比较速度，而应关注稳定性和持续改进。
适应阶段实践
通过持续的反馈和适应以调整项目，交付价值
迭代评审会议、迭代回顾会议
展示评审、技术评审、速度、燃尽图
展示与评审
团队完成特定功能时，团队定期展示工作产品，展示后，PO接受或拒绝故事
- 迭代结束时展示
- 频繁交付
- 良好的愿景盒持续反馈
- 不断交付，越短越好
对产品价值、产品质量、团队绩效、项目状态进行展示和评审
常见评审：客户角度审查产品功能，工程师角度审查产品技术质量、团队角度团队绩效评估、项目整体状态审查
敏捷中的挣值
- 在迭代中使用
- 基于已完成的功能
- 按照故事点计算，SPI 为已完成的故事点除以计划完成的故事点
- CPI是已完成的功能值除以实际的成本
速度的概念
本次迭代中实际完成的故事点大小的总和，让团队得以通过观察历史表现来准确的规划下阶段的能力
速度的计算
不会根据别人的期望计算速度
基于已完成的用户故事
1速度=1故事点
速度的展现
燃尽图、燃起图、发布燃起图
速度的监控
以团队的实际能力为准
- 基于经验和价值的衡量指标
- 仅限于未来的几周
- 敏捷不能创造出更多的工作能力
- 在不同的团队横向比较速度是不明智的
- 最好的情况是速度达到稳定持续
回顾
迭代回顾会议，指向未来
结束阶段
扫尾、复盘、庆祝
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
