異地協(xié)作敏捷開發(fā)團(tuán)隊(duì)轉(zhuǎn)型實(shí)踐

余迪謙

?

異地協(xié)作敏捷開發(fā)團(tuán)隊(duì)轉(zhuǎn)型實(shí)踐

余迪謙

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

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

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

0 引言

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

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

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

1 分布式研發(fā)團(tuán)隊(duì)面臨的典型問題

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

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

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

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

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

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

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

研發(fā)總部通常很難了解到異地團(tuán)隊(duì)的開發(fā)細(xì)節(jié)和項(xiàng)目進(jìn)展。從而加深總部團(tuán)隊(duì)對異地團(tuán)隊(duì)的項(xiàng)目進(jìn)展和項(xiàng)目能力的擔(dān)憂。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 結(jié)論

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

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

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

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

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

[5] 王旭. 傳統(tǒng)軟件開發(fā)團(tuán)隊(duì)如何轉(zhuǎn)型為敏捷開發(fā)團(tuán)隊(duì)[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] 劉蓉, 陳波. 基于微信公眾平臺(tái)的招生咨詢智能聊天機(jī)器人[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ā)方法與實(shí)踐[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)師，碩士，研究方向?yàn)檐浖こ?、互?lián)網(wǎng)。

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