最近两个月，加入一个engineering的项目，项目采取的是敏捷 Scrum的开发方式，我进入的时候， sprint3已经结束。本人经历了sprint4和正在经历sprint5。 虽然只是扮演普通开发人员的角色，在此过程中也积累了对敏捷开发的一些思考：
1. 关于Scrum Meeting
理论上： Scrum Meeting每天一会， 全员参加，每个成员总结前面一天所做的事情： 完成的， 未完成的， 遇到的问题，然后是今天需要做的事情： 计划完成的事情
实际中： Scrum Meeting执行力度不够，并没有坚持每天都开。
建议： 1. 任命专人负责，pm或者sa， 负责开Scrum Meeting，实行问责制。
2. 最好站着进行，能提高效率。
2. 关于任务安排
理论上： 每个task的分割和安排都能达到合理的颗粒度，task的责任人明确知道每天的任务：内容，进度等。
实际中： 出现过task的delay。
建议： 1. 及时交流进度，Scrum Meeting的意义就在于此。
2. 最好站着进行，能提高效率。
3. 结对编程
理论上： Coding人员的安排，可以考虑结对编程。
实际中： 基本是这么安排的，一个模块2-3个人，最多的模块4-5个。
建议： 1. 结对编程的兄弟姐妹要加强沟通，最好是坐在一起， 至少能很及时方便的沟通。
2. 对于能力一强一弱的，比较好安排，能力强的做主要部分，但需要分出基础部分给搭档。对于个人能力差不多的，需要强调沟通意识，尽量将任务划分的够清晰。
4. 关于文档
理论上： 敏捷开发更注重coding的质量，觉得良好的coding比文档更能说明逻辑。
实际中： 出现人员变动： 离职，新成员加入，尽管有设计文档，单只能说是概要设计，导致交接和新队员的融入遇到一些困难。
建议： 1. 需要记录每个Sprint潜在的问题， 比如一个功能是分散在多个sprint中，而且是经过了多个人接手，每个sprint中完成的任务对功能的实现的影响是什么需要有记录，发生人员变动时
才能比较好的理解已完成的，未完成的，目前存在的问题。
2. 还是需要实现的人员提供比较详细的设计，并加强review。
5. 关于测试
实际中： UT都是由开发人员自己完成，自己写代码，自己写测试，自己测试。 FT设计了统一的case， 实现并测试功能，没有测试人员，由开发人员实现了自己测。 前面的sprint做过集成测试，后面的sprint由于各组件都在变动和开发中，还没有到能做集成测试的程度。 曾经用hudson+maven+svn做过持续自动化测试。当中有段时间基本没看，后来强调了，加强了，但又松懈了。
建议： 1. 安排专人负责测试： 包括FT的实现，测试以及自动化测试，需要实行daily build，加强QA。
6. 关于数据库。
实际中： 由于开始的时候，各个组件采取单独开发，单独维护自己的数据，应该在sprint3，4中出现数据库的实例太多，既有开发用的，也有测试用的，还有测试性能用的，导致数据库管理方面出现了一定程度的混乱。 后来找了DBA进入项目组，负责维护所有的数据库。