原文發(fā)表于 InformIT

　　持續交付是一種軟件開(kāi)發(fā)策略，用于優(yōu)化軟件交付流程，以盡快得到高質(zhì)量、有價(jià)值的軟件。這種方法讓你能更快地驗證業(yè)務(wù)想法，通過(guò)直接在用戶(hù)那里進(jìn)行試驗，做到快速迭代。 盡管《持續交付》一書(shū)主要講的是工程實(shí)踐，但持續交付的概念對整個(gè)產(chǎn)品交付過(guò)程都有重大意義，包括對特性的”fuzzy front end”、設計和分析的意義。

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

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

　　持續交付五個(gè)關(guān)鍵實(shí)踐，為你建立一個(gè)從猜測到持續反饋的最有效途徑，它們就是：

　　從最小可行產(chǎn)品(MVP)開(kāi)始——Start with a minimum viable product.

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

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

　　少做——Do less.

　　用戶(hù)故事中要包括特性開(kāi)關(guān)——Include feature toggles in your stories.

　　Start with a Minimum Viable Product (MVP)

　　“假如你沒(méi)有因產(chǎn)品首發(fā)版本的寒酸而感到尷尬，就說(shuō)明該產(chǎn)品的發(fā)布實(shí)在是太晚了。 ” Reid Hoffman, cofounder and chairman of LinkedIn (參見(jiàn)“建立大公司的十大創(chuàng )業(yè)原則”)

　　如果你的項目一啟動(dòng)，就有一大堆需求文檔 放在項目經(jīng)理的桌上，那你已經(jīng)失敗了。精益創(chuàng )業(yè)運動(dòng)的核心思想中，關(guān)鍵的一個(gè)就是最小可行性產(chǎn)品(minimum viable product, 縮寫(xiě)為MVP)， 即為驗證你的業(yè)務(wù)猜想而需做出的最小工作量。

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

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

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

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

　　Measure the Value of Your Features

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

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

　　你要能回答下面這樣的問(wèn)題：

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

　　在做A/B測試時(shí)，該特性在哪個(gè)版本的效果更好?

　　所有的系統指標看上去都不錯，一個(gè)用戶(hù)說(shuō)我們的網(wǎng)站不能用。難道是我們的網(wǎng)站壞了嗎?

　　我們產(chǎn)品中的哪些特性是收入的最大來(lái)源?

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

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

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

　　只有當度量項被放在用戶(hù)故事中一起完成時(shí)，這種學(xué)習方式才有可能。

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

　　Perform Just Enough Analysis Up Front

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

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

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