敏捷开发小结

1. 敏捷开发简介

1.1. 什么是敏捷开发

     敏捷开发，简言之就是是一种以人为核心、迭代、循序渐进的开发方法。

     敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。

1.2. 敏捷宣言

1.2.1. 个体和交互重于过程和工具

     敏捷方法认为，人是软件开发中最重要的因素，开发团队要能做到团结协作，人与人面对面的交流、沟通，是最快速、最有效的途径。

1.2.2. 可以工作的软件重于面面俱到的文档

     文档的意义在于为程序服务，过多的文档需要开发人员花费大量的时间去维护，而且还要确保文档与代码的实时性，否则就失去了文档的意义。而问题也就在于，开发人员没有把时间、精力放到最重要的任务上，能力、资源没有最大化的发挥效能。敏捷方法认为，文档应当短小精悍、易于维护，而且主题突出。

1.2.3. 客户协作重于合同谈判

     做过软件开发的人都知道，客户对产品的需求是不断变化的，试图一开始就规定项目的细节和进度，显然是不现实的，只有开发团队和客户彼此精诚合作，常与沟通，频繁的客户反馈，才能促使项目的成功。

1.2.4. 随时响应变化重于循规蹈矩

     客户的需求在产品的开发阶段是不断变化的，即使谈判时确定的需求，也可能会根据某些因素而发生巨大的改变。因此，敏捷方法认为，在制定计划时应尽可能的简洁、灵活，以适应技术和需求方面的变动。当然，所有的未知的因素是不可能考虑周全的，这就要求我们在制定计划时，留出一定的缓冲期，来应对这些未知情况。

1.3. 核心思想

     简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目经常被拆分为多个子项目或多个步骤来完成，而一个步骤又称为一次迭代，在每一次迭代完成之后，都会产生一个可交付的产品。这样做有效的分解了整个项目的复杂度，便于实现产品交付目标，同时在项目的早起，就能拿出初具雏形的产品。

     敏捷开发方法的核心思想概括起来，就是“以人为本”和“适应变化”。

1.3.1. 以人为本

     敏捷方法认为，人是软件开发中最重要的因素。对于人来说，软件开发应该是一种愉快而又轻松的事情，它们注重调动自我的能动性，以积极、愉悦、乐观的心态完成开发，并培养人的自豪感。敏捷开发的理念是充分的信任开发团队能够很好的完成任务，这是管理的中心主题。

1.3.2. 适应变化

     传统的软件开发强调的是，足够清晰的需求，制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对客户对需求的实时更改，后续的维护必将会付出巨大的代价。

     而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到客户的反馈，不断适应需求的变更，从而使得最终的产品能够充分的符合客户的要求。

1.4. 敏捷开发方法

1.4.1. Scrum

     Scrum是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程，主要用于产品开发或工作管理。Scrum于1995年提出，并在2001年同其他方法论一起组成“敏捷联盟（Agile Alliance）” 。Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。在这个框架中，整个开发周期，包括若干个小的跌代周期，每个小的的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

角色

ScrumMaster

? 保证Scrum团队可以遵守Scrum的价值，实践和规范

? 帮助Scrum团队和组织采用Scrum模式进行项目流程组织

? 指导并带领团队变得更加高效，实现更高质量

? 保护团队不要受到外界因素的干扰

? 保证各个不同角色之间的良好协作，消除障碍

? 帮助PO更好的利用团队的能力

? 不要管理团队

产品负责人PO（Product Owner）

? PO是一个人并只能由一个人来担任

? 负责管理产品待办事项表（Product Backlog）并保证其对于客户和团队保持透明度

? 对产品待办事项表进行优先级排序

? 与团队一起来进行工作量估算

? 对于项目的成功负责并保证投资回报率（ROI）

团队Team

? 最佳团队大小：5~9人

? 多功能团队：程序员，测试人员，设计师，数据库管理员和架构师

? 保证团队成员全职参与开发

? 自我管理，没有头衔之分，不组建子团队

? 成员更替只能在迭代之间进行，更佳方式是在发布之间进行

1.4.2. 极限编程

     极限编程（eXtreme Programming），是一种全新的、轻量级的、灵巧的软件开发方法，是一种软件工程方法学。它强调程序设计团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重软件开发中人的作用。

核心价值观

沟通（Communication）

     问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。XP认为项目成员之间的沟通是项目成功的关键，并把沟通看作项目中间协调与合作的主要推动因素。因此，项目相关人员之间进行充分、多渠道（最好面对面）的沟通是很有必要的。

简单（Simplicity）

     XP假定未来不能可靠地预测，在现在考虑它从经济上是不明智的，所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。 在系统可运转的前提下，做最简洁的工作，坚定的专注于最小化解决方案；在开发中不断的优化设计，时刻保持代码简洁、无冗余。需求尽量的简单，设计尽量的简单，代码尽量的简单，文档尽量的简单。

