几天前参加了2010敏捷中国大会。因为以前没有对敏捷的实践经验，所以这一次的收获一不系统二不务实。下面把几点认识列出来，作为总结。
- 敏捷并非全新的一套理论和方法，实际上XP和Scrum等，比《敏捷宣言》更早出现。敏捷不是为了革命，而是对如何更好地为客户创造价值所做的一些改进。也因此，敏捷不等于抛弃一切原有的方法，实施敏捷，是一个逐渐的尝试过程。
- 敏捷不是银弹。首先，大量的实践表明它不能解决所有的问题，很多失败仍然发生；其次，并不是所有的项目都适合使用敏捷。对于需求较为固定和明确、能合理规划执行的项目，传统的开发方法反而有不错的效果。然而，绝大部分情况并不在此列。
- 是否切换到敏捷，有两种驱动力：一、现状中有无法解决的问题存在，很痛苦；二、管理人员对此很有信心，大力推动。诺基亚西门子的演讲人介绍了经验：先小范围实验，通过实效来让管理者认同。
- 敏捷的具体实施方法并不是固定的。这次大会多次对Scrum的标准认证提出了质疑。事实上，敏捷并不是一套完整的方法，我始终认为可以将其拆分开来，根据实际情况逐一评估和试验是否好用。每一种方法本身也应该有所改进，根据自身情况来试用。简而言之，不教条，吸取思想。
- 敏捷的思想可以分为几个层次：一、极限编程、重构、TDD等；二、流程改造、新的管理方式；三、持续集成和持续发布。国内的开发者往往一上来就想实施二、三，但一是技术基础，需要先行。
- 尽早发现问题、暴露问题，然后正视并共同解决。我觉得这是特别好的想法，是一种良性循环。但实际执行的难度不小——最初肯定会是问题最多的时候。这就像做Code Review，最初很痛苦，只有长期地实行了，才会稳定持续改进，而且每次的增量让人可以接受。
- 敏捷团队的沟通。团队内部、团队之间应该避免神秘主义、敞开交流。互相了解情况不但有助于水平的提升，还对整个项目有促进作用。在Scrum团队中，避免出现特立独行的分工角色，测试参与需求和设计、开发人员参与测试，都有助于把本职工作做得更好。充分的交流可以避免重复浪费，这一点有实际的体会。
- 管理者应该让每个人都明白团队的使命、责任、愿景、方向和价值，从而激发大家的积极心态。
- 对个人的品质要求：有强烈的学习意愿、主动迎接变化、持续的重塑自我、乐于影响他人。
- TDD：技术上，没有想象的那么简单。刚开始实施在管理上也会有较大的难度。有案例是一年左右才做到整个团队能自然地TDD，采取有经验的先行者带动其他人的方法。不必要对所有代码都TDD。
- 敏捷的快速响应变化，来自于各种自动化技术，包括自动测试、自动构建、自动集成、自动部署、自动交付……而持续改进则来自于持续集成、持续交付等。
- 站会。每人2分钟左右，将有必要告诉其他人的情况予以说明，遇到问题也可以提出来。
- 文档。不是no-document，最重要的功能定义文档是肯定需要的，而且应当具体。项目估算偏差较大，主要原因一般是对需求和功能的描述不具体。
- 版本控制。具体技术也许并不难，养成好的习惯、有版本控制的正确思维，才是需要引导的。
- 管理：减少管理力度，杜绝强制性命令。”Help others, not order.”