题序：结合英国电信项目等敏捷开发实践及权威或非权威资料而作此文，如有雷同，不属巧合（英雄所见大致如此），如有不同，欢迎拍砖，如需转载，请注明出处（http://kei.javaeye.com），谢谢^_^

一、敏捷概述

1）敏捷诞生的历史背景 

敏捷的诞生经历了五个阶段

第一阶段 20世纪60年代

      关键词：软件作坊

      特征：规模小，以作坊开发为主，没有任何流程可言

第二阶段 20世纪70年代

      关键词：软件危机

      特征：随着硬件的飞速发展，软件的规模和复杂度增加，引发了软件危机

第三阶段 20世纪80年代

      关键词：软件过程控制

      特征：引入了成熟的生产制造方法，“以过程为中心”，分阶段控制软件开发（瀑布模型），缓解了软件危机

第四阶段 20世纪90年代

      关键词：重型过程

      特征：软件失败的经验促使过程被不断增加约束和限制，软件开发“重型化”，开发效率低，响应慢

第五阶段 2001~？

      关键词：敏捷

      特征：信息时代到来，需求变化更快，交付周期成为核心竞争力，轻量级、更适应变化的敏捷开始流行

2）敏捷宣言（http://agilemanifesto.org/） 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

我们正在提示更好的软件开发方法。我们使用它并且帮助其他人使用。通过这些，我们意识到：

Individuals and interactions over processes and tools

个体及交互比流程与工具更具价值 

Working software over comprehensive documentation

可用的软件比冗长的文档更有价值 

Customer collaboration over contract negotiation

与客户的协作比合同谈判更有价值 

Responding to change over following a plan

对变化的响应比遵循计划更有价值

That is, while there is value in the items on the right, we value the items on the left more.

也就是说，我们认可上述右边事项的价值，但我们更加重视左边的事项。

即：

个体及交互  >  流程与工具

可用的软件  >   冗长的文档

客户协作     >   合同谈判

响应变化     >   遵循计划

3）敏捷宣言背后的12准则 

我们遵循以下准则：

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

4）为什么使用敏捷

1、敏捷更符合软件的开发规律

      软件就像一个活的植物，自上而下，逐步有序生长，而敏捷符合软件开发规律，不断迭代和增量开发，最终交付符合用户价值的产品。

2、软件对生产率、质量、满意度和成本有明显改进

      根据敏捷开发实践的领导者Scott Ambler发起的调查，发现：

      在使用了敏捷思想去指导工作之后，

      有82%的企业的生产率得到了明显的提升；

      有78%的企业产品质量得到了明显的提高；

      有78%的企业的客户满意度得到了明显的提升；

      有37%的企业的成本得到了有效的控制和降低。

二、正确理解敏捷

1）对敏捷的误解

以下几点是最常见的误解

1、敏捷不需要文档、设计和规划；

2、只是优秀实践，无法推广；

3、只适用小型项目；

4、只会对研发产生改变；

5、管理者不需要了解敏捷；

6、按照敏捷步骤走进行了；

7、敏捷是CMM替代品，是另一种流程；

8、敏捷只注重快速交付，不注重架构。

2）统一对敏捷的认识

敏捷 = 理念 + 优秀实践 ＋ 具体应用

理念：Ｖalue、Ｔeam、Ａdapting

优秀实践：站立会议、每日构建、重构、结对编程、迭代计划．．．

具体应用：项目Ａ、项目Ｂ、项目Ｃ．．．

3)解读理念

Value: 聚焦客户价值、拒绝浪费。

Team: 激发团队潜能，加强协助。

           团队是价值的创造者，软件开发时团队活动，应该提升团队沟通效率，降低交流成本

Adapting: 不断适应变化，交付达到业务目标的产品。

          为什么要做到Adapting?

          软件的规模会增长，需求会增加；软件开发复杂，不可预测因素太多；“人月神话”总结了软件系统的四个属性：复杂性、一致性、可变性和不可见性。

4）深入理解敏捷理念

Value: 

◆ 标识和消除软件开发中的浪费

什么是开发中的浪费

    1、部分完成的工作：比如没有转化为代码的设计文档，没有及时合入的代码。

    2、未应用的特性:开发人员花费了九牛二虎之力完成的功能，但是用户却不需要使用。

    3、再次学习：人员流动，导致重复学习；遇到难题，不咨询领域专家，而是花费更多的人力去研究。

    4、信息丢失：不恰当的沟通方式导致信息在传递过程中丢失。

    5、任务切换：多任务下工作，效率会下降20%-40%。

    6、延迟：各个模块依赖性过强，导致工作受阻。

    7、缺陷：缺陷本身就是浪费，缺陷越遗留，浪费越大

◆ 交付刚刚好的系统

