余迪謙

?

異地協(xié)作敏捷開發(fā)團隊轉(zhuǎn)型實踐

余迪謙

（武漢眾邦銀行股份有限公司，湖北 武漢 430000）

越來越的科技公司開啟了跨地域建設(shè)研發(fā)中心的步伐，隨之而來的研發(fā)管理面臨者諸多的異地挑戰(zhàn)。尤其是以高效溝通、快速迭代、持續(xù)改進為特征的敏捷開發(fā)模式，在許多公司研發(fā)中心的異地布局中表現(xiàn)出了極大的不適應(yīng)。通過研究多家跨國公司敏捷實踐的案例，能夠提煉出在敏捷的需求理解、迭代計劃、每日站會、迭代驗收、回顧會議等環(huán)節(jié)中的若干重要掌控要點。對于這些要點的掌控程度，直接影響著敏捷團隊異地協(xié)作的效果，關(guān)系著項目整體的成敗。

敏捷；軟件工程；異地協(xié)作

0 引言

近年來我國軟件企業(yè)越來越成熟，規(guī)模越來越大，不少企業(yè)在全國各地成立了區(qū)域研發(fā)中心。也有不少的企業(yè)走出國門，在海外成立軟件研發(fā)中心。這種多點布局，會給企業(yè)帶來諸多好處，比如各地的人才各有優(yōu)勢，各地政府的政策傾斜各有所長，中西部的運營成本明顯低于東部發(fā)達地區(qū)。而研發(fā)成本，往往是軟件企業(yè)最主要的成本構(gòu)成，通過分布式研發(fā)中心的部署，可以充分的利用到各地的優(yōu)勢，從而使得企業(yè)研發(fā)體系達到降低成本，同時又能招攬高級人才的目的。

不過，這種分布的是研發(fā)布局，也會給企業(yè)的研發(fā)體系，帶來不小的挑戰(zhàn)。根據(jù)國外研究，異地協(xié)同的研發(fā)會不同程度的影響到項目的工期與效率，其主要的影響因素來自于7個方面[1]：距離溝通，實際距離，站點間相互依存關(guān)系，文化的適應(yīng)性，體系結(jié)構(gòu)的適應(yīng)性，項目的創(chuàng)新性和項目周轉(zhuǎn)。針對這些影響因素，國內(nèi)也有一些定量也就的方法和成就[2]，但對于具體實踐中的問題討論較少。軟件工程專業(yè)的學(xué)校教育，在這方面也是鮮有涉及，或者正在摸索階段[3]。

本文，基于敏捷軟件模式，著重討論和分析了在具體環(huán)節(jié)中的應(yīng)對實踐。

1 分布式研發(fā)團隊面臨的典型問題

IBM，諾基亞，微軟等老牌跨國公司進入中國設(shè)立研發(fā)中心時間早，結(jié)合本人經(jīng)歷以及走訪北上廣等大城市中在這些軟件研發(fā)中心中工作的項目經(jīng)理、架構(gòu)師等員工，我們大致可以看出這種多地分布式研發(fā)中心可能存在這樣一些共性的典型問題：

1.1 異地建立的研發(fā)團隊很難融入原有的研發(fā)體系

這個問題基本上是所有公司的新建異地研發(fā)中心都遇到過的。原有研發(fā)總部的人員已經(jīng)習(xí)慣了相互看著屏幕，坐在一起用投影開會，或者喊一嗓子就能有回音的交流方式。而對于異地研發(fā)中心的同事們的概念是模糊的，大多只停留在名字，或者公司的email符號上面。進而，原有研發(fā)總部的人員大多不太愿意同異地的同事協(xié)同，特別是性格大都不那么外向的研發(fā)人員。

1.2 異地建立的研發(fā)團隊自身發(fā)展的局限性

除開異地團隊獨立負責(zé)一款產(chǎn)品研發(fā)外，大多數(shù)的異地團隊需要從研發(fā)總部接受一部分項目來進行研發(fā)。通常有一個知識轉(zhuǎn)移的過程，這一過程要求異地團隊能夠有一批經(jīng)驗豐富的高級技術(shù)人員。往往這類高級人才的稀缺，會制約知識轉(zhuǎn)移的速度和質(zhì)量的提高。

