如何才能做到持續交付？(2)

　　此時，這個項目就進行了所謂的“兩難境地”，或叫“死亡行軍”，人們在很大的壓力上加班工作，試圖修復整個系統。這令每個人都極不滿意，而事實上， 在某些領域，這種失控模式已經成為一種家常便飯。

　　在那些實踐持續交付的項目中，開始時進展可能比較慢。因為項目一開始要建立基礎設施，對構建、測試和部署做自動化，并在得到成功構建的產品后，在類生產環境中執行驗收測試。這讓團隊成員，尤其是剛接觸它的管理者，感到不舒服。然而，這正說明它起作用了。持續交付的影響表現在它把痛苦提前了，從而讓交付過程更加平穩、真實且可度量。

　　你原來體會到的是“開發完成“，與“真正完成”不一樣?，F實中，真正的“完成”是指發布給用戶，或者至少在集成環境上嚴格地進行驗收和回歸測試后，在類生產環境中向客戶演示。在新功能開發完后，其實還有很多工作要做：交付過程中的這部分被叫做最后一哩。持續交付堅持認為：“只有過了這一哩”，工作才算完成，根本就沒有“完成了百分之五十”這個說法，所以，這讓整個交付進度看上去比較慢。​

　　然 而，通過持續交付，你能得到可持續性。首先，因為持續交付意味著軟件一直處于可發布狀態，所以可以把原來的測試與集成階段移掉，這就會大大降低項目風險。在這兩個階段，經常會發現嚴重問題，甚至是整個架構的缺陷。而修復這些問題的時間則很難預期。通過持續交付，這些問題在交付過程的早期就會被發現，些修復成本往往比較低。

　　​其次，對于新開發的特性來說，能更快地從客戶和用戶那里得到反饋。通過增量開發和持續發布給用戶，你能在特性創作過程中就得到早期反饋，并不斷調整。這樣，軟件的演進可以更快速地滿足用戶的需求。

　　設法進行增量開發

　　在主干上增量開發時，為了能夠將大的特性拆分成小的、有價值的、可測試且相對獨立的用戶故事，需要分析人員、測試人員及開發團隊的緊密合作。這么做，有幾個好處。

　　可能最重要的好處就是，它促使團隊將一個功能里，關鍵的部分和非關鍵部分區分開來，這讓客戶能在更小的粒度上做決策。將一個“必須做”的特性分解成多個小的、可增量開發的小需求，能更有效地區分出哪些是該功能的核心，哪些是外圍需求。

　　然后，你可以將功能的核心部分(最初的最直接的實現)給用戶進行測試，并找出用戶接下來想做什么。這樣可以給客戶一些具體的數據，讓他們更好地對該功能的剩余工作進行優先級的排序。當然，也很可能在他們看過以后，客戶希望將后續的時間花在其它功能上了。而且，假如客戶看過以后。認為這個特性沒有什么價值，你可以馬上停下來，不再浪費精力在這上面了。

　　增量開發依賴于每個人每天都能夠提交一次，這樣，應用程序才可以持續集成。對于那些習慣于在長生命周期分支上開發新特性或每個分支對應一類客戶的團隊來說，這看上去是不可能的。好消息是，在主干上開發是可行的，對于很大的團隊也是可行的。壞消息是，它要求應用程序由松耦合的組件構成，并有良好的架構。它還要求，可以通過配置項在UI上能控制特性的開與關，這樣，你才能可以靈活地控制，當功能準備好后，再打開開關。即使一些新功能只開發到一半，你也能持續地發布你的軟件。

　　然而，這樣做的收益也很大：你能持續不斷地把已經做好的功能交付給客戶，而不用絞盡腦汁地猜測哪個功能有價值。頻繁地發布有價值的新功能是提高收入的 最好方式。

　　我怎么知道我是不是真的在持續交付?

　　持續交付是否需要一個像“Nokia 測試”那樣的checklist呢?實際上，沒有那個必要，因為有一個非常簡單的方法來驗證，你是不是真的在持續交付：你的軟件是不是一直處于產品可發布狀態。你只要按個回車鍵就可以把 它發布給用戶。如果你的發布過程很痛苦，而且不太頻繁，并且在發布之前還有一個充滿風險的集成階段，那么你就沒有在做持續交付。

　　持續交付中最重要的度量是周期時間(cycle time)：從決定實現某個想法開始，到將其發布給用戶為止這段時間長度。有幾個原因讓它成為一個很重要的度量：

　　第一，這是一個全局度量指標，用于度量整個過程的有效性。

　　第二，這是一個團隊度量指標，而不是一個個人度量指標——只整個團隊關注于改進交付過程，才有可能改變周期時間。

　　部署流水線提供了部分答案：部署流水線的實現會給你提供一些你需要的數據，主要是從提交到發布這段時間的。那么，只要你有一種方式將提交與特性關聯起來，你就可以看到某個特性的周期時間。如果現在的工具不能讓你收集這些數據，那就找一個去吧。

　　這樣，你就可以制定一個持續改進流程，應用約束理念 ，或者使用看板，在交付過程中找到瓶頸，并想辦法移除它們。持續交付可以也應該同樣使用持續改進的方式減少成本，提高收入的增量地方式實現。

原文轉自：http://www.kjueaiud.com