作為 ThoughtWorks 的一名咨詢師，我曾不止一次的被問到 ThoughtWorks 的交付項目和一般意義上的外包到底有何區別。要區分差別，首先要對外包加以定義，外包從最傳統的 IT 外包到業務流程的外包，以及最近幾年新興的知識流程外包，其本身的定義也在不斷的演化。每種外包有其不同的訴求，傳統的IT外包和業務流程外包追求成本的降低，而知識流程的外包則更著眼于客戶 知識能力的提升以及團隊的成長。

　　ThoughtWorks 的交付項目更多的是一種知識流程外包的高端服務。交付項目的成功不僅是交付卓越的軟件，還需要在交付卓越的軟件的過程中， 深刻理解客戶的市場需要和業務模式，并通過自己的努力去影響客戶，最終和客戶以一個團隊的模式一同交付高質量的軟件。 而怎樣去影響客戶的行為，進而鼓勵他們去嘗試更多最佳實踐呢？是否只能通過咨詢項目達到這個目的呢？一般來說，咨詢是需要長期在客戶現場進行持續的影響，才能產生效果。但交付項目如同很多外包項目一樣，通常是離岸的。那么隔著十萬八千里的距離，再加上幾個小時的時差，如何才能真的像一個團隊一樣緊密合作，并且持續的影響客戶嘗試更多最佳實踐，一步步實現交付卓越軟件這一目標呢？ 溝通，就是基于知識流程外包的分布式開發中，最大的挑戰。

　　正如前面所說的，我們有著地理上的距離，這就意味著我們會有巨大的文化差異。客戶說“還可以”，可能意味著其實有些問題。如果說東西方的文化差異可以通過了解當地的風俗民情去理解的話，那么企業的文化差異就需要一些同理心了。作為一家“不創新就會死（Innovate or Die）”的先鋒企業，我們的咨詢師通常是勇于嘗試，熱衷創新的；而我們的客戶卻很有可能是擁有龐大的組織結構的傳統企業，做任何一點改變都需要考慮所有部門利益，甚至很長時間都難以做出一個決定，這和我們的快速反饋原則往往都是不相容的。

　　所以溝通毫無疑問會成為分布式開發最大的挑戰。經過多個分布式開發項目，我們總結出以下幾個最佳實踐：

　　快速啟動（Inception)

　　快速啟動中， 所有的項目干系人通常會聚集到一起，在兩周左右的時間中進行一系列的愿景分享、業務探索、產品設計、需求收集以及計劃發布等活動。

　　快速啟動的目的首先是讓大家聚到一起。作為可能要合作上幾個月甚至幾年的隊友，雖然之后很長一段時間大家天各一方的工作，但在啟動階段能夠認識彼此，通過面對面的溝通對對方的工作有感性的認知，無疑對于后面工作的展開會起到重要作用。

　　快速啟動通過兩周密度較大的活動，讓每個團隊成員，在盡可能短時間的內，達成共識。這其中包括了解戰略愿景，進而理解項目的機遇與挑戰；通過和市場人員的溝通去理解客戶需要；和產品部門一起設計出符合客戶體驗需要的產品原型，進而拆分出可開發的需求；根據優先級排列并發布計劃。

　　在兩周的時間里，團隊將一個商業概念轉換為形象的原型，并制定可供開發使用的發布計劃，快速啟動的交付物無疑對于后面的開發階段非常重要，而更重要的是快速啟動的交付物是整個團隊一起工作產出的。每個人都參與了產生的過程，分享了相同的上下文，這對于后面的開發階段的有效溝通會非常有幫助。

　　在快速啟動之后，團隊一般就可以開始進入迭代0的開發了。在迭代0中，所有團隊成員能繼續一起工作，在這個較短的迭代搭建好環境，對架構都形成共識，試著在迭代0里去完成一個基本的需求。

　　快速啟動和迭代0這段時間中，所有團隊成員緊密合作，不光對于交付軟件有所幫助，也能更好地讓咨詢師理解客戶團隊的工作習慣、技術水平和代碼風格，進而評估哪些最佳實踐是適合客戶團隊的。比如我曾經參與過的一個項目中，在快速啟動階段，我們發現客戶團隊的很多基本實踐，如TDD，已經做的很好，代碼水平也很嫻熟，但部署的方式卻很落后。同時，業務部門的需求明顯需要持續交付來支撐，于是持續交付就成了重點嘗試的實踐。每個項目都具有自己的獨特性，所以通過快速啟動的方式，用最快的速度了解客戶的知識流程上需要改進的地方，這樣跟客戶溝通的時候，才會讓客戶更加認同知識流程外包的高附加值。

　　站會：

　　相信了解敏捷的人對站會這一實踐都不會陌生。在分布式開發過程中，我們不僅開展了團隊的站會，還進行了基于角色的站會。一般而言，團隊的站會更多的關注故事卡的狀態流動，檢查路障，而不會關注每個不同角色的具體工作；而在基于角色的站會上，例如開發站會上，開發人員之間可以討論技術上的某個難點。同樣的，業務分析人員也要通過每日的業務分析站會來了解產品經理的思路變化和業務部門的更新。 我曾經遇到過一個項目有來自三地的測試人員，那么測試人員之間的站會就非常重要，測試人員利用角色站會這一機會討論測試策略。隨著項目的演進，測試的重點也不斷轉移，從一開始關注功能測試到逐漸關注集成測試，角色站會給他們提供了一個契機及時討論項目碰到的問題和機會。