反馈（Feedback）

     尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈：小交付、短迭代、测试先行等。XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。

勇气（Courage）

     这是最重要的核心价值。因为XP强调要“拥抱变化”，因此对于用户的反馈，提倡积极面对现实和修改问题的勇气，如放弃已有代码，改进系统设计等；勇敢的重构；所有人拥有代码；敢于极限（把好的方法做到极致）。XP认为，软件开发中，人是最重要的一个方面。在一个软件产品的开发中，人的参与贯穿其整个生命周期，是人的勇气来排除困境，让团队把局部的最优抛之脑后，达到更重大的目标。

1.4.3. 特征驱动开发

     特征驱动开发（FDD），是敏捷开发方法中的一种，他来源与新加坡的一个大型软件开发项目，由著名软件专家Jeff de Luca 、Eric Lefebvre、Peter Coad共同提出的。它强调特征驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量。

     他提出的每个功能开发时间不超过两周，为每个用例user case限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。他抓住了软件开发的核心问题领域，即正确和及时地构造软件。

     FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。

开发过程

     FDD方法包括5个过程，其中的按照功能设计和构建是反复的迭代过程。

1、开发整体模型

     这是FDD开始一个项目的初始工作，在主设计师的指导下，带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求，然后使用四色原型进行域建模。一般在此阶段中，能够得出系统的架构设计图。

2、构建功能列表

     这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分，将整个领域分成一定数量的区域（主要功能集），每个区域再细化为一定数量的活动。活动中的每一步被划分称为一个功能。形成了具有层次结构的分类功能列表。个人认为，在此阶段中，能够形成系统的概要设计。

3、计划功能开发

     项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的复杂性，计划实现功能的顺序，完成一个功能开发计划。它提供了对项目的高层视图，让业务代表了解功能开发、测试和发布日期，以便业务代表和部署小组能够计划交付哪些功能的日期。本阶段的主要成果是，能够形成项目开发计划。

4、按照功能设计

     项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计，得出分析模型、设计模型。由于一次设计并不全面，因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了：详细设计、项目里程碑计划等。

5、按照功能构建

     按照设计进行编码实现，由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评审。在测试和检查通过后检入到配置管理库中进行构建。第5和第4 阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑 的继续，直到最后项目的完成。

1.4.4. Crystal

     水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列，其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

七大体系特征

1、经常交付

     任何项目，无论大小、敏捷程度，其最重要的一项体系特征是每过几个月就向用户交付已测试的运行代码。如果你使用了此体系特征，你就会发现，“经常交付”的作用还是很让人吃惊的。

     项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。开发人员打破未决问题的死结，从而实现对重点的持续关注。团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。

2、反思改进

     在我们的开发中，时常会出现这样那样的问题，技术难题、各种烦心事等等，这会在很大的程度上影响项目的进展。而且，如果其他任务对这项任务有依赖的话，那么其他的任务也会被推迟，这就很可能会导致项目的失败。

     换句话说，如果，我们能够经常在迭代会中及时的反思和改进，那么，这种事情应该是不会发生的，或者说发生了，也能够很快的找到解决方案去应对它。事实上，从慌乱的日常开发中，抽出一点时间来思考更为行之有效的工作方法就已经足够了。

3、渗透式交流

     渗透交流就是信息流向团队成员的背景听觉，使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。若其中一名成员提出问题，工作室内的其他成员可以选择关注或不关注的态度，可以加入到这个问题的讨论当中来，也可以继续忙自己的工作。

4、个人安全

     个人安全指的是当您指出困扰您的问题时，您不用担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任，团队协作才能真正的实施，开发效率也就会直线上升的。

5、焦点

     所谓“焦点”，就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚的了解他们自己最重要的任务是什么，确保他们能够有充分的时间去完成这些任务。

6、与专家用户建立方便的联系

     与专家用户持续建立方便的联系能够给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。

7、配有自动测试、配置管理和经常集成功能的技术环境

     自动测试可以为开发人员在代码修改后就可以进行自动测试，并且能够发现存在的一些bug，以至开发人员能够及时的进行修改，对于他们来说，节省了时间，提高了效率，而且还不用为烦人的测试而苦恼。

     配置管理系统允许人们不同步地对工作进行检查，可撤消更改，并且可以将某一系统设置保存后进行新系统的发布，当新系统出现问题，即可还原原系统的设置。

     经常集成可以使得团队在一天之内对系统进行多次集成。其实，团队越频繁地对系统进行集成，他们就能够越快地发现错误，堆积到一起的错误也会越少，并使他们产生更新的灵感。

     最好的团队是将将这三大技术结合成“持续测试集成技术”。这样做他们可以在几分钟内发现因集成所产生的错误。