2.2 敏捷软件开发
在传统的软件开发方法中，工作人员努力构建客户想要的产品。他们花费大量的时间努力从客户那里获取需求，针对需求进行分析和建模，并且归纳成规格说明书。然后，评审说明书，与客户开会讨论，最后签字。表面上看他们开发的产品是符合客户的要求的，但通常事与愿违。在项目快要结束的时候，需求和范围、产品的适用性成为争论的焦点。
敏捷软件开发方法告诉我们开发项目是一个学习的体验。没有谁能完全理解所有需求之后才开始项目，即使是客户也一样。客户一开始有一些主意，但是他们也会随着项目的进展进一步了解他们的需要。同样，开发人员在一开始学习到他们能知道的东西，但是他们需要继续通过项目来学习更多的东西。没有人完全清楚会构建出什么来，直到项目结束。因为每个人都在通过项目进行学习，敏捷软件开发方法改变了开发过程以便识别出持续学习，并培养每个人的学习能力。
敏捷就是“快”，快才可以适应目前社会的快节奏。要快就需要更多地发挥个人的个性思维，虽然通过结对编程、代码共有、团队替补等方式能减少个性思维对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷软件开发是一个新的思路，但不是软件开发的终极选择。对于时间长、人数众多的大型软件应用的开发，文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合，是软件开发组织者面临的新课题。
2.2.1 敏捷方法与开发原则
敏捷方法的两大主要特征是对“适应性”的强调与对“人”的关注。经典的软件工程方法借鉴了工程学领域的实践，它强调前期的设计与规划，并尝试在很长的时间跨度内为一个软件开发项目制定严格而详尽的计划，然后交由具备普通技能的人群分阶段依次完成目标。
敏捷过程强调对变化的快速响应能力，它通过引入迭代式的开发手段，较好地解决了如何应对变化的问题。这里要说明的是，“迭代”并非一个新概念，以迭代为特征的开发方法由来已久。例如，螺旋模型便是一种具备鲜明的迭代特征的软件开发模式。
敏捷过程将整个软件生命周期分解为若干个小的迭代周期，通过在每个迭代周期结束时交付阶段性成果来获取切实有效的客户反馈。其目的便是希望通过建立及时的反馈机制，以应对随时可能的需求变更，并作出响应的调整，从而增强我们对软件项目的控制能力。所以，敏捷过程对变化的环境具有更好的适应能力，相比于经典软件开发过程的计划性特征，敏捷过程在适应性上具有更大的优势。
传统的软件工程方法旨在定义一套完整的过程规范，使软件开发的运作就像设备的运转，人在其中则是可以更换的零件，不论是谁参与其中，该设备都能完好地运转，因此它是面向过程的。这种做法对于许多软件公司来说是件好事，因为这意味着，开发进度是可预见的，流程方法固化、可复用，人力成本减少，人员的流动不会对软件开发构成影响。敏捷过程也非常强调人的作用。没有任何过程方法能够代替开发团队中的人员成本，因为实施过程方法的主体是人；而过程方法在其中所起的作用，则是对开发团队的工作提供辅助支持。
敏捷开发提出了12条原则：
1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，越短越好。
4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5）围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。
6）在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
7）可工作的软件是首要的进度度量标准。
8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9）不断地关注优秀的技能和好的设计会增强敏捷能力。
10）简单是最根本的。
11）最好的构架、需求和设计出自于自组织的团队。
12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
2.2.2 极限编程及其模型
极限编程（Extreme Programming，XP）是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一，是由Kent Beck在1996年提出的。极限编程具有积极沟通、简化设计、迅速反馈等特点，一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。
极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象。传统的做法是，在项目起始阶段定义好所有需求再费尽心思地控制变化，而极限编程有能力在项目周期的任何阶段去适应变化，将是更加现实、更加有效的方法。对比传统的项目开发方式，极限编程强调把它列出的每个方法和思想做到极限、做到最好。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。与一般流行的开发过程模型相比，极限编程具有如下优点：
1）XP模型是“轻量型”或“灵活”的软件过程模型，并且与面向对象语言结合起来，提供了一种很有特点的软件开发解决方案。
2）XP被用来解决大型软件开发过程中所遇到的问题，可以称为“专家协作”的开发方式。
极限编程的一个成功因素是重视客户的反馈——开发的目的就是满足客户的需要。XP方法使开发人员始终都能自信地面对客户需求的变化。极限编程强调团队合作，经理、客户和开发人员都是开发团队中的一员。团队通过相互之间的充分交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件。程序员通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早地将软件交付给客户。
极限编程的核心有4个要点：交流、简单、反馈和勇气，它们构成了极限编程的精髓。
1．交流
开发人员与客户的交流。开发人员与客户有效的交流是软件开发前期必不可少的，因为这些交流将直接影响到一个项目是否能够符合客户的要求。在极限编程中，需要一个非常精通业务的现场客户，他们不仅随时提供业务上的信息，而且要编写业务验收测试的测试代码，这样就可以在很大程度上保证项目的方向不会错误。
开发人员之间的交流。软件开发往往需要多个开发人员一起协同工作来完成，他们之间需要充分地交流以理解软件的需求和接口，保证由不同的人员完成的软件部分能有效集成并减少错误。
开发人员与管理人员的交流。在一个项目组里面，管理人员和开发人员之间的关系是影响项目的一个非常重要的因素，如果处理不好，可能会直接导致项目的失败。这对管理人员的素质提出了很高的要求。如果开发人员能够和管理人员进行好的交流，他们的工作环境就会得到很大的改善，从而使团队的战斗力得到很大的提升。
2．简单
设计的简单。在极限编程的过程中，提倡一种简单设计的观点。这样做的好处是我们不需要在设计文档上面花费太多的时间，因为文档必然要被修改，一般情况下等一个项目结束的时候，我们会发现当初的文档已经面目全非了。因此，在软件开发的前期，设计工作中要做的就是确定我们需要实现的最重要的功能。
编码的简单。编码的简单表现在迭代的过程中。在极限编程的过程中，不需要一次完成所有需要的功能，相反，变化在极限编程中是被提倡的。我们可以先简单地实现一点功能，然后添加详细的内容，再对程序进行重构，最终的代码将是非常简单的，因为依照重构的原则进行了修改之后，所有的类、函数和过程都是非常简短而非冗长的，每一个模块完成的功能非常明确。
注释的简单。在某些项目中，有时对注释要求很严格。一般的程序员或许会认可这一观点，但事实并非如此，与其让注释来解释程序，不如在给变量、过程和函数起名的时候用大家都能够理解的名称，那样即使没有太多的注释，别的程序员想要读懂该程序也不是一件非常困难的事情。
测试的简单。在极限编程中，测试主要是通过编写测试代码来自动完成的。特别是在一些面向对象的编程环境中，可以使用xUnit等工具来进行快速、有效的单元测试。每一次修改了程序之后，都要运行测试代码来看程序是否有问题。
3．反馈
客户对软件的反馈。在极限编程的过程中，强调了现场客户的重要性。因为一旦有了现场客户，就能够随时对软件做出反馈，能够保证在“反馈”的过程中不断调整，保证软件前进的方向。
测试代码对功能代码的反馈。这里极限编程强调的是先测试、后编程的思想，也就是说在编写功能代码之前就先要编写测试代码，测试代码可以保证功能代码是正确的。
4．勇气
接受任务的勇气。项目开始时，一般是由管理人员来为开发人员分配任务。但这种分配只不过是根据管理人员自己对每个人的大致估计来完成的，所以很难做到令每一个人都很满意。在这个时候，我们不妨尝试这样的一种方法：将所有的任务公布给大家，然后让开发人员自己来选择自己想要做的任务。这样，由于任务是自己选定的，那么满意度会有很大程度的提高。
敏捷软件开发是针对过程控制中没有解决的问题提出来的。软件是人开发出来的，而开发人员执行过程应该不可能像计算机执行软件那样严格，开发过程不可能被非常详细地计划出来。试图把开发过程非常详细地分解、计划和跟踪，无论在技术上还是成本上都有难度。敏捷开发正是基于此提出了一套轻量级的方法。但是，敏捷开发对于开发人员的技能、职业素养、开发团队的文化氛围都有较高的要求。