《敏捷宣言》

2001年2月，17名软件专家在美国犹他州瓦萨奇山雪鸟滑雪胜地相聚，经过几天的讨论和辩论，共同起草了《敏捷软件开发宣言》，简称《敏捷宣言》。这些专家包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们。许多人已经有了自己创建的方法论，并开始传播，他们都具有编写软件的丰富经验，并且都在寻求文档驱动的重量级软件开发流程的替代方案。

敏捷宣言四大价值观

• 个体和互动高于流程和工具。
• 工作的软件高于详尽的文档。
• 客户合作高于合同谈判。
• 响应变化高于遵循计划。

也就是说，尽管右项有其价值，但更要重视左项的价值。

伴随着四大价值观，敏捷宣言提供了12条原则：

1、我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意(价值优先)。

2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，通过敏捷过程掌控变化(拥抱变化)。

3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期(短迭代交付)。

4、业务人员和开发人员必须相互合作，项目中的每一天都不例外(业务参与)。

5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标(以人为本)。

6、无论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈(面对面沟通)。

7、可工作的软件是进度的首要度量标准(成果导向)。

8、敏捷过程倡导可持续开发。发起人、开发人员和用户要能够共同维持其步调稳定延续(保持节奏)。

9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强(追求卓越)。

10、以简洁为本，它是极力减少不必要工作量的艺术(简单务实)。

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

12、团队定期地反思如何能提高成效，并相应地调整自身的行为(持续改进)。

尽管这些价值观和原则源自于软件行业，但至今敏捷方法的应用已扩展到许多其他的非计算机软件开发行业，并将其发展为一种思维模式，在许多不同的实践中体现。

敏捷软件开发

“敏捷”是一个囊括了各种框架和方法的涵盖性术语。它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。敏捷软件开发简称敏捷开发，是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重人的作用。

敏捷开发的发展过程中，出现了多个不同的流派，比如：极限编程(Extreme Programming，XP)、自适应软件开发(ASD)、动态系统开发方法(DSDM)、水晶方法、特性驱动开发(FDD)等，但其中的基本原则是一致的。从开发者的角度，主要特点有站立会议、看板、小版本发布、较少的文档、注重合作、客户参与、自动化测试、适应性计划调整、结对编程等等。从管理者的角度，主要关注点有测试驱动开发(TDD)、持续集成(CI)、重构等等。在具体项目中，各团队可选择适合其项目和组织文化的不同方法和实践。

还可以将敏捷方法视为精益方法的子集，它们都是精益方法的具体实例。

敏捷是许多方法的一个总称

看板方法虽然是精益阵营中的一种重要方法，但人们也通常将其视为一种重要的敏捷框架，广泛地应用于敏捷环境中。

所有这些方法都具有以下共同特征：

1、迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2、增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3、开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4、持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。

5、开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

敏捷开发过程

敏捷开发过程

敏捷开发过程通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。从业务角度看，敏捷就是创建组织更快(早)地交付有价值的产品和灵活地响应变化的能力。

结构化的需求管理

Epic、Feature、Story、Task是用来划分需求颗粒度的标签，需求根据颗粒度大小按分为不同的层级。

• Epic：史诗，是项目的愿景目标。通常是对整个项目的概括性描述。
• Feature：可以带来价值的产品功能或特性。Feature比Epic更具体形象，用户可以感知，具有业务价值。
• Story：我们通常所说的用户故事，User Story的简称。是从用户角度对产品功能的详细描述，承接Feature，并放入项目的待办事项列表，动态调整。始终让高优先级的Story优先交付给客户。Story要符合INVEST原则：Independent(独立的)、Negotiable(可讨论的)、Valuable(有价值的)、Estimable(可估算的)、Small(颗粒度适中的)、Testable(可测试的)。
• Task：是团队成员要完成的具体任务。通常将Story分配给开发人员，然后开发人员将Story分解为Task并估算相应的工时。

Epic-Feature-Stroy-Task是一种将需求进行结构化管理的方法，从上到下逐层分解并形成自下而上的依赖。在实际开发过程中，需要变换而动态调整时，要避免偏离目标方向，保证所添加的Story和Task和它们上层是有关联的。从而保证团队的工作是在朝着目标前进。

敏捷团队

敏捷团队注重快速开发产品。在实践中，最有效的敏捷团队往往由5到9个成员组成。理想情况下，敏捷团队应该集中在一个团队工作场所工作，团队成员都为专职成员。敏捷提倡自我管理型团队，敏捷团队与仆人式领导一起成长，领导充分信任并支持团队的工作方法。

特点一：自组织自管理

