2.1 敏捷理论体系解读

敏捷的内容非常丰富，本节对敏捷的理论体系的介绍主要通过如图2-1所示的几个方面展开。

2.1.1 敏捷背景介绍

敏捷最初于20世纪50年代被提出，并被认为是一种奇怪的、甚至无政府主义的观点。随后，在企业实践过程中出现了各具特色的敏捷模型，如 XP、TDD、DSDM、自适应软件开发、水晶系列、Scrum等。2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）一词被全体聚会者所接受，用以概括一种全新的软件开发价值观。这种价值观，通过一份简明扼要的“敏捷软件开发宣言”（以下简称敏捷宣言）被传递给了世界，宣告了敏捷开发运动的开始（见图2-2）。

敏捷提出的初衷是形成一套更加快速、更加可靠的软件开发方法，让软件使用者尽可能早地看到满意的产品。

2.1.2 三大支柱解读

敏捷框架并非预测性的框架，瀑布源于工程学，瀑布模型是预测性的框架。由于项目立项建设周期长，在开始设计和构建之前，往往要一次性完成半年或一年的计划，预先要进行周密规划和立项调研。层层审批后，会形成一份长长的时间进度表。在项目实施过程中，随着资源的变化、需求的变更，进度会产生严重偏差，进而导致计划失控，陷入混乱的泥潭。敏捷范围管理的主要特征在于，在一部分范围明确需求后（具备前期几次迭代的功能需求后），就开始架构设计具有不完全范围的解决方案。在迭代过程中，不断向产品的需求列表中添加新特性，并从客户那里收集反馈，以便更好地理解客户的想法，不断完善现有产品的功能，这是自适应生命周期的主要特征之一。

敏捷有三大支柱，分别是透明度、可检验、自适应，如图2-3所示。

所谓透明度就是指团队内部不应该有秘密的小团队，不应该有秘密的日程，也不应该有其他什么秘而不宣的事情。在组织或团队里，如果每个人都不知道其他人在忙什么，也不清楚其他人平日的忙碌对于项目有什么贡献，就容易产生隔阂。只要一切透明，团队就能通过自我组织来解决显而易见的问题。透明度高、注重信息分享的团队工作默契程度高，效率会明显提高。

可检验指的是在开发过程中经常性地停下手中的工作，对已经取得的成果进行检查，看看这些成果是否是自己期待的，想想有没有更好的方法来改进。这看似简单，做起来并不容易，这需要从事相关工作的人员有思想，善于自省，具有实事求是的精神和自我约束的意识。

当团队或个体可以进行自我管理，有能力决定如何开展工作，并获得了如何做事的决定权后，若发现最终交付的产品无法达标、无法满足预期，便需要对过程或工作方式进行调整。能够调整自己的行为，意味着我们能适应任何环境，这种调整与检验会形成一个良好的循环，即自适应。

2.1.3 四大核心价值观及解读

四大核心价值观是敏捷宣言所传递出的重要信息，如图2-4所示。

下面分别介绍四大核心价值观。

价值观1：个体和互动高于流程和工具。

管理层习惯将管控体系想象成超级复杂的机器，并以为拥有完美的流程和工具就会带来完美的结果，而技术人员只不过是机器中的某个配件或某道工序，他们的工作可随时被新人取代。然而IT产品的实现过程是无形的，它是由技术人员的智慧、知识和经验创造的，所以人员比生产流水线更重要。敏捷提出，要更关注人的绩效和能力的提升，形成团队成员默契愉快的合作关系。

价值观2：工作的软件高于详尽的文档。

说不清从什么时候开始，软件项目的文档越写越多。而写文档是在初期设计方案时，与客户沟通产品需求的辅助方式。我们常常发现，当客户看到已完成开发的功能后会产生新的灵感，告诉我们他们真正想要的功能是什么样的。使用文档充分记录这些过程可以还原事情的真相，但也加重了项目的负担。当然，不是说文档没有意义，而是我们现在可以使用更灵活的方式来记录信息，比如交给运维团队的操作手册可以是录制好的视频，这样更生动，信息也更全面。

价值观3：客户合作高于合同谈判。

要与客户建立长期的合作关系，愿意在项目开发过程中随时按照客户要求进行更改。

