在实际的开发过程中，难免有些工作方式或做法违背了敏捷的原则，所以我们需要不停的纠正或改进我们的工作方法来适应敏捷的12条原则。
敏捷的12条原则：
1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人构建项目。给他们提供所需要的环境和支持，并且相信他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该都能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单 - 使未完成的工作最大化的艺术 - 是根本的。
11. 最好的架构、需求和设计出自于自组织的团队。
12. 每隔一定时间，团队会在如何才能更有效工作方面进行反省，然后相应地对自己的行为进行调整。
由于我们公司项目的特殊性，我们的项目都是有ODC成都和新加坡总部两地人员一起合作完成项目。PO都是在新加坡，所以我们很难做到原则中的第4、6条。为了解决这个问题，我们主要采取以下几种方法：
- 把所以队员的电脑换成笔记本，这样方便进行1对1的视频会议。
- 对于对于史诗级TASK，提前计划会议，然后在Meeting Room和PO远程会议讨论。
- 项目的计划会议，回顾会议及评审会议都采取远程视频会议的方式进行。
其实在项目一开始的期间，我们还有违反过第7条。当开发人员将开发的分支Merge到主分支时，总是出错。最后发现主要原因是成员测试的不够充分。采取方式如下：
- 这个问题的主要原因是，队员对DoD没有统一的认识。项目一开始没有定义项目的DoD检查清单。所以我们立即举行一个会议来定义我们项目的DoD检查清单，让所有队员的完成的定义，有一个统一的认识。
- 交叉Review，Merge。开发队员完成任务后，提交Merge Request，由另一个队员review他的Codes, 然后merge到项目的主分支。
