全球化团队的敏捷开发模式

唐 涌， 马振勇， 张道林

（1．东华理工大学软件工程学院，江西 南昌 330013;2．上海惠普有限公司，上海 201203）

计算机从诞生以来，技术的革命就从来没有停止过。软件开发也在进步着，人们提出许多改进软件开发过程的方法。每一种方法都被吹捧为“重大成果性突破”，每一种方法都声称“使过程可控”。虽然有很多改进的方法，但是管理混乱的软件开发过程仍然随处可见，投入越来越多的人力、财力，所有人都变得疲惫不堪，但是整个项目却在进度的泥淖中越陷越深。2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，业界一批专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，并把这些价值观和原则称为敏捷开发，他们称自己为敏捷联盟，随后创建了敏捷联盟宣言。自《敏捷宣言》发布以来，敏捷开发正在以前所未有的速度改变着整个开发流程。经过了十几年的尝试和完善之后，越来越受到大家的重视。越来越多的开发者开始学习敏捷开发，越来越多的团队开始尝试敏捷开发，越来越多的公司开始全面推行敏捷开发。这无不说明，敏捷开发确实能够帮助开发团队适应当前的开发环境，更快速有效的发布自己的产品。

1 敏捷开发理论

1．1 敏捷开发的定义

敏捷开发是软件项目的一个概念框架。敏捷即灵活性，快速响应。它是一种以人为核心，迭代、循序渐进的开发方法。在敏捷开发中，会把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。最大限度地降低短期固定时间的迭代式软件的开发风险。敏捷开发给企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3至10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到相应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。敏捷开发由几种轻量级的软件开发方法组成。它们包括:极限编程（XP）、Scrum、精益开发、动态系统开发方法、特征驱动开发、水晶开发等。

1．2 敏捷开发的现状

自《敏捷宣言》发布以来，这种倡导团队价值和沟通的开发方式迅速在业界扩散和传播，经过十余年的发展，敏捷开发已经从最初的概念走向实践，敏捷开发方法也经过不断的迭代在人们的实践中走向普及。敏捷开发在国外得到了很好地推广，大部分使用敏捷方法的公司都集中在外资跨国企业。如HP、IBM、SUN，以及一些软件外包公司。同时也有一些比较前沿的国内公司率先推广了敏捷开发。如华为、腾讯等。在中国只有很少的一些有关组织和公司在近几年开始使用敏捷方法。所以，中国的敏捷开发采用率仍然停留在技术采纳生命周期的初期试用阶段。不过中国的一些知名企业如腾讯、百度、华为、中兴等正在推广敏捷开发模式。根据Forrester/Dr．Dobb’s 2009年的调查，敏捷开发已经占到所有开发比例的35%，而且他们预言，在2013年将会超过80%［1］。具体数据如图1所示。

图 1 Forrester/Dr．Dobb’s Global Developer Technographics Survey，Q3 2009

1．3 敏捷开发与传统开发方法的区别

（1）敏捷开发注重个人的创造力和创新能力，团队相互沟通。设计无处不在，开发人员有更多的灵活性。

（2）敏捷开发能快速响应需求的变化。在敏捷开发中，尽量多的发布产品给客户进行试用，就会从客户那里得到更多的反馈来改进产品。因为产品发布频繁，每一个版本新增加的功能设计简单，没有复杂的架构，当客户有新的需求或对需求进行变动，也能很快适应。

（3）注重代码（产品）超过注重文档。传统软件开发方法往往先做需求分析，然后做概要设计，然后试图对一个软件开发项目在很长的时间跨度内作出详细的计划［2］，然后依照详细设计书进行开发。这类方法在计划制定完成后拒绝变化，而敏捷开发方法则拥抱变化，并能根据客户反馈随时对计划作出相应的调整来适应变化。

（4）传统项目管理

● 事先对整个项目进行估计、计划、分析。

● 反对变更;变更需要重新估计、重新规划。

● 严密的合同来减少风险，如果改变需求要走CR流程。

● 项目作为一个“黑盒子”，对客户与供应商的可视性差。

● 产品化和测试阶段是分离的。

● 文档和计划驱动的方法。

● 软件交付时间晚，意识到风险的时间晚。

（5）敏捷项目管理:

● 对整个项目做一个粗略的估计，每一次迭代都有详细的计划。

● 鼓励变化，客户价值驱动开发。

● 信任和赋予权力;合约使变更变得简单，增加价值。

● 客户和开发人员之间是紧密的连续的合作关系。

● 每次迭代都产生可交付的软件。

● 专注于交付软件。

● 第一次迭代就可交付能工作的版本，风险发现得早。

1．4 为什么需要敏捷开发

