Siemens Healthineers在teamplay使用持續交付

摘要： 本文要點 持續交付是一種保證系統在整個開發過程中都處於可釋出狀態的工作方式。這通常需要在組織、技術和開發文化方面的變革才能實現。如果你現在無法釋出到生產環境，那麼就不是持續交付。 在通往持續交付的旅途中有許多階段性的成果。那是個逐步採用的過程，而不是...

概述

持續交付是一種保證系統在整個開發過程中都處於可釋出狀態的工作方式。這個看似簡單的理念需要我們重新思考傳統軟體開發過程的所有方面。

在這篇文章中，我們將介紹Siemens Healthineers的一個大型軟體開發組織如何開始向持續交付轉型，描述了他們在規範化的醫療領域逐步、安全地改變開發過程所採用的策略與技巧。

teamplay由Siemens Healthineers開發。這是一個面向醫療機構的績效管理解決方案，彙集醫療健康專業人士，通過團隊努力推動醫療和人類健康。

通過連線醫療機構和它們的影像裝置，teamplay應用旨在建立世界上最大的放射學和心臟病學團隊，為其成員提供工具，處理大資料，應對這些部門中日益增加的成本壓力。

基於雲的解決方案teamplay及其應用將通過提供明白易懂的績效資料概覽幫助做出及時明智的決策。

它監控數量，如影響吞吐量或劑量水平、員工利用率、整個部門的房間和資源，一直到每種裝置和過程，簡化報表，顯示工作流何處需要調整。

它會連線teamplay的其他使用者以及他們的資料，提供比較基準，與其他醫療保健提供商毫不費力地交換影像和報告。

應用程式

teamplay Usage和teamplay Dose 是teamplay網路託管的兩個應用程式的例子。teamplay Usage

使得醫療機構可以監控分值和趨勢，如病人變化次數或者不同影像掃描裝置執行檢查的次數。

teamplay Dose使衛生機構可以獲知掃描裝置使用的輻射劑量水平，突出內部閾值和國家閾值的偏差。

該網路包含2550多個teamplay連線，而且數量還在增加。由第三方接入teamplay公共API的應用程式數量也在穩步增長。一旦醫療健康機構連線到這個網路，該機構的影像掃描裝置就會不斷地向雲端傳送資料。

技術

這些資料被在微軟Azure雲上執行的teamplay消費。使用者通過一個使用者介面同這些服務進行互動，該介面是用AngularJS實現的一個單頁應用程式。前端整合很簡單，通過iFrames，因此，使用teamplay公共API的第三方應用程式可以選擇他們自己的技術。

改進開發過程

目前，teamplay系統的變更每季度釋出一次。我們的目標是大幅提速。這會使得我們可以更快地釋出特性，從而可以更快地響應使用者需求。從技術的角度講，更快的交付和更短的迴圈週期應該可以幫助我們減少批次大小，使得變更更小，風險更低，縮短目前在每次釋出前所需的穩定期。通過提升整個過程的質量，我們意在改善釋出日期的可預測性。

以此為目標，teamplay開發團隊開始致力於部署自動化。首先，我們致力於實現自動化開發部署。然後，我們增加了自動化完整性測試，檢查應用程式的主要功能。這些測試可以確定部署是否處於可用狀態。它們在部署之後立即執行，並告知開發團隊構建是否適用於探索性測試。

部署及完整性測試的自動化給產品穩定性帶來了顯著的提升。不過，更頻繁地釋出以及縮短每次釋出之前的穩定期仍然是一項挑戰。

採用持續交付

持續交付（CD）是一種軟體開發方法，基於一種更為嚴格的工程方法。它不僅僅是部署自動化和自動測試技術。CD的目標是使軟體在整個開發過程中都處於可釋出狀態。這個簡單的理念影響著組織軟體開發方法的每個方面。不管是從技術角度，還是從業務角度，可釋出性都是需要的。為此，技術工程和需求工程需要同時做出調整。