自组织自管理是指当团队遇到问题的时候，团队成员需要自己研究解决方案，自己解决问题，不需要领导的监督，实现自我驱动。例如：如果一个团队成员承诺8个小时完成某一项开发任务，并认领了该任务，就不需要其他人去监督他了，自己可以主动完成任务，主动反馈问题，主动寻求帮助等等。

特点二：自适应

通过对以往项目的研发流程、技术方案、团队协作、交付成果、客户反馈、存在的问题等进行回顾、复盘、反思，团队自行优化调整，以更好地进行下一次迭代过程。

特点三：完全透明

项目进行过程中，团队成员每天在做什么，遇到了什么问题，完成了什么任务，彼此都是清晰了解的。可以在每日站会中传递这些信息，或是在看板中展示。

常见敏捷实践

敏捷开发过程有一些常用实践，在实际开发过程中可以参照或有选择性执行。

回顾

回顾也经常称作“复盘”、“阶段性总结”，是最重要的一个实践，原因是它可以帮助团队从之前的产品开发工作及其过程中学习、改进和调整其过程。敏捷的原则之一是“团队定期地反思如何能提高成效，并相应地调整自身的行为”。回顾可以在项目中间进行，也可以在项目结束时进行。通常可以选择在这些关键时刻进行：

• 当团队完成一个发布或者加入一些功能时。不一定是一个巨大的增量，可以是任何发布，无论它有多小。
• 自上次回顾以来，又过了几周时间。
• 当团队出现问题时，以及团队协作完成工作不顺畅时。
• 当团队达到任何其他里程碑时。

通过回顾，针对定性的或定量的数据为依据，然后利用这些数据找到根源，设计对策，并对所有的需要改进的事项进行优先级排序和制定行动计划，然后团队选择合适数量的事项加入下一次迭代计划。

重要的是，回顾并不是责备，而是让团队学习并改进。

待办事项列表

待办事项列表可以理解为一个需求池，我们收集到的客户需求和反馈意见，以及团队内部的产品规划和反馈意见，都可以存放到需求池，并给每一项需求标注优先级和计划版本，以显示预期的可交付成果序列。根据实际情况，优先级和计划版本也可以动态调整。依据待办事项列表，就可以划定下一个迭代开发的范围。

每日站会

团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。需要为每日站会规定时间，比如不超出15分钟。可以通过某种形式“过一下”看板或任务清单，团队中的任何人都可以主持站会。

通常，在基于迭代的敏捷中，每个团队成员都轮流回答下列问题：

• 上次站会以来我都完成了什么?
• 从现在到下一次站会，我计划完成什么?
• 我的障碍(或风险或问题)是什么?

从这些问题得出的答案能够让团队自我组织，并让团队成员为完成之前和整个迭代中承诺完成的工作承担彼此的责任。

站会是为了发现存在问题，而不是解决它们。将问题记录起来，然后创建另一次会议，它可以在站会之后立即召开或者选择某个合适的时间召开，并在会上解决问题。

要鼓励任何团队成员主持会议而不是由项目经理或领导主持，以确保它不会变成状态报告会议，而是作为团队进行自我组织和相互承诺的会议。

看板

在敏捷项目管理中，团队常用的一个工具就是白板加上便签。我们可以把任务写在便签上，把白板做成待办、处理中、已完成等泳道，然后把这些便签贴到相应的泳道里面，每天更新各项任务的进度。团队成员也可以根据看板清楚地了解到每项任务的进度等信息。

展示/评审

当团队以用户故事的形式完成特定功能时，团队会定期展示工作成果。看过展示后，产品负责人接受或拒绝故事。一般的指导方针是，每两周至少展示一次团队的工作产品，这种频率对于大多数团队来说是足够的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。

展示/评审的作用还体现在，可以保障产品、开发和测试对需求理解一致。我们在敏捷过程中通过版本计划评审、需求评审、设计评审、测试用例评审和开发ShowCase这几个关键活动保障。版本计划评审和需求评审中，产品经理讲解版本范围、需求及上下文关联影响，开发和测试都会参加，如果需求理解不一致的地方就马上沟通由产品经理把关。到测试用例评审的时候，需求细化成一个个测试用例，这样让开发和测试进一步深化理解需求达成一致。到开发完成功能，给测试和产品Showcase，测试和产品再一次核对开发实现功能与需求是否一致，明显不一致的地方当场指出来，等开发人员修正后才提交给测试进行测试，这样就能及早发现开发中的一些问题，避免带到测试环境，提升测试的有效性。

持续集成

持续集成是指每当我们有新的代码产出时，可以通过一种自动化的方式在服务器上进行构建、打包，进而可以发布到集成环境、测试环境或者生产环境里面。有了持续集成作为基础，我们才能快速对代码进行重构(所谓重构就是响应变化)、尽快收到反馈、以及频繁发布。