敏捷產(chǎn)品開發(fā)，一百個人有一百種理解，敏捷本來就是一個集合性的名詞，講到敏捷大家可能會聯(lián)想到：scrum、xp、測試驅動開發(fā)、看板、持續(xù)集成、持續(xù)重構、技術卓越等等這些詞，還會聯(lián)想到與價值觀相關的部分，比如說：應對變化、自組織、適應性等等。

這樣講沒有問題，但這對我們理解敏捷真正的含義并沒有太多的作用。有一位軟件工程界的宗師級人物曾說過：“如果你過去問我支不支持敏捷，我可能說支持或不支持，并給個理由，現(xiàn)在只能說支持了，因為現(xiàn)在敏捷指的就是軟件開發(fā)中一切好的方面，如果有什么不好的東西那就表示不夠敏捷?！边@樣的說法對于敏捷的推廣或許有好處，但對真正理解敏捷和實施敏捷而言卻不然。

德魯克說：任何組織的績效都只在外部反應出來。外部就是給你帶來價值的地方，也就是用戶或者客戶。敏捷作為一種管理的手段或方法，存在的目的是幫助組織取得成效。其責任是協(xié)調資源取得成效。不管是方法或技術都是為了成效服務的。

想要理解敏捷，必須回到業(yè)務目標，這是根本。敏捷的對立面經(jīng)常是瀑布，上圖左邊就是一個瀑布模式，開發(fā)分成分階段：需求-設計-開發(fā)-測試，每個階段形成一個瀑布流，這種瀑布流的開發(fā)方式存在的問題是：價值交付只能是在最后。橫坐標代表時間線，就是在全部做好之后一次性交付價值。

一次性交付價值存在的問題：根據(jù)摩爾定律，每18個月之后用同樣的錢可以買到一倍的東西。反過來看， 18個月之后交付的話只能得到今天交付的一半的價值，越遲交付的是越少的價值，這是針對硬件產(chǎn)品來說的，對于軟件產(chǎn)品和互聯(lián)網(wǎng)時代做的產(chǎn)品而言影響更深，越遲交付的產(chǎn)品可能面世的機會都沒有，獲得超額利潤的機會也沒有。

面對在瀑布開發(fā)下延遲交付的情況，敏捷提出的解決方案很簡單：迭代。每一個迭代交付一部分價值，這部分價值因為交付得早就意味著更多的價值。敏捷的業(yè)務目標：更快（早）地交付價值。這里的快不是絕對速度與流量的更大，而是指交付的時間更早。

再來看敏捷開發(fā)的第二個業(yè)務目標。圖的左邊也是坐標圖，表示一個項目，橫坐標是時間，從項目開始到結束；縱坐標是團隊對這個項目或產(chǎn)品所擁有的知識和了解。 什么時候團隊對于項目的知識和了解最豐富？顯然是結束的時候。另外一個有意思的問題是 什么時候做出對項目最重要的決策呢？開始的時候。

也就是說我們往往在知識最匱乏、了解最不夠的時候做出最重要的決策，并把這個決策當成事實來對待，后面發(fā)生的事情很難反映到項目中去，知識的累積也很難反映到項目中去。這是知識累積和決策時機之間的悖論。

敏捷應對這個悖論的方法是：決策是增量做出來的，每個迭代做出一部分決策，交付一部分產(chǎn)品，得到相應反饋，并根據(jù)反饋再做下一個迭代的決策，不斷獲取反饋應對變化，這個反饋可能是交付之后的，也可能是市場或競爭對手的變化帶來的。

敏捷的第二個業(yè)務目標：更靈活的響應變化。也就是說通過增量出決策，不斷交付獲取反饋，積累更多知識，并應用這些知識做出更正確的決策，更靈活響應變化，這個變化包括主動的知識積累，也包括市場的變化、競爭對手的變化、團隊對項目的了解。

綜上所述，可以從業(yè)務角度對敏捷做一個解釋：敏捷就是敏捷

（able to move quickly and easily）。

對于產(chǎn)品開發(fā)而言，敏捷的目標是：創(chuàng)建一個組織更早地交付價值，更靈活的應對變化的能力。敏捷對于業(yè)務層面來說是一個目標，對于一個組織來說是一種能力，這種能力是必備的，幫助我們在今天的市場和業(yè)務環(huán)境下取得成功。

當我們清楚了敏捷是一種目標一種能力的時候，我們對敏捷的理解就能達成共識：我們需不需要這種能力？這是不是我們的目標？這對于我們取得競爭的勝利有沒有必要？而在今天這個競爭的業(yè)態(tài)，敏捷是一種組織必須具備的基本能力。所以我們需要討論的是如何具備這種能力，如何變得更敏捷。下面會講一些方法和實踐，都是為這個目標服務的。

為了實現(xiàn)敏捷的業(yè)務目標，我們需要迭代和持續(xù)交付。這為我們帶來的新的挑戰(zhàn)是過去傳統(tǒng)的方法不適用了。隨著更多問題的提出，也相應地產(chǎn)生了一系列方法和實踐：

• 比如怎么管理迭代交付的過程呢？于是就有了scrum、FDD、測試驅動開發(fā)、XP（極限編程）的管理實踐和框架來幫助我們管理迭代開發(fā)的過程，這些實踐都是為目標服務的；

• 每個迭代交付什么，怎么規(guī)劃？于是就有了產(chǎn)品代辦列表、用戶故事、故事地圖等實踐。

• 每個迭代都交付一些，那么測試工作量或回歸工作量會不斷遞增，怎么應對不斷增大的集成和回歸測試工作？于是就有了測試驅動開發(fā)、自動化測試、TDD；

• 如何溝通需求，于是就有了行為驅動開發(fā)、實例化需求等方法；

• 如何保證代碼的演進或演進式的迭代，于是就有了代碼共有、簡單設計、持續(xù)重構、領域驅動設計、演進式設計等方法。

業(yè)務目標是why，為什么要這么做。這些方法都是服務于業(yè)務目標，解決了how的問題。其實大部分時候這是必然的選擇，必須實現(xiàn)這個目標，在這個前提下再來想怎么做。當然這并不容易，不是這些實踐的簡單累加就會敏捷了，還需要系統(tǒng)地形成方法。

最近兩三年的時間，精益這個詞變得非常熱門，凡提敏捷處必有精益，好像不提精益感覺就不酷似的。我們先看精益產(chǎn)品開發(fā)是什么？

上圖我們稱之為waterfall，我們都知道waterfall不好，它不能應對變化、延遲了價值交付，那要怎么辦？

現(xiàn)實的第一個挑戰(zhàn)：開發(fā)環(huán)節(jié)的迭代并不帶來真正的價值交付和真實反饋。

我們需要引入迭代開發(fā)，比如scrum、xp。圖中的waterfall是從需求開始到測試結束，但是現(xiàn)實中可能不一定是，現(xiàn)實中在需求之前可能還有產(chǎn)品規(guī)劃、產(chǎn)品定義，可能還有更早的一些探索，測試之后還有實施、驗證、調整等，這時候我們發(fā)現(xiàn)在更大范圍來講其實還是一個waterfall，如上圖所示，只不過在開發(fā)階段實現(xiàn)了所謂的迭代，但并不能真正實現(xiàn)迭代的價值交付。

