听说敏捷很久了，直到最近才真正的去了解这个东西。敏捷真正的含义其实是“lightweight process”，我认为最核心的内容就是拥抱变化，换言之，就是利用轻量级过程快速应对变化。敏捷的所有实践我认为都是以承认需求是不断变化且我们不可能预先设计出一个完美的解决方案为前提，其实这个和软件开发的实际情况是更相符的。所以自然就引入了持续集成、不断重构等概念。另外一方面，敏捷讲究的是用户参与，认为用户是软件最终价值的评定者，所以让他们来充分参与到产品的开发中。所以就有了用户故事、测试驱动等方式。

 

 

 
        最近看了一些敏捷的资料，发现敏捷的实践很多，但是并不是什么都能直接拿来用。看了有些团队实践敏捷的经验，感觉能成功的都是真正把敏捷的思想融入到开发工作中，而不是照搬。简单说一下自己认为一些非常不错的实践，当然还有很多好的实践没有提到，有些是大部分软件工程方法都会提到的，有些是觉得我们现在的环境下实施不太可能吧。

        1. 简化设计，注重实践，在变化中完善。
        其实这点还是备受争议的，我个人看法是架构设计在大多数系统中还是很重要的，我觉得初期要有一个比较好的架构设计，比如SAAS，因为如果架构有严重问题，以后修改起来代价也很高。但是没必要一开始就去努力构建一个非常强大的系统，往往事情的发展是不太可能完全估计的，所以系统的架构肯定也不会一层不变，在新的需求情况下不断完善才是最合理的。
 
        2. 小版本发布，每个迭代周期都有可运行的系统
        这确实是一个很有想法的方式，仔细想想其实实施起来并不困难，我们一个版本都是包含若干个feature，完全可以拆开成为一个个阶段去做。但是随之而来的问题是怎么保证每个迭代周期每个人都能正好完成工作，以及频繁发布带来的额外工作量。前者在敏捷中是用用户故事把feature分解，在用任务进一步分解，用于衡量具体的工作量，另外再提倡团队精神，大家协作保证工作按时完成。后者是通过测试自动化来解决，但是对于web页面的测试可能只能放在发布前去做一次。
 
        3. 用户故事。
        这是敏捷方法的一个核心概念。他讲究的是用户参与和交谈。用户参与是说让最终的用户来参与定制具体的功能，这才能确保开发出来的东西确实是用户所需要的，同时研发参与就能减少信息传递链，确保大家的理解一致。交谈是强调延迟细节，这个非常重要，研发不会有人有兴趣去看一长篇的需求文档，虽然在瀑布式开发中我们不得不这么去做，但是如果仅仅列出需要做的功能，等到具体要实现的时候再与用户沟通来确定具体需求，这样大家交流的目的性非常强，还能总结之前的经验来提出更好的方案，对于刚刚确认过的内容研发所做出来的东西和客户的需求更一致。
        最后提一下，这里需要区分用户和客户，他们的需求都是我们要满足的。
 
        4. 测试驱动开发。
        这个概念听到很久了，感觉非常好，但是却没见到身边的团队有这么去做的，等看到敏捷的时候才发现原来配合使用才会有更好的效果。由于每个迭代周期所要做的功能点都用用户故事表示出来了，所以目标明确，那很容易就写出应该完成的结果。根据这个结果开发，自然就可以用TDD。
 
        其实没提到的结对编程、持续集成、重构等都是非常好的实践，虽然我们也或多或少用到这些概念，但是有时候确实是还可能更深入的。刚刚接触敏捷，根据自己理解写了点，现在最重要的还是想想怎么把敏捷的东西用到我们实际工作中来，并带来更高的工作效率。