下载掌阅APP，畅读海量书库
立即打开
目前非常流行的极限编程（eXtreme Programming）包含若干概念，比如迭代-递增模型的需求和分析工作流、成本-效益分析方法、测试驱动开发、结对编程、时光盒、站立会议等。而敏捷是一组软件开发思想的统称，以一组软件开发方法论为代表，具体体现为许多互相支援的概念、工具和实践经验。
根据软件开发技术的发展历程，有几个原因导致敏捷（Agile）开发方式在互联网时代的出现，具体分析和说明如下。
●20世纪六七十年代，最初的软件顾客是大型研究机构、军方、美国航空航天局、大型股票交易公司等，它们需要通过软件系统来开展科学计算、军方项目、登月项目、股票交易系统等超级复杂的项目。这些项目对功能的要求非常严格，对计算准确度的要求也相当高。
●20世纪八九十年代，软件进入桌面软件时代，开发周期明显缩短，各种新的软件开发方法开始进入实用阶段。但是，发布软件的媒介还是软盘、CD、DVD，做一个软件发布需要较大的经济投入，不能频繁更新版本。
●互联网时代，大部分服务是通过网络服务器端实现的，在客户端有各种方便的推送（Push）渠道，一般消费者成为主要用户。而且网络的传播速度和广度使知识的获取变得更加容易，这就使得很多软件服务可以由一些小团队来实现。同时，技术更新的速度也在加快，“一个大型团队用一种成熟技术开发2～3年再发布软件”的时代已经过去了，用户需求的变化也在加快，开发流程必须跟上这些快速变化的节奏。于是，敏捷开发方式应运而生。
从2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程，他们在过程要点、结果要点、合作性和计划性这些方面肯定了表2.2中现有做法的价值（第2列），但是强调敏捷做法（第3列）更能带来价值。
表2.2 现有做法与敏捷做法的比较
敏捷中的极限编程就是把各种好办法（best practice）发挥到极致（extreme）：如果满足顾客的需求很重要，那么就用顾客的语言和行为来指导功能的开发（Behavior Driven Development）；如果顾客表达能力不强，就请顾客代表和团队人员一起工作；如果测试/单元测试能帮助提高质量，就先写单元测试，从测试开始写程序（Test Driven Development）；如果代码复审可以找到错误，就从一开始就处于“复审”状态（即结对编程）；如果计划没有变化快，就别做详细的设计和文档，通过增量开发、重构和频繁发布来满足用户的需求；如果代码重构会提高质量，就持续不断地重构。
与计划驱动（plan-driven）和形式化开发方法（formal method）相比，在产品可靠性要求、需求变化、团队人员数量、人员经验、公司文化、实际例子、用错方式的后果等方面，敏捷也有自己的适用范围，具体比较情况如表2.3所示。其中，可靠性准则包括健壮性（系统承受用户无效输入的能力）、可靠性（指定操作与所观察行为之间的差别）、可用性（系统用于完成正常任务的时间）、容错性（在错误条件下系统的运行能力）、安全性（系统抵御恶意攻击的能力）、预防性（在出现错误和故障时，系统避免威胁人类生命的能力）等。
表2.3 敏捷的适用范围
Scrum方法是1995年由Ken Schwaber和Jeff Sutherland博士共同提出的敏捷开发框架，已被众多软件企业广泛使用，如Yahoo、Microsoft、Google、Motorola、SAP、IBM等。Scrum原意是指橄榄球运动时的积极进取、你争我夺。
Scrum框架示意图如图2.4所示，整个开发过程由若干个迭代周期构成，每个迭代周期称为一个Sprint。Scrum通过以下过程实现产品的迭代开发：首先，产品经理根据用户需求和市场需要，提出一个按照商业价值进行排序的客户需求列表；在每个迭代的开始，开发团队要召开迭代计划会议，从这个列表中挑选出一些优先级最高的条目，形成迭代任务；在迭代开发过程中，要召开每日立会，检查每天的进展情况；在迭代结束的时候，会产生一个可运行的交付版本，由项目的相关人员参加产品的演示和评审会议，来决定该版本是否达到发布的要求。
图2.4 Scrum框架
一个Sprint通常是一个2～6周的迭代周期，很多团队采用2周作为一次迭代。互联网/移动互联网应用产品市场变化快、竞争激烈，有可能采用1周的迭代周期。Sprint的长度一旦确定，将保持不变。其产出是“完成”的、可用的、潜在可发布的产品增量。需求在一个Sprint内是不允许变化的。
Scrum框架主要由3部分构成：角色、制品、活动。其中角色主要分为产品负责人、Scrum主管和团队成员；制品有产品订单、迭代订单和燃尽图；活动包括迭代计划会议、每日立会、迭代评审会议和迭代回顾会议。
在Scrum团队角色中，产品负责人是灵魂人物，需要定义产品需求、确定产品发布计划、对产品收益负责、确定需求优先级、调整需求和优先级、验收迭代结果。Scrum主管直接管理项目，帮助团队制订冲刺计划，组织每日站立会议，引导团队正确应用敏捷实践，确保团队紧密协作，排除团队遇到的障碍，保护团队不受打扰；团队成员一般有5～9人，团队是跨职能的，成员都全职工作，通过自我组织和管理，合作完成冲刺开发工作，需要保证每一次冲刺的成功。
Scrum制品有产品订单、迭代订单和可工作软件等，其中产品订单是从客户价值角度理解的产品功能列表，功能、缺陷、增强等都可以是产品订单项，整体上根据客户价值进行优先级排序；迭代订单是从开发技术角度理解的迭代开发任务，在简单环境中，可直接把产品订单项分配到迭代中，而在复杂环境中，可把一个产品订单项再细分为Web/后台、软件/硬件、程序/美工等开发任务；可工作软件是可交付的软件产品，“可交付”应视不同情况提前设定和选定交付标准，正式产品可能包括使用文档，在新产品开发初期可能只需要交付勉强看到效果的产品。
在迭代计划时，产品负责人负责产品订单的内容、可用性和优先级，告诉开发团队需要完成产品订单中的哪些订单项，开发团队决定在下一次迭代中能够承诺完成多少订单项。在迭代过程中，不能变更迭代订单，即在一次迭代中，需求是被冻结的。
产品订单最初是基本的、明确的需求，至少要足够一个迭代周期的开发；随着开发团队对产品和用户的了解，产品订单不断演进、动态变化，以保证产品更合理、更有竞争性、更有用。产品订单条目按照优先级来排序，优先级主要由商业价值、风险、必要性来决定。
有些可视化管理的实践，比如任务白板，将团队的任务和进度可视化地展现出来。这最好是实物白板，因为电子白板可能会削减团队间的沟通，降低团队的透明度，违背敏捷重视人和团队的原则。另外，燃尽图以图形化方式展示了剩余工作量（ Y 轴）和时间（ X 轴）之间的关系。
Scrum规划有发布规划和迭代规划：发布规划定义用户故事并进行优先级划分，估算规模及评估团队开发速度，制订发布计划；迭代规划确定迭代目标并选择用户故事，将用户故事分解和细化到任务，并对故事和任务分布进行时间估算。
迭代计划会议在每次迭代（或冲刺）开始时召开，时间一般有2～4h，目的是选择和估算本次迭代的工作项，其中第一部分以需求分析为主，选择和排序本次迭代需实现的订单条目，第二部分以设计为主，确定系统的设计方案和工作内容。
每日站立会的目的是明确团队计划，协调成员间每日活动并报告和讨论遇到的障碍，通过任务板帮助团队聚焦于每日活动，根据需要更新任务板和燃尽图。每个团队成员需回答三个问题：上次例会后完成了什么工作？遇到了什么困难或障碍？下次例会前计划做什么？
迭代评审会议的目的是向最终用户展示迭代的工作成果，希望得到反馈，并以之创建或变更订单条目。基本要求是由团队展示有可能发布的产品增量，允许所有参与者尝试由团队展示的新功能，以及用户对团队演示的产品功能进行反馈。
每一次迭代完成后，都会举行一次迭代总结会，即迭代回顾会议。会上所有团队成员都要反思这个迭代。举行迭代总结会议是为了进行持续过程改进，时间限制在1h左右。迭代回顾会议的关键要点有：会议气氛宽松自由，团队全员参加，畅所欲言，发现问题和分析原因；关注重点，每次仅就1～3个关键问题做出可行的解决方案；跟踪闭环，可以放入下一次迭代订单中执行改进。
用户故事（User Story）是从用户角度对功能的简要描述，格式如下：作为一个＜角色＞，可以＜活动＞，以便于获得＜价值＞。其中，角色是指谁要使用这个功能，活动是指需要执行什么操作，价值是指完成操作后带来什么好处。
一个好的用户故事具有独立性、可协商、有价值、可估算、短小、可测试等特点。其中，独立性是需要尽可能避免故事之间存在依赖关系，否则会产生优先级和规划问题；可协商是指故事是可协商的，不是必须实现的书面合同或需求；要确保每个故事对客户或用户是有价值的，最好让用户来编写故事；可估算是指开发者应该能预测故事的规模以及编码实现所需要的时间；故事尽量短小，最好不要超过10个理想人天，至少在一个迭代中完成；所编写的故事必须是可测试的。
以下为用户故事举例。顾客可以使用信用卡购买购物车中的商品（接受VISA、Master和American Express信用卡），可以再细分为以下几种测试场景：通过VISA、Master和American Express信用卡测试；通过VISA借记卡测试；用其他卡测试失败；用正确的、错误的和空的卡号进行测试；用过期的卡测试；用不同限额的卡测试。原先的用户故事可能不合适，可以通过迭代进行调整。
用户故事中可以有多种用户类型，比如维基百科网站有三类用户：维基百科用户希望上传文件，以便进行分享；客服代表希望为客户的问题创建记录卡，以便记录和管理客户支持请求；网站管理人员想要统计每天有多少人访问了网站，以便赞助商了解网站会给他们带来多少收益。可见，用户身份不同，视角和立场也会有很大的不同。
另外，系统对浏览器的配置型号和版本也有一些要求，比如要求系统必须支持IE 8、IE 9、Safari 5、Firefox 7和Chrome 15浏览器；作为开发人员，如果想选择合适的过滤引擎，可以做两个参考原型，分别进行性能测试、规模测试和类型测试，通过比较确定最终的方案。
产品订单是一系列用户故事的列表。如图2.5所示，产品负责人首先确定产品订单，这是粗粒度功能，是按照优先级进行排序的；然后通过迭代计划会议得到细粒度的功能/任务，形成迭代后的订单；最后由开发团队加以实施，完成增量功能。
以下是一个电商网站用户故事的实例，按优先级进行排序。
1）用户浏览商品，作为一名想购买商品但不确定商品型号的顾客，希望能对浏览网站上的在售商品按照商品类型和价格范围进行过滤；
2）用户搜索商品，作为一名想查找某种商品的顾客，希望能进行不限格式的文本搜索，比如按照短语或关键字搜索；
3）注册账号，作为新顾客，希望注册并设置一个账号，包括用户名、密码、信用卡和送货信息等；
图2.5 产品订单的处理流程
4）维护购物车，作为一名顾客，希望能将指定商品放入购物车，查看购物车内的商品以及从购物车中移除不想要的商品；
5）结账，作为一名顾客，希望能完成购物车内所有商品的购买过程；
6）编辑商品规格，作为工作人员，希望能够添加和编辑在售商品的详细信息，包括介绍、规格说明、价格等；
7）查看订单，作为一名工作人员，希望能登录并查看一段时间内应该完成或已经完成的全部订单。
敏捷估算是指将所有订单条目需要的工作量估算值相加，形成估算值总和。估算总值除以平均速率等于迭代数量。
理想时间是一个绝对度量单位，是某件事在剔除所有外围活动以后所需的时间，一般为一天有效工作时间的60%～80%比较合理，不会是全部。理想时间的估算方法是：团队查看每个故事，针对复杂性要素讨论故事，然后估计要用多少理想时间可完成该故事。这种方法是人们平时习惯使用的，容易理解和使用；但带来的问题是很难达成共识，因为人天生不擅长做绝对估计，不同的人对理想时间的估算是不同的，因为每个人的能力和认识都不同；由于每个人的理想时间不一样，因此这种估算不能相加，否则产生的计划肯定是不准确的。
故事点是一个相对度量单位，使用时可以给每个故事分配一个点值。点值本身并不重要，重要的是点值的相对大小。故事点的基本做法是给一些简单的标准故事设定一个“标准点数”，形成比较基线；其他故事与标准故事进行比较，给出一个相对的比例，得到该故事的一个估计值。使用难点在于：故事点的项目或产品特征很明显，几乎无法进行跨团队比较；如果没有历史数据，很难设定标准故事。
对于2.4.3节介绍的电商网站用户故事，可以分配不同的故事点，比如按照优先级1～7，分别需要的故事点是2、5、1、3、8、3、2，这与项目实际开发中需要的时间是匹配的。
敏捷估算的原则是：开发团队一起估算，产品负责人和Scrum主管不参与实际估算，而是分别进行阐述澄清和指导引导。需要注意的是：估算应该准确但不必过分精确，过于精确的估算是浪费。实践中可以使用敏捷估算扑克来进行，估算扑克是一种基于共识的工作量估算技术，估算扑克牌的数值范围由团队决定，有些牌是自然数排列，有些是斐波那契数，有些则是不连续自然数，例如2的幂。