持續集成實踐之持續交付的五個核心實踐

　　原文發表于 InformIT

　　持續交付是一種軟件開發策略，用于優化軟件交付流程，以盡快得到高質量、有價值的軟件。這種方法讓你能更快地驗證業務想法，通過直接在用戶那里進行試驗，做到快速迭代。 盡管《持續交付》一書主要講的是工程實踐，但持續交付的概念對整個產品交付過程都有重大意義，包括對特性的”fuzzy front end”、設計和分析的意義。

　　持續交付的一般性原則如下：

　　與其設計一大堆特性，再策劃一個持續數月的版本發布，不如持續不斷地嘗試新想法，并獨立發布給用戶。通過充分思考，即便很大的特性或者大范圍的變更，也能夠通過一系列小步驟得到更快反饋，而且一旦你認為有必要停下來的話，可以隨時停下來。利用跨功能團隊在幾小時或幾天內交付這些小且增量式的功能，就能比競爭者有更多的創新，將投資回報最大化。

　　持續交付五個關鍵實踐，為你建立一個從猜測到持續反饋的最有效途徑，它們就是：

　　從最小可行產品(MVP)開始——Start with a minimum viable product.

　　衡量新特性的價值——Measure the value of your features.

　　做恰好充分的預先分析——Perform just enough analysis up front.

　　少做——Do less.

　　用戶故事中要包括特性開關——Include feature toggles in your stories.

　　Start with a Minimum Viable Product (MVP)

　　“假如你沒有因產品首發版本的寒酸而感到尷尬，就說明該產品的發布實在是太晚了。 ” Reid Hoffman, cofounder and chairman of LinkedIn (參見“建立大公司的十大創業原則”)

　　如果你的項目一啟動，就有一大堆需求文檔 放在項目經理的桌上，那你已經失敗了。精益創業運動的核心思想中，關鍵的一個就是最小可行性產品(minimum viable product, 縮寫為MVP)， 即為驗證你的業務猜想而需做出的最小工作量。

　　當然，在制造業，MVP的概念已經有數十年的歷史——它們被稱作原型(prototypes)。在使用原型時，你不必把你的MVP展示給全世界的所有人，只要選擇其中一組測試(beta)用戶就行了。甚至用一個尚無法工作的軟件都行——你可以創建一個pretotype，來收集信息，一行代碼也不必寫。

　　假如對受眾來說，第一個版本至關重要，你也完全可以向全范圍的用戶展示經過精心打造的更完美的產品。例如，某個公司用別的商標品牌發布了它的iPhone應用的一個MVP版本。只是為了得到具有統計意義的重要反饋，即它的業務規劃是否能成功。而次要目標是驗證一下該軟件的交付流程。

　　找到MVP如何運作至關重要的一點是，需要一個由業務人員和技術人員組成的跨功能團隊(cross-functional team)。這個團隊中的角色包括用戶體驗設計(User Experience Designer，UX)，分析、測試、開發、運營和基礎設施建設。當然，一個人可以承擔多個角色，所以也不是非要很多人，才能完成一件事。

　　由于一個小團隊在數周內(而不是一兩個月的時間里)就可以完成MVP，所以此時也不需要很多儀式，因為你不必象賭博一樣，押上整個公司，或一大筆錢。

　　Measure the Value of Your Features

　　“度量是產品的一部分” — John Allspaw， VP of Technical Operations, Etsy (參見“Building Resiliencein Web Development and Operations”).

　　精益創業中另一個核心概念是驗證性學習(validated learning)，即通過收集產品被真正使用后的衡量指標，而不是通過對用戶的提問來驗證效果。正是電視劇《Dr. Gregory House》中，他喜歡說的那樣，人們會說慌的——盡管更文雅一些，我們可以說他們不知道他們想要什么。把你的用戶當做是試驗對象，而不是那些聰明的代言人(intelligent agents)。

　　你要能回答下面這樣的問題：

　　我們在產品上所做的這些修改是否讓更多的人注冊了，逗留時間增加了，還是增加了收入? Or is it time to pivot?

　　在做A/B測試時，該特性在哪個版本的效果更好?

　　所有的系統指標看上去都不錯，一個用戶說我們的網站不能用。難道是我們的網站壞了嗎?

　　我們產品中的哪些特性是收入的最大來源?

　　你不必在Apache的日志中搜羅信息，也不必試圖從那些輔助功能上回溯，或利用定制化查詢，就應該能夠回答這些問題。這些問題應該看一眼儀表盤(Dashboard)就能知道，而且，這些信息應該是完全可審計的。

　　在Eric Rie的《精益創業》The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses(Crown Business, 2011)一書中，他提到了 Grockit 的故事:

　　遵循精益制造中的 kanban 原則， […]Grockit改變了產品優先級評估流程。在這個新流程中， 直到驗證性學習(validated learning)時，用戶故事才算完成。所以，一個用戶故事要經歷四個階段：在product backlog中，正在實現中，完成(從技術角度看特性是完成了)，以及驗證中。驗證被定義為：“第一時間知道某個用戶故事是不是一個好主意” 。這種驗證通常是以某種隔離測試來展示客戶行為的變化，當然也包括客戶訪談或問卷調查。

　　只有當度量項被放在用戶故事中一起完成時，這種學習方式才有可能。

　　看上去，這一原則可能是針對web應用的，事實上，對于嵌入式系統和用戶自行安裝的產品也是同樣道理。為了遠程調試和失敗報警的目的，以及理解用戶的使用模式，所有類型的系統需要收集這些度量項。

　　Perform Just Enough Analysis Up Front

　　“你要知道，當團隊在編碼之前試圖完成規格說明的收集時，你就不是在做迭代開發。” Bas Vodde, “History of Nokia Test.”

　　一旦你想到了一個點子，是一個最小可行產品(minimum viable product)，你就要開始交付軟件了。第一步是分析。但是backlog中所有的用戶故事不必被全面分析。因為那么做，這也是一種浪費。為了全面分析用戶故事，你要從客戶、開發人員、測試人員、用戶體驗設計和用戶那里得到信息。如果團隊在花大量時間去收集這些信息，那么他們的這些工作實際上還沒有交付有價值的功能，也無法從那些使用該系統的用戶中得到真正的反饋。

原文轉自：http://www.anti-gravitydesign.com