2.3 敏捷过程
20世纪90年代后期，随着技术的发展和经济的全球化，软件开发也出现了新的特点，即在需求和技术不断变化的过程中实现快速的软件开发。在这个背景下，软件行业借鉴了制造业“敏捷制造”的思想，逐渐形成了敏捷（agile）软件开发这一新型软件开发模式。在2001年，以Kent Beck、Martin Flower、Alistair Cockburn等为首的一些软件工程专家成立了“敏捷联盟”（http://www.agilealliance.com），并提出了著名的敏捷宣言，这标志着敏捷软件开发的思想逐步走向成熟。
和传统过程不同的是，敏捷过程强调以人为本，快速响应需求和变化，把注意力集中到项目的主要目标——可用软件上，在保证质量的前提下，适度文档、适度度量。敏捷过程基于适应而非预测，它弱化了针对未来需求的设计而注重当前系统的简化，依赖重构来适应需求的变化，通过快速、短迭代的开发，不断产出和演化可运行软件。敏捷过程以人为导向，把人的因素放在第一位。它认为，软件开发中的绝大部分是需要创造力的设计工作，因此，在管理理念上应注重领导和协作，而非命令和控制，充分发挥软件人员的能动性和创造力。敏捷过程特别强调软件开发中相关人员间的信息交流，认为面对面的交流的成本要远远低于文档交流的成本，应减少不必要的文档，提高应变能力。
从本质上讲，敏捷过程是为克服传统软件过程中认识和实践的弱点开发而成的，它可以带来多方面的好处，但并不适用于所有的软件开发项目。它也并不完全对立于传统软件工程实践，而是保留了传统软件工程实践的基本框架活动：客户沟通、策划、建模、构建、测试、交付、迭代等，但将其缩减到一个推动项目组进行构建和交付的最小任务集。
2.3.1 敏捷过程的价值观和原则
敏捷过程的框架分为四个层次：动机、价值、原则和实践，如图2-6所示。
（1）动机
互联网的迅猛发展和经济全球化向软件开发提出了新的挑战：快速的市场进入时间、快速变化的需求、快速发展的技术。在这个背景下，许多软件工程师都试图改变传统软件过程的复杂性，自下而上地提出了敏捷过程。
（2）价值
《敏捷宣言》中包含了四条著名的敏捷价值观，所有敏捷过程都必须同意这个价值观才能加入敏捷联盟中。
图2-6 敏捷过程的四个层次
● 注重个人和交互胜于过程和工具。
● 注重可用的软件胜于事无巨细的文档。
● 注重客户协作胜于合同谈判。
● 注重随机应变胜于循规蹈矩（恪守计划）。
敏捷开发认为关注左边的内容更能适应市场需求，提升客户满意度。
（3）原则
从四条敏捷价值观出发，敏捷联盟提出了十二条基本原则：
● 最优先的目标是通过尽早地、持续地交付高价值的软件来满足客户需要。
● 欢迎需求变化，甚至在开发后期也是如此。敏捷过程通过驾驭变化来帮助客户取得竞争优势。
● 经常交付可用软件，间隔从两周到两个月不等，优先采用较短的时间尺度。
● 整个项目自始至终，业务人员和开发人员都必须每天在一起工作。
● 以积极主动的人员为核心建立项目团队，给予他们所需的环境和支持，并且信任他们能够胜任工作。
● 在开发团队内外传递信息最有效率和效果的方法是面对面的交流。
● 可用的软件是最主要的项目进展指标。
● 敏捷过程提倡可持续的开发。项目发起人、开发者和用户都应该始终保持稳定的工作步调。
● 持续关注技术上的精益求精和优良的设计以增强敏捷性。
● 简约——使必要的工作最小化的艺术——是成功的关键。
● 最优的架构、需求和设计浮现于自组织的团队。
● 团队定期不断地对如何更加有效地开展工作进行反思，并相应地调整、校正自身的行为。
这些敏捷原则是用来判断一个组织是否做到了敏捷的主要依据。
（4）实践
敏捷到底应该如何做？如何将敏捷价值观和原则落到实处？这是大多数人最关心的问题。人们已研究总结出大量成熟的敏捷实践，在此基础上提出了一系列具体的敏捷过程，如Scrum、Kanban、XP、AgileUP、AM（Agile Modeling）、Lean、FDD、Crystal等。接下来将介绍最有代表性的敏捷过程——Scrum和Kanban。
2.3.2 Scrum
Scrum是目前最流行的软件过程，它关注敏捷的软件项目管理，由Ken Schwaber和Jeff Sutherland于1993年提出，已在全球许多公司中应用，适用于需求难以预测的复杂商务应用产品的开发。Scrum一词来源于橄榄球运动，意为两队并列争球。敏捷软件开发就像是橄榄球的争球过程，是迅速的、有适应性的、自组织的。
Scrum认为软件开发过程更多是经验性过程（empirical process），而不是确定性过程（defined process）。确定性过程是可明确描述的、可预测的，因而可重复执行并能产生预期的结果，并能通过科学理论对其进行最优化。经验性过程与之相反，应作为一个黑箱（black box）来处理，通过对黑箱的输入输出不断进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，从而产生满意的输出。Scrum方法将传统软件开发中的分析、设计、实现视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边缘，充分发挥人的创造力。若将经验性过程按确定性过程来处理（如瀑布模型），必将使过程缺乏适应力。
Scrum的核心准则是自我管理和迭代开发。
（1）自我管理
Scrum团队的目标是提高灵活性和生产能力。为此，他们自组织、跨职能，并且以迭代方式工作。每个Scrum团队都有三个角色：①Scrum主管（Scrum Master），负责确保成员都能理解并遵循过程，通过指导和引导让Scrum团队更高效地工作，生产出高质量的产品；②产品负责人（Product Owner），定义和维护产品需求，负责最大化Scrum团队的工作价值；③团队（Team），负责具体工作。团队的理想规模是5～9人，团队成员具备开发所需的各种技能，负责在每个Sprint（冲刺迭代）结束之前将产品负责人的需求转化为潜在可发布的产品模块。
Scrum过程中没有中心控制者，强调发挥个人的创造力和能动性，鼓励团队成员进行自我管理，使用自己认为最好的方法和工具进行开发。Scrum主管的职责不是检查和监督团队成员的日常工作，而是消除团队开发的外部障碍，指导团队成员工作，对内部成员进行培训。Scrum通过鼓励同场地办公、口头交流和遵守共同规范创建自组织团队。
（2）迭代开发
Scrum是一种演化型的迭代开发过程，如图2-7所示。Scrum的核心是Sprint，即贯穿于开发工作中的短期迭代。一个Sprint周期通常为1～4周，它是一个固定时间盒，在项目进行过程中不允许延长或缩短。每个Sprint都会提交一个经测试可发布的软件产品增量版本。Sprint由Sprint计划会、开发工作、Sprint评审会和Sprint反思会组成。
图2-7 Scrum过程
Scrum采用四个主要的文档：产品待办事项列表（product backlog）、Sprint待办事项列表（Sprint backlog）、发布燃尽图（release burndown chart）和Sprint燃尽图（Sprint burndown chart）。产品待办事项列表是囊括了开发产品可能需要的所有事项的优先排列表。Sprint待办事项列表包含在一个Sprint内将产品待办事项列表转化成最终可交付产品增量的所有任务。发布燃尽图衡量在一个发布计划的时间段内剩余的产品待办事项列表。Sprint燃尽图衡量在一个Sprint时间段内剩余的Sprint待办事项列表条目。
Scrum采用任务板来可视化软件开发的进展，它可以是一个大白板，也可以使用软件，如图2-8所示[2]。任务板上展现了当前Sprint的所有任务，每项任务用一张“即时贴”来代表，上面记录着任务的名称、优先级、接受任务的开发者姓名、预计的完成时间等信息。任务板上有3列：待处理的任务（To Do），即Sprint中要着手的待办事项或用户故事（user story）；进行中的任务（Doing），即团队成员已经认领的、正在处理的任务；已完成的任务（Done），即团队成员已经完成的、被关闭的任务。在Sprint过程中我们要不断地更新任务板。
图2-8 Scrum任务板示例
Scrum主管通过每日立会（standup meeting）来保证项目组成员了解其他所有人的工作进度。Scrum每日立会是每天早上进行的15min的会议，大家必须站立开会，例如站在任务板前。每个团队成员要回答以下三个问题：昨天你做了什么？今天打算做什么？有没有问题影响你达成目标？团队成员通常需要与Scrum主管沟通解决这些问题，这些沟通不是会议讨论内容，因此每日立会只是提出问题，会后再个别沟通具体问题的解决方案，以确保每日立会的时长控制在15min以内。
Scrum能快速适应需求变化，提高开发进度和质量，在工业界取得了很大成功。Standish Group的2018年chaos报告中的调查结果表明，Scrum的项目成功率达到58%，而传统的瀑布模型的项目成功率仅有18%。
2.3.3 Kanban
Kanban，又称为看板，源自精益制造，从丰田公司的实践中演化出来，其核心在于工作的全方位可视化以及基于工作的实时沟通。通过看板墙（Kanban board）中各工作项的直观展示，让团队成员清晰了解各项工作的状态及进展，并识别瓶颈。
看板墙和Scrum任务板很类似，可以是物理板或电子板。不同的是，在看板墙中，根据团队的规模、结构和目标的不同，团队可以设置自己个性化的工作流。图2-9是一个典型的看板墙，它的每个迭代由待办事项（Backlog）、选择（Selected）、开发/处理中（Develop/Ongoing）、开发/已完成（Develop/Done）、部署（Deploy）和发布（Live！）等步骤组成。我们也可以把开发进一步细分为设计、编码和测试。看板墙的作用是把整个开发流程可视化。团队在看板墙的各栏目中贴上卡片来代表开发过程中的各个工作项，让团队工作流可视化呈现。
图2-9 看板墙示例
看板墙上的每张卡片代表一个工作项，它记录了有关该工作项的相关信息，使整个团队能够全面了解负责该工作项的人员、正在完成的工作的简要描述、估计该工作需要多长时间等。电子板上的卡片通常还会包含功能截图和其他对经办人有价值的技术细节。看板卡片允许团队成员在任何时间点都能了解每个工作项的状态以及相关细节。
栏目顶部的数字代表该步骤的最大工作项容量。Kanban通过限制进行中的工作项的数量，防止过度生产，并动态地揭示开发过程中的瓶颈。进行中的工作项（work in progress, WIP）称为在制品。团队通过将在制品与团队能力的匹配来达到软件的“及时”（just in time, JIT）开发。
Kanban和Scrum都是基于快速迭代的敏捷过程，采用自组织团队。和Scrum不同的是，Kanban的最大特点是限制正在进行的工作项的数量，以及看板墙上可视化的工作流。此外，Kanban的迭代没有规定的固定时长，没有规定的角色。两个过程可以相互融合，例如微软提出的Scrum-ban。