同時，由于項目的需求側(cè)，如市場部門，產(chǎn)品經(jīng)理等等人員大多和研發(fā)總部在一塊。異地研發(fā)團隊缺少和這些人員的日常交流，和需求團隊的距離，通常也削弱了他們對項目需求的理解效果。

1.3 研發(fā)總部很難了解異地研發(fā)中心的研發(fā)狀況

研發(fā)總部通常很難了解到異地團隊的開發(fā)細節(jié)和項目進展。從而加深總部團隊對異地團隊的項目進展和項目能力的擔憂。

2 敏捷實踐中關(guān)鍵環(huán)節(jié)的掌控

軟件開發(fā)的敏捷模式，由于他的諸多優(yōu)點。研究數(shù)據(jù)表明，采用敏捷開發(fā)的模式，能夠顯著的提升軟件團隊的競爭力，能夠收到明顯的效果[4]，現(xiàn)在已經(jīng)慢慢被各個軟件廠商所接受，并努力的將自己的傳統(tǒng)軟件研發(fā)團隊轉(zhuǎn)型為敏捷的模式[5]。敏捷開發(fā)有多種實現(xiàn)方法[6]，其主要過程歸納提煉一下，大致有這么幾個環(huán)節(jié)，如下圖所示：

圖1 敏捷開發(fā)的主要環(huán)節(jié)

大家普遍認為，敏捷在本地小團隊，尤其是互聯(lián)網(wǎng)的小項目中[7]，能夠出色的達成軟件開發(fā)的各項目的。而對于一些大項目，特別是對于需要多個團隊協(xié)同開發(fā)的項目，敏捷模式會顯得不那么合適。

同時，大家也都承認，在小項目本地小團隊中，對于敏捷模式各個環(huán)節(jié)的掌控力度，通常要比異地團隊的情況要有力的多。根據(jù)本人多年從事scrum master和架構(gòu)師工作經(jīng)歷，以及同行交流調(diào)研的情況來看，在異地團隊協(xié)同中成功的項目案例也是有很多的。通過對這些成功案例的分析，可以發(fā)現(xiàn)在敏捷模式的各個環(huán)節(jié)中，有如下關(guān)鍵的幾點需要針對異地分布式團隊重點把握：

2.1 需求理解環(huán)節(jié)

需求理解是軟件工程中最為重要的一步，他決定者軟件開發(fā)是否能達到預(yù)期目的。開發(fā)過程中的好多難點，人員的加班，很多都與需求理解的不到位有關(guān)系。在異地團隊協(xié)作開發(fā)的模式中，需求理解環(huán)節(jié)的掌控尤為重要。

在敏捷模型中，團隊需求的管理者應(yīng)當是PO(product owner)。PO需要向團隊解釋產(chǎn)品需求，以及和團隊一道對需求進行拆分和排序。PO是敏捷backlog(項目需求池)的第一責(zé)任人，同時也是迭代驗收環(huán)節(jié)中的關(guān)鍵驗收人。在實際項目中，PO代表研發(fā)團隊，向產(chǎn)品經(jīng)理，或者市場需求部門負責(zé)。

那么在異地團隊的模式下，PO的對需求的掌控應(yīng)當注意哪幾個方面的內(nèi)容呢？

首先，在初次需求闡述的時候，盡量做到多團隊同時講解。充分利用電話會議，遠程視頻等工具，保證各地團隊都能夠清晰的接受PO的講述，并能夠參與提問與互動。異地團隊之間，也能夠相互聽到或看到對方和PO的互動，第一時間將PO的第一手闡述同步到各地。這個第一手信息的同步非常重要，因為通常80%以上的需求會在第一次會議中充分溝通到位。使用各種方式保障這一會議的有效性，和各方理解的一致性是非常有必要和劃算的，這能夠有效避免后續(xù)很多重要問題的理解分歧。

