在Software Developer 2.0 2009会议上以及之前参加的一些会议上看到一个现象，大厂商都开始敏捷了，如果你现在还徘徊是否要敏捷，我觉得可能为时已晚，你要立刻敏捷起来！
SD2.0 2009上微软给大家介绍了Visual Studio 2010，从界面上来看沿袭了Office 2007的风格，工具条排列很花哨，也有一大堆微软经典的wizards，利用这些向导可以很方便的完成开发工作。一个被我关注的重点是VS2010整合了开发流程中除了编码以外的东西，比如版本控制、缺陷管理、UML建模等都融合进入这个集成开发环境，并且它还拥有敏捷开发的一些特性模板，单元测试模板用于测试驱动开发。不难看出微软为了方便开发者，将最近开发管理所需的功能都列入到它的VS2010里面去了，而且是全网络化的解决方案，开发人员之间是可以很方面的共享信息的。相信在微软内部也有团队在实施敏捷。
IBM的一场演讲中也透露出，IBM内部软件开发也在实施敏捷，而讲演者Robert Degg来自Rational，他主要的工作就是在IBM内部帮助各个软件开发部门实施敏捷。
通过网上的一些文档介绍，Google, Yahoo!, Facebook, Twitter, eBay等大型互联网公司都在实施敏捷开发并有些成效。敏捷已经不是两三年前大家都在观望的局面了，已经不是只有创业团队敢于尝试的一种开发方法了，渐渐的你会发现身边的软件公司都多少的运用敏捷开发的方法，你还犹豫什么？
忽悠大家半天再来说说如何实施敏捷
也许敏捷方法并不和你现在使用的方法有太大的差异，我认为我们要从小事出发，用敏捷方法解决我们现在特定的问题，这样才能积累所有人的信心继续朝着更高的方向改进。毕竟老板只会看效果，如果不能在短时间内达到效果，说到天花乱坠也没有用。下面列举一些可以注意的小点，你可以按照你具体的情况来选择实施。
- 对待需求按照重要程度排序，一段时间内只完成确认的最终要的任务
其实很多开发团队也是这么做的，只是敏捷方法提出频繁迭代的概念，让完成需求有一个特定的周期，并且这个周期要尽可能频繁的迭代。每个周期完成的是完整的事情，没有完成的百分之多少的概念，只有完成和没有完成。这样保证每个迭代有工作的产物，保证下一个迭代万一出现问题我也能拿出上一个迭代的成功产物。
另外重要程度排序也会使得最重要的业务需求最先完成，不至于做的半天都是无用功。
迭代周期中不加入其它新的变化导致在一段时间内足够的清净让开发人员来完成工作。
- 测试驱动
也许这个题目太大，你可以缩小化成自动单元测试，因为要自动测试所以你要写测试脚本，也许你会在写完程序后懒得写测试脚本所以把测试脚本编写在程序开发前面。选择一个适合的测试框架，你会很快达到这个目标。你会发现不必为了找一个bug花费很多的时间，如果你要查问题，就给自己一个假设，用这个假设实现一个测试来验证吧，逐渐的你的测试脚本会限制你，一有bug测试就无法通过了，你就不需要找而是直接修复发现bug。
对于小团队，这里其实更重要的是让单元测试从无到有。
- 配对编程
也许你会对这个很怀疑，但我能说的是，这只是一个形式，如果你仔细观察，在你公司内部，也会经常因为某一个人解决不了一个问题而抓住另外一个人，两个人一弄就是一下午，也许问题已经解决了，两个人也会继续一段时间。配对本来就是一个很自然的事情。
配对根本解决什么呢？
1、人的经验问题，不可能都是全才，配对有利于带新人，或者让两个不同领域的开发人员能互相熟悉或产生升华。这点通常在配对前两个人一起设计而体现。
2、代码复查；首先我相信大部分开发团队是没有这个独立的工作内容的，但它真的很重要，代码复查可以让所有人在一个编码标准下开发，复查可以让一些有问题的设计思路更早被发现，因为一个不好的设计并不会产生bug，但也许它影响了后续的性能或者灵活的可扩展性。因此如何引入代码复查而又不增加而外的开发负担呢？配对编程是个很好的方法。
3、形成通才而不是很多专才；通常我们担心某些点没了某些人就不转了这种情况，一个是不利于公司管理，二来也不利于那个人发展（我因为精通某一个方面就弄要负责那个方面，也许我都已经厌倦了，但无法自拔，解脱只有辞职换工作了），配对编程的经验共享使得可以弱化上述问题，并且所有人被灌输的是你感兴趣的部分你都可以了解，不是对每个开发人员发展都有激励作用嘛？
- 任务管理或缺陷管理
也许这不算敏捷里面的东西，但它和敏捷开发密不可分，例如Scrum里面的burndown chart就是代表bug被解决的趋势。老外讲究的一个思路是：你如果想优化一个事情，就首先要弄清楚如何度量这个事情，只有度量的结果才能反馈你的改进是否有效。因此无处不在的数据会很直接的体现项目的状况。
现成的有很多系统可以辅助你进行任务管理和缺陷管理，我推荐Trac，一个使用Python编写的集成系统，用于开发中知识共享，围绕它也可以找到很多第三方的插件来满足你的需求。
ok，对比一下你的现状，也许你离敏捷并不遥远，只需要参考一下将好的东西吸取到你现在的过程中，就这么简单，开始行动吧，也许未来你也能创造出一个什么敏捷方法！