我們把這種模式稱之為：water-scrum-fall，我們理想的目標是通過迭代更早地交付價值、更靈活的應對變化，但事實上僅僅是開發(fā)環(huán)節(jié)或者工程團隊環(huán)節(jié)的迭代，并不能帶來真正的價值交付，也不能得到真正真實的反饋，那么我們需要做得更多，需要更加端到端。

現(xiàn)實帶來的第二個挑戰(zhàn)：單個團隊的實施也無法交付完整的用戶價值。

在大的電信公司，比如華為，去做這個事情的時候會發(fā)現(xiàn)，為了交付一個價值需要多個團隊，華為稱為多個網(wǎng)元，不同的網(wǎng)絡設備，每個設備都可能涉及到幾百人上千人，這時每個設備下面可能會分成不同的功能團隊、或者叫特性團隊、模塊團隊。整個需求是分層的，在華為解決方案層面對應的需求是客戶的原始需求；網(wǎng)元層面對應的是功能性需求；模塊層面對應的是可分配需求，這時你會發(fā)現(xiàn)單個模塊團隊去敏捷不可能端到端，無法交付完整的價值，也無法得到反饋，所以我們?yōu)榱烁绲亟桓秲r值，其實就需要協(xié)調多個團隊。

總結起來就看到了理想和現(xiàn)實的差距：理想是更快地交付價值，更靈活地應對變化；現(xiàn)實是：在開發(fā)階段或者在團隊實現(xiàn)階段去做敏捷，或做單個團隊的敏捷，往往不能帶來價值的完整交付和靈活應對變化，這是很多團隊面臨的挑戰(zhàn)。

精益是解決這一類問題的方法，精益作為一個思想比敏捷產(chǎn)品開發(fā)誕生得更早，遇到這樣的問題可以訴諸于精益。那么精益是什么？維基百科上對精益的定義是：精益思想是關于有效組織人類活動的一個新的思維方法，目標是消除浪費，更多地交付對個人和社會有用的價值。概括為兩個核心點：消除浪費、增加價值。

針對產(chǎn)品開發(fā)來說是順暢、高質量地交付真正的價值。

怎么去實現(xiàn)呢？精益真正區(qū)別于其他的方法并不是它的目標更好，而是它有與這個目標相適應的一整套方法學和實踐，接下來要說的是如何實現(xiàn)順暢和高質量地交付價值。

上圖是精益產(chǎn)品開發(fā)里一個比較核心的概念圖，說的是我們對待效率的不同態(tài)度。很多改進一定程度上都是在提高效率。我們把效率分成流動效率和資源效率：

資源效率是資源的使用率和產(chǎn)出，比如工程師的產(chǎn)出、每個設備的產(chǎn)出，資源產(chǎn)出越高效率越高，這是資源效率；

流動效率是從用戶的角度去看，一個用戶的需求從提出到交付整個流動的速度，從提出到交付流動的時間，流動速度越快效率越高。

上圖的四象限：

• 左下是一人干活十人圍觀，其資源效率和流動效率當然都是很低的；

• 右下是消防員，其實消防員的流動效率是很高的，一旦用戶提出需求，他可以在第一時間響應，一點都沒有等待，但他的資源效率很低，大部分時間都處于待命；

• 左上是煉鋼爐，煉鋼爐的情況是它一旦開啟后面的東西必須配合排隊，因為煉鋼爐的耗費是很大的，必須保證他資源的利用率，而待加工的物料（用戶價值）則在后面排隊；

• 右上是快遞公司，快遞公司對資源效率的要求是很高的，因為關系到成本，對流動效率的要求同樣也很高，因為這關系到對用戶的服務。

對于產(chǎn)品開發(fā)來說，我們希望效率跟快遞公司類似，也就是說資源產(chǎn)出要高，對用戶的響應速度要快，用戶的需求從進去到出來的時間要短，絕對速度要高。如何達到這一點是我們真正要關注的地方。

在傳統(tǒng)的方法里，我們都會更注重資源效率，這是有原因的，我們改進的的時候會改進開發(fā)的效率、改進需求產(chǎn)出的效率、改進測試的效率，因為對于我們的管理方式來說，我們看到的就是一個個職能部門，而這種效率的改進到最后往往都是起不到效果的，因為簡單的改進你都會做到，剩下的局部優(yōu)化往往會影響到系統(tǒng)的性能，即整個的有效產(chǎn)出。這就會產(chǎn)生一個個的效率豎井，設計開發(fā)運維，一個個看上去效率都很高，但是事實上有效地價值流動卻不能產(chǎn)生，系統(tǒng)并不是最優(yōu)化的。

我們習慣聚焦于資源效率，宏觀地來看在整個開發(fā)過程中開發(fā)和運維這兩個大部門其實也是在關注各自的資源效率，然而很多時候這種效率的提升是沒有用的，局部優(yōu)化帶來系統(tǒng)的劣化，這是一個非常普遍的情況，所以僅僅聚焦于資源效率產(chǎn)生的是效率豎井，精益產(chǎn)品開發(fā)對此提出來不同的看法。

如圖所示，如果我們沿著資源效率的改進繼續(xù)下去，會發(fā)現(xiàn)過度的局部優(yōu)化損害的是整體的效率，并帶來全局協(xié)調的困局。也就是說你看上去提高了資源效率，但最后它由于整體協(xié)調的困局，資源效率的改進也是無以為繼的，這種情況特別普遍，對于很多一直在做效率改進的部門，如果一直沿著這條路走下去，各個部門單獨改進，最后流程變得原來越來越復雜臃腫，整體效率很難提升。

我們熱衷于改進資源效率，因為我們每天都能看到資源效率，而流動效率則不然，用戶需求從進去到出去這個過程是看不見的，我們看到的是誰忙不忙，一天能產(chǎn)出多少代碼，因此我們更傾向于去改進看得到的東西，這是很正常的。

上圖中一個醉漢在路上尋摸了差不多半個小時，警察一直在旁邊看著，實在看不下去了就問醉漢在干什么。醉漢說我在找我的鑰匙。警察看了一下說這兒沒有鑰匙。然后又找了一會兒說：你鑰匙是丟在這兒了嗎？醉漢說：不是呀。警察又問那你為什么在這兒找呢？你知道醉漢怎么回答的嗎？醉漢說：只有這兒有光啊。

資源效率是我們能看到的地方，卻不是關鍵（Key）所在。我覺得這個隱喻很精確。

有一個精益產(chǎn)品的大師說：在產(chǎn)品開發(fā)中，我們的問題幾乎從來不是停滯的資源（或不動的工程師），而是停滯的產(chǎn)品需求（用戶價值）。但這個問題是很難看到的，那么我們在精益產(chǎn)品開發(fā)中怎么來處理這個問題，其實就有了答案，首先得看到需求流動的過程，看到了才能去改變。

第一步：理清價值流，約束在制品數(shù)，改善流動效率

精益產(chǎn)品開發(fā)的第一步是：提高流動效率。讓用戶的需求批量降低，并減少排隊和擁堵，讓它在整個研發(fā)過程中順暢地流動起來，從進去到出來的過程時間盡量短，等待盡量少。