其次，各地團隊回下分頭進行本地討論。這一過程，PO可以參與，但主要是聆聽，不必過早的基于解答團隊的疑問。這樣，既讓團隊能夠集體的去理解需求同步各個內(nèi)部成員的理解，又能夠幫助PO梳理產(chǎn)品需求之中的不明確的點，特別是從開發(fā)角度來看，那些問題不清晰，和需要進一步定義明確。這本身也是產(chǎn)品需求不斷完善的一個過程。

在這一過程中，PO的沉默是非常有必要的。如果，PO急于給團隊解答，非常容易帶來一系列不良的影響：其一，對本地團隊問題的解答，未必能準確的同步到異地團隊中去，容易引入雙方理解不一致的隱患；其二，從問題的本身來說，PO未必能夠在短時間內(nèi)有明確而合適的回答，日后經(jīng)過需求側(cè)論證或者調(diào)研，很有可能推翻PO此時的回復(fù)；其三，PO此時的回復(fù)，容易打斷開發(fā)團隊對于需求理解的思考過程，很可能后續(xù)的理解會受PO此時的解釋而左右，使得團隊失去了獨立思考的機會。

最后，PO對需求疑問的反饋主要是通過兩種形式來完成：1.針對大面積的需求，特別是初次討論時的疑問，應(yīng)當舉行各團隊的全體電話、視頻會議，進行統(tǒng)一解釋。2.對于之后零零散散的需求詢問，PO也應(yīng)該仔細解答，并且應(yīng)用好諸如email備忘錄，公共wiki等電子方式，將問答存檔，并分享同步到各個敏捷團隊。當然最好形成完備的需求文檔，一般此文檔是非正式，緊緊用于項目組和用戶之間的溝通[7]。

總之，PO的需求環(huán)節(jié)是異地協(xié)同開發(fā)中最為重要的一環(huán)。此處要點若沒掌控好，后續(xù)的研發(fā)就是失之毫厘謬以千里了。

2.2 計劃會議環(huán)節(jié)

在向PO理解完需求，backlog已經(jīng)建立以后。通常各個團隊都會開始自己每個迭代的計劃會議。在計劃會議中，團隊會更具自己的情況來對每個故事進行評分，按照每個迭代的容量大小來進行計劃排期。

在這一環(huán)節(jié)中，增對異地協(xié)作的情況，scrum master只需要注意兩點：

1）就是在進行故事依賴關(guān)系分析的時候，要充分挖掘出對異地團隊工作的依賴。特別是要重視在關(guān)鍵路徑上的依賴關(guān)系。通常這些關(guān)系表示為，系統(tǒng)之間的調(diào)用接口，模塊的引用關(guān)系，或者數(shù)據(jù)輸入的依賴。盡早的識別出這些依賴關(guān)系，有助于團隊能夠盡早的采取措施來規(guī)避他們帶來的風(fēng)險。比如，建立和異地團隊的定期會議溝通機制，或者聯(lián)調(diào)、代碼共享的機制，等等。實踐證明，只要團隊能夠在計劃會議環(huán)節(jié)識別出異地依賴的風(fēng)險，那么在后續(xù)的研發(fā)過程之中，他們通常都能夠很好的采取相應(yīng)措施，成功的緩釋這些風(fēng)險。

2）就是要在計劃制定后，各團隊，需要相互通報自己的檢查點，或者聯(lián)調(diào)時間點。由于在敏捷開發(fā)模式中，任務(wù)的完成是以PO的最后驗收結(jié)果為依據(jù)的。PO往往只關(guān)心，最后產(chǎn)品整體展現(xiàn)出來的效果。所以，當研發(fā)團隊都充分的理解這一模式以后，他們往往會自發(fā)的進行跨團隊的協(xié)商，并留住聯(lián)調(diào)的時間緩沖區(qū)。雖然主要是自發(fā)的，但這一過程中scrum master要扮演好協(xié)調(diào)者和提醒者的角色。特別是在各自的檢查點、聯(lián)調(diào)點臨近的時刻，scrum master要主動的了解各地團隊的完成情況，相互通報進展，盡早的識別出潛在的風(fēng)險。

總之，在這一環(huán)節(jié)，scrum master應(yīng)當盡量對風(fēng)險因素敏感，早識別，早應(yīng)對。