我們邀請Dave Farley在我們的軟體開發方法的各個方面為teamplay 提供幫助。我們的基本目標是提升安全性、穩定性和開發過程的效率。

由於teamplay 開發的軟體在醫療健康領域使用，要符合領域規範，所以安全性至關重要。合規與高質量產品的生產都極其重要。

teamplay相當傳統的開發方法有一些傳統的問題。最大的問題也許是，隨著軟體及組織複雜性的提升，團隊以期望的速率開發新特性的能力越來越低。

我們的目標是通過運用良好的工程原則來克服這些困難。我們希望可以提升質量和反饋頻率，改善整個組織的合作，使開發文化轉向更規範的高質量工程方法。

可以提供高質量反饋的高效過程和機制是使團隊和個人能夠更好地看到自己的工作和決策成果的基礎。良好的反饋是任何高質量過程都具備的特點。

有效的協作至關重要。我們的目標是通過優化實現更為分散的、以任務為中心的領導風格。teamplay組織的分散式特性意味著在靠近工作的地方進行本地決策更為重要。建立高效的團隊結構和良好的工作實踐可以促成更加分散的決策方法。這很重要，可以推動我們邁向更強大的工程文化。

我們通過培訓、輔導以及文化變革方面更廣泛的思考推進這些變革。每個團隊都接受一些有關持續交付理念和哲學的培訓。這有助於人們理解為實現這種變革而對每個人提出的要求。

接下來，我們圍繞著我們要求人們採用的一些具體技術進行更細緻的實習培訓。我們讓有CD經驗的人和正在學習這種新方法的團隊一起工作。

在技術端，我們致力於通過更好的自動化測試和更高效的部署管道提升反饋。故事地圖為需求過程提供幫助，類似領域專屬語言這種技術的使用可以與故事地圖生成的故事聯絡起來，提供一種以這些“可執行規範”為基礎的聯合開發方法。

其中許多變革還在進行過程中。採用情況因團隊而異，有些在技術上更困難，還有廣泛傳播的文化，變革尚未完成。不過，這是意料之中的。我們的目標是通過長期的變革過程安全地逐步提升開發過程。

選擇變革策略

考慮到我們從teamplay開發過程開始持續交付轉型，顯然，需要縮短團隊的測試反饋週期。我們需要24到48個小時才能知道測試執行結果。我們希望通過一系列旨在提升反饋質量的步驟把這個時間縮短到1小時。

為此，需要做一個基本決策。我們可以繼續使用現有的管道，一口氣部署和評估teamplay，並致力提升其速度。這會涉及擴充套件我們的構建伺服器，既包括橫向，也包括縱向。我們需要探索增量編譯，僅執行受軟體變更影響的測試。另外，我們可以把我們的架構分解成微服務，為每個微服務建立一個專用的管道。

我們決定採用一種折中方案，介於這兩個正交選項之間。因此，我們決定為每個teamplay應用程式建立一個專用的的管道。

這種方法不需要我們為了整體部署以及提升隨之而來的測試執行速度而投資複雜的工程，也不需要我們把架構分解成非常小的組成部分，並在它們之間設計向後相容的契約。我們將來可能會考慮微服務方法，但是現在，我們僅致力於把teamplay的每個應用程式作為獨立於其他部分的整體來發布。

在決定為每個teamplay應用程式建立一個專有的管道後，我們需要詳細討論下團隊如何建立新特性以及新特性如何進入管道。換句話說，我們需要看下團隊如何定義、實現和測試特性。

改進質量

必須要有一個過程，可以確保團隊建立的管道輸入符合必要的質量要求，可以實現充分、可靠的自動化。僅僅有一個管道，或者每個應用程式一個管道，這並不是目標本身。目標是能夠把高質量的應用程式釋出到生產環境。要實現這個目標，需要團隊為管道提供高質量的輸入，一個高效的管道可以儘可能快地執行輸入，提供反饋，幫助團隊高質量地完成工作。