我們首先要做的事情是以用戶價值為核心，打通整個組織的價值交付鏈條。就是要去分析這個價值流，然后識別和消除那些明顯不合理的部分，讓從用戶的問題到解決方案的過程越短越好，這就是改進流動效率的第一步。

要做到可視化，要分析和可視化端到端的價值流動過程。質量管理之父戴明說過一句話：如果你不能以一個清晰的過程來展示你所從事的工作，你就不會真正地了解你在做什么。產(chǎn)品開發(fā)所從事的工作就是交付用戶價值，從用戶問題出發(fā)到交付解決方案。

我們做的就是要可視化端到端的價值流動過程。

工具：看板

看一個團隊的看板，這是一個端到端的交付過程，藍色的紙條從需求提出到設計到向開發(fā)團隊澄清然后是就緒，就緒后我們稱之為用戶故事，這里的就緒是指對開發(fā)團隊就緒了，開發(fā)知道驗收標準了，相應的技術風險也分析了，之后一大段是實現(xiàn)中，這個實現(xiàn)中被劃分成很多橫向的條，這些條被稱之為泳道，每個泳道里是一個需求（白色的紙條），后面的藍色和黃色紙條是這個需求對應的任務，任務里分屬不同的列和模塊。

當所有的任務結束后，這個故事就可以拿到驗證、待驗證、待驗收、已交付，流經(jīng)整個過程?！毒娈a(chǎn)品開發(fā)原則、方法與實施》一書對此有詳細的介紹。

從這幅圖可以看到，這是一個端到端的交付過程，最前面一段是產(chǎn)品，最后一段去驗收交付的也是產(chǎn)品，中間一段是研發(fā)的過程，這是一個2B的產(chǎn)品，無法讓用戶直接參與，所以產(chǎn)品代表用戶去發(fā)布和接收需求，一定程度上是從用戶開始到用戶結束的一個端到端的價值流動過程，我們也看到研發(fā)即所謂的實現(xiàn)階段，反映了團隊的協(xié)作，不同的模塊團隊協(xié)作去交付這個故事，也看到了需求分解和合并，需求分解成任務，任務完成后再合并成需求去測試。

右邊需求上貼著紅色紙條是bug或問題，表現(xiàn)缺陷、問題和阻礙。

這個看板清晰地反映了三個方面：需求的交付過程、各個團隊的協(xié)作怎么去交付一個需求、需求的分解和合并。

這里能看到需求的流動，比如泳道數(shù)是有限的，團隊并行開發(fā)的需求數(shù)目是有限的，這個有限有一個好處：我們要盡快地完成那些已經(jīng)開始的需求，如果泳道滿了，你也不應該開始更多的需求。也就是盡快交付已經(jīng)開始的價值。如果這個交付過程中間有問題，因為泳道數(shù)量有限，很快能看到擁堵，問題也會及時暴露出來，及時解決。所以更加注重需求的完成，而不是需求的開始，也就是說我們是以價值交付來驅動整個過程的。

除此之外，我們還應該看到它反映的流動過程，及其背后的規(guī)則，比如一個需求從一個階段進入到另一個階段需要滿足怎樣的規(guī)則。上圖給出了兩個規(guī)則示例，所有進入就緒的故事必須滿足：

• 必須完成實例化需求活動，開發(fā)、測試和業(yè)務共同澄清需求，并定義明確交互過程和驗收標準；

• 大需求已拆分為工作量在兩周以內的故事；

• 已與業(yè)務關聯(lián)方確認相關計劃；

• 識別大的技術風險并定義應對方案；

• 需求已經(jīng)入庫；

• 涉及三個（含三個）開發(fā)人員以上的需求，執(zhí)行好協(xié)調人，負責進度協(xié)調。

所有移交測試的需求需要滿足：

• 并入正式的版本，并通過持續(xù)集成環(huán)境的檢驗

• 開發(fā)對照實例化過程中的驗收標準進行了自測。

其實這些流動過程加上規(guī)則就構成了團隊是如何操作這些需求的，也就是戴明所說的我們以一個清晰的過程來展示我們所從事的工作。

這樣一塊看板

• 清晰全面地反映需求和需求交付的過程；

• 瓶頸和問題能在看板上得到即時體現(xiàn)；

• 團隊可以根據(jù)看板信息協(xié)作和做決定。

但這只是一個基礎，它分析了價值流，也可能會對價值流做適當?shù)膬?yōu)化，但是我們還需要基于這個基礎對價值流做一些管理，讓其順暢流動，這是下一步要解決的問題。

第二步：有效地提高資源效率

我們最終要實現(xiàn)的是資源效率和流動效率的同步提高。但我們必須從流動效率提高，才能保證全局的協(xié)調，就是整個價值交付鏈的協(xié)調，涉及到需求、開發(fā)、業(yè)務，測試，如果從流動效率開始的話就能保證他們的協(xié)調一致，然后再以此為基礎進行資源效率的改進，這時候的改進才可以為繼，否則如果從資源效率開始就會陷入?yún)f(xié)調的困局。所以效率改進的第二步是：在流動效率保證的基礎上有效地提高資源效率。

工具：實例化需求

看板記錄了價值流，在此基礎上我們要去管理價值流，比如一個需求怎么進入就緒，需求的分析過程這里不詳細展開，通過實例化需求分析和澄清需求，或拆分需求，實例化需求是分解需求的很好的方式。

工具：站會

流動過程中看板反應了問題和瓶頸，怎么通過站會來促進價值流動？站會不是檢查每天的工作的，而是促進價值流動的。標準的Scrum站會更多的是陳述每個人的工作，是以做什么優(yōu)先，看板的站會是以價值流動優(yōu)先的，關注流動，解決流動中的問題，所以一般效率會高很多。

前文講的只是兩個例子，怎么去管理價值的流動，主要是價值的輸入，比如需求填充的過程、就緒隊列的過程、價值流動過程的管理，還有輸出，發(fā)布部署等，都是為了促進價值的順暢流動。

現(xiàn)實是做了流動管理后，價值的流動過程還會有這樣那樣的問題，比如質量、進度、協(xié)調的問題，這時候怎么辦？

為了分析和看到這些問題，就會引入精益的反饋和度量方法，在這里也不詳細介紹。每個方法都會對應自己的度量，精益的度量有其獨到之處：以價值流動為核心的，比如累積流圖，是比較精確地再現(xiàn)了價值流動的過程、團隊協(xié)作的過程，從而發(fā)現(xiàn)并衡量這些問題。

持續(xù)改進是精益產(chǎn)品開發(fā)的一個核心，也是精益思想的一個核心，通過持續(xù)改進來實現(xiàn)價值的順暢流動，通過各種度量來反應問題，支持這種持續(xù)改進，所以精益在這方面是有其獨到之處的。

在這里我們講的是，通過反饋來收集定性和定量的反饋，并定期分析這些反饋，然后落實為具體的行動，比如流程操作，而這種操作會反應到看板和背后的規(guī)則上去，也有可能是其他方面，比如基礎環(huán)境、代碼設計、測試守護、人員能力，具體行動改進落實后再通過反饋看改進的效果，我稱之為反饋、分析、改進的循環(huán)。有點類似于戴明的PDCA。

和PDCA相比少了一個計劃的過程，在精益產(chǎn)品開發(fā)中是把持續(xù)改進內建到產(chǎn)品開發(fā)過程中，所以沒有單獨的計劃過程，反饋、分析、改進是一個持續(xù)的內建的過程，內建到開發(fā)和交付的過程中，其結果是反而比較容易落實。