2.3 每日站會環(huán)節(jié)

在計劃制定了以后，執(zhí)行就是成敗的主要因素了。每日敏捷團隊會選擇一個時間，站起來開一個簡短的小會。通常在這個會議中，每個成員都是依次報告三個問題：昨天我做了什么？今天準備做什么？目前有沒有什么阻礙住我的工作。

由于敏捷團隊工作在相同或類似的軟件開發(fā)環(huán)境和配置中[9]，有的公司可能會覺得盡可能多溝通，越多越好，從而選擇將異地的團隊合并起來，通過電話等形式，一起開站會。根據(jù)實踐的效果來看，我并不提倡這種做法。

首先，站會的目的就是為了敏捷團隊內(nèi)部能夠快速的交換信息，互通有無，進而互相幫助，最終目的是使得本輪迭代能夠成功。然而，異地2個團隊的迭代的目標往往是不同的。隊員在工作中遇到的困難和阻礙，往往也是和本地的人員、實驗環(huán)境直接相關(guān)的。異地的團隊，其實一般不了解，也不太關(guān)心這些本地細節(jié)。

其次，站會的形式本身就要求迅速的完成。而異地團隊合并進來舉行，一來會是的參會的人數(shù)增加，時間拉長；二來，從溝通效率上來講，遠程畢竟沒有面對面直接高效，這樣也容易拉長會議時間。當站會的時間被拉長，那么它也就失去了站會本身“站”的意義了。

總之，站會應(yīng)該盡量做成敏捷團地的本地時間。如果覺得某幾天的工作實在是有必要將細節(jié)通報給異地團隊，可以邀請一部分工程師過來旁聽本地的站會，待站會結(jié)束后，再留下相關(guān)人員深入的進行專題討論。

2.4 迭代驗收環(huán)節(jié)

在本環(huán)節(jié)，主要活動是各個敏捷團隊向PO展示本輪迭代的開發(fā)成果，并得到PO的改進意見反饋。針對異地敏捷團隊的情況，根據(jù)經(jīng)驗，我們建議PO采取遠程會議的形式，讓各個小組輪流講述自己迭代的成果，然后回答PO的提問。

這一環(huán)節(jié)的關(guān)鍵掌控者是PO。PO需要關(guān)注研發(fā)成果是否符合計劃時的預(yù)期，同時要將改進意見明確的提出并同步到每個參與項目的敏捷團隊知曉。當異地團隊參與驗收時，由于參與人數(shù)較多，往往容易陷入到團隊之間的技術(shù)或者其他細節(jié)討論之中。此時，PO應(yīng)該要完全的掌控此驗收會議的進程，讓會議的焦點集中到是否滿足需求，以及后續(xù)產(chǎn)品如何改進這一核心主題上來。過于發(fā)散的討論，往往是這一環(huán)節(jié)失敗的主要原因。由于涉及到需求的變化與改進，這一環(huán)節(jié)的失誤或缺失，會直接影響到后續(xù)幾個迭代的成敗，應(yīng)當引起PO和scrum master的高度重視。

在PO需求驗收完成以后，我們強烈建議scrum master組織各個團隊的高級工程師對本輪迭代的成果代碼進行代碼審查。其目的有三：其一，通過代碼審查，查找出代碼中的缺陷以及潛在的風(fēng)險，從源頭上提高代碼質(zhì)量；其二，通過交叉審查異地團隊的代碼，能夠相互增進團隊間的了解和縮短彼此的心里距離；其三，便是通過交叉審查，能夠幫助團隊中的初級工程師盡可能多的得到成長的支持。為團隊的可持續(xù)性成長提供基礎(chǔ)保障。對于代碼審查的具體，很多文章都有論述，本文不在贅述。只是注意盡量把握由本地團隊高級人員主審本地代碼，異地團隊的參與的原則，并留存好評審的詳細記錄。

總之，在對這一環(huán)節(jié)的掌控，PO需要緊緊鎖住需求實現(xiàn)的評估與反饋[10]；scrum master需要盡可能多的做一些質(zhì)量控制，異地交流和人才培養(yǎng)的工作。各地團隊便能慢慢的深入了解對方，建立起互信。

