下载掌阅APP，畅读海量书库
立即打开
在20世纪90年代，一批轻量级软件开发方法在针对重量级软件开发方法（通常又统称为瀑布式开发）的批判中应运而生。与瀑布式开发的过度流程制约、过分强调计划和琐碎的管理不同，这些轻量级软件开发方法无疑更加灵活，减少了软件开发过程中的条条框框。这些开发方法包括1991年提出的快速应用开发、1994年提出的统一过程开发和动态系统开发、1995年提出的Scrum、1996年提出的透明水晶法和极限编程、1997年提出的功能特性驱动开发等。这些方法都在《敏捷软件开发宣言》（简称为《敏捷宣言》）之前提出，统称为敏捷软件开发方法。
2001年，17名软件开发者
在犹他州雪鸟度假村会面，讨论这些轻量级开发方法，并划时代地发表了《敏捷宣言》。《敏捷宣言》提倡：个体和交互胜于过程和工具，工作软件胜于全面的文档资料，客户合作胜于合同谈判，响应变化胜于遵循计划。
《敏捷宣言》的作者基于他们的软件开发经验和实践，进一步明确了敏捷软件开发价值观。之后，其中一些人成立了“敏捷联盟”，这是一个根据《敏捷宣言》的价值观和原则促进软件开发的非营利组织，持续促进敏捷开发的发展。
此外，可以追溯到的1957年的迭代和增量软件开发和20世纪70年代初的自适应软件开发则是敏捷开发的原型。
与传统的软件工程相比，敏捷开发主要针对快速变化、非确定性和非线性软件产品需求的开发。准确的评估、稳定的计划和预测在敏捷开发的早期阶段一般是无法有效获得的，即便强行为之，结果也无多大意义。
敏捷开发需要开发者具有灵活的思维方式，能够跳脱传统瀑布式开发线性执行的框架，实现思维的跳跃。在敏捷开发过程中，需求和设计不免是紧急的，但是大规模、盲目的前期投入将造成浪费。因此，结合敏捷开发和相关行业经验，自适应性、迭代和进化是敏捷开发的关键。
敏捷开发的本质是适应性软件开发。适应性方法的基本要义就在于快速适应不断变化的现实需求。敏捷开发依赖一支自组织、自适应的跨部门开发团队，当外部需求发生变化时，自适应的团队也应该跟着变化。自适应的团队很难预知未来会发生什么，且距离项目目标日期越远，相关情况越不可预测。
敏捷开发的基本原则是做好产品的原型设计，避免对软件系统进行过分的建模，针对当前需求建模，保持模型简单，时刻做好拥抱变化的准备。以下是《敏捷宣言》所遵循的12条原则。
1）倡导尽早交付且可持续交付满足用户需求的软件产品；
2）积极应对需求变化；
3）保持短期且敏捷的发版节奏；
4）保持研发团队与业务团队的高频协作和沟通；
5）选择充分信任与支持项目的人员，且核心人员应具有进取心；
6）保持面对面沟通；
7）软件的可用性是整个项目的主要度量标准；
8）敏捷开发过程需保持快速且可持续发展；
9）保持对卓越的技术与设计的持续关注与改进；
10）精益生产，简洁为本；
11）团队的自我管理；
12）时时总结。
以上12条敏捷开发原则是对敏捷开发价值的阐释。将敏捷开发价值落实到具体可操作的行为上，是敏捷软件开发项目得到客户认可的必经之路。
敏捷开发的需求文档应当从用户角度出发，以用户故事的方式表达用户需求，避免开发人员和测试人员先入为主地将重点放在技术和实施上，而应将重点放在需求上。以用户故事方式编写的需求通常是可测试的。
在敏捷开发过程中，有效沟通是非常必要的。开发人员和测试人员及时有效的沟通，有利于项目的顺利进行。项目团队以及团队下承担子项目的小组也应保持定期交流，通过各种方式进行头脑风暴，及时解决问题，避免问题积累。
为了提高测试效果以及测试效率，开发人员和测试人员可以在需求分析阶段一起参与需求讨论，在需求分析、评审的同时，进一步定义要测试的需求项，并确定需求的分类和优先级。如此，开发人员和测试人员通过相互沟通，充分发挥各自角色优势，形成互补，弥补传统需求分析的不足。而且在需求分析阶段，开发人员和测试人员及时沟通有利于测试用例的编写和测试的实施；将测试结果充分、翔实、准确地反馈给开发人员，有利于产品的后续改进。
在需求设计过程中，测试用例编写也是非常重要的。最好的情况是，在需求设计完成的同时测试用例编写也完成，并且及时完成测试，及时发现针对当前需求存在的问题，避免问题的累积，进而大大降低改进成本。
对比传统瀑布式开发周期，敏捷开发要求以小版本形式的快速迭代，最小化软件开发背离市场需求过久、过远的风险，确保软件产品和服务始终满足市场主流需求。
本节以Scrum为例，为大家展开介绍敏捷开发。
1995年10月16日在美国得克萨斯州奥斯汀举办的面向对象技术的高峰会议（OOPSLA）上，Ken Schwaber与Jeff Sutherland首次提出了Scrum敏捷开发模型。Scrum敏捷开发模型（见图3-4）是一种快速迭代和增量敏捷开发方法。Scrum的基本思想是，问题不会一次性地被完全理解、定义，应专注于提升和最大化团队的快速交付和响应需求变化的能力。与传统瀑布式开发模型相比，这种模型有助于减少在项目开发期间用户需求改变所造成的成本损失。Scrum敏捷开发模型以“用户故事”的方式将工作划分为功能增量，让功能增量对产品的整体价值产生贡献。
图3-4 Scrum敏捷开发模型
在Scrum敏捷开发模型中没有标准的开发规则，开发人员需根据项目团队的规模、组织架构、功能目标等，制定灵活可变的方式。以下几个原则是相对通用的。
1）Scrum敏捷开发的核心价值是快速、持续地向用户交付有价值的软件产品；
2）拥抱用户需求变化，通过快速迭代、频繁交付以及把控产品质量来提高产品优势；
3）减少文档数量，实现全局规划的可视化视图；
4）提高开发团队和业务团队人员的协同性，及时沟通、面对面交流，加强团队之间的信任；
5）简单化，定期总结、调整和校正。
和传统瀑布式开发模型及其他迭代的开发模型相比，Scrum敏捷开发模型主要有以下几个特点。
1）团队氛围好：Scrum敏捷开发模型可以赋予团队更大的权利，通过业务团队与开发团队的有效融合，大大提高了团队能动性，降低了团队沟通成本。
2）灵活性强：实践灵活性极高，由市场需求驱动技术开发，以便快速响应、迅速反馈用户需求。
3）开发成本低：实时沟通交流有效降低了文档维护成本，快速交付降低了时间成本。
4）最大化生产效率：让产品以最快的速度交付给用户，以最快的速度响应市场变化，这样做的效果就是生产效率显著提高。
5）项目风险低：交付时间短、迭代速度快、有效应对市场需求变化并及时调整布局，有效降低了不确定因素带来的风险。
在Scrum敏捷开发过程中，根据软件项目的需求清单一般制定2～4周为一个开发周期，每个周期定义为一个冲刺（Sprint）。冲刺是Scrum敏捷开发管理中一个惯常的、重复的短工作周期。团队在每一个冲刺中的计划任务，即冲刺清单，应当包括任务清单、相关负责人，以及每天未完成的工作量。
敏捷开发团队所有成员将冲刺清单拆分成一个能8小时完成的任务列表清单，通过面对面沟通形式对每位成员目前工作量进行分析评估，根据客户的需求变化以及市场的响应进行迭代更新。每一个冲刺完成后，对整体的项目而言就相当于完成了一个大版本的迭代，并把此版本快速交付给用户。这个过程不断重复，直至项目交付完成。
Scrum敏捷开发流程如图3-5所示。
图3-5 Scrum敏捷开发流程
Scrum敏捷开发周期如图3-6所示。
图3-6 Scrum敏捷开发周期
Scrum敏捷开发具体实现如下。
（1）两个工具
白板和即时贴是敏捷开发管理中必不可少的两个辅助工具，也是Scrum敏捷开发最直观的管理工具。当团队都在同一个办公区域时，可将需求清单和燃尽图通过白板和即时贴以任务看板的形式展现，直观、方便、简洁，如图3-7所示。
（2）3个角色
以人为本是Scrum敏捷开发的核心理念。Scrum团队的管理原则是以软件开发为中心，为团队提供良好的开发环境。面对开发中的困难，开发团队齐心协力、共克难关，同时还要确保与客户商业目标高度一致。
Scrum敏捷开发团队中一般包含3个角色：产品经理、项目经理和团队成员。
·产品经理，顾名思义就是软件产品的主要责任人，负责确定产品的功能，决策产品发布的时间以及发布的内容。产品经理还能根据市场变化来确定功能开发的优先级，在项目开发过程的每个冲刺内调整功能开发优先级。在一个冲刺结束后，产品经理组织团队人员评审此阶段的成果。
·项目经理的职责是监督开发进度，保证开发团队资源的利用率和团队良好协作。项目经理需要协调并解决团队开发中的困难，有效屏蔽与项目无关的因素，保证开发过程按既定计划有序进行，并对项目开发进度进行把控。
·团队成员，就是敏捷开发团队中的每一个成员。敏捷开发强调团队成员的主观能动性，所以团队成员要有高度的自我管理能力。团队成员需充分理解产品的愿景、功能的设计逻辑，确定每次冲刺的目标和工作成果，并能够向产品经理进行产品演示。在规则范围内，团队成员有权做任何事情以确保目标达成。
（3）3个物件
Scrum敏捷开发要求项目的需求管理面向市场，将项目目标向商业目标看齐。需求的优先级规划和满足情况在Scrum敏捷开发中尤其重要。一般Scrum敏捷项目团队有3个必不可少的物件。
·需求清单：良好的需求管理是项目成功的第一步。在理想情况下，每个需求项都要对客户产生价值。一般使用“用户故事”的方法展现需求，从客户角度直观表达功能需求，这样有助于开发团队深入理解需求的核心目的，节省交流时间，提高开发效率。需求清单的优先级由产品经理来确定，并且在每个冲刺结束之后更新需求清单的优先级。
·冲刺清单：就是在每一个冲刺中明确必须完成的工作。制定冲刺清单的关键因素在于团队成员选择适合自己的任务，而不是由产品经理或者项目经理去分配，这样做的好处就是能够充分调动开发团队中每一个成员的积极性，发挥团队成员自身的优势，最大限度让团队成员发挥价值，有效提高开发效率。在项目开发过程中，随着需求的变化，允许每个团队成员调整冲刺清单，增加、删除、修改任务清单；同时在每天工作结束时更新每个任务剩余的工作量。
·燃尽图：可以直观地反映一个冲刺中的剩余工作量情况。如图3-7所示，Y轴表示剩余工作，X轴表示时间周期，随着时间的消耗，工作量逐渐减少，这个过程就好比蜡烛燃烧殆尽一样。燃尽图还可以直观展示团队预估的时间进度与实际开发进度之间的差异，帮助开发团队在下一个冲刺中优化项目周期。在一个冲刺开始阶段，错误的估算或遗漏会导致工作量在燃尽图上呈上升态势。
图3-7 看板&燃尽图
（4）4个会议
快速迭代和当面沟通是Scrum敏捷开发提高开发效率的两个重要手段。快速有效的会议是Scrum敏捷开发模型的精髓。Scrum敏捷开发过程中要包含以下4个会议。
1）工作周期计划会：冲刺计划会是确定一个冲刺的原则性会议。会议时间一般会比较长，分为上下两场：上半场确定产品需求清单；下半场准备冲刺清单。要求产品经理在会议前准备好产品需求清单，制定冲刺周期内的需求清单。在产品需求确认会议上，团队从产品需求清单中挑选出自己愿意承担的并且优先级较高的开发工作，如果有遗漏，可以由项目经理统筹分配。到产品冲刺清单确认会议，团队成员将选定的产品需求清单转化为可交付的产品功能清单，制定出冲刺清单，其中包含功能任务预估、开发功能分配清单。工作周期计划会要确定项目日程、工作安排和完成标准。
2）每日交流会：每日交流会是敏捷开发的重中之重。不论团队人数多少，例会可以限时15分钟。每日交流会由项目经理主持。如果团队中某个成员因故无法出席，可以请其他成员会后转达会议内容。在会议上，每位团队成员自我思考3个可以促进工作完成的问题：在昨天的工作时间中做了哪些工作？在完成功能开发的时候遇到了哪些阻力？面对遇到的难题该如何面对和如何解决？从中能学习或吸取到哪些经验？会议围绕这三个问题开展，但不解决具体问题，问题放在会后由相关人员自行解决。每日交流会的结果就是发现并确定最新的开发障碍清单、更新冲刺清单、更新工作进度。每日交流会是Scrum敏捷开发的核心与灵魂，也是一个敏捷开发项目成败的关键所在。为了保证交流会的有效性和趣味性，可增加一些惩罚措施如做俯卧撑、下蹲起立等。
3）冲刺评审会：冲刺评审会的目的是让开发团队向产品经理和客户需求方展示已完成的功能，获得客户的反馈，对产品需求清单进行调整。会议一般有如下流程。
①团队成员确定自己的冲刺目标，一起复盘冲刺中出现的问题以及可以发扬的点；
②团队成员通过一个冲刺周期的功能开发，对自己所做工作进行总结、汇报，提出改进的地方，倾听其他成员优秀的解决方案；
③客户需求方指出未交付或未达到期望的功能，或者增加新的功能需求，并将其加入产品需求清单和划分优先级。
冲刺评审会议结束时，项目经理与产品经理共同讨论并宣布下一次冲刺评审会的时间节点。
4）冲刺回顾会：冲刺回顾会是项目内部会议，在每个冲刺结束时展开，目的是交流、总结和展望。会议气氛相对轻松，甚至可选在室外开展。会议开始后，团队全体人员需要回答3个问题：上一个冲刺阶段在哪些方面做得比较好；在上一个冲刺阶段哪些方面没有达到自己的要求，如何改进；在下一个冲刺阶段如何把优势发挥到极致，并克服掉缺点。
冲刺回顾会是一个交流型会议。项目经理出席会议不是给团队成员提供解决问题的答案，而是促使团队成员发掘Scrum敏捷开发过程中更优的解决方案，记录并总结团队成员的问题以及在冲刺阶段中值得表扬、需要改进的地方，最后明确改进之处及责任人，更新团队的冲刺数据。如果冲刺回顾会不能有效地促进团队进步，此次会议的意义就微乎其微。
Scrum敏捷开发可以适应不同规模的开发项目，以简单的系统应对复杂的变化。Scrum敏捷开发的最大优势是灵活的需求管理，能够快速应对市场需求变化，与追求快速、极简的互联网发展贴合度高。
Scrum敏捷开发是一种高效、灵敏的软件项目管理方式，可以精准地面向市场定位，让每一位团队成员的优势充分发挥出来，从而打造出一支可以快速交付有价值产品的团队。