周六参加了Baidu技术交流会，会上的两个主题《webautomationtest》和《TDD》都是当前非常感兴趣的话题，因为：目前采用敏捷的方式开发我们的自动化测试框架和脚本。

　　敏捷这种模式或多或少大家都有些了解，虽然挺久之前对此就有所了解，但一直没有深入，只是草草看些书籍，了解些梗概，也还相当混淆。

　　但这次为了采用这种开发模式，和头认真的学习《敏捷软件开发原则、模式与实践》这本业界的经典书籍，也根据书中的模式进行结对编程，测试驱动开发等极限编程的典型实践进行演练，对于敏捷这种开发模式有了客观的了解，当然，还不深入。

　　看看振奋人心的敏捷宣言吧：

　　我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：

　　个体与交互胜过过程和工具
　　可以工作的软件胜过面面俱到的文档
　　客户写作胜过合同谈判
　　响应变化胜过遵循计划

　　虽然右项也具有价值，但我们认为左项具有更大的价值。

　　2001年的宣言，发展至今，已经指导很多公司进行了相关的实践。当然，我们这里也没有机会在发布的软件产品中进行敏捷的尝试，在产品层面，我们的影响还不够，但，在我们自己的自动化测试框架和脚本开发中，已经开始遵循敏捷中的典型方法—极限编程来指导我们日常的开发工作了。

　　在日常的工作中应用敏捷，激动的让人无以复加。看看如下的一些敏捷原则，你是否感觉到同样的激动？

　　在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈：我们越来越多的交互方式使用文档，使用电话，却没有发现我们的座位其实只有几步之遥，相比于那些交流方式，我更喜欢面对面和我的团队伙伴进行交流，这样我可以通过他（她）们的语言之外的表情，动作，了解他们更多的需求，也能让我产出的方案更贴近他们的需求；

　　工作的软件是首要的进度度量标准：放弃那些所谓的MPP吧，思维导图吧，大家真正需要的是可以工作的软件。有多少项目的产生周期是和MPP中涉及的一致的？

　　最好的架构、需求和设计出自于自组织的团队：相信你的团队伙伴，同时，让你的团队处在积极，乐观，进取的氛围下，大家彼此快乐的工作，自愿为团队奉献更多的应用和方法，而不是用所谓的高压去推进。

　　。。。。。。

　　当然，这些只是原则的一部分，其实我更激动的是一种心态上的契合。

　　我一直相信，流程和方法能够辅助项目的成功，但真正引导项目成功的决定因素，还是人。在敏捷这里，我找到了理论的依据：“过程和方法对于项目的结果只有次要的影响，首要的影响是人”；“人是获得项目成功的关键因素”；“项目的成功不是以稳定可靠的产品作为唯一输出，还要有不断进步的工程师”。。。