2.5 回顧會議環(huán)節(jié)

本環(huán)節(jié)的主要活動通常在是敏捷團隊內(nèi)部進行，針對本輪迭代，大家反思3個問題：我們那些方面做的好？哪些方面做得不好？可以有怎樣的行動來改進，讓我們做得更好？這一環(huán)節(jié)是敏捷開發(fā)的精髓，是為什么敏捷能夠持續(xù)不斷的改進團隊各項能力和效率的最直接原因。

經(jīng)過不同方式的嘗試，我們認為回顧會議環(huán)節(jié)，除了PO或者共同的領(lǐng)導(dǎo)以外，不必邀請異地團隊成員來參加。利用這個封閉的時間，充分的進行本地敏捷團隊的改進提高。Scrum master可以將大家提到的涉及到異地合作領(lǐng)域的內(nèi)容討論記錄下來，然后在另找個時間，同異地的敏捷團隊scrum master進行專場溝通，一同探討遠程協(xié)作的改進空間，并歸納出一些具體的措施。對于這些跨團隊的措施，我們建議使用一個共享wiki來逐條管理，根據(jù)具體的落實情況更新wiki狀態(tài)。異地團隊之間，scrum master可以約定一個時間，來作為周期檢查點，邀請每條措施的具體跟進人員一塊，檢查回顧這些措施的執(zhí)行情況。待這一機制形成習(xí)慣，周期性的開了起來，各個異地團隊直接的遠程協(xié)作方式，變能得持續(xù)的改進。大家的相互之間的了解，也會進一步加深，合作越來越默契。

總之，在這一環(huán)境，scrum master需要分級掌控團隊內(nèi)部的改進措施，和團隊之間的改進做措施，發(fā)揮出敏捷模式的精髓。

3 結(jié)論

本文根據(jù)各大公司在異地研發(fā)團隊建設(shè)的實踐經(jīng)驗，詳細論述了敏捷軟件開發(fā)模式下，異地團隊協(xié)作相關(guān)的關(guān)鍵環(huán)節(jié)掌控點。希望對各單位的研發(fā)中心敏捷團隊建設(shè)有所幫助。另外，本文沒有討論同一個敏捷團隊的異地成員問題。因為從過去這么些年的經(jīng)驗看，這種敏捷團隊的異地部署，都很難最后取得成功。不過，隨著移動辦公工具的豐富，與SOHO一族的隊伍壯大，相信在不就得將來，這種部署模式成功的案例，也會越來越多。

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

[2] 殷茗, 成麗媛, 鄧國林, 姜繼嬌. 異地分布式敏捷軟件開發(fā)的時間成本估算研究. 計算機系統(tǒng)應(yīng)用, 2018, 27(6): 189-194.

[3] 王芳, 鄧一星, 秦映波. 敏捷軟件項目管理課程教學(xué)方案研究與實踐[J]. 軟件, 2018, 39(4): 77-81.

[4] 嚴智淺析敏捷方法與開發(fā)實踐[J]. 信息化研究, 2013, 39(2): 52-59.

[5] 王旭. 傳統(tǒng)軟件開發(fā)團隊如何轉(zhuǎn)型為敏捷開發(fā)團隊[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] 惠子青, 劉曉燕, 朱匯龍. 基于敏捷開發(fā)增量UML模型的研究[J]. 軟件, 2018, 39(1): 142-146.

[9] 陳申平. 敏捷軟件開發(fā)中的配置管理探討[J]. 軟件, 2018, 39(5): 134-138.

[10] 桑大勇, 王瑛, 吳麗華. 敏捷軟件開發(fā)方法與實踐[M]. 西安: 西安電子科技大學(xué)出版社, 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-)，男，系統(tǒng)架構(gòu)師，碩士，研究方向為軟件工程、互聯(lián)網(wǎng)。

余迪謙. 異地協(xié)作敏捷開發(fā)團隊轉(zhuǎn)型實踐[J]. 軟件，2018，39（10）：238-241