异地协作敏捷开发团队转型实践

余迪谦



异地协作敏捷开发团队转型实践

余迪谦

（武汉众邦银行股份有限公司，湖北 武汉 430000）

越来越的科技公司开启了跨地域建设研发中心的步伐，随之而来的研发管理面临者诸多的异地挑战。尤其是以高效沟通、快速迭代、持续改进为特征的敏捷开发模式，在许多公司研发中心的异地布局中表现出了极大的不适应。通过研究多家跨国公司敏捷实践的案例，能够提炼出在敏捷的需求理解、迭代计划、每日站会、迭代验收、回顾会议等环节中的若干重要掌控要点。对于这些要点的掌控程度，直接影响着敏捷团队异地协作的效果，关系着项目整体的成败。

敏捷；软件工程；异地协作

0 引言

近年来我国软件企业越来越成熟，规模越来越大，不少企业在全国各地成立了区域研发中心。也有不少的企业走出国门，在海外成立软件研发中心。这种多点布局，会给企业带来诸多好处，比如各地的人才各有优势，各地政府的政策倾斜各有所长，中西部的运营成本明显低于东部发达地区。而研发成本，往往是软件企业最主要的成本构成，通过分布式研发中心的部署，可以充分的利用到各地的优势，从而使得企业研发体系达到降低成本，同时又能招揽高级人才的目的。

不过，这种分布的是研发布局，也会给企业的研发体系，带来不小的挑战。根据国外研究，异地协同的研发会不同程度的影响到项目的工期与效率，其主要的影响因素来自于7个方面[1]：距离沟通，实际距离，站点间相互依存关系，文化的适应性，体系结构的适应性，项目的创新性和项目周转。针对这些影响因素，国内也有一些定量也就的方法和成就[2]，但对于具体实践中的问题讨论较少。软件工程专业的学校教育，在这方面也是鲜有涉及，或者正在摸索阶段[3]。

本文，基于敏捷软件模式，着重讨论和分析了在具体环节中的应对实践。

1 分布式研发团队面临的典型问题

IBM，诺基亚，微软等老牌跨国公司进入中国设立研发中心时间早，结合本人经历以及走访北上广等大城市中在这些软件研发中心中工作的项目经理、架构师等员工，我们大致可以看出这种多地分布式研发中心可能存在这样一些共性的典型问题：

1.1 异地建立的研发团队很难融入原有的研发体系

这个问题基本上是所有公司的新建异地研发中心都遇到过的。原有研发总部的人员已经习惯了相互看着屏幕，坐在一起用投影开会，或者喊一嗓子就能有回音的交流方式。而对于异地研发中心的同事们的概念是模糊的，大多只停留在名字，或者公司的email符号上面。进而，原有研发总部的人员大多不太愿意同异地的同事协同，特别是性格大都不那么外向的研发人员。

1.2 异地建立的研发团队自身发展的局限性

除开异地团队独立负责一款产品研发外，大多数的异地团队需要从研发总部接受一部分项目来进行研发。通常有一个知识转移的过程，这一过程要求异地团队能够有一批经验丰富的高级技术人员。往往这类高级人才的稀缺，会制约知识转移的速度和质量的提高。

同时，由于项目的需求侧，如市场部门，产品经理等等人员大多和研发总部在一块。异地研发团队缺少和这些人员的日常交流，和需求团队的距离，通常也削弱了他们对项目需求的理解效果。

1.3 研发总部很难了解异地研发中心的研发状况

研发总部通常很难了解到异地团队的开发细节和项目进展。从而加深总部团队对异地团队的项目进展和项目能力的担忧。

2 敏捷实践中关键环节的掌控

软件开发的敏捷模式，由于他的诸多优点。研究数据表明，采用敏捷开发的模式，能够显著的提升软件团队的竞争力，能够收到明显的效果[4]，现在已经慢慢被各个软件厂商所接受，并努力的将自己的传统软件研发团队转型为敏捷的模式[5]。敏捷开发有多种实现方法[6]，其主要过程归纳提炼一下，大致有这么几个环节，如下图所示：

图1 敏捷开发的主要环节

大家普遍认为，敏捷在本地小团队，尤其是互联网的小项目中[7]，能够出色的达成软件开发的各项目的。而对于一些大项目，特别是对于需要多个团队协同开发的项目，敏捷模式会显得不那么合适。