　　迭代計劃會議：

　　迭代計劃會議也是常見的實踐。在分布式的場景下，迭代計劃會議需要更多的準備，要求各方團隊成員提前理解下一迭代需要完成的需求，這樣大家可以在迭代計劃會議的時候著重討論有疑惑的需求，而不是浪費很多時間在解釋需求本身是什么上。在答疑解惑之后，大家對要完成的迭代目標必須形成一致的意見。同時，在分布式的開發中，不同地域方的團隊成員會更加關注本地團隊所能完成的需求，卻忽略了其他地域團隊的開發速度。在其他地域團隊遇到困難時，更重要的是幫助對方一起完成對方做的需求，而不是只關注自己做的需求。通過一起達成迭代目標，讓大家分享共同的責任感。

　　在實際項目過程中，通常業務分析師會提前將計劃的需求故事發給團隊成員。運用合適的分布式項目管理工具會讓這一過程更加容易，如 Mingle 或者 Jira。在工具中整理出下一個迭代的故事墻，讓團隊成員提前看到虛擬墻。在迭代計劃會議上，主持方將虛擬墻打開并屏幕共享給其他方，這樣各方就可以關注在同一個需求故事卡的討論上。

　　回顧會議：

　　由于各種限制原因，分布式團隊很容易產生溝通不足現象。而回顧會議創造了必要的溝通橋梁，因而非常重要，一定要保證所有方都能參與進來。遠程回顧會議通常利用在線白板，讓每個成員提前在在線白板上提交上個迭代里做得好的和值得改進的地方。這樣，當回顧會議開始后，每個人都是有所思考的，提出的意見更有深度，而且也可以更好地利用回顧會議的時間一起探討所有人都關注的問題。通常，通過回顧會議可以發現，處于不同地理位置的多方成員往往關注的事情也不同，而會議上各方成員又可以了解對方在擔憂什么，遇到了哪些困惑，并將這些擔憂困惑分享，形成大家都認同的改進行動。

　　結對編程：

　　結對編程這一實踐對于知識的傳遞非常重要，即便在分布式團隊中，結對編程依然是非常重要的實踐。合理地利用時差，在各方重疊的工作時間里通過屏幕共享工具遠程結對，是保證代碼質量的重要手段。

　　每天合理地利用遠程結對不光可以傳遞知識，同時也是一種有效地影響其他團隊成員的方式。遠程結對可以讓咨詢師清楚了解處于不同地域位置的客戶團隊的代碼水平、代碼風格和思維方式，從而可以通過每天頻繁的結對編程言傳身教最佳實踐。這種影響行為改變的方式效果顯著，而且對于增強團隊成員互相了解信任，并形成有統一責任感的“同一個團隊”，也非常有幫助。

　　但不可否認，遠程結對會影響開發效率。并且，由于各方工作時間安排以及公共假期等原因，很難保證遠程結對的頻率。所以，遠程的代碼評審（Code Review）就顯得格外重要。每天各方開發人員在一個固定時段去評審所有提交的代碼，能夠讓團隊成員不光關注自己，也了解別人做了哪些代碼改動。同時，代碼評審對于形成統一的代碼風格也很重要。當處于遠端的咨詢師想去去影響客戶的代碼風格時，如果無法讓所有的人都理解為什么要用某種風格，那么之后的一致性也就無從談起。而遠程代碼評審就能在溝通不足的條件下，從分展示好的風格帶來的改進（Lead By Example），從而達到提成遠程提升客戶技能的目的。

　　在分布式開發中，我們依然遵循基本的實踐，同時為了克服遠程開發溝通不足的缺陷，并達到整個團隊能力提升的目的，我們更關注建立溝通渠道和及時的分享。所有的實踐在滿足基本的目的之后，都要考慮是否能通過這一實踐分享知識以及獲取知識的正確方式，客戶成員是否能得到能力的提升。

　　除了溝通這一挑戰之外，分布式開發環境下當然還有其他各種挑戰，如如何遠程的讓團隊保持足夠的凝聚力，讓大家不因為距離而產生陌生感？ 所以，經常在工作之余進行些適合遠程的團隊的游戲，定期邀請各方成員去對方工作的地方工作幾周，體會對方的工作環境，能夠更好地幫助團隊保持一致的目標。此外，分布式團隊模式下的項目也有需要關注的特有的風險，如各自國家的成員有不同的公共假期，最后的部署上線如何安排等細節都需要去關注。

　　由于基于知識流程外包的分布式開發追求交付的成功以及團隊的成長，那么面對不同的客戶團隊就會有不同的挑戰。作為咨詢師，在關注軟件交付本身的同時，更要關注如何提升團隊的能力。通過以上這些實踐不難發現，雖然依然采用敏捷的基本實踐，但在分布式開發的場景下，適當地改進基本實踐，才能真正實現高附加值的卓越軟件交付。