第三步：提升效率邊界

第三步是說效率是有邊界的，不可能資源效率和流動效率同時達到100%，前面圖片中消防員為了達到自己的流動效率，其實是犧牲了資源效率的，為了能及時響應火情，大部分時間是待命的，但產(chǎn)品開發(fā)希望兩點都比較高，最好是能接近于理想值。所以怎么能突破這個平衡點是我們又一個要考慮的問題。《精益產(chǎn)品開發(fā)原則、方法與實施》一書對此有詳細的介紹，時間關系就不多說了。 

精益產(chǎn)品開發(fā)的改進其實是從流動效率開始的，首先要可視化端到端的交付過程，然后管理好價值的流動，在管理好價值流動的情況下，再去發(fā)現(xiàn)這些問題，提高資源效率，我們希望保障全局的協(xié)調，這是以用戶價值為核心的改進。怎么讓它端到端的打通保證產(chǎn)品價值的交付，并做到真正交付有效的價值。這是精益思想的獨到之處，

第二步也講了，最終我們還是要改進產(chǎn)出效率，但是必須是基于可持續(xù)的改進，全局的改進，在全局協(xié)調、用戶價值順暢流動的基礎上，再去改進和保證流動的速度更高。

我們看到精益看板方法的實踐體系，正式在落實上面所說的思想和方法。

精益看板方法的五個實踐：

第一：可視化價值流動，根據(jù)團隊情況建模設計一個看板；

第二：顯式化流程規(guī)則，有了一個看板流動過程，它的規(guī)則是什么，通過這個規(guī)則，團隊怎么能夠更好地組織和決策；

第三：控制在制品數(shù)量， 前兩步實施好了這是一個很自然的結果；

第四：管理價值流動，包括輸入輸出和中間過程；

第五：建立反饋，持續(xù)改進。

這里是一個概貌，具體的內容就不詳述了，有興趣可以看書。

敏捷產(chǎn)品開始是為了更快的交付價值，更靈活的應對變化，而在現(xiàn)實中卻會碰到這樣那樣的問題，精益產(chǎn)品開發(fā)是幫助我們變得更敏捷的一個方法。除此之外還有另一個重要的方面，怎么保證端到端地順暢地交付高質量的價值，這是精益產(chǎn)品開發(fā)要解決的問題，這比敏捷“更靈活應對變化”要求更高一點，而且如果你的交付過程是順暢的，你自然就應該是敏捷的，當然精益產(chǎn)品開發(fā)更重要的還是第二點：交付的價值是有用的，能保證業(yè)務的成功。

就是說如果你交付的價值是沒用的，不能保證業(yè)務的成功，那這種交付是沒有用的。敏捷開發(fā)對此的答案是我們要應對變化，如果市場變化了我們跟著變，但其實在今天看來這是有一些被動的。它做了一個假設，這個假設是：有人會告訴我該怎么變，但事實上不是，用戶不會告訴你他需要什么，用戶的選擇太多了，他只會選擇能夠滿足他的，甚至于能夠引導他的，所以如何交付有用的價值，是接下來要講的精益產(chǎn)品開發(fā)和精益創(chuàng)新要解決的問題。

這幅圖是招商銀行的案例，招商銀行在順暢、高質量交付價值方面是國內企業(yè)中做得很典范的，它的看板是一個真正的端到端反應價值交付和團隊協(xié)作的看板。

我們要回答的問題是：除了順暢、高質量地交付價值，還需要什么？

這個問題的答案很明確：順暢交付是前提，但交付有用的價值才是根本。

那么，什么才是有用的價值？

我們面臨的環(huán)境，引用一個最近很熱門的詞“烏卡時代”，就是說我們現(xiàn)在的時代是易變的、不確定的、復雜的、模糊的，產(chǎn)品開發(fā)生存的環(huán)境越來越困難，我們也不知道面對的需求是什么，客戶告訴你的明天就可能會發(fā)生變化。

這個時代的另一個特征是：選擇權已從生產(chǎn)者轉移到消費者一側，我們早已告別了稀缺時代，用戶的選擇太多了，我們稱之為選擇的暴力。選擇權在用戶手中，過去我們將我們的產(chǎn)品創(chuàng)新要能跟得上鼠標點擊的速度，今天鼠標也不用點了，用戶用手中的手機隨時做出選擇，而且更可能是無視。帶來的直接變化是你做的東西用戶不一定會用，用戶不用就是浪費，精益就是要增加價值和消除浪費，但產(chǎn)品開發(fā)中，乃至整個創(chuàng)業(yè)和創(chuàng)新過程中最大的浪費是：交付用戶不在乎的東西。

總之，烏卡時代變化太快，越來越難把握，選擇權轉移到用戶手中，我們需要新的創(chuàng)新和產(chǎn)品開發(fā)模式，來做出一個用戶在乎的會去用的東西。

這時就引入精益創(chuàng)業(yè)的概念。和傳統(tǒng)的有規(guī)模的企業(yè)去講精益創(chuàng)業(yè)可能會有一些敏感，要鼓勵我們去創(chuàng)業(yè)嗎？其實不是，精益創(chuàng)業(yè)概念的提出者定義了“創(chuàng)業(yè)”的意思：在高度不確定的情況下開創(chuàng)一個新的產(chǎn)品或服務。所以即使在傳統(tǒng)的大規(guī)模企業(yè)中開創(chuàng)一個新的產(chǎn)品，如果它具有不確定性，需求不確定、用戶不確定、問題不確定、方案不確定，那就需要精益創(chuàng)業(yè)的方法，來做出一個用戶要的東西。

這是對精益創(chuàng)業(yè)的定義， 并不是說一定要是一個創(chuàng)業(yè)公司，而是在一個不確定的情況下做一個新東西。創(chuàng)業(yè)過程中最大的浪費是：構建沒人在乎的東西。

精益創(chuàng)業(yè)的目標是做一個能賣出去的產(chǎn)品，而不是賣一個能做出來的東西。就是說因為選擇權轉移了，不是做一個東西就一定能賣出去的，所以做一個能賣出去的產(chǎn)品是精益創(chuàng)業(yè)的目標。

那么怎么做到這一點呢？在這幅圖里我們看到，我們以為成功的過程是這樣的一條直線，事實上成功是一個不斷探索的過程，必須要承認這一點。

如果你制定一個計劃去執(zhí)行并希望它一定成功，泰森對此的評價是：每個人都有一套計劃，直到一拳打在他的嘴上。所以今天創(chuàng)業(yè)者如果還抱著這樣的思路，必然的結果就是這樣的。你幾乎找不到一個沒有在過程中調整自己方向的成功的創(chuàng)業(yè)產(chǎn)品。

精益創(chuàng)業(yè)其實是一個科學的思維，上圖是偉大的庫克船長探索太平洋的過程。

精益創(chuàng)業(yè)的過程是從承認自己的無知開始，今天一個偉大的想法越來越不那么重要了，至少它不能保證成功。