持續交付地圖

在一系列的研討會、諮詢會議和培訓課程之後，我們建立了自己的持續交付模型，如下圖所示：

上圖展示了我們希望採用的產品變更定義、測試、實現和部署方式。

這幅圖的最上面列出了我們使用的方法：測試驅動開發（TDD）、行為驅動開發（BDD）、領域驅動開發（DDD）、結對程式設計、結對輪轉（兩人一組）及團隊部署管道。供所有團隊成員使用的所有這些方法將使我們達到應用程式總是處於可部署狀態的目標。後續，釋出決策不會因為達到技術上的就緒狀態所需的時間而受阻，而是根據純業務和管理的考慮來進行。

圖中的彩色小人圖示代表應該執行特定過程步驟的角色：產品經理（PO）、業務分析師（BA）、設計人員（Des）、架構師（AR）、開發人員（Dev）、運維工程師（Ops）。圖中主線的顏色代表相應角色應該使用的方法（TDD、BDD、DDD、結對），圖片右上方有圖例說明。

還是在圖片上方，顯示了我們希望使用使用者故事地圖和BDD場景來詳細描述產品的方式。在圖片右側，說明了我們希望使用的產品測試方式，建立一種領域專屬語言（DSL）來表示測試用例、驗收測試和TDD。在圖片底部，展示了我們使用4階（接受1、接受2、過渡、生產）段團隊管道部署產品的方式。

這個圖形一直非常有用。除了幫助我們整理思路外，專案成員還可以藉助這張圖快速找出，按照他們的角色他們應該做什麼才能促成持續交付。

過程總覽

讓我們看下，如何像上圖那樣，使一個特性走過整個流程。

假設

假如團隊中有人有一個關於新特性的想法。第一步是陳述我們希望測試的假設。這可以通過以下三元組來完成：

• 我們相信這個<能力>
• 將產生這個<結果>
• 當我們看到<測量訊號>，我們知道我們成功了

過程的所有後續部署都是為了證明上面陳述的假設是對還是錯。陳述假設很重要，因為它提供了工作範圍：我們只需要實現測試假設所需要的功能和產品檢測。

低保真原型

該過程的下個步驟是把想法變成原型，以便從客戶那裡獲得早期反饋，看看這個想法是否引起了他們的共鳴，是否應該進一步投入。這一步是由產品經理和設計人員完成，提供一個低保真原型（例如，手動繪製的紙上原型或概念線框）。

接下來，產品經理和設計人員會大致地介紹特性，只是為了向專案中的其他角色解釋。

故事地圖

在下一個步驟中，每個人都參與使用者故事地圖的建立。使用者故事地圖以層次化的方式展示與特性關聯的使用者旅程。產品經理、架構師、業務分析師、設計人員和開發人員全部參與討論，瞭解和規劃使用者在使用該特性時的旅途。重要的是要考慮使用者經歷的所有步驟，也包括在產品之外執行的那些，如果有的話。團隊中的每個人都需要了解使用者旅途。

建立完使用者故事地圖後，下一步是排定工作優先順序，確定將會首先發布的一個小故事集。這個故事集將構成我們的最小可行產品（MVP）。然後，從MVP集合中選出一個故事進行改進。

建立BDD場景

改進使用所謂的BDD場景來完成。每個場景使用Gherkin語言的Given/When/Then語句進行表示。重要的是確保產品經理、架構師、業務分析師、開發人員和運維人員全都可以為故事的場景集合做出貢獻，因為每個角色都是從不同的角度來看待專案。

通常，產品經理會從功能的角度貢獻最初的場景集合。整個團隊一起擴充套件最初的功能場景列表。舉例來說，架構師可以從負載和安全的角度貢獻額外的場景。運維工程師可以貢獻與監控和日誌相關的場景。業務分析師負責確保團隊涉及了所有方面（或“某某性”）。