传统的软件开发，采用的是瀑布式的开发模式。在前面开发阶段，整个流程都是依据需求在进展，从最初的需求提出到需求分析，从概要设计到详细设计，从功能的设计到编码，最后到编码的测试、整合与部署，一环扣一环。所以说，只有你很小心，才能做得很好。而且做设计的时候，做开发的人要等待;做开发的时候，做测试的人要等待。所以，大家都在等待上一个环节做好才能做下一个环节。如果开发过程中发现设计有问题，则需要更改设计书。如果发现了需求有问题，那就要做详细的需求变更的评估了。然而，目前，我们的项目过程中，却经常返工，这其中一个很重要的原因就是——变化是永恒存在的，敏捷对于要求不停的在变化，我们一个迭代就会发布给客户一个版本，如果客户觉得好的话，我们会把它留下来。最后，我们会不断使我们的产品变成客户最想要的版本。采用敏捷方法得当的话，可以:

● 更加透明，随时跟踪项目的状态和进展情况，及早发现问题和风险。

● 快速交付，每次迭代都能交付可运行的软件。

● 最高风险和最高优先级的需求，最优先进行开发。

● 改善应对变更能力，减少大量的重计划。

● 改善项目沟通。

● 更好地客户参与，避免错误的假设。

2 Scrum开发方法

2．1 Scrum开发的定义

Scrum是一种常用的敏捷开发方法。Scrum是一个迭代性、增量性的流程，适用于几乎任何的产品开发以及工作管理。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标并有明确的推进。

Scrum开发方法是由 Ken Schwaber和 Jeff Sutherland提出，名称来自英式橄榄球，表示“并列争球”［3］，在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体的快速行为，奋力实现同一个目标——胜利。

2．2 Scrum 概述

Scrum是由一个开发过程、三种角色以及一套规范的实施方法组成。它可以被运用于软件开发、项目维护、软件测试，也可以被用来作为一种管理敏捷项目的框架。在Scrum中，产品需求被定义为产品需求清单。产品需求清单可以是用户案例，独立的功能描述，技术要求等。所有的产品需求清单都是从一个简单的想法开始，并逐步被细化，直到可以被开发的程度。

图2 橄榄球队在争球

Scrum将开发过程分为多个Sprint周期，每个Sprint有固定的时间长度，一般是2至4周的开发周期。首先，产品需求被分成很多的产品需求清单条目。然后，在Sprint计划会议上，会把最重要或者是最具价值的产品需求清单被优先安排到下一个Sprint周期中。同时，在Sprint计划会上，将会预先估计所有已经分配到Sprint周期中的产品需求清单的工作量，并对每个条目进行设计和任务分配。在Sprint开发过程中，开发团队每天都会进行一次简短的Scrum每日例会。Scrum每日例会上，每个团队成员需要向团队汇报各自的进展情况，同时提出目前遇到的各种障碍。每个Sprint周期结束后，都会有一个可以被使用的系统交付给客户，并进行Sprint评审会议。评审会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求清单的形式保留下来，并在随后的Sprint周期中得以实现。Sprint回顾会随后总结上次Sprint周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的Sprint计划会议。Scrum的整个流程如图3所示。

2．3 Scrum中三种主要角色

Scrum中有三种重要的角色，他们分别是产品负责人、Scrum教练和Scrum团队。

2．3．1 产品负责人

图3 Scrum framework

产品负责人主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，确保每个成员明晰需求列表内容、明确哪些条目具有最高优先级，同时产品负责人有权力接受或拒绝开发团队的工作成果。在我们看来，产品经理是最重要的一个角色，他负责最大化Scrum团队的工作价值。我们认为，很多产品没有真正得到用户的认可是因为没有像乔布斯一样的产品负责人［4］。产品负责人的职责主要归纳为以下几点:

● 定义产品特性。

● 决定发布日期和内容。

● 对产品收益负责（ROI）。

● 根据商业价值排定特性的优先级。

● 根据需要在每个迭代中调整产品特性和优先级。

● 接受或否决开发结果。

2．3．2 Scrum 教练

Scrum Master主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。他的重要之处在于，他能保证自己的团队不受外界干扰，能够更快更好地实现Scrum团队的工作价值。同时他负责确保成员都能理解并遵循过程，就像舵手，要迅速调整团队方向。Scrum Master的职责主要归纳为以下几点:

● 对项目组来说代表管理层。

● 负责制定Scrum价值观念和实践，确保每一个成员都认同Scrum价值观和遵守其游戏规则。

● 组织每天的Daily Scrum会议。

● 帮助Scrum Team规划Sprint计划。

● 清除障碍。

● 确保团队功能完备富有效率。

● 促进所有角色和职能的紧密协作。

● 替团队抵御外部干扰。

2．3．3 Scrum 团队

Scrum团队是Scrum的中心角色，产品交付要依靠团队。Scrum团队主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5至10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力，同时具有一定的表达能力;成员可以采用任何工作方式，只要能达到Sprint的目标。Scrum团队的职责主要归纳为以下几点:

● 跨部门:程序员，测试员，界面设计人员等等。

● 成员必须是全职投入:可以有例外 （例如数据库管理员等）。

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

● 一个sprint中保持成员稳定。

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

● 所有团队成员协调，合作完成Sprint中每一个规定的工作。

● 所有团队成员和Scrum Master负责每一个Sprint的成功。

2．4 Scrum中三种产出工件

Scrum中有三种产出工件，分别为产品需求清单、冲刺订单和燃尽图。

2．4．1 产品需求清单

产品需求清单是囊括了开发产品可能需要的所有事项的优先排列表。产品需求清单也可称为User Stories（用例），因为它们能够给产品的用户带来价值。产品负责人负责产品需求清单的内容、可用性和优先级。产品需求清单永远不会是全面的，最初的版本只列出最基本的和众所周知的需求。产品需求清单根据产品和开发环境的变化而演进。产品需求清单是动态的，它经常发生变化以确保产品更合理、更具竞争力和更有用。只要产品存在，产品需求清单就存在。基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括:

● 功能方面的需求，功能点。

● 非功能方面的需求，如性能改进。

● 要修改的Bug，上一版本的已知错误。

● 新技术，如支持新的操作系统或者平台。

● 不确定项，如新的功能。

● 产品需求清单是不断完善的。

Product Owner在项目进行过程中可以随时更新:增加、删除、修改功能，变更优先级等。下一次迭代中要包含较高优先级的需求。

2．4．2 冲刺订单

冲刺订单是由Scrum团队在Sprint计划会议中确认的待办任务列表。团队选择了Product Backlog中的一些项目，通常是用户故事的形式，并且明确每个用户故事需要完成的任务。大多数团队会估算每个任务需要多少时间去完成。

许多条目在Sprint计划会议中已经定义。这些就是团队确认的完成Sprint目标所必须做的工作。Sprint待办事项列表条目必须被分解。进行充分的分解，那么过程中发生的变化就可以在每日例会上得到理解。一天或一天之内的工作量对Sprint待办事项列表条目来说是比较适合的。

团队在整个Sprint内都会修改Sprint待办事项列表，同时在Sprint内合并Sprint待办事项列表。因为它是针对每个成员的任务，所以可能有时任务会偏多或偏少，亦或某项任务耗费的时间超出或提前于预期。当出现新工作时，团队需要将其追加到Sprint待办事项列表中去。随着任务进行或者被完成，需要更新每项任务的估算剩余工作量。如果某项任务失去开发的意义，就可以将其除去。在Sprint内只有团队可以对Sprint待办事项列表进行修改，也只有团队可以对列表的内容或估算进行修改。Sprint待办事项列表是高可见度的，是对团队计划在当前Sprint内完成工作的实时反映，并且，该列表只属于团队。

2．4．3 燃尽图

Sprint待办事项列表燃尽图展现的是当前Sprint内剩余的Sprint待办事项列表工作数量。创建该图需要通过累计Sprint中每日待办事项列表估算来确定剩余工作量。Sprint内的剩余工作量就是所有Sprint待办事项列表的剩余工作总量。每天对这些数据进行跟踪，并绘制燃尽图，时刻显示剩余工作量。用线将图上的点依次连接起来，团队就可以控制完成Sprint工作的进程。所耗时长并不属于Scrum的关注范围，剩余工作量和完成日期才是利益相关因素。

2．5 Scrum中五种仪式

Scrum中有五种重要的仪式，他们分别是Sprint、Sprint计划、Spring 评审、Sprint回顾、Scrum每日例会。

2．5．1 Sprint

Sprint的本意是指冲刺，在 Scrum中，一个Sprint就是一个迭代，Scrum项目通过一系列的Sprints来推进，Sprint长度通常2－4周，它是一个时间箱，在项目进行过程中不允许延长或缩短Sprint长度。

2．5．2 Sprint计划

Sprint计划会议制定迭代计划。对于一个月为周期的Sprint，计划会议的时间盒限定为8小时。对于较短的Sprint，根据Sprint的长度，按比例缩小会议的时间。Sprint计划会议的内容包括以下两个部分:在第一部分中决定Sprint需要做什么。第二部分（4小时的时间盒对应一个月的Sprint），团队研究在Sprint内如何将功能构建成产品增量。

2．5．3 Spring 评审

Sprint末尾时要举行Sprint评审会议，一个月的Sprint通常对应4小时时间盒的评审会议。对于时间少于一个月的Sprint来说，根据Sprint的长度，按比例缩小会议的时间。在Sprint评审会议中，Scrum团队和利益相关人沟通Sprint中完成了哪些工作。然后，根据完成情况和Sprint期间产品待办事项列表的变化，他们确定接下来的工作。这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作