价值观4：响应变化高于遵循计划。

面对市场和环境的变化，我们要接受客户层出不穷的想法，要有适者生存的能力，不基于预测式的项目管理框架，避免前期长时间投入追求完美的设计阶段。应该使用一个自适应的生命周期，因为客户的想法是不断浮现出来的，客户迟来的想法不会带来很多返工的问题，因为我们的规划和设计也是逐步完善的。

2.1.4 12条原则及解读

四大核心价值观在实践中能够起到引导作用，但是具体实践的时候需要进一步细化，由此引入了12条原则，如下所示。

第1条，我们最重要的目标是通过持续不断地较早交付有价值的软件使客户满意。

“客户满意”和“有价值的软件”是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，关键在于开发期间与客户密切合作。产品管理是确保客户需求在开发期间能被正确理解的关键。我们应该把精力集中于对客户而言最有价值的工作上。拥有较早交付有价值的软件的能力是满足客户的关键。

第2条，欣然面对需求变化，即使在开发后期也一样。为了获取竞争优势，敏捷掌控变化。

敏捷框架基于自适应性的开发生命周期，我们总能接受变化，因为每次我们想改变某些东西时，不需要重新规划前期已定义的设计。除此之外，我们很乐意接受变更请求，因为每一项变更都离客户真正的需求更近了一步。

第3条，经常地交付可工作的软件，相隔几星期或一两个月，最好采取较短的周期。

开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是缩短开发周期。发布周期的长度依赖于业务决策，并且和客户的期望紧密关联。短开发周期内的频繁交付缩短了反馈周期并可促进团队沟通。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。

第4条，业务人员和开发人员必须相互合作，项目进行中的每一天都不例外。

只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品经理可以知道市场状况、客户需求和客户价值，开发团队可以知道产品和技术的可行性。

第5条，激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，并加以信任，从而达成目标。

软件开发是基于技术专家、团队成员的知识储备和经验而开展的工作，开发过程更像是一种创造，在激发个体的斗志和创造力中，个体的自主性是关键因素。人在受到尊重并且有权决定自己的工作方式时通常工作得更好。每次冲刺要设定团队明确的目标和范围，角色职责清晰，形成自组织。

第6条，不论团队内外，传递信息效果最好、效率最高的方式是面对面交谈。

团队甚至客户工作在同一个场所是最合理的。当我们看到人们彼此交谈时，信息更多以听说的形式被传递，这种沟通方式称为“渗透式”沟通，而这些交流的信息是文档无法替代的（虽然不能否认文档的重要性）。将每件事都写下来简直是不可能的，我们不应该只依靠写文档来传递重要信息。然而，如果团队无法实现在同一场所工作，我们应该充分利用现代技术，如聊天群，尽量降低因无法面对面沟通而带来的影响，并在日常例会时同步任务进展和问题。

第7条，可运行的软件是进度的首要度量标准。

程序文件即使完成 99%，其代码仍是跑不通的，这跟完成 0%是一样的，除非技术人员能跟客户一起找到共同的标准来沟通进展。解决这一问题的方法是，我们要与客户同步需求待办清单进度的完成/未完成状态，并通过完成/未完成状态来跟踪需求的整体进展，以及需求测试通过/未通过的质量信息。

第8条，敏捷倡导可持续开发。责任人、开发人员和用户要能够共同维持开发步调稳定可持续。

每天上班打卡不是真正的目标，实现产品交付才是目标。加班似乎会让流程变得更快，但事实上，加班会降低生产率并增加产品缺陷，从而影响产量，人越是疲劳，创造力就越低。我们宁愿保持一种可持续的步伐。

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

敏捷不强调前期设计并不意味着不需要担心设计。敏捷项目里一定是包括设计的，在每次迭代中每个需求都会有设计任务。而且，任何技术负债（代码缺陷、架构缺陷等）都会使开发速度减慢。我们不应该让技术负债积压，所以要持续地进行重构，弥补发现的缺陷，持续关注架构的质量。

第10条，以简单为本，极力减少不必要的工作量。

这种原则既适用于产品的功能特性，也适用于流程，多余的功能不要添加。所有流程应该时刻面临挑战。例如，这步真的需要吗？谁会读这个文档？这个功能可以为客户带来什么价值？