我們旨在保證故事較小。如果使用者故事的場景數量超過6個，那麼該使用者故事就太大，需要在使用者故事地圖中劃分成更小的特性。

我們還希望保證故事專注於使用者需求，故事和場景應該不包含任何技術細節（不提及實現細節或UI），而是完全從使用者的角度編寫。

一個很好的檢驗是，當客戶打進電話要求回答有關特性實現的問題時，1線支援可以使用使用者故事和場景。如果使用者故事和場景是從使用者角度編寫的，沒有涉及實現細節，那麼它們在1級支援回答客戶問題時應該會非常有用。

BDD和DSL

一旦團隊就使用者故事的BDD場景集合達成一致，就可以逐個測試和實現場景了。我們採用了真正的測試優先方法，在準備好恰當的測試工具之前，不開發任何生產程式碼。這樣可以確保把測試從產品程式碼分離出來，有一個良好的關注點隔離，這反過來有助於降低測試維護成本。

場景測試的第一步是提出一種新的或者擴充套件現有的領域專屬語言（DSL），在這裡是Test DSL。Test DSL的靈感來自領域驅動設計（DDD）方法，從使用者故事和場景定義的思路探討到實際程式碼，在整個過程中發生的所有對話中使用相同的語言。

藉助Test DSL，我們使用Gherkin語言以可執行、可重用的形式定義BDD場景。不過，只有前面定義的場景不包含實現細節時才可能重用。這樣做還有一個好處，Test DSL可以由非技術人員編寫，他們對問題領域有很好的理解。這使得他們可以準確地說明他們的需求，因為規格說明書是可執行的。

在定義好場景的Test DSL後，就可以由開發人員在驗收測試中實現。這是我們第一次做實現決策。我們希望儘可能地通過API進行測試，因為這些測試執行速度快，而且比UI測試要健壯許多。不過，在有些情況下仍然希望通過UI測試，以確保特定的功能在合併前端和後端後仍然有效。

這裡還有一點需要說明，就是我們的驗收測試用例在DSL級別進行了有效的定義，而且不包含實現細節。這就是說，當我們後續調整驗收測試實現時，我們的驗收測試用例不需要修改。根據之前使用Test DSL定義的測試用例，我們可以很輕鬆地驗證調整後的產品功能和調整後的驗收測試用例實現。

DSL還有一個額外的好處，就是可以跨場景重用場景的部分實現。例如，如果DSL為場景的“When”子句定義了一種系統引導方法，同樣的實現通過不同的引數化就可以在其他場景中重用。這有助於提高測試程式碼重用，因此可以提升測試實現速度。

同時，這有助於驗收測試的功能隔離。這點很重要，因為功能隔離測試可以並行執行，互不干擾。這種並行有助於縮短測試反饋週期。

最後，可以在DSL中納入功能別名，那樣，當建立領域物件如Imaging Scanner時，就可以給它們附加UID，確保功能隔離，這樣就不必在測試程式碼中顯式指定UID。

驗收測試

Dave建議在構造驗收測試基礎設施時採用4層架構。這可以實現上文描述的抽象分層、關注點隔離。

如果沒有這種隔離，當要測試的系統發生變化時，上層功能測試就會變得脆弱。

這個4層模型是：

• 第一層 測試用例
• 第二層 DSL
• 第三層 協議介面卡
• 第四層 要測試的系統

使用抽象DSL編寫測試用例（第一層）獲取使用者意圖，而不是互動的技術細節，這些“可執行的規格說明書”仍然與要測試的系統保持非常鬆散的耦合關係。

第二層實現了DSL。共享許多測試用例通用的領域級概念，如AddScannerToHospital、 CalculateRadiationDoseByScan、DistributeScanProtocol。

第三層是一個“協議介面卡”的集合。這些介面卡把領域（DSL）概念轉換成與第四層——要測試的系統——的真實互動。

這使得測試用例編寫者可以完全專注於系統需要做“什麼”，而不是系統“如何”做。