上圖展示的是兩幅地圖，左邊是1459年歐洲人的世界地圖，那時候的人相對現(xiàn)在來說是無知的，但是他們的地圖反而更詳細，世界所有的地方都根據(jù)他們想象的樣子畫出來，認為世界就是這樣。而另一幅地圖是1525年，哥倫布剛剛發(fā)現(xiàn)新大陸，這時候的地圖出現(xiàn)大量留白，這就鼓勵我們去探索。所以說承認自己無知，才能激發(fā)求知欲，去發(fā)現(xiàn)去探索。科學的革命本質上也是一場無知的革命，是從承認自己的無知開始的，之后才有了后面科學的發(fā)展。

跟承認自己的無知相對應的是先知的封印，這是一個宗教用語，先知知道一切。為什么我對這個詞有特別深刻的印象呢？我和一些創(chuàng)業(yè)團隊或者一些公司里的創(chuàng)業(yè)項目接觸，發(fā)現(xiàn)最大的障礙是先知的封印，就是說我定義了這個方向，你們團隊去執(zhí)行就行了，這樣的結果幾乎都是失敗的。真正的成功需要團隊一起去探索去調整。所以要想成功，我們首先要承認自己的無知，以觀察、實驗、數(shù)據(jù)為基礎，去調整建立新的能力，這是科學革命的態(tài)度，產(chǎn)品開發(fā)產(chǎn)品探索也需要科學的方法，這已經(jīng)在科學界和工程界被一再證明了。

精益創(chuàng)業(yè)的核心：開發(fā)測量認知的循環(huán)和經(jīng)實證的認知

精益創(chuàng)業(yè)的核心概念是：我們有一個概念，但它是被看做一個猜想或設想，根據(jù)這個設想開發(fā)一個產(chǎn)品，測量它，得到數(shù)據(jù)，通過數(shù)據(jù)建立認知，判斷這個想法靠不靠譜、可不可行，接下來調整想法，如此往復，我們稱之為開發(fā)測量和認知的循環(huán)，通過這個循環(huán)建立一個經(jīng)實證的認知，經(jīng)實證的認知是對應于初始的概念，初始的概念只是一個概念、假設，被驗證了以后才能成為認知。

這個循環(huán)包含了一個順時針的驗證的環(huán)和一個逆時針的計劃的環(huán)，逆時針的環(huán)是有了一個想法，我們對它的態(tài)度是：首先要想拿到什么樣數(shù)據(jù)來證明這個想法是可行的，而為了拿到這個數(shù)據(jù)，我們需要做一個什么樣的產(chǎn)品。然后再進入執(zhí)行的循環(huán)。

這幅圖更形象地說明了從一個想法開始，經(jīng)過開發(fā)、測量、認知循環(huán)，然后分析數(shù)據(jù)，如此往復，建立起一個可靠的商業(yè)模式。

如何實施精益創(chuàng)業(yè)和創(chuàng)新的實踐，問題是從哪里開始？

關于從哪里開始，我們首先要知道的是：我們的創(chuàng)業(yè)團隊或者創(chuàng)新團隊的目標是什么。這個目標不是這兒有一堆需求我們要把它做完，這不叫創(chuàng)新。我們的目標是探索出一個可重復和可規(guī)模化的商業(yè)模式，我們交付的不僅僅是產(chǎn)品，而是一個商業(yè)模式。

完整的商業(yè)模式才能保障能賣出去，可規(guī)?；?，而僅僅是能做出來。

商業(yè)模式是關于一個組織如何創(chuàng)造、交付和獲取價值的完整故事。其中兩個最重要的方面：產(chǎn)品和市場。產(chǎn)品包括：定位是什么，解決什么問題，用什么方案，需要什么樣的成本、結構；市場包括：渠道、定價方式、運營等。

刻畫商業(yè)模式

所以要做一個創(chuàng)新的過程，要知道初始的商業(yè)模式是什么樣的，這個商業(yè)模式不一定合理，但是我們要把它刻畫出來、描述出來，要從這個初始的商業(yè)模式開始探索最后交付一個可行的商業(yè)模式，包括產(chǎn)品和市場。

這個實踐叫精益畫布，就是用一頁紙刻畫你的商業(yè)模式，它有很多相互關聯(lián)的模塊構成，比如說客戶定位、客戶問題、解決方案、渠道、成本等。畫布左邊的模塊是和產(chǎn)品相關的，右邊的與市場相關。產(chǎn)品帶來成本，市場帶來收入，我們怎么保證成本和收入達到平衡。除了精益畫布以外，還有很多其他的方法來刻畫商業(yè)模式，比如價值定位地圖、商業(yè)畫布等。

分析風險

刻畫商業(yè)模式之后還要識別各種風險，市場風險、產(chǎn)品風險、客戶風險等。所有的風險或者假設都必須被驗證和解決了，這個商業(yè)模式才能成立，這個過程就是證明商業(yè)模式的可行，當然也包括商業(yè)模式的調整。

我們首先得有plan A,有了 plan A以后，識別它的風險，然后有計劃地去驗證這些風險，最后形成可行的商業(yè)模式，如圖橫向的是一個個的方案，有些方案在初始的階段就會被否定掉，有些是因為識別到的風險而被否定，最終要交付的是一個可行的商業(yè)模式。

但是，產(chǎn)品創(chuàng)新的過程不可能是看著商業(yè)模式來做的，有時候精益畫布被過度神話了。產(chǎn)品創(chuàng)新和開發(fā)過程需要進入更細的粒度。我們產(chǎn)品創(chuàng)新的過程，必須要去衡量創(chuàng)新和交付的進度是什么樣的，這是精益創(chuàng)業(yè)一個很重要的話題。

我們必須要有數(shù)據(jù)才能衡量進展，比如概念，每個人都覺得自己的概念好，那我們怎么衡量這個概念是好的還是壞的；測量，測量什么？怎么測量？認知，要建立認知，沒有數(shù)據(jù)就沒有認知。

我們的問題是要去定量衡量創(chuàng)新的過程，而過去常用的方法并不可行。比如基于功能交付的進度無法衡量創(chuàng)新的進展；比如我們用過去運營的指標——用戶數(shù)、收入來衡量產(chǎn)品的創(chuàng)新過程也是不適用的，因為整個創(chuàng)新過程中對用戶數(shù)可能只需要一個很低的數(shù)值，一小部分人被真正滿足了就可以，如果一味地追求用戶數(shù)和收入，往往會帶到一些虛榮的指標當中去，我們需要一個不一樣的指標來衡量創(chuàng)新的進展。稱之為：創(chuàng)新會計，或創(chuàng)新核算。

比如著名的海盜模型。它是關于業(yè)務指標的，但對于指導創(chuàng)新仍然不夠用。

在這幅圖中我們需要看到商業(yè)模式是怎樣運行的：用戶是怎么進去的，進去后怎么激活的，激活后怎么留住的，留住后怎么產(chǎn)生銷售的，一個老用戶怎么給我們帶來新用戶的…我們需要去核算整個過程。我們看到了這整個過程，但問題是從哪里開始？

我們可以把一個產(chǎn)品的運營比作一個工廠，這個工廠運營的其實就是用戶，怎么吸引用戶、滿足用戶、留住用戶、產(chǎn)生收入，我們要核算的是整個這個過程。

如果我們能找到這些指標，我們該先關注什么哪一個？Eric Ries說：一個新產(chǎn)品增長有三個引擎：粘性引擎；病毒引擎；付費引擎。

