首先明確一點(diǎn)，最敏捷的做法就是不要遠(yuǎn)程團(tuán)隊(duì)或分布式團(tuán)隊(duì)，遠(yuǎn)程一定比不上面對(duì)面同一地點(diǎn)的模式，畢竟環(huán)境不同，就不要期望遠(yuǎn)程團(tuán)隊(duì)和本地團(tuán)隊(duì)具備相同的效能，甚至期望更高。

那么，無論何種原因，如果已經(jīng)存在遠(yuǎn)程團(tuán)隊(duì)，如何提高效能呢？在考慮具體的操作之前，需要進(jìn)行價(jià)值流分析，避免價(jià)值交付（圍繞客戶和價(jià)值交付的一組人開發(fā)一個(gè)或多個(gè)軟件系統(tǒng)）的相關(guān)人員分布在不同的地點(diǎn)?？梢钥紤]調(diào)整遠(yuǎn)程團(tuán)隊(duì)的職責(zé)分工，形成一個(gè)地點(diǎn)的人員可以獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立運(yùn)維相應(yīng)的軟件或者服務(wù)的架構(gòu)，盡量避免本地和遠(yuǎn)程的兩方人員產(chǎn)生耦合。那么這個(gè)問題就變成了在各自的地點(diǎn)獨(dú)立進(jìn)行敏捷迭代開發(fā)，而團(tuán)隊(duì)之間的依賴，可以按需雙方處理。

效能和效果最差的情況就是本地和遠(yuǎn)程團(tuán)隊(duì)有較高的耦合性，需要考慮的是如何將雙方組織為一個(gè)敏捷團(tuán)隊(duì)，進(jìn)行如 Scrum 相關(guān)的活動(dòng)等事項(xiàng)?？梢詤⒖既缦乱恍┳龇▉砟M本地協(xié)作效果：

• 使用統(tǒng)一的一站式 DevOps 平臺(tái)，或者統(tǒng)一的 DevOps 工具鏈；

• 在需求和協(xié)作領(lǐng)域，電子工具可以展示包含多個(gè)迭代的發(fā)布計(jì)劃，每個(gè)迭代可以使用看板來跟蹤用戶故事和任務(wù)；

• 使用在線文檔記錄各種信息，包括需求細(xì)節(jié)、架構(gòu)和設(shè)計(jì)，以及迭代活動(dòng)相關(guān)活動(dòng)；

• 各種溝通、評(píng)審、迭代計(jì)劃、每日站會(huì)、迭代評(píng)審和迭代回顧會(huì)議，在使用線上視頻會(huì)議系統(tǒng)的時(shí)候打開攝像頭；

• 使用在線白板進(jìn)行團(tuán)隊(duì)的信息共享、頭腦風(fēng)暴等；

• 雙方定期互派人員作為大使出差到對(duì)方地點(diǎn)，進(jìn)行短期工作。

本文整理自《研發(fā)效能100問》，原作者 ??趙衛(wèi) 敏捷DevOps專家 《軟件研發(fā)效能權(quán)威指南》副主編