第11条，最好的架构、需求和设计出自组织团队。

架构、设计和需求会随着项目的进行慢慢浮现，并且团队会从中学到很多东西。一些前置、架构和设计是必要的，但是不能把它们定义在纸面上。架构师和系统工程师是管理研发团队的一部分，不要成为“孤岛”。

第12条，团队定期地反思如何能提高成效，并依此调整自身的举止表现。

无论我们工作做得多好，我们相信总有改善的余地。花时间反思和从经验中学习能够持续改进产品。

2.1.5 Scrum敏捷框架

本小节将就如何实践Scrum敏捷框架进行说明。

1.Scrum敏捷框架简介

敏捷框架有很多种，Scrum只是其中一种。根据2018年Scrum联盟的报告，在敏捷实践中，Scrum敏捷框架占55%的比例，另外还有Scrum/XP（Scrum和XP的结合）、Scrumban（Scrum和看板的结合）等方式也使用到了Scrum敏捷框架。Scrum是目前十分流行的敏捷框架。敏捷框架使用状况如图2-5所示。

从图 2-5 中也可以看出，Scrum 敏捷框架是目前敏捷实践中的主流框架，这也是我们从多种框架中挑选Scrum敏捷框架进行介绍的原因。

Scrum敏捷框架最早由Jeff Sutherland在1993年提出。Ken Schwaber于1995年在OOPSLA会议上标准化了Scrum敏捷框架的开发过程，并向业界公布。

“Scrum”一词引自“橄榄球”。球队成员的合作亲密无间，球队成员灵活机动地接球、传球，并作为一个整体迅速突破防线，这个情景可能更能适应今天更具挑战性的市场需求。

在Scrum敏捷框架中，Sprint是一个非常重要的概念，它的本意是指冲刺，一个Sprint就是一个迭代。Scrum项目通过一系列的Sprint来推进，Sprint长度通常为2～4周，它是一个时间箱。稳定的周期会带来更好的节奏，在项目进行过程中不允许延长或缩短Sprint长度。

Scrum敏捷框架的内容也非常丰富，这里介绍其主要的组成部分，主要围绕如何展开Sprint来进行。

● 三个角色：产品负责人（Product Owner）、Scrum教练（Scrum Master）、Scrum团队（Scrum Team）。

● 四个活动：冲刺规划会议（Sprint Planning Meeting）、每日站立会议（Daily Scrum Meeting）、冲刺复审会议（Sprint Review Meeting）、冲刺回顾会议（Sprint Retrospective Meeting）。

● 三个工件：产品待办清单（Product backlog）、冲刺待办清单（Sprint backlog）、燃尽图（Burn-down chart）。

在本节接下来的内容中，我们将会介绍Scrum敏捷框架的组成和实践方法。

2.三个角色

Scrum敏捷框架中包含三个角色：产品负责人、Scrum教练与Scrum团队。

1）产品负责人

产品负责人负责建立和维护产品特性，这需要与客户不断地沟通和协作，决定产品应该做什么，定义产品需求，最重要的是确定需求的优先顺序。总体而言，产品负责人需要具备如下4个特点。

● 产品负责人需要在相关领域内掌握丰富的专业知识。一方面，只有对团队内部的工作流程和技术水平足够了解，才能知道哪些事情能做，哪些事情不能做。另一方面，只有了解当前正在采用的流程，才能知道哪些事情是真正有价值的。

● 产品负责人必须获得自主决策权。产品负责人应该被给予决策权，这样才能自行决定产品的前景与具体实现，产品负责人应该为结果负责。

● 产品负责人必须有足够的时间与团队成员接触，向团队成员解释清楚需要做什么，以及为什么要这么做。

● 产品负责人必须对价值负责。在商业语境下，最重要的就是收益。团队通过每个“故事点”可以创造多少收益去评价一位产品负责人的业绩。假如已知一个团队每周完成 40个“故事点”的工作量，就可以计算出每一个“故事点”可以创造多少收益。

2）Scrum教练