把這三個引擎放到工廠模式里，就會發(fā)現(xiàn)我們應該先關注的是怎么黏住用戶。這部分涉及到的內容很多，由于時間的關系不展開講。

總結：整個創(chuàng)新過程需要一個可交付的商業(yè)模式，然后要能刻畫這些商業(yè)模式，找到一個可行的商業(yè)模式，在真正指導我們具體執(zhí)行的過程中，我們需要有數(shù)據(jù)，圍繞這些數(shù)據(jù)一定要理解產(chǎn)品的運營方式，怎么去吸引用戶激活用戶留住用戶產(chǎn)生收入，以及產(chǎn)生口碑效應等，不同的產(chǎn)品需要不同的方法，并建立不同的數(shù)據(jù)指標，要知道什么時候去關注什么指標，由這些指標出發(fā)真正設計你的產(chǎn)品。當然對于不同的具體產(chǎn)品，你還需要做的更細，上圖就是電商產(chǎn)品的例子，就不展開了。

關鍵：要看到全貌的同時，聚焦當前時刻最關鍵指標。全貌是整個產(chǎn)品是怎么運營的，聚焦是在什么時間應該聚焦到什么指標上。這幅圖里把產(chǎn)品的打造分成不同的階段，并稱之為關隘模型，也就是說你得一關關的過，每個階段關注與之對應的目標，具體到創(chuàng)新核算，就是專注于相關的指標，在不同的階段應該聚焦不同的關鍵指標。

我們找到了不同階段應該關注的不同指標，接下來要解決的問題是如何從目標出發(fā)設計產(chǎn)品？

工具：影響地圖

引入一個新的方法——影響地圖。影響地圖解決的問題是從目標出發(fā)怎么設計一個產(chǎn)品的功能。之所以叫影響地圖，是假設我們通過產(chǎn)品功能來影響用戶的行為，最終實現(xiàn)產(chǎn)品的目標。

影響地圖是一個非常有效的、支持精益創(chuàng)業(yè)的需求挖掘和需求規(guī)劃的方法，在互聯(lián)網(wǎng)行業(yè)被普遍采用，上圖給了一個影響地圖的概貌和一些例子，影響地圖是由四個級別構成：why目標是什么；who誰能幫助我們實現(xiàn)這個目標，用戶或與用戶相關的人；how他通過什么行為幫助我們實現(xiàn)這個目標；最后what為了產(chǎn)生這個行為我們產(chǎn)品需要做什么功能。

影響地圖有一個核心點：影像地圖里的需求只能看成假設，我們假設做了這些需求就能對用戶的行為產(chǎn)生影響，假設產(chǎn)生了這樣的影響就能實現(xiàn)我們的目標，真正做的時候影響地圖把這個假設呈現(xiàn)出來不斷印證，這個假設印證的過程其實最后就是體現(xiàn)精益創(chuàng)業(yè)的過程，基于概念開發(fā)產(chǎn)品，通過測量得到數(shù)據(jù)最后驗證這個概念。

所以影響地圖綜合了精益創(chuàng)業(yè)的實踐和精益需求的方法。

如圖，舉一個影響地圖的例子，既是需求挖掘、需求設計的方法，也是需求規(guī)劃和迭代規(guī)劃的方法。

產(chǎn)品的設計永遠不是一個簡單的事情，并不是說告訴你一個框架一個小的方法就能實現(xiàn)的，用好影響地圖背后的產(chǎn)品設計假設，通過改變或影響用戶的行為來實現(xiàn)業(yè)務和產(chǎn)品的目標。如何改變和影響用戶的行為其實需要對人性的把握和商業(yè)邏輯的理解，以及一些產(chǎn)品設計的真正的技巧，比如如何提高用戶轉化的LIFT設計模型（在培訓中會講到），提高用戶粘性的模型。產(chǎn)品設計本身就是一門學問，通過精益產(chǎn)品設計方法把相關的精益產(chǎn)品設計理念整合起來。

產(chǎn)品創(chuàng)新的挑戰(zhàn)：在耗盡資金和時間前實現(xiàn)產(chǎn)品和市場的匹配。任何一個創(chuàng)業(yè)都是有時間和資金的約束的，不管內部還是外部。要在耗盡這些時間和資金之前交付一個可行的商業(yè)模式，至少證明值得繼續(xù)投資。

創(chuàng)新管理的核心：延長創(chuàng)新跑道的長度。

之所以用一個飛機的跑道來舉例，是想說明在跑道的盡頭飛機必須能夠起飛，跑道有多長很重要，這個長度由什么決定呢？大家很自然會想跑道的長度是還有多少時間多少錢。比如給了我兩年，肯定比給我一年更容易成功，比如給了我一千萬肯定比給我500萬更容易成功。但事實上跑道長度不取決于時間和金錢，它們只是約束條件。

那么，跑道的長度由什么決定呢？

創(chuàng)新是一個探索的過程，取決于探索的效率。跑道的長度取決于：在給定的時間和金錢的條件下組織能做出有效轉型的次數(shù)。每次轉型都是一次探索，并不是每次轉型都是大的方向的轉型，比如是用戶定位的轉型、問題的轉型、解決方案的轉型等的改變，但必須是有效地改變。注意這里很重的一點是“有效的”轉型。

也就是說我們必須從先知的封?。ㄓ幸粋€想法，你們去做吧，肯定行）轉變成科學的探索方法（能指引我們有效探索和轉型）。

科學的探索方法有三個最重要的點：速度、專注、有效學習。三者缺一不可。

• 速度容易理解，缺少速度會耗盡資源；

• 缺少專注會導致過早優(yōu)化，沒有在正確的時間做正確的事情；

• 缺少有效學習會導致瞎忙。看上去在探索，在轉型，但是總是沒向正確的方向去。

如何做到這三點呢？這是精益創(chuàng)業(yè)實踐和精益創(chuàng)新管理需要關注的東西。

• 速度：快速迭代、減小實驗批量快速試錯、順暢流動（從一個想法到驗證要更快）；

• 專注：要看到整體、目標驅動、專注單一指標、目標清晰的MVP；

• 有效學習：承認無知、精益設計、明確假設帶著目的驗證假設、數(shù)據(jù)/結果分析、直面結果并行動，勇于轉型。

回到敏捷宣言（如上圖）。這是2001年提出的，其實它的全稱是敏捷軟件開發(fā)，當是大家還是聚焦于軟件開發(fā)過程的問題，今天面臨的問題是如何更順暢地端到端地交付有用的產(chǎn)品，所以敏捷宣言也需要作一個擴展。精益和敏捷宣言：（如下圖）

作為一個完整的體系，需要先有精益產(chǎn)品設計，在此基礎上有相應的精益或敏捷的需求和管理方法：比如實例化需求、用戶故事地圖等，再是產(chǎn)品開發(fā)的輸入，在輸入的基礎上需要有看板這樣的方法，然后到產(chǎn)品交付，這時候要跟產(chǎn)品運營打通，得到反饋支持產(chǎn)品探索和創(chuàng)新實踐，精益數(shù)據(jù)的分析方法、構建和優(yōu)化、驗證的方法，再回過頭來支持精益產(chǎn)品設計，形成循環(huán)，這是我們完整的精益產(chǎn)品開發(fā)體系。