同时，大家也都承认，在小项目本地小团队中，对于敏捷模式各个环节的掌控力度，通常要比异地团队的情况要有力的多。根据本人多年从事scrum master和架构师工作经历，以及同行交流调研的情况来看，在异地团队协同中成功的项目案例也是有很多的。通过对这些成功案例的分析，可以发现在敏捷模式的各个环节中，有如下关键的几点需要针对异地分布式团队重点把握：

2.1 需求理解环节

需求理解是软件工程中最为重要的一步，他决定者软件开发是否能达到预期目的。开发过程中的好多难点，人员的加班，很多都与需求理解的不到位有关系。在异地团队协作开发的模式中，需求理解环节的掌控尤为重要。

在敏捷模型中，团队需求的管理者应当是PO(product owner)。PO需要向团队解释产品需求，以及和团队一道对需求进行拆分和排序。PO是敏捷backlog(项目需求池)的第一责任人，同时也是迭代验收环节中的关键验收人。在实际项目中，PO代表研发团队，向产品经理，或者市场需求部门负责。

那么在异地团队的模式下，PO的对需求的掌控应当注意哪几个方面的内容呢？

首先，在初次需求阐述的时候，尽量做到多团队同时讲解。充分利用电话会议，远程视频等工具，保证各地团队都能够清晰的接受PO的讲述，并能够参与提问与互动。异地团队之间，也能够相互听到或看到对方和PO的互动，第一时间将PO的第一手阐述同步到各地。这个第一手信息的同步非常重要，因为通常80%以上的需求会在第一次会议中充分沟通到位。使用各种方式保障这一会议的有效性，和各方理解的一致性是非常有必要和划算的，这能够有效避免后续很多重要问题的理解分歧。

其次，各地团队回下分头进行本地讨论。这一过程，PO可以参与，但主要是聆听，不必过早的基于解答团队的疑问。这样，既让团队能够集体的去理解需求同步各个内部成员的理解，又能够帮助PO梳理产品需求之中的不明确的点，特别是从开发角度来看，那些问题不清晰，和需要进一步定义明确。这本身也是产品需求不断完善的一个过程。

在这一过程中，PO的沉默是非常有必要的。如果，PO急于给团队解答，非常容易带来一系列不良的影响：其一，对本地团队问题的解答，未必能准确的同步到异地团队中去，容易引入双方理解不一致的隐患；其二，从问题的本身来说，PO未必能够在短时间内有明确而合适的回答，日后经过需求侧论证或者调研，很有可能推翻PO此时的回复；其三，PO此时的回复，容易打断开发团队对于需求理解的思考过程，很可能后续的理解会受PO此时的解释而左右，使得团队失去了独立思考的机会。

最后，PO对需求疑问的反馈主要是通过两种形式来完成：1.针对大面积的需求，特别是初次讨论时的疑问，应当举行各团队的全体电话、视频会议，进行统一解释。2.对于之后零零散散的需求询问，PO也应该仔细解答，并且应用好诸如email备忘录，公共wiki等电子方式，将问答存档，并分享同步到各个敏捷团队。当然最好形成完备的需求文档，一般此文档是非正式，紧紧用于项目组和用户之间的沟通[7]。

总之，PO的需求环节是异地协同开发中最为重要的一环。此处要点若没掌控好，后续的研发就是失之毫厘谬以千里了。

2.2 计划会议环节

在向PO理解完需求，backlog已经建立以后。通常各个团队都会开始自己每个迭代的计划会议。在计划会议中，团队会更具自己的情况来对每个故事进行评分，按照每个迭代的容量大小来进行计划排期。

在这一环节中，增对异地协作的情况，scrum master只需要注意两点：

1）就是在进行故事依赖关系分析的时候，要充分挖掘出对异地团队工作的依赖。特别是要重视在关键路径上的依赖关系。通常这些关系表示为，系统之间的调用接口，模块的引用关系，或者数据输入的依赖。尽早的识别出这些依赖关系，有助于团队能够尽早的采取措施来规避他们带来的风险。比如，建立和异地团队的定期会议沟通机制，或者联调、代码共享的机制，等等。实践证明，只要团队能够在计划会议环节识别出异地依赖的风险，那么在后续的研发过程之中，他们通常都能够很好的采取相应措施，成功的缓释这些风险。

