实施敏捷管理之后，团队连续两个迭代的交付没有完成承诺。
在回顾会议中，大家认为是因为开发之后代码缺陷率比较高导致的。
进一步往下追溯，团队认为，代码的缺陷来源主要是系统的架构不够灵活，耦合度高，一个修改可能影响到很多地方，但是这些影响却没有在代码开发时被识别出来，直到功能测试时才暴露。
而这个暴露的是：
1. 业务架构没有预先做好设计，功能的简单堆叠导致页面逻辑复杂。
2. 开发前团队没有做好模块化设计，导致系统的结构越做越烂。
3. 团队没有重构的习惯。
为什么会有这些问题呢：
1. 业务缺乏对产品的整体观。
2. 团队被需求追着跑，更倾向于使用战术开发，短期内让功能跑起来，而不管长期的扩展和复用。逐渐的团队的效率下降，反过来又影响需求的交付。
聊清楚这些问题后，经过和PO的商议，团队做出了以下两个action decision：
1. 每个迭代开始前，在已有的planning会议基础上，增加一个需求梳理会议，理解需求，共同做好业务和技术架构设计。
2. 每个迭代中预留10%~20%的空间用于系统的优化重构。
3. 代码集成前需要经过peer review才能提交。