Q：@SparkYu@何紅旗：敏捷、精益有什么區(qū)別？

A：先說一個事實：敏捷早期受到了精益思想的一些影響，比如Scrum和XP的發(fā)明人都聲稱收到精益思想的啟發(fā)，但這些影響不是根本性的。早年提敏捷時，較少說到精益。不過最近3，5年情況變了，好像只說敏捷，不帶上精益就一點也不酷。

兩者中，敏捷更容易理解。敏捷就是敏捷（able to move quickly and easily）。具體到產(chǎn)品開發(fā)就是：“更早的交付價值，更靈活的應對變化”，這是一個目標，也是一個能力要求。至于各種實踐，其實都是為這一目標服務的。比如Scrum是管理迭代交付過程的一個框架，有人可能說不是，說Scrum還是一個持續(xù)改進的框架，但持續(xù)改進不也是為了價值交付嗎？TDD，持續(xù)集成等實踐都是服務于這個目標。

精益的目標也不復雜，消除價值交付過程中的浪費，交付更多有用的價值。它最核心的就是兩個字“價值”，體現(xiàn)到產(chǎn)品開發(fā)中就是要“順暢，高質量地交付有用的價值”，就目標本身而言，如果順暢，你自然就是敏捷的，精益是涵蓋了敏捷的，但不能因此就說精益更牛，畢竟說大目標誰不會啊。精益的核心還是為了實現(xiàn)這一目標背后的方法學支持。方法學我沒辦法展開來講，好在，我有一篇完整的文章說了，也做過一次線上分享。大家可以參考。在我的公號（LeanAction）中回復“精益思想”可以找到這篇文章。

那為什么精益這兩年提得特別多呢，我看到三個原因。

第一： 產(chǎn)品交付的要求越來越高了。如果只是開發(fā)階段的迭代根本不能做到交付真正的價值。這時原先適應小團隊和交付階段的Scrum，XP方法搞不定了。

我們需要打通組織的整個價值鏈，做到所謂前后的真正拉通，規(guī)模和關聯(lián)復雜時還要融合左右，目標只有一個——快速的交付價值或驗證設想。今天幾乎所有的大規(guī)模敏捷框架（比如SAFe，LeSS）都會把精益思想和實踐作為基礎，背后就是這個道理。順便說一句，我個人是不支持任何大規(guī)模敏捷框架的。

第二：創(chuàng)新的要求越來越高了。敏捷宣言里說，我們要響應變化。Scrum和XP的實踐也是這么做了。但今天互聯(lián)網(wǎng)時代，要求變得更高了。響應變化這個詞其實顯得有點被動，它暗含了一個假設，就是有人會告訴你改變了，該怎么變。然而，今天這不是事實了。團隊需要刻意的有計劃的去探索、去尋求變化，甚至試錯這個詞都不能表達背后的意義，應該是目標驅動地、系統(tǒng)和高效試錯。唯有這樣才能交付出有用的東西。在這一背景先產(chǎn)生了精益創(chuàng)業(yè)的方法，精益創(chuàng)業(yè)事實上是精益思想，在產(chǎn)品創(chuàng)新（而不僅僅是創(chuàng)業(yè)）過程的應用。這個和精益思想有什么聯(lián)系我就不展開了，Eric Ries在《精益創(chuàng)業(yè)》中有很好的闡述。

第三：敏捷的落地和變革非常困難。定義一個理想的模式是容易的，了解現(xiàn)狀要難一些，但也還好。最困難的是，如何從現(xiàn)狀到達理想的目標。精益方法為此提供了方法學和實踐的支持。我在書的第19章，就專門闡述了這一點。我講了怎么化解資源效率和流動效率的悖論，并以流動效率為核心來組織團隊的改進過程。這背后其實就是精益的改進思路和實踐。

總結一下：

第一：敏捷作為一個目標，就是更早交付和靈活的響應變化。它特別重要，但不代表產(chǎn)品交付的全部。

第二：精益強調是順暢和高質量的交付，以及交付的是真正的價值。

第三：精益作為一個工具，應該主導精益和敏捷的實施。畢竟創(chuàng)新和價值交付是產(chǎn)品開發(fā)組織存在的理由。我們應該回到這個根本上來。

不過，很多時候精益和敏捷一般是混著用的，這沒關系。重要的是，你應該合理應用敏捷的實踐，并掌握精益這個強大的工具，實現(xiàn)真正的精益和敏捷的目標——順暢（包含靈活）和高質量的交付真正的價值，有力支持業(yè)務的成功。

Q：@Charles 敏捷和持續(xù)交付的關系

A：敏捷是一個目標，也是一個能力要求，而持續(xù)交付是這個能力的最核心部分，是集成和標志，具備持續(xù)交付能力，其它能力估計問題也不大。

Jez Humble 給持續(xù)交付的定義是：以可持續(xù)的方式將各類變更（包括新功能、缺陷修復、配置變化、實驗等）安全、快速地落實到生產(chǎn)環(huán)境或用戶手中的能力。

按這個定義，持續(xù)交付不就是敏捷響應的能力嗎？不過，持續(xù)交付從字面意義上，偏向工程實踐，特別是軟件構建和部署的Pipeline，但它也應該包含組織和管理實踐。

其實今天，敏捷、持續(xù)交付、DevOps、精益（產(chǎn)品開發(fā)）是近義詞，每個社區(qū)也都在努力擴展自己的外延，都在拉近自己和業(yè)務以及創(chuàng)新的關系，最后也就殊途同歸了。

另外，持續(xù)交付這個詞，我蠻喜歡的，它指向明確，又有撬動作用。DevOps就不那么明確。但模糊性反而DevOps有更大的想象空間，搞得朋友多多的，誰都為它站臺，特別是云計算廠商，都號稱自己是DevOps 的enabler。這樣也不錯，眾人拾柴火焰高嘛。

Q：@飛翔的心: 進行scrum開發(fā)，如果提升團隊的需求拆解能力？

@梅：產(chǎn)品大特性如果需要跨sprint時，是否需要拆分成小故事？如何評估和衡量？

A：大特性的分解是必要的，因為這樣才能：

1）更早和更靈活地交付；2）更早的發(fā)現(xiàn)風險；3）方便計劃安排

拆分有三個基本要求，1）要足夠小，從迭代的角度，至少要能很容易的放入一個迭代，理想情況下一個迭代要能做多個需求；2）拆完的要端到端（有價值，能測試，能交付）；3）拆完后還要能看到整體。

為了拆而拆而拆，把拆分當成單獨的工作是常見的誤區(qū)。拆分應該是需求組織、分析和澄清的副產(chǎn)品，而不是單獨的任務。

具體到實踐，故事地圖和實例化需求這兩個實踐很有用。其中故事地圖是為了按業(yè)務場景來組織和規(guī)劃需求。實例化需求的目的是有效地分析和澄清需求，過去OOA(面向對象分析)所解決的問題，實例化需求當中也會體現(xiàn)，只不過更適合迭代或持續(xù)的交付。實例化需求，我實施的時候覺得是個比較容易的實踐，也能解決上面的問題。但是現(xiàn)實中做好的團隊的確不多，等我有時間應該好好總結一下才對。