2）就是要在计划制定后，各团队，需要相互通报自己的检查点，或者联调时间点。由于在敏捷开发模式中，任务的完成是以PO的最后验收结果为依据的。PO往往只关心，最后产品整体展现出来的效果。所以，当研发团队都充分的理解这一模式以后，他们往往会自发的进行跨团队的协商，并留住联调的时间缓冲区。虽然主要是自发的，但这一过程中scrum master要扮演好协调者和提醒者的角色。特别是在各自的检查点、联调点临近的时刻，scrum master要主动的了解各地团队的完成情况，相互通报进展，尽早的识别出潜在的风险。

总之，在这一环节，scrum master应当尽量对风险因素敏感，早识别，早应对。

2.3 每日站会环节

在计划制定了以后，执行就是成败的主要因素了。每日敏捷团队会选择一个时间，站起来开一个简短的小会。通常在这个会议中，每个成员都是依次报告三个问题：昨天我做了什么？今天准备做什么？目前有没有什么阻碍住我的工作。

由于敏捷团队工作在相同或类似的软件开发环境和配置中[9]，有的公司可能会觉得尽可能多沟通，越多越好，从而选择将异地的团队合并起来，通过电话等形式，一起开站会。根据实践的效果来看，我并不提倡这种做法。

首先，站会的目的就是为了敏捷团队内部能够快速的交换信息，互通有无，进而互相帮助，最终目的是使得本轮迭代能够成功。然而，异地2个团队的迭代的目标往往是不同的。队员在工作中遇到的困难和阻碍，往往也是和本地的人员、实验环境直接相关的。异地的团队，其实一般不了解，也不太关心这些本地细节。

其次，站会的形式本身就要求迅速的完成。而异地团队合并进来举行，一来会是的参会的人数增加，时间拉长；二来，从沟通效率上来讲，远程毕竟没有面对面直接高效，这样也容易拉长会议时间。当站会的时间被拉长，那么它也就失去了站会本身“站”的意义了。

总之，站会应该尽量做成敏捷团地的本地时间。如果觉得某几天的工作实在是有必要将细节通报给异地团队，可以邀请一部分工程师过来旁听本地的站会，待站会结束后，再留下相关人员深入的进行专题讨论。

2.4 迭代验收环节

在本环节，主要活动是各个敏捷团队向PO展示本轮迭代的开发成果，并得到PO的改进意见反馈。针对异地敏捷团队的情况，根据经验，我们建议PO采取远程会议的形式，让各个小组轮流讲述自己迭代的成果，然后回答PO的提问。

这一环节的关键掌控者是PO。PO需要关注研发成果是否符合计划时的预期，同时要将改进意见明确的提出并同步到每个参与项目的敏捷团队知晓。当异地团队参与验收时，由于参与人数较多，往往容易陷入到团队之间的技术或者其他细节讨论之中。此时，PO应该要完全的掌控此验收会议的进程，让会议的焦点集中到是否满足需求，以及后续产品如何改进这一核心主题上来。过于发散的讨论，往往是这一环节失败的主要原因。由于涉及到需求的变化与改进，这一环节的失误或缺失，会直接影响到后续几个迭代的成败，应当引起PO和scrum master的高度重视。

在PO需求验收完成以后，我们强烈建议scrum master组织各个团队的高级工程师对本轮迭代的成果代码进行代码审查。其目的有三：其一，通过代码审查，查找出代码中的缺陷以及潜在的风险，从源头上提高代码质量；其二，通过交叉审查异地团队的代码，能够相互增进团队间的了解和缩短彼此的心里距离；其三，便是通过交叉审查，能够帮助团队中的初级工程师尽可能多的得到成长的支持。为团队的可持续性成长提供基础保障。对于代码审查的具体，很多文章都有论述，本文不在赘述。只是注意尽量把握由本地团队高级人员主审本地代码，异地团队的参与的原则，并留存好评审的详细记录。

总之，在对这一环节的掌控，PO需要紧紧锁住需求实现的评估与反馈[10]；scrum master需要尽可能多的做一些质量控制，异地交流和人才培养的工作。各地团队便能慢慢的深入了解对方，建立起互信。

2.5 回顾会议环节

