I、敏捷提升阶段，但是目前看不到实质性提升（开发回顾会过程中的质疑）
一、迭代做的比较好的地方：
1、各组组员一个人干一件事，工作专注，驱动力强，保障了迭代工作按时上线
2、迭代遵循工作计划，前期做好设计评审，过程推动强，各个环境均时间点提交，提测质量高
3、成员责任心、主动性提高，主动推动工作进展，各环境保障质量提高
（补充）4、千行代码缺陷率由之前的3~4‰ 降低至现在的0.8‰
二、被表扬人
1、戴XX，接口同事称赞，协助开发同事分担汇集基础工作，帮助产品分析问题；
2、陈XX、王XX受产品、测试团队表扬，能够清晰理解分内的工作及工作量，给与砍掉需求提供有利支持；
3、团队内部相互感谢相互支持，迭代工作顺畅，整体团队气氛更为融洽；
敏捷团队建设，有一个非常简单有效的方法就是“看见”，我/我们看见了“ta”为我们做的一切，同时，让"ta"知道我们很感激——提升团队认同感。
所有这些不仅是体现了做事的提升，还体现了做人——团队文化的一种提升。
这个问题个人补充说明两点：
第一、关于提升，除了这些做到比较好的地方，还有一个比较“实质性提升”就是：千行代码缺陷率由之前的3~4‰ 降低至现在的0.8‰。
第二、我理解这个问题之所以被提出来，可能是对“敏捷”还存在一些误解。
我简单澄清一下概念，敏捷源自“精益”和“持续改进（PDCA）”，它是一种思想，scrum、xp、看板等都是在这一思想指导下被创造出来的实践。
但并不是说只有在这些实践下产生的提升才是敏捷引起的提升，而是说我们所做的一切行为、措施等引起的提升，都是在做“敏捷”，也可以说在做“精益”，在做“持续改进”
敏捷是个大概念，scrum、xp.....不能代表敏捷，也就是说即使不用哪些已知的敏捷实践，只要我们在向着目标不断改进和提升，就是在敏捷。
而敏捷与“持续改进”最大的不同就是，更注重人和文化。敏捷团队建设的核心是让所有人放心的说话（没有批评只有包容），贡献智慧，最终建设成为“学习型组织”以便在VUCA时代可以应对变化。
II、接口团队前期工作过于紧张，总体工作量要一周内完成70%，提供测试团队测试、提供前端联调（开发）
III、需求设计还是相对紧张，因为工期砍了部分需求，影响了产品设计质量，对需求有临时调整（产品）（计划相关）
IV、由于时间紧，临时砍掉需求，给产品带来了需求设计上的困扰（产品）（计划相关）
V、后期需求影响到前期需求的前端框架，具体为权限功能变更，前期没有，后期提出来，首页功能布局后期设计与前期设计不一致导致前一迭代修改（前端）（计划、需求相关）
II~V几个问题是我概括了一下是属于“应对变化的问题”，这是敏捷要解决的核心问题之一，在会上没有结论，建议咱们再组个会研讨一下，请各位定个时间通知我。
尝试GROW模型
G（Goal setting）：设定，目标
R（Reality Check）：现状，要搞清楚目前的现状、客观事实是什么；寻找动因；what, why
O（Options）：寻找解决方案；
W（Way Forward）：代表制定行动计划和评审时间