2．5．4 Sprint回顾

在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint，这是一个3小时时间盒的会议（根据Sprint的长度，按比例缩小会议的时间）。在这个会议上，Scrum Master鼓励团队在Scrum过程框架和时间的范围内，对自己的开发过程进行改进，使下一个Sprint的效率更高、更易工作。许多书籍都介绍了召开回顾会议的技巧。

2．5．5 Scrum 每日例会

团队每天进行15分钟的检验和适应的会议就称为Scrum每日例会。每日例会在各个Sprint都是在同一时间、同一地点进行。会议上，每个团队成员需要汇报以下三个问题:

1．从上次会议到现在都完成了哪些工作;

2．下次每日例会之前准备完成什么;

3．工作中遇到了哪些障碍。

每日例会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。

3 全球化团队的敏捷开发模式

3．1 HP的全球化开发团队和敏捷开发模式

HP是一个全球化的公司，拥有着数量庞大的全球化开发团队。我们开发的一些大型应用一般会有十几个甚至几十个子应用程序，它们之间的依赖关系有的时候非常复杂，如图4所示。这样就需要不同应用程序开发团队之间的相互协作，沟通很重要。比如，我们总共有600个人在开发一个大型应用，我们可以分为20个开发团队，每个团队大概30人。

图4 多个子应用程序以及关联关系

这还不够，一般每一个应用程序开发团队都是一个全球化的团队。所以，30个人可能包含一个美国团队、一个欧洲团队、一个中国团队、一个印度团队，每个团队7－8人。全球化的团队就需要我们更多的团队合作了。如图5所示。

图5 多个子应用程序的全球化开发团队

这么复杂的应用程序，这么复杂的人员编排，如果没有很好的管理方式，根本无从下手。Scrum似乎很好地解决了这个问题，把团队拆分成一个个的小团队，每个小团队都在执行Scrum，一个迭代一个迭代地往前推进。如图6所示。

图6 多个子应用程序的全球化Scrum开发团队

3．2 Scrum of Scrum

正因为有如此庞大的全球化Scrum团队，需要Scrum of Scrum来管理好Scrum团队。其实Scrum of Scrum就是Scrum的项目管理，用Scrum的方式来管理 Scrum团队。在 HP，每周会有 Scrum of Scrum，每个Scrum团队的Scrum Master一般都会参加。Scrum of Scrum不只是有一层，项目大的情况下，会有Scrum（of scrums（of scrums…）。如图7所示。

图7 Scrum of Scrum

3．3 风险控制和成本控制

风险控制和成本控制是项目管理中非常重要的两个部分。“风险发现得越早，消除风险的成本就越低”［5］。在Scrum中，把项目分成一个个的迭代，即使一个迭代出现了问题，在回顾会议的时候发现问题，及时改正，这样损失的只是一个迭代。而且还会通过持续集成、自动测试、频繁交付、客户参与等方法极大程度地降低传统意义上的开发风险。

3．4 持续集成

传统的瀑布式开发，测试和集成一直延迟到项目结束时才执行，问题往往发现得太晚，如果要解决问题，则有可能导致错过最后期限。所以，持续集成对敏捷开发非常重要。持续集成是一种软件开发实践，要求团队成员经常集成他们的工作。每个人至少每天集成一次，这导致每天有多个集成。在HP，很多的应用程序要频繁做集成，这些集成是通过自动化的构建进行验证的，这些构建运行回归测试，以尽快检测集成错误。我们发现，这种方法会导致集成问题大幅减少，更快地实现有凝聚力的软件开发。

4 结束语

敏捷开发，不代表没有设计，没有文档。敏捷开发带来的更多的是一种思想，它要求团队能够充分合作，有激情，有热情，循序渐进地朝着正确的方向前进，并且能够快速地发现问题，快速地纠正错误。Scrum则是敏捷开发的一个典型，只有把目标拆分，一个冲刺一个冲刺地去实现，才能更好地把握项目的进度和风险。HP等很多国外公司已经全面开始推行敏捷开发，相信未来更多的国内公司能够认识敏开发，并从敏捷开发中受益。

［1］任思迷．论敏捷开发中的团队建设［J］．计算机光盘软件与应用，2013，29（2）:114-118．

［2］程志梅，陆钢，刘光萍．基于B/S模式的网络教学系统的设计与实现［J］．东华理工大学学报:社会科学版，2009，28（2）:185-187．

［3］王哲．Android敏捷开发指南［J］．程序员，2012，21（9）:53-56．

［4］许惠清．基于网络环境下教学模式的研究［J］．东华理工大学学报:社会科学版，2008，27（3）:276-278．

［5］胡文生，赵明，杨剑峰，等．敏捷开发过程中的迭代策略分析［J］．微电子学与计算机，2012，27（5）:276-278．