從這裡你可以看到這種方法更詳細的介紹：ofollow,noindex" target="_blank">持續交付驗收測試——Dave Farley 。

使用“可執行規格說明書”指導TDD

在編寫好驗收測試後，我們預料到它會失敗！它在執行時變紅了，因為產品程式碼還沒有編寫。我們是有意這樣做的。我們希望採用“紅-->綠-->重構-->提交”的方式。首先實現測試。一旦執行，它就會因為缺少產品程式碼而變紅。

為了使測試通過，我們對產品程式碼做足夠的修改。一旦通過，它就綠了！在把變更提交到管道之前的最後一步是重構，把整個過程梳理一下。

然後，我們提交變更。“紅-->綠-->重構-->提交”是有好處的，因為它可以確保在測試程式碼和產品程式碼之間有一個很好的抽象。

我們僅為已經存在的測試編寫產品程式碼，測試可以告訴我們產品具體要做什麼。由於測試程式碼是優先編寫的，所以它生來就是與產品程式碼鬆耦合的。

這樣，我們就可以稍後更改產品程式碼，而不必更改大量的測試程式碼。這樣一來，開發人員就可以快速實現新的使用者故事。在“紅-->綠-->重構-->提交”工作方式中，不斷重構是這個過程不可或缺的部分。我們鼓勵開發人員在他們的工作中關注每一次提交的質量。

在編寫完驗收測試並變紅後，我們開始建立程式碼，滿足規格說明書。我們使用TDD編寫程式碼，因此，程式碼在兩個不同的層面進行測試。對於我們而言，這意味著我們需要首先編寫單元測試。再次經歷紅-綠-重構！這可以指導產品程式碼設計，讓我們可以專注於一個小功能。然後，我們根據單元測試告訴我們的東西編寫產品程式碼。一旦新的單元測試通過，我們就稍微重構一下，把單元測試和產品程式碼段一起提交到團隊管道（“紅-->綠-->重構-->提交”）。

結對程式設計

所有涉及程式設計的任務，如DSL、驗收測試、TDD、產品程式碼實現、管道，都是由開發人員結對完成的。

兩人的工作依據“駕駛員-領航員”的概念開展。駕駛員積極輸入程式碼，考慮所使用的程式語言的結構。領航員指導駕駛員該做什麼，他更多的是思考概念層面的東西。

兩個人會定期交換駕駛員-領航員角色。而且，一旦一個使用者故事的工作完成了，這對開發人員通常就會解散，加入團隊中的其他配對。這個過程保證團隊的程式碼所有權，團隊快速響應測試失敗的能力（因為許多人都可以修復測試），團隊適應摩擦而又不對生產力帶來較大影響的能力以及團隊快速高效地引入新成員的能力。

結對程式設計的價值

結對程式設計看上去是一種昂貴的方法，實際上它不是。它使團隊可以更快地產出高質量的成果[1][2][3]。

不過，即使沒有這些優勢，結對程式設計幫助團隊採用新方法、過程和技術的價值也是非常之大。

結對程式設計是一種非常強大工具，使團隊可以更快地學習，建立和強化團隊文化，使開發團隊可以在團隊內部嚴格執行必要的原則，提升質量，培育創新。

構建和部署管道

回到團隊管道：一旦提交到達管道，它會經歷5個階段：構建代理、接受1、接受2、過渡和生產。

在構建代理階段，我們執行在這個過程的TDD階段建立的所有單元測試，並運用針對專案定義的靜態程式碼分析規則。我們的目標是大約5分鐘的時間裡從這個階段的管道獲得反饋。5分鐘的週期很重要，因為這大概是一對開發人員可以稍事休息而不開始其他工作的時間段。如果反饋在5分鐘之內到來，那麼這對開發人員得保證精神集中於此次提交，以便可以立即修復失敗而不產生任務切換成本。任何單元測試失敗都會導致這個階段的管道變紅。變更被拒絕！