当质量、进度、资源冲突时，该怎么做呢？

          通过简单的增加工作量、加班也许可以解决问题，但是会导致：

          质量下降、项目延期、客户不满、团队疲劳，并埋下长期的隐患。

交付刚刚好的系统够可以很好地解决问题，因此我们应该了解：

          1、用户在产品交付前要求多而全，在产品交付后要求功能稳定，尤其是电信行业，用户希望我们的产品能够Always work，而不是Sometime。

          2、为了交付多而全的产品，可能会引发延迟，不稳定，不如交付刚刚好，可用的，质量高的产品。

          3、交付刚刚好的产品，可以帮助用户对需求有更深入的了解。

          4、做到刚刚好，需要管理者有足够的勇气和果断的决策。

◆ 随时构建质量，不容忍缺陷

缺陷遗留会导致付出高额成本，为什么会有缺陷遗留呢？

         1、单独的质量保证活动容易形成缺陷可以遗留到下个阶段的心理；

         2、开发和测试在前期的协作不够。

如何保证在项目一开始就随时构建质量？

         1、形成零缺陷文化，不要容忍缺陷，发现问题就解决，在项目刚开始就打下高质量的坚实基础

         2、测试和开发密切协作，测试要深入到设计过程中，共同预防问题。

◆ 及时消除技术债务，保持快速响应

常见的技术债务：

         1、日益腐烂的代码结构；

         2、高复杂度的代码；

         3、没有清除静态告警的代码；

         4、低的自动化覆盖率

         5、其他 

为什么会有技术债务

          为了满足短期商业目标，在技术上让步，虽然对当前影响小，但是会严重影响后续的版本质量和快速响应客户需求的能力

如何对待技术债务

          债务是有成本的，如果不及时还，积累的利息会越来越高，大大影响开发效率，因此应该将加以管理并及时偿还（代码重构） 

Team:

◆ 弄清团队基本事实

团队激励

          1、当团队自我管理时，效率最高

          2、员工在实现对自己的承诺时，比别人要求的更有责任心

          3、人们总会尽力做到最好

          4、在高压下工作，会减低质量要求

团队绩效

          1、当不被打扰时，工作效率最高

          2、团队自我解决问题时，能力提升最快

          3、广泛的、面对面的交流是最好的沟通方式

◆ 敏捷下管理者的改变

敏捷下管理者最大的挑战是“放松”控制

传统的管理方式（控制）

         1、制定详细的计划

         2、指令性的工作方式

         3、监控过程

         4、复杂的规章制度

敏捷下的管理方式（激发）

         1、以目标来牵引，让团队主动工作

         2、为团队提供资源，排除障碍

         3、营造自我管理的团队气氛

         4、作为教练辅导团队

         5、简单的管理规则，但一定要严格遵守

◆ 敏捷下成员的改变

敏捷下员工改变的关键是从被动工作到主动工作

传统的工作方式（被动）

         1、听话的员工

         2、独立贡献者

         3、被动等待指令

         4、独立工作为主，协作少

         5、只注重个体“做完”，不注重团队目标

         6、文档和邮件为主要沟通方式

         7、能力相对单一，学习能力不足

敏捷下的工作方式（主动）

         1、作为团队一员，全方位积极参与

         2、共同参与计划制定和人员安排

         3、团队协作贯穿始终

         4、关注团队目标

         5、面对面沟通

         6、能力要求广，主动学习适应变化

Adapting:

◆ 必须认清“客户是逐渐发现真正需求”

   美好的愿望

         1、客户知道想要什么

         2、开发知道如何满足用户需求

         3、开发过程中需求不会有变化

   残酷的现实

         1、客户逐渐发现他想要的

         2、开发逐渐发现如何满足用户需求

         3、开发过程中随时会有需求变化

  让用户一开始就知道自己想要的东西是不现实的！我们可以通过不断的交付来启发用户明确需求。
        

◆ 小批量是快速交付的关键

   在需求对应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率越高；在资源利用率相同的情况下，批量越小，交付周期越短

   小批量交付的好处
         
          
         

我们首先要做的就是通过尽早地、持续地交付有价值的软件，使客户满意，经常性地交付可以工作的软件，交付间隔可以几周到几个月，越短越好。
     ——敏捷的十二个原则之一

◆ 通过迭代计划不断调整以适应需求

   每一次迭代开始，只需要详细地做本次迭代内容计划，并严格执行。对后续较远的迭代内容只做粗略计划，避免浪费。 

◆ 持续保持良好的软件架构

  良好的架构是适应变化的基石

        1、电信级软件庞大、复杂、周期长、需要良好的架构保证可以长期的演进，避免大规模返工。

         2、良好的架构可扩展，适应变化能力强，能很好地支持敏捷

         3、良好的架构耦合度低，有助于增量开发，持续构建方便

