幾年前，我特別重視定期與軟件開發人員開會交流。然而，在幾次會議之後，我意識到長時間的會議並不適合他們，反而打擾了他們正在進行的編碼工作。但是我需要他們和我保持同步——這是成功開發的粘合劑。很快，我瞭解了敏捷式會議，我們開始在谷歌的Hangout中進行虛擬會議，效果很不錯。

隨著世界各地的組織都在嘗試精益，敏捷開發和遠程開發團隊——兩種不同的精益方法成為相輔相成的組合，它能實現全球各地的人們一起合作，以一種精簡、高效的方式完成軟件開發。

這種方式的優勢：

✔ 更快的生產週期

✔ 併發編程

✔ 能夠持續部署更少的障礙

✔ 工作倦怠的機會更少

然而，敏捷開發和遠程團隊有時也會有一些挑戰：

◆ 在遠程團隊成員之間建立融洽的關係

◆ 跨時區協調

◆ 當兩個團隊只在短時間內在線時，如何安排會議

◆ 不同開發文化之間的協作

為了緩解這種衝突的情況，組織需要一種混合的敏捷開發方法，專門針對簡化和支持遠程軟件開發。以下是我的實戰經驗分享：

1.有意義的自動化

持續的流程審查是實現生產力的關鍵。首先確保在具體事實基礎上回顧你的開發流程，並尋求解決方案以使流程儘可能有效和簡化。投資於一個傘形應用程序，它無需為不同的流程使用不同的應用程序，從而通過沒有重複的流程來更快、更有效地執行任務。

在持續時間較長的項目或管理遠程團隊時，創建持續集成的文化特別有價值。

自動化可以通過多種方式節省時間：它可以快速跟蹤整個交付和報告過程，賦予參與人員一種責任感，並且100%可以實現，這都要歸功於最新的技術進步。例如，Jira是計劃和構建優秀產品的團隊的首選跟蹤器。許多團隊選擇Jira來捕獲和組織問題、分配工作以及跟蹤團隊活動。無論團隊位於何處，它都能完成任務。

用戶故事：讓我們來看看德國汽車巨頭奧迪是如何在日常業務中使用Jira的。

奧迪的辦公室遍佈全球，但其主要研發中心均設在德國，擁有6000多名員工。他們在2007年開始使用Jira來進行問題跟蹤和知識管理，今天，它們被用來支持所有的團隊和他們的項目——無論哪個部門。在道路測試設施中，測試人員在測試驅動期間將汽車軟件bug記錄到Jira中。在賽道之外，團隊使用Confluence來存儲文檔、部門協議、會議記錄和政策，以幫助公司保持高效和透明。

工具提示：

• 用於文檔存儲庫和文件共享的Google驅動器。
• 版本控制來監視和推送代碼。(Bamboo,BitBucket)
• Slack for real-time, power conversations——快速回顧，改變和決定。

敏捷很簡單——把時間花在實際工作上

成功的咒語很簡單，真的——少說多做。許多敏捷團隊對開發模型本身非常著迷。敏捷模型是用來提高生產力的，如果我們不夠敏捷，不能利用敏捷為團隊帶來好處，那麼敏捷就是失敗的。

例如，對於遠程團隊，距離可能成為他們在遇到挑戰或障礙時迴避改進解決方案的理由。這可能會對整個團隊產生反作用。制定一個時間表，確保你的團隊每週或每天完成他們份內的工作，儘可能讓團隊成員對決策執行的參與度與對決策制定的參與度相當。

你們開會的時間應該有利於團隊成員所在的相應時區，可以通過全程關注所有成員的參與度來優化會議持續的時間。你也可以考慮輪流開會，這樣各個時區的團隊都不會對會議時間感到負擔。研究這些會議如何影響生產力，並相應地減少或增加頻率。一旦項目結束，確保最終結果在團隊之間共享，並強調每個團隊參與的價值。

用戶故事:在採用新的業務實踐方面，Amazon一直是潮流的引領者，它對Scrum的廣泛應用值得一提。Scrum促進了分散的自由決策權，旨在讓團隊以一種精簡的、無需繁文縟節的方式創建、交付和運行高質量的軟件。Scrum的實現是在Amazon的底層進行的，它允許團隊響應需求，並在發現障礙時及時處理。

“day day up”

本質上，敏捷性允許在發佈和評估原型時為短期開發項目做更詳盡的規劃，對於長期計劃則更為籠統。