Q：@小魚：如何讓非IT人員理解敏捷，然后可以一起參與推動敏捷的實施和改善？

A：敏捷作為一個目標（快速、靈活的交付）本來就是業(yè)務的目標，而IT人員要做的是建立起實現(xiàn)這一目標的能力，我們稱之為IT的敏捷交付能力。

這是前提，那怎么讓非IT的人員理解敏捷呢。那就是要回到業(yè)務本身，談靈活交付，談端到端的價值交付，談交付真實的價值。這些背后往往包含精益的思想，這部分解釋了為什么最近兩年，突然談敏捷時，必有精益。

Q:@天外來客：WIP經(jīng)驗值與案例

A：我在書中用了三個章節(jié)和大量的案例談WIP這件事，也給出了相應的經(jīng)驗和方法。

對這個問題，我在實施中很少會糾結。而那些糾結WIP應該是幾的團隊，往往還有更基礎的問題需要解決。那就是要圍繞價值組織團隊的協(xié)作和交付，打通和可視化端到端的價值交付流程。有了這個基礎，你會發(fā)現(xiàn)WIP的設置和貫徹難度會極大的降低。專注于已經(jīng)開始的價值，快速完成它們，難道不是很自然的事嗎？

如果團隊看到的只是任務，這時要求設置WIP限制，就會很不容易接受，達到的實際業(yè)務效果也不直接，推廣起來當然難。

Q:@追夢：我想了解的是：敏捷開發(fā)流程的前提是團隊都需要具備敏捷思維，那么如何帶動團隊快速敏捷起來呢？

A：什么是敏捷思維？憑什么你的思維是敏捷的，而我的不是呢？這是我們應該思考的。

我不認為敏捷思維的說法是錯的，但現(xiàn)實中鼓吹敏捷思維，效果的確不好。這你也看到了。作為個人應該有敏捷思維（不管這種思維是尊重人也好，適應性或成長思維也罷），但回到執(zhí)行層面卻不能要求別人有自己所謂的“敏捷思維”，更不能以此占據(jù)道德高點。

我們需要的價值思維和目標思維，而把敏捷看成實現(xiàn)目標的方法。所以，第一步應該達成共識的是，我們作為一個組織應該如何交付價值，我們對外的目標是什么，需要什么樣的能力。而后才是需要是是什么樣的敏捷方法，來幫助我們建設這一能力，和實現(xiàn)目標。

組織存在一定是對外交付價值，靈活的交付價值，這一點是沒有異議的。從這個基礎出發(fā)，我們就有機會構建好基本的共識和選擇正確的方法。這也是為什么我在書中，強調最多的兩個字是“價值”，而后再強調“價值的流動”。我強調的還不夠的是“有用的價值”，這是我后面要做的。

Q:@小樓聽雨：我想問一下，PMP項目管理和敏捷管理有啥區(qū)別？敏捷方法迭代速度快，在有限的時間和資源下，如何快速實現(xiàn)功能開發(fā)交付？用PMP方法管理團隊和利用敏捷管理項目團隊，各有啥優(yōu)缺點？

A：我個人做項目經(jīng)理很多年，PMP有它的價值，從PMP知識體系中我獲益不少。但PMP的知識體系是不敏捷的，即使今天有ACP也改變不了這個事實。因為 “項目”這兩個字就決定了它的屬性，項目創(chuàng)造了批量、創(chuàng)造的節(jié)點。批量本身就和敏捷交付是背道而馳的。敏捷交付需要更多的是產(chǎn)品思維，實現(xiàn)產(chǎn)品的持續(xù)交付、持續(xù)反饋、持續(xù)運營和持續(xù)調整。

在敏捷交付中，我們需要弱化項目思維，而增加產(chǎn)品和價值思維。弱化批量化的階段實踐，而建設持續(xù)交付和反饋的能力。

另外，在需要大量同步、協(xié)調和決策評審的實施類項目中，PMP知識體系及實踐框架會繼續(xù)存在且發(fā)揮作用。。

Q:@大宇：敏捷開始的結束時間是固定的、而開發(fā)對象可以允許變更和追加的、如何在遵守時間的前提下對待式樣變更。有沒有什么實踐經(jīng)驗上的注意點可以分享。

A：固定時間盒不是敏捷的必然實踐，它只是Scrum的實踐，在Scrum框架中有它的道理。要注意的點是:

• 拆分需求，但不要為了拆分而拆分，比如通過實例化需求把需求拆分成端到端的小需求。這樣才有安排和變更的靈活性。

• 不要把Sprint做成小瀑布了，一旦做成小瀑布，所有的需求同時開始了，變更起來就不太可能了。而且最后往往會守不住時間，或因為時間而犧牲質量。

Q：精益對時間盒子的要求，是不是沒有scrum那么硬性？

A：是的，scrum對時間盒的要求非常嚴格，時間盒是scrum里最核心的概念之一，scrum認為時間盒就是其心跳，所有的計劃和跟蹤模式都是基于時間盒，對于同一個團隊其時間盒的要求是相等的，這是由其框架模式?jīng)Q定的。

在看板方法里對時間盒是沒有要求的，scrum是面向迭代的，看板是面向流動的，它更關注持續(xù)流動，在看板里也建議有相應節(jié)奏，但是需求填充和交付的節(jié)奏不一定是一樣的，比如可以一個星期填充一個需求，而交付可以是兩個星期或一個月一次。之所以建議有節(jié)奏，是可以給大家對一件事情有一個預期，但不是必須的。

Q:@ 陳嬌智：項目進度推進一拖再拖，每個階段都有無數(shù)不同問題，如果確保項目質量和進度并存問題？

A：關于質量：以需求為粒度控制質量，實現(xiàn)單個需求的持續(xù)流動，而不是以迭代或項目為粒度控制時間點。我在第21章有詳細的討論。進度問題其實也是相關的，實現(xiàn)需求的持續(xù)流動，而弱化項目的階段，在需求上內建質量，就不存在每個階段無數(shù)問題這一說了。這一點招商銀行的項目管理是典范，做得非常好。

Q:@琪琪：大項目做敏捷、持續(xù)集成，過程中專項或集成的工作并行太多，導致團隊同時在運轉的事項比較多，狀態(tài)切換或專項轉換混輪，怎么處理解決這種狀態(tài)的混亂，或者怎么提高大項目管理中多項事情并行的效率？

A：操作上兩個方面。第一：合理規(guī)劃，理清輸入。這是源頭。第二：在第一點的基礎上，限制在制品。

可能還有兩個更基礎的問題：第一：組織結構的合理性，是否與交付的需要適配；第二：技術實踐的到位程度，比如有很多手工集成的工作，可能意味著需要劃分的合理性，或持續(xù)集成實踐的到位程度。

Q:@滿江紅: 梳理用戶故事地圖，如果即想按角色分類，又想按迭代劃分，如何呈現(xiàn)到地圖上，有沒有好的實例？

答：看來你已經(jīng)實踐的比較深入了。這兩個本來就有一些沖突。我個人的觀點，按角色分是為了挖掘和過濾需求，到規(guī)劃的時候，就不要強求按角色來規(guī)劃迭代了。規(guī)劃的時候應該按業(yè)務目標（優(yōu)先）和場景來規(guī)劃，如果正好能匹配角色，那是件好事，匹配不上不要強求。