三、敏捷开发中的Scrum方法

1）什么是Scrum

术语 Scrum 来源于橄榄球活动，在英文中的意思是橄榄球里的争球。在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时，他们奋力争球。

Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

Scrum 是一种灵活的软件管理过程，它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。

Scrum 采用了经验方法，承认问题无法完全理解或定义，关注于如何使得开发团队快速推出和响应需求能力的最大化。因此，Scrum 的一个关键原则就是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。

2）Scrum 在软件开发过程框架的主要最佳实践

迭代式软件开发：通过将整个软件交付过程分成多个迭代周期，帮助团队更好地应对变更，应对风险，实现增量交付、快速反馈。

两层项目规划（Two-Level Project Planning）：基于远粗近细的原则和项目渐进明细的特点，通过将概要的项目整体规划和详细的近期迭代计划有机结合，帮助团队有效提高计划的准确度、资源管理能力和项目的按时交付能力。

整体团队协作（Whole Team）：通过关注保持整个团队可持续发展的工作节奏、每日站立会议和自组织的工作分配，实现团队的高效协作和工作，实现提高整个团队生产力的目的。

持续集成：通过进行更频繁的软件集成，实现更早的发现和反馈错误、降低风险，并使整个软件交付过程变得更加可预测和可控，以交付更高质量的软件。

3）Scrum中的三要素

Scrum 是一个包括了一系列实践和预定义角色的过程框架。任何软件开发过程框架都可以由最基本的三个要素组成：角色（人）、活动及其输入输出的工件。

     角色
           1、产品负责人（Product Owner）；
           2、Scrum 主管（Scrum Master）；
           3、开发团队

    活动
           1、冲刺规划会议（Sprint Plan Meeting）；
           2、每日站立会议（Scrum Daily Meeting）；
           3、冲刺复审会议（Sprint Review Meeting）；
           4、冲刺回顾会议（Sprint Retrospective Meeting）；

    输出工件
           1、产品订单（Product Backlog）；
           2、冲刺订单（Sprint Backlog）；
           3、燃尽图（Burndown Chart）；
           4、新的功能增量。

4）Scrum中的角色 

 Scrum 定义了许多角色，根据猪和鸡的笑话可以分为两组，猪和鸡。

一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆卖什么呢？”，鸡想了想说“餐馆卖火腿和鸡蛋怎么样？”，“我不这么认为”，猪说，“我全身投入，而你只是参与而已”。

“猪”：是全身投入项目和 Scrum 过程的人，主要包括代表利益干系人的产品负责人，同项目经理类似的Scrum 主管和开发团队。

1、产品负责人：代表了客户的意愿，这保证 Scrum 团队在做从业务角度来说正确的事情。同时他又代表项目的全体利益干系人，负责编写用户需求（Story），排出优先级，并放入产品订单（Product Backlog），从而使项目价值最大化的人。他利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个冲刺迭代中完成。他对项目产出的软件系统负责，规划项目初始总体要求、ROI（投资回报率）目标和发布计划，并为项目赢得驱动及后续资金。

2、Scrum 主管（Scrum Master）：又称为敏捷教练，负责 Scrum 过程正确实施和利益最大化的人，确保它既符合企业文化，又能交付预期利益。Scrum 主管的职责是向所有项目参与者讲授 Scrum 方法，正确的执行规则，确保所有项目相关人员遵守 Scrum 规则，这些规则形成了 Scrum 过程。Scrum 主管并非团队的领导（由于他们是自我组织的），他的主要工作是去除那些影响团队交付冲刺目标的障碍，屏蔽外界对开发团队的干扰。

 3、开发团队：负责找出可在一个迭代中将产品待开发事项（冲刺订单）转化为功能增量的方法。他们对每一次迭代和整个项目共同负责，在每个冲刺中通过实行自管理、自组织，和跨职能的开发协作，实现冲刺目标和最终交付产品。一般由 5~9 名具有跨职能技能的人（设计者，开发者等）组成。

“鸡”：并不是实际 Scrum 过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益所有者参与每一个冲刺的评审和计划并提供反馈。

1、用户：软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”。

2、利益所有者（客户，提供商）：影响项目成功的人，但只直接参与冲刺评审过程。

3、经理：为产品开发团体架起环境的那个人。

5）Scrum中的活动 

Scrum 提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范,这些有助于创造自我组织的团队。

冲刺规划会议：冲刺开始时，均需召开冲刺规划会议，产品负责人和团队共同探讨该冲刺的工作内容。产品负责人从最优先的待开发事项中进行筛选，告知团队其预期目标；团队则提出在接下来的冲刺内，评估预期目标可实现的程度。冲刺规划会议一般不超过 4 小时。在前 2 个小时中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品订单的内容、目的、含义及意图。而在后 2 小时，团队则计划本冲刺的具体安排。