橄榄球赛场的教练会尽可能地发挥上场球员的优势，让我们感受到每个球员由内而外地散发出一股能量，这些能量可以汇聚成一股更为强大的能量。Scrum 教练与之相比，要做的是确保团队实现快速交付。我们常听到 Scrum 教练与团队成员探讨：“我们如何才能做得更好？”这会引导团队整体持续地改善自己的工作。

Scrum教练需要做到：

● 导入敏捷文化和最佳实践，确保每个团队成员认同和尊重敏捷的价值观；

● 激励团队士气，促进团队合作，确保团队富有效率；

● 帮助团队排除干扰，确保冲刺目标的顺利进行；

● 不是一位事无巨细的管理者，更像是服务于团队的“仆人”；

● 确保团队运作过程透明。

3）Scrum团队

Scrum 源于经验主义，因此稳定的团队所积累的经验对于规划的判断非常重要。相关研究表明，稳定的团队比新组建的团队的生产力要高。团队成员之间的熟悉度也对产出效率和质量有着积极的影响。除了生产力方面的影响，稳定的团队对于规划也至关重要。每个Scrum团队由于组成的人员不同，因此各有特色，工作节奏各不相同。强迫一个团队盲目遵从其他团队的工作方式，未必会有好的效果。

● Scrum团队一般有6～9个人。

● 程序员、测试员、界面设计人员等团队成员应当是跨职能、多样化的，具备所谓的“T”型技能。

● 团队成员必须是全职投入的。

● 团队自我组织：在理想情况下，团队成员是平等的，不分头衔的。

● 在一个Sprint中应保持成员稳定。

● 负责将Product Backlog转化成Sprint中的工作项目。

● 所有团队成员协调、合作完成Sprint中的每一个规定的交付物。

3.四个活动

Scrum 敏捷框架中包含四个主要的活动，实际都是项目会议，接下来我们将对每个会议的目的、形式、结果进行说明。

1）冲刺规划会议

每个冲刺都将冲刺规划会议作为开始，这是一个固定时长的会议（不超过4小时），在这个会议中，Scrum团队共同选择和理解本轮冲刺要完成的工作。

会议形式包括如下两项议程。

第一项议程：首先由产品负责人介绍产品，确定该Sprint将要完成什么任务。产品负责人向团队明确产品待办清单中优先级最高的产品，与团队一起明确冲刺目标，基于团队的能力和以往冲刺的速率一起决定冲刺中需要完成的产品数量。

第二项议程：Scrum 团队研究本轮冲刺如何完成要交付增量的工作产品或功能。Scrum 团队对冲刺需要完成工作产品的数量和复杂度达成共识，对需求充分理解并进行估算，将产品待办清单中的内容转化成软件开发中的具体工作任务。任务需要被分解，以便在一天之内完成。团队通过自己认领的方式获取任务。

会议结果：每个团队明确本轮冲刺的目标，每个人明确本轮冲刺各自的具体工作任务。

2）每日站立会议

会议目的：Scrum团队通过每日站立会议来确认他们仍然可以实现Sprint的目标。

会议形式：由Scrum团队自己组织，条件允许的话，每天都应该在同样的时间和地点组织所有成员站立进行。只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。最好是每天早晨进行，会议时长一般为15分钟左右，时间比较短，有利于团队成员安排好当天的工作。

Scrum团队所有成员轮流回答以下3个问题。

● 昨天我完成了什么工作？

● 今天我打算做什么？

● 我在工作中遇到了什么困难，是否阻碍了我的工作进展？

3）冲刺复审会议

会议目的：冲刺复审会议用来演示在这轮冲刺中开发的产品功能，由产品负责人进行确认。产品负责人也可以邀请相关的人参加。

会议形式：

● 团队按冲刺计划，逐个介绍并现场演示这次冲刺完成的功能。

● 如果产品负责人想要改变功能，则需要添加到新的需求列表中，出现的缺陷也要加入缺陷列表中。

● 如果项目遇到障碍一时无法解决，把该障碍加入障碍类列表中。

● 不需要太正式，不需要PPT，会议时长控制在2小时以内。

会议结果：对这次冲刺的成果和整个产品的开发状态达成共识。

4）冲刺回顾会议

