我的实际体会：
- 总结会，每个迭代都进行，把反思改进形成习惯。（这是之前没有的）
- 团队敏捷成熟度自评，关注团队成长。
- 计划会：共同估点，过故事细节，尽可能减少功能遗漏，并让大家对需求的理解一致，避免业务误差。
- 流式交付：让测试人员对开发交付时间点有明显的概念，据此作出测试计划。让开发人员之间协作更加协调，尤其功能有交互的时，避免彼此间的盲目等待。
- 故事估点：可以衡量一个团队的产能。工时则不可以。估点与估时不是等比换算关系。
- 用户故事：是需求的具现化，是需求的脉络。让团队对整个需求业务有宏观的了解和整体的概念。
- 每日晨会，彼此都了解进度，彼此知道在做什么。
- 提升了产品发布效率，但没有提升单位时间内的代码量（开发效率）。
- 成员之间透明，每个人都可以随时了解之间的开发进度，尤其有依赖时更显得重要。每个人都可以随时了解Sprint的整体进度，以随时调整。
最直接受益者
- 通常高层领导和客户最为关注产品的发布速度，使用敏捷后，每个迭代都有产出，因此二者是最有体会的。
- 对于一般程序员或测试人员，使用Scrum后，相比之前增加一些会议或实践，反而会感觉增加了负担，占用了开发测试时间，并没有体现“敏捷”。感受不到Scrum的好处，因此容易出现抵抗情绪或不解。