本环节的主要活动通常在是敏捷团队内部进行，针对本轮迭代，大家反思3个问题：我们那些方面做的好？哪些方面做得不好？可以有怎样的行动来改进，让我们做得更好？这一环节是敏捷开发的精髓，是为什么敏捷能够持续不断的改进团队各项能力和效率的最直接原因。

经过不同方式的尝试，我们认为回顾会议环节，除了PO或者共同的领导以外，不必邀请异地团队成员来参加。利用这个封闭的时间，充分的进行本地敏捷团队的改进提高。Scrum master可以将大家提到的涉及到异地合作领域的内容讨论记录下来，然后在另找个时间，同异地的敏捷团队scrum master进行专场沟通，一同探讨远程协作的改进空间，并归纳出一些具体的措施。对于这些跨团队的措施，我们建议使用一个共享wiki来逐条管理，根据具体的落实情况更新wiki状态。异地团队之间，scrum master可以约定一个时间，来作为周期检查点，邀请每条措施的具体跟进人员一块，检查回顾这些措施的执行情况。待这一机制形成习惯，周期性的开了起来，各个异地团队直接的远程协作方式，变能得持续的改进。大家的相互之间的了解，也会进一步加深，合作越来越默契。

总之，在这一环境，scrum master需要分级掌控团队内部的改进措施，和团队之间的改进做措施，发挥出敏捷模式的精髓。

3 结论

本文根据各大公司在异地研发团队建设的实践经验，详细论述了敏捷软件开发模式下，异地团队协作相关的关键环节掌控点。希望对各单位的研发中心敏捷团队建设有所帮助。另外，本文没有讨论同一个敏捷团队的异地成员问题。因为从过去这么些年的经验看，这种敏捷团队的异地部署，都很难最后取得成功。不过，随着移动办公工具的丰富，与SOHO一族的队伍壮大，相信在不就得将来，这种部署模式成功的案例，也会越来越多。

[1] Carmel E. Global Software Teams: Collaborating Across Borders and Time Zones. Upper Saddle River: Prentice Hall PTR, 1999: 80-81.

[2] 殷茗, 成丽媛, 邓国林, 姜继娇. 异地分布式敏捷软件开发的时间成本估算研究. 计算机系统应用, 2018, 27(6): 189-194.

[3] 王芳, 邓一星, 秦映波. 敏捷软件项目管理课程教学方案研究与实践[J]. 软件, 2018, 39(4): 77-81.

[4] 严智浅析敏捷方法与开发实践[J]. 信息化研究, 2013, 39(2): 52-59.

[5] 王旭. 传统软件开发团队如何转型为敏捷开发团队[J]. 软件, 2014, 35(3): 203.

[6] Martina Ceschi, Alberto Sillitti, Glancarlo Succi Project Management in Plan-Based and Agile Companies. IEEE Software[C]. 2005.

[7] 刘蓉, 陈波. 基于微信公众平台的招生咨询智能聊天机器人[J]. 软件, 2018, 39(6): 49-57.

[8] 惠子青, 刘晓燕, 朱汇龙. 基于敏捷开发增量UML模型的研究[J]. 软件, 2018, 39(1): 142-146.

[9] 陈申平. 敏捷软件开发中的配置管理探讨[J]. 软件, 2018, 39(5): 134-138.

[10] 桑大勇, 王瑛, 吴丽华. 敏捷软件开发方法与实践[M]. 西安: 西安电子科技大学出版社, 2010: 145-149.

Practice of Agile Teams’ Collaboration in Different Region

YU Di-qian

(Wuhan Zhong-Bang Bank Ltd.430000, Wuhan, Hubei, China)

Along with more and more technology companies start setting up development center in different region, there are more and more challenges in its management. Specially Agile, whose characteristics are efficiant communication, quick iterations, and continuously integration, is not easily adapted in this transistion. Key control points are summarized in agile phases, such as Requirement understanding, Sprint Planning, Daily Stand-up, Demo meeting and retrospecitve meeting, by studying several multi-national company R&D centers. How they are masters, it impacts effect of agile teams collaboration as well as the success of project.

Agile; Software engineering; Collaboration

TP311.5

A

10.3969/j.issn.1003-6970.2018.10.046

余迪谦(1983-)，男，系统架构师，硕士，研究方向为软件工程、互联网。

余迪谦. 异地协作敏捷开发团队转型实践[J]. 软件，2018，39（10）：238-241