在實施持續交付的過程中，我們很容易聚焦於自動化和工具，因爲作爲起點，它們通常是最容易做的。然而，持續交付的成功實現，還依賴於根據最終交付物而對組織結構所做的優化。對於持續交付來說，最大的障礙是依據角色和分層結構來組織團隊，而非業務上的最終交付物（即產品或服務）。
爲了解決開發團隊、測試團隊和運維團隊之間的“筒倉”，Devops運動應運產生。那麼，這些“筒倉”爲什麼會存在呢？Gartner的Coleen Young說過下面這段話，直接切入這個問題的核心：
事實上，每個IT組織一定會面臨一個必然引起組織結構徹底改變的流程改造。傳統IT服務的交付和組織模式以有效性爲代價，達到了高效性。在過去，計算能力非常昂貴，資源稀缺的時候，將人員利用率和資產的生命週期成本最大化是合理的。這種面向資源的業務流程最終會導致功能壁壘。優化後的基於流程的組織在橫向上側重於各自環節的產出，而不是在全局上最終交付物的產量。
“筒倉”產生的根本原因在於計算資源的歷史費用和發佈過程的高成本。而批量單位的大小與交接成本之間有直接關係。這在Economic Lot Size 方程式上已經體現了，這個方程式是來處理交易成本（transaction cost）將一個工作塊交付給下一環節（如從開發到測試）和持有成本（不交給下游的成本）之間的平衡。這在Donald Reinertsen的書《產品開發流程的原則》中有討論，如下圖所示：
持續交付：減少交易成本
在大型機時代，發佈一個版本的交易成本較小。之後，當我們進入客戶端/服務器架構的時代，以及後來基於網頁的軟件系統，每次發佈的交易成本就變得越來越高了，甚至在總成本中佔首位。而這就驅使我們進行批量開發，從而導致了我們今天看到的“筒倉”。
然而，持續交付傳遞了一種信息，即現在有很多工具、模式和實踐，可以大幅度地降低發佈的交易成本，使得持有成本佔到交付總成本的大頭。
這樣的話，形成組織壁壘的根因就不復存在了。而且，由於壁壘會導致低質量的軟件，生產環境的穩定性差，以及發佈的次數越來越少。因此，對於那些關鍵業務的項目團隊來說，更有必要消除這些問題。
跨功能團隊：爲了最終交付物而做優化
筒倉的替代物是跨功能團隊。正如Young建議的那樣，在跨功能團隊中，我們對最終交付物或者交貨時間做優化。通過實現持續交付的那些實踐，可以將交易成本降到可忽略不計的水平。然後，通過限制在製品數量這種方式來實現小批量生產，並設法讓這些小批量功能在儘可能短的時間裏發佈給用戶，或者至少能夠做到“可以發佈給用戶”的水平。
跨功能團隊並不是一個新概念，但人們常常低估了它的重要性。對於減少交貨時間（lead-time）來說，跨功能團隊是一個至關重要的因素。因爲，功能交付的延期在很多時候是由於溝通開銷引起的。如果參與某產品（或服務）的所有人都能夠在一起工作，那麼在寫代碼之前，開發人員就可以直接把測試人員叫來，給他展示已做好的功能，以便能夠得到快速反饋。而測試人員和開發人員可以一起合作創建功能驗收測試，開發人員也可以與DBA一起討論數據庫結構的變更，還可以與基礎設施專家一起討論基礎架構上的一些平衡點。
這不但會讓軟件交付更快，而且會有更多的樂趣。當然，我們最終會得到高質量的軟件、低風險的發佈，以及從客戶那兒得到更快速的響應。在Amazon做出“組成面向服務架構的跨功能團隊”這一決定時，這些因素都是其認爲的關鍵收益。
對於“跨功能團隊”，常常會聽到這樣幾種的反對聲音。一是當所在的組織要遵從某些法案，如薩班斯－奧克斯利法案，或支付卡行業數據安全標準（PCI-DSS，全稱爲Payment Card Industry Data Security Standard）時，需要做到責任隔離。實際上，在跨功能團隊裏，能夠更高效地實現責任分離，正如我在最近爲 Cutter IT Journal的一篇文章提到的。
另一個反對的聲音是當創建跨功能團隊，並實現持續交付時，會有附加成本。的確如此，這意味着你只會在那些處於戰略地位的核心服務組合上投入這種附加成本。此時，通過產品的快速上市、從用戶那裏學習並快速迭代，以及避免開發沒有用的功能（這是軟件開發中產生浪費的最大來源）得到通常數倍於這種附加成本的回報。——當然，在“筒倉”引起的問題當中，有一部分問題是可以通過更好的管理手段來緩解的。比如，確保在這些“筒倉”中，資源負荷不過重，人員在各筒倉間輪換，以鼓勵協作和理解。
如何走向跨功能模式的組織？
如果你的IT組織不大，比如還不到30人，那麼你可以一下就轉變成跨功能模式。然而，在大型組織中，正如《持續交付》中的所有事情一樣，這應該是個迭代且增量的過程。
從一個試點項目開始。首先，確保你能收集整個項目週期中的總成本和總收入，以及其它相關度量項，比如週期時間(cycle time)以及每個發佈版本所交付的增量價值。整個團隊要對該服務的SLA（服務等級協議，Service-Level Agreement）負責。而且，更爲重要的是，對自己依賴的基礎設施，能夠做到自服務，包括測試環境和生產環境在內，從而不必爲了硬件準備這樣的工作而等上幾天或幾星期。應該給該團隊一些時間來實現持續交付，並且聚焦於交付一個最低可行的產品（minimum viable product），然後根據從用戶那兒反饋的真實數據進行快速迭代。
有分佈式團隊的大型組織更應該轉向“跨功能團隊”這個目標。而關鍵在於：確保不是依據角色不同而組織團隊。對於“持續交付高質量軟件”來說，沒有什麼能比讓開發團隊在一個國家、測試團隊在另一個國家，而運維團隊在其它國家的傷害更大啦。
最後，團隊應該首先關注於，通過分解成最低可行的產品集並測試，以驗證其所做出的業務假設。而一旦失敗，就很容易進行調整。
原文來自《持續交付》, 更多關於“持續交付”的內容請訪問 http://www.continuousdelivery.info。