人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
-- Tom DeMacro、 Timothy Lister
一、简介
概念：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷软件开发宣言：
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
敏捷软件开发有很多不同的实践和形式，它包含很多具体的方法论比如极限编程（XP），Crystal和Scrum，当然并不局限于这些方法论。其中大多数方法特点类似，采用增量迭代式的方法来计划、开发和部署软件项目。每个方法论均依靠反馈，提高软件项目的透明度，来发现那些通常易被个别人忽略或遗漏的问题。些额外提供的信息，可以让每个人都能更早做出更好、更明智的决定，从而能够适应不断产生的变化，并进行优先级调整。敏捷方法论的一个重要特点是需向客户频繁发布项目结果。发布时机尚未成熟，至少还可以提供可演示并且具备发布潜力的软件。
采用敏捷实践并不神秘。它只是尽力更快、更早交付价值的一种方式。敏捷方法的根基在于，它鼓励尽量先为客户交付系统中最具价值的部分。不同的实践让团队能够在保证质量的前提下完成任务。
终端用户不需要苦等整套系统全部开发完成，他们就可以从最具价值的部分提前获益了。为了达到这样的目的，敏捷专注于通过纪律性的工作方式提高沟通质量，增加从持续反馈中学习的机会，并且减少不必要的例行公事所带来的麻烦。举个例子，持续回顾将在整个项目周期里反复进行，以让团队仔细思考并且持续的调整他们的开发流程，以符合开发的具体场景。
二、敏捷软件开发要素
图：敏捷开发模型
上图两个圆圈表示不同的视角上的敏捷实践，包括开发者视角和项目管理的视角。接下来从里向外进行介绍。
Test-Driven Development（测试驱动开发）：它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。
Continuous Integration（持续集成）：在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。 在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。
Refactoring（重构）：相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。
Pair-Programming（结对编程）：在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。
Stand up（站立会议）：每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。
Frequent Releases（小版本发布）：在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。
Minimal Documentation（较少的文档）：其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。 这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。
Collaborative Focus（以合作为中心）：表现为代码共享。在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。
Customer Engagement （现场客户）。敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。
Automated Testing （自动化测试）：为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。
Adaptive Planning（可调整计划）：敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。
三、敏捷开发与传统开发模式（瀑布模型）式对比
| 敏捷开发 | 传统开发 | |
| 需求 | 复杂多变、非典型、不确定 | 需求确定、传统行业 |
| 计划 | 可调整 | 严格计划 |
| 开发周期 | 较短 | 较长 |
| 文档 | 崇尚较少文档 | 文档齐全 |
| 人 | 对开发人员素质要求较高 | 要求不高 |
| 项目规模 | 适合较小团队（100人以下） | 没有限制 |
| 规范 | 可能不符合CMMI | 能适应CMMI规范 |
从上表可看出，敏捷开发较适合需求不是很明确，或者非典型的开发项目。而在传统的瀑布模型开发里，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。这样导致流程繁琐，对需求变更 的响应慢；而敏捷的核心是迭代，其终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
四、敏捷团队建设
在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。
项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Learning Lunch也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。
除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。
无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。
除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。
公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。
在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。
附1敏捷开发工具：
敏捷开发工具（.Net）
- NUnit――单元测试。
- NAnt――build工具
- NDoc――文档生成。
- CruiseControl.Net ――持续集成。
- MS TFS——团队协作
敏捷开发工具(Java)
- Ant——build工具
- Junit——单元测试
- JavaDoc——文档生成
- CruiseControl——持续集成
- IBM Jazz——团队协作
附2 图书与网站：
敏捷软件开发:原则、模式与实践（Agile Software Development, Principles, Patterns, and Practices ） 原出版社： Prentice Hall 出版社：人民邮电出版社 作者： (美)Robert C. Martin
高效程序员的45个习惯：敏捷开发修炼之道 人民邮电出版社 作者：(美)Venkat Subramaniam Andy Hunt 译者： 钱安川、郑柯
构筑敏捷的开发团队：微软Visual Studio 2010实战兵法 电子工业出版社 作者： 高阳、蒋建华、毛志勇、段君毅
企业应用架构模式 作者：（美）福勒 著 出版社：人民邮电出版社
敏捷开发的艺术(The Art of Agile Development) 原出版社： O'Reilly Media, Inc. 出版社：机械工业出版社 作者： James Shore 、Shane Warden 译者： 王江平
卓有成效的程序员（The Productive Programmer）原出版社： O'Reilly Media, Inc 作者： (美)Neal Ford 译者：Thoughtworks中国公司
软件开发沉思录--ThoughtWorks文集（The ThoughtWorks Anthology: Essays on Software Technology and Innovation） 原出版社： Pragmatic Bookshelf 出版社：人民邮电出版社 作者： ThoughtWorks公司 译者： ThoughtWorks中国公司
http://www.thoughtworks.com/cn/ ThoughtWorks中国公司
http://www.infoq.com/cn InfoQ
http://www.martinfowler.com/ Martin Fowler，ThoughtWorks的首席科学家，当今世界软件开发领域最具影响力的五位大师之一
http://blog.nona.name/ 李默，ThoughtWorks公司高级咨询师、业务分析师
http://www.cnblogs.com/DesignPatterns/ 肖鹏，ThoughtWorks中国公司咨询师
http://gigix.thoughtworkers.org/ 熊节，ThoughtWorks中国公司咨询师