会议目的：团队的定期自我检视，全体成员讨论有哪些好的做法可以形成团队的规范，哪些不好的做法不能再继续下去，以及哪些好的做法要继续发扬。

会议形式：

● 会议时长一般控制在15～30分钟。

● 每个冲刺都要做。

● 全体参加。

不管我们发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，以及所拥有的技能和可得到的资源，在限定的环境下，可以做出最好的成果。

会议结果：让每个人都了解开发过程是什么样的，冲刺结束后需求或任务的完成标准是什么。

4.三个工件

除了三个角色与四个活动，Scrum 敏捷框架中还包含三个工件：燃尽图、产品待办清单、冲刺待办清单。

1）燃尽图

使工作透明化的工具之一就是燃尽图，在图 2-6 中，横轴代表本轮冲刺的工作天数，纵轴代表工作量，用于跟踪团队成员冲刺剩余天数可用的工作量和实际剩余任务的工作量。随着剩余天数的减少，剩余任务的工作量也逐渐减少，在理想情况下，最终剩余天数和剩余工作量会延展向下，“燃尽”至零。

接下来通过一个案例来展示项目中燃尽图的使用方式。假设在某个项目中共有5天的冲刺时间，在这个冲刺中相关人员所分配的任务信息按照预测和实际进行了每日更新，如图2-7所示。

有了这样的信息，团队成员在当前冲刺的可用工作量和实际工作量的关系就能以“燃尽”形式体现出来，如图2-6所示。

2）敏捷待办清单

敏捷待办清单分为产品待办清单和冲刺待办清单。产品待办清单就是传统的需求清单，也称为需求池，它是项目最终需要交付的功能蓝图，是预期的最终产品的愿望清单，这个清单列出了所有的功能，是有序列表，而且是动态的，将包括不断完善和细化的需求。这些需求都用简单的、非技术的、商业的语言来描述，我们称之为故事，所有的故事对项目每个干系人都是可见的。项目的每一个要求和每一个变化都将以用户故事的方式进行描述。冲刺范围内的故事，也称为冲刺待办清单，是优先级最高的用户故事。

5.用户故事和产品增量

除了三个角色、四个活动、三个工件，在Scrum敏捷框架中还有一些重要的概念，比如用户故事和产品增量。

1）用户故事

相较于传统的需求分解，在敏捷中，故事的写法也非常重要。要想学会写用户故事，要思考客户可以从产品中得到什么价值，为什么要给客户提供这样的价值，或用户为什么会需要这些价值。按照叙事思维来组织用户故事，比如作为 X，我想要Y，所以做 Z。设计用户故事时可以加入用户使用场景，这是一种融入用户体验的设计思维。

用户故事的编写，可以通过如图2-8所示的INVEST原则来进行，具体说明如下。

● 独立的：如果用户故事不是独立的，将无法根据其业务价值对其进行排序。价值排序是可以调整的，在每次冲刺总结后都可以重新定义故事的优先级。如果不能完全独立，就要将相关的解决方案尽量合并在一起，在同一轮冲刺中完成。

● 可协商的：产品故事的定义要便于沟通，与内部团队及客户之间是可以协商的，通过协商可以完善需求的各个细节和解决方案。

● 有价值的：每个故事都应该能体现其对产品整体的商业价值，评判故事价值应尽可能使用可量化的标准，量化的价值是产品故事的排序依据。

● 可估计的：只需对产品待办清单顶部的故事进行估计。未明确和细化的故事因为需求和方案是不确定的，所以没有估计的价值。在每次的冲刺启动会中，要对本轮冲刺的故事重复估计。

● 小的：只有产品待办清单顶部的用户故事是最小的，不清晰的故事是难以估计的，应该排在待办清单的下方。

● 可测试的：故事的定义要包括验收标准，验收标准可以作为用户故事的补充，也可以作为工作完成准则（Definition of Done，简称为DoD）的一部分。

2）产品增量

产品增量指的是冲刺结束时，开发团队基于冲刺待办清单完成的功能总和。产品负责人可以接受团队完成的功能，也可以拒绝未满足产品经理要求的功能，未完成的功能需要重新整理到产品待办清单中，如图 2-9 所示，随着完成的功能增量的增加，产品待办清单中的故事数量随着冲刺迭代而降低。