每日站立会议：在冲刺中，每一天都会举行项目状况会议，被称为 “每日站立会议”。每日站立会议有一些具体的指导原则：
      1、会议准时开始。对于迟到者团队常常会制定惩罚措施（例如给大家买零食、下次主持会议等）。 
      2、欢迎所有人参加，但只有“猪”类人员可以发言。
      3、不论团队规模大小，会议被限制在 15 分钟。
      4、所有出席者都应站立（有助于保持会议简短）。
      5、会议应在固定地点和每天的同一时间举行。
      6、在会议上，每个团队成员需要回答三个问题：
           昨天你完成了那些工作？
           今天你打算做什么？
           完成你的目标是否存在什么障碍？

冲刺复审会议：一般2小时，由团队成员向产品负责人向其他利益相关人展示迭代周期内的产品开发情况，并决定下一次迭代的内容。

冲刺回顾会议（Retrospective Meeting）：每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在 2 小时。主要包括四个方面：做的好的、做的不好的、风险、经验。

           

6）Scrum 工件

产品订单：产品订单（Product Backlog）是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并作出预估。预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品适用性、实用性和竞争性。

冲刺订单：冲刺订单是大大细化了的文档，用来界定工作或任务，定义团队在 Story 中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位，没有任务可以超过 16 个小时。如果一个任务超过 16 个小时，那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。

燃尽图：燃尽图（Burndown Chart）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺中随时间变化而变化的剩余工作量（可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目）。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。我们可以借助它设想在增加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获得更多功能。它可以展示项目实际进度与计划之间的矛盾。        

新的功能增量：Scrum 团队在每个冲刺周期内完成的、可交付的产品功能增量。

7）Scrum 过程说明

在 Scrum 项目管理过程中，一般产品负责人获取项目投资，并对整个产品的成功负责。他会协调各种利益干系人，确定产品订单中初始的需求清单及其优先级，完成项目的商业价值分析和项目整体规划，并任命合适的 Scrum 主管开展项目工作。

在 Scrum 软件开发项目中，每个冲刺就是一个为期 30 天的迭代。在每个冲刺开始时，产品负责人和 Scrum 主管通过召开冲刺规划会议和“两层项目规划”的最佳实践，制定冲刺订单（类似于迭代计划），明确将在本次冲刺中实现的需求清单，相应的工作任务和负责人。在每个冲刺迭代中，团队强调应用“整体团队协作”的最佳实践，通过保持可持续发展的工作节奏和每日站立会议，实现团队的自组织、自适应和自管理，高效完成冲刺工作。在每个冲刺结束时，团队都会召开冲刺复审会议，团队成员会在会上分别展示他们开发出的软件（或其他有价值的产品），并从产品负责人和其他利益干系人那里，得到反馈信息。

在冲刺复审会议之后，团队会自觉召开冲刺回顾会议，回顾整个项目过程，讨论那些方面做得好，哪些方面可以改进，实现软件交付过程的持续、自发的改进。

四、敏捷中的一些术语

1）Story 用户故事

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
           角色：谁要使用这个功能。
           活动：需要完成什么样的功能。
           商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：
           作为一个<角色>, 我想要<活动>, 以便于<商业价值>
           例如: 作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给 他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

Story的六个特性 INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

独立性（Independent）: 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）: 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）: 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）:开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）: 一个好的故事在工作量上要尽量短小，最好不要超过8个人/天的工作量,至少要确保的是在一个迭代能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。 

可测试性（Testable）: 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

2）任务墙

任务板（墙）展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。

3）持续集成

什么是持续集成？

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。请注意，持续集成不等于持续的编译。

      持续集成要素
            统一的代码库
            自动构建
            自动测试
            每个人每天都要向代码库主干提交代码
            每次代码递交后都会在持续集成服务器上触发一次构建
            保证快速构建
            模拟生产环境的自动测试
            每个人都可以很容易的获取最新可执行的应用程序
            每个人都清楚正在发生的状况
            自动化的部署
      持续集成的价值
            减少风险
            减少重复过程
            任何时间、任何地点生成可部署的软件
            增强项目的可见性
            建立团队对开发产品的信心 

五、我的敏捷开发心得体会

1、敏捷的确可以提高工作效率和产品质量

2、最重要的是理解并接受敏捷的思想

3、开发过程中必须遵循敏捷的原则，但具体的活动可以灵活控制

4、敏捷对人的能力要求较高，同样对人的能力提升也快

5、刚开始按照敏捷的原则办事会比较痛苦，比较累，但是熬过这段时间就会从中大大获益