如果所有單元測試都通過了構建代理階段，我們就可以把特定團隊開發的這個產品部分部署到團隊管道的下一階段，即接受1。一旦部署，我們就為那個團隊執行所有的驗收測試。任何驗收測試失敗會再次導致變更被拒絕。這個階段的管道會變紅。

如果所有驗收測試都通過了接受1環境，我們就知道，團隊正在開發的這個產品部分可以獨立執行。為了確保產品的這個部分在依賴於其他團隊時仍然可以執行，我們引入另一個環境，即接受2。在接受2環境裡，我們部署來自接受1環境的產品部分及其對其他團隊的依賴。一旦部署，我們就在接受2環境裡執行一些驗收測試，實際測試整合點——契約整合測試。

我們期望，隨著團隊之間的契約變得日益穩固，我們將來可能可以去掉接受2環境。

我們希望接受1&接受2的反饋週期為大約1小時。這很重要，因為這使得這對開發人員每天可以執行多次提交，也就是說，如果在接受1或接受2環境裡出現了失敗，開發人員在這一天中還有多次機會來修復問題。修復完成後就可以重新提交變更，看著它一路綠燈通過接受2環境。

這個比較短的反饋週期使得結對的開發人員可以快速推進工作，快速失敗，使團隊獲得很高的速度。

關於1個小時的反饋週期，還有一點很重要，它鼓勵結對開發人員在測試失敗修復方面的良好行為，回到管道開始的地方，做一次新的提交，而不是修補環境，如接受1和接受2。

如果反饋週期比1小時長很多，比如6小時，開發人員就沒有選擇了，只能修補環境使測試通過，因為這比等著新的提交從管道起點到進入接受2環境要快（很可能要到下一個工作日了）。

短反饋週期的重要性

持續交付是一種確保軟體總是處於可釋出狀態的工作方式。

變更反饋傳遞給開發團隊的速度和團隊保持軟體執行的能力之間存在著密切的聯絡。

在持續交付中，任何測試失敗，我們就會拒絕變更。這就是說，任何測試失敗都意味著我們的軟體沒有處於“可釋出狀態”。如果我們希望執行持續釋出，我們就需要縮短反饋週期！

努力建立短反饋週期是一種推動團隊健康變革的極其有效的機制。

根據經驗，迭代工作，縮短從概念到可工作、可釋出的軟體之間的時間，你必須：

• 採用良好的團隊結構
• 提升自動化
• 提升模組化
• 改善自動化測試
• 消除手動瓶頸
• 改善需求過程
• 改進設計
• （其他許多好東西）

建立釋出候選

一旦接受2環境中的所有驗收測試都通過了，業務部門就可以決定向名為Cut的客戶驗收測試環境推送釋出候選。在這個環境中，被選中的客戶可以使用釋出候選，向開發團隊提供真實的反饋。再一次，由於接受1&接受2環境的反饋週期預計為1小時，所以Bug修復每天可以根據需要向過渡環境部署多次。

一旦釋出候選部署到Cut，就會對它應用生產級監控和預警，和應用到生產環境的一樣。

開發人員可以在Team Information Radiator上看著提交流經管道以及每個環境的當前狀態。Information Radiator上的紅色很容易吸引注意力，提示開發人員快速採取行動。

採用情況

teamplay的不同團隊採用我們這個持續交付模型的速度並不一樣。有的團隊在練習把TDD和結對作為日常工作模式。有的團隊把BDD運用到了經過選擇的特性上。這是一個漸進過程，不同的團隊以不同的速率採用不同的方法。有的團隊比較快，有的比較慢，這受許多技術和人為因素的影響。

幾乎所有團隊都採用了使用者故事地圖。我們有外部顧問和我們的產品經理結對，為即將到來的特性建立初始的使用者故事地圖。然後，我們讓其他所有團隊角色都參與到使用者故事地圖活動中，使他們熟悉這種方法。我們把便利貼粘在牆上做成離線使用者故事地圖，並使用合適的工具建立線上故事地圖。工具支援至關重要，因為我們的團隊在地理上是分散的。使用故事地圖不僅能共享對使用者旅途/目標的理解，而且事實證明，對制定釋出優先順序也非常有用，因為它使得優先順序決策更容易，使每個團隊成員都參與到這個過程。