敏捷就是快速執行和快速發佈。沒有完美的餘地。這是正確的。因此，你每天所做的工作決定了你將交付什麼。完成每天的目標或小的可交付成果對團隊來說是一個巨大的激勵，並且創造了一種不斷接近最終目標的感覺。

工具提示：

- Basecamp 3: Basecamp從一開始就是我們的客戶溝通工具。新版本不僅僅是消息發佈通道——Basecamp 3通過它的to-dos特性幫助我們的團隊輕鬆地自動化日常任務。

一切為了衝刺（sprint）

雖然有一個時間表是好的，但是不要讓會議佔用了團隊的工作時間。

短小精悍是通關訣竅。保持衝刺（sprint）的短小能夠提高生產力，也更有利於團隊快速發佈。畢竟，這不僅僅是關於發佈和生產力的問題，還包括團隊的思維方式，正是這種思維方式使他們永遠不會停滯不前，從而真正實現敏捷。由於衝刺（sprint）時間較短，因此規劃更為現實，因為規劃是基於當前統計數據做出的。

工具提示：

Jira等工具與Slack集成後，可以將Jira中重要事件的通知自動推送到Slack通道中。這使得團隊成員可以實時更新sprint進度，而不必等待響應和停滯進度。

建立一個可靠的項目路線圖

羅馬不是一天建成的，需要時間、精力和大量的頭腦風暴！同樣，你需要制定項目路線圖，因為這是與敏捷團隊溝通的行動計劃，無論他們身在何處，產品或解決方案將依此隨著時間的推移而發展。

遠程分佈式團隊意味著不同的時間框架，這使得規劃成為一項挑戰，因為你無法隨時跟他們討論細節。在這種情況下如滾動波計劃之類的方法可能會讓事半功倍，即詳細計劃在時間軸上離你最近的事情以及重要的遠景。在多個敏捷團隊之間共享，這樣的計劃將為團隊的日常工作提供關鍵的環境，並響應競爭格局的變化。你所要做的就是把它分解成幾個月、幾個星期和幾天。每天應該定義當天可交付的成果，因為每天交付的東西對於最終目標至關重要。

用戶故事:敏捷的工作生態系統促進了分佈式的團隊文化，這一點在當今的行業中很少得到體現。以微軟為例，它已經成功地在企業範圍內使用了敏捷模型。

但是，當它開始時，它也有瓶頸，這些瓶頸實際上對質量和進度產生了負面影響。但是，他們使用第三方框架（例如SAFe），將敏捷應用於企業項目解決了他們的問題。他們從規劃和架構開始，著手構建功能，最後才與代碼打交道。遙測技術被用來跟蹤系統工作，並實現自動化測試。通過敏捷軟件開發，微軟成功地將其發佈週期從幾個月縮短到幾周，並能夠更快地響應客戶的需求。

測量。更改。發佈。

不要只是部署，測量。通常，我們最意想不到的事情總會發生。這時候，你需要改變策略，或其中的某一個環節。敏捷意味著你應該能夠在任何需要的時候做到這一點。這就是敏捷帶來變化的原因。

根據數據和度量標準構建下一個路線圖。

對於敏捷和精益流程，基本指標是提前期、週期時間、團隊速度和開/關率。這些度量標準有助於規劃並幫助你做出有關流程改進的明智決策。當這些指標中的任何一個不在你期望的範圍內或朝著令人擔憂的方向發展時，不要猜測原因，讓你的團隊參與進來，公開進行討論，共同解決問題。

結論

敏捷對於軟件開發來說非常好用，因為它關注於自我管理的團隊，自治，以及對優先待辦事項的可見性。擴展敏捷性的過程似乎很簡單：如果它在一個部門有效，那麼你只需將它應用到所有的團隊和部門，即可構建敏捷的公司生態系統。記住，即使對於分佈式團隊來說，遠程並不是問題——由於大量可用的通信平臺，如Slack、Jira或Skype，世界變得更小了。鼓勵密切的溝通是在分佈式團隊中維護敏捷流程的關鍵。

關於作者

Tanya Kumari是應用程序開發機構Classic Informatics的敏捷專家。她是一位熱心的讀者、音樂愛好者和技術發燒友，喜歡瞭解技術世界的最新進展。當她不在撰寫有關敏捷團隊動態的最新文章時，你可以在咖啡機旁找到她——正在向同事介紹健康生活方式的好處以及如何實現。

注：本文編譯自InfoQ