有些團隊已經實現了一個團隊管道，而且正在優化不同環境的反饋週期。我們在團隊中鼓勵一種試驗和自測量的文化，推動人們越來越多地採用這種方法，直到它變成所有團隊面對所有新使用者故事時的常規工作方法。

為了試驗，有些團隊每兩週就會專門拿出一天來學習與工作相關的新東西。此外，所有的方法，如TDD

、BDD、結對、使用者故事地圖、DSL、驗收測試、紅-綠-重構-提交，最初都是被團隊拿來在非常小的範圍內試用，如在單個使用者故事中。當團隊在一個小範圍內獲得了對該方法的信任，看到了它的效果，如使用TDD實現了一個故事，他們就把方法的應用擴充套件到越來越多的故事。

不過，我們看到，看板和#NoEstimates很快就被大量採用。我們驚奇地發現，大部分團隊都從Scrum切換到了看板，從衝刺估計切換到了#NoEstimates，而且是由他們自己在被賦予選擇許可權後幾周之內完成的。

對於自測量，我們建立了一個供內部使用的CD成熟度模型，對於本文介紹的各種CD方法，團隊自我評估採用情況。團隊每月自評，事實證明，這有助於人們在頭腦中把預期的開發過程放在首位，每月一小步向著它迭代。

此外，我們向團隊提供了自動生成的儀表板，上面有衡量部署穩定性的CD指標。事實證明，以聚合方式檢視上述方法是否恰當應用併產生了穩定的部署是很有用的。在有些團隊中，可以使用這些指標指導CD轉型。

小結

我們還處在採用持續交付的起步階段，但是，到目前為止，所採取的步驟已經產生了經過證明的成果!例如，在一個團隊把TDD和結對運用到過去經常發現生產Bug的程式碼庫區域中的新特性時，我們可以交付那個特性而沒有任何生產Bug。

隨著持續交付的實現，我們希望成為一個試驗型組織。我們希望不再忙於交付充滿假設的計劃，相反，我們一直在生產環境中執行業務試驗，快速驗證假設。

這是指經常在生產環境中執行小試驗，從技術和產品的角度嘗試新想法，並把成功的試驗不斷地整合到產品中。

參考文獻

1. “360bdc1b.pdf" rel="nofollow,noindex" target="_blank">協作程式設計案例 ” Nosek 1998
2. “強化結對程式設計案例 ” Williams, Kessler, Cunningham & Jeffries 2000
3. “結對程式設計關乎業務連續性 ” Dave Hounslow

關於作者

Dave Farley是持續交付、DevOps和軟體開發領域的意見領袖。他是“震撼獎”獲獎著作《持續交付》一書的合著者，他常常在大會上做演講，他還是一名博主，同時也是反應式宣言的作者之一。Dave現在一名獨立的軟體開發人員和顧問，同時也是持續交付公司的建立者和負責人。你可以通過Twitter（@davefarley77 ）、部落格 或公司網站 聯絡他。     

Dr. Vladyslav Ukis 畢業於德國紐倫堡大學計算機科學系，後來是英國曼徹斯特大學。他每次畢業後都加入了Siemens Healthineers，一直致力於軟體架構、企業架構、創新管理、私有和公有云計算、團隊管理和工程管理等方面的工作。近年來，他一直在Siemens Healthineers數字生態系統平臺推動持續交付轉型，幫助一個大型的、分散式的、快速成長的開發團隊採用新的工作方法，調整架構，實現所需的文化變革，保證系統在整個開發過程中總是處於可釋出狀態，實現持續交付。

檢視英文原文：Adopting Continuous Delivery at teamplay, Siemens Healthineers