摘要：摘要什么是第一性原理第一性原理如何指導(dǎo)我們的精益敏捷開發(fā)阿里資深解決方案架構(gòu)師暢銷書精益產(chǎn)品開發(fā)原則方法與實施作者何勉，結(jié)合實踐案例，詳述第一性原理和精益敏捷的規(guī)模化實施。前言今天分享的題目是第一性原理和精益敏捷的規(guī)模化實施。

摘要： 什么是第一性原理？第一性原理如何指導(dǎo)我們的精益敏捷開發(fā)？阿里資深解決方案架構(gòu)師、暢銷書《精益產(chǎn)品開發(fā)：原則、方法與實施》作者何勉，結(jié)合實踐案例，詳述第一性原理和精益敏捷的規(guī)模化實施。

導(dǎo)讀：什么是第一性原理？第一性原理如何指導(dǎo)我們的精益敏捷開發(fā)？阿里資深解決方案架構(gòu)師、暢銷書《精益產(chǎn)品開發(fā)：原則、方法與實施》作者何勉，結(jié)合實踐案例，詳述第一性原理和精益敏捷的規(guī)模化實施。

前言

今天分享的題目是第一性原理和精益敏捷的規(guī)模化實施。

我們講第一性原理，先從它的反面“貨物崇拜”說起。

貨物崇拜發(fā)生在西南太平洋的小島，二戰(zhàn)時期美軍在這里駐軍，美軍撤走以后小島發(fā)生一個很奇特的現(xiàn)象，小島的原住民部落中興起一個宗教儀式——他們用草木搭起飛機(jī)模型，并作為圖騰來崇拜。

他們每年定期會在自己的身體上畫出USA三個大字母立隊行軍，拿著木頭槍游行，并拜飛機(jī)，手里還會拿樹葉翻來翻去，大家猜猜他們在干什么？

他們覺得美軍不需要打獵、捕魚卻有充分的物資，這些物資都是島民沒有見過的好東西。他們認(rèn)為美軍只是普普通通的人，美軍的種種行為是在召喚神靈——也就是被他們稱為鐵鳥的飛機(jī)，鐵鳥帶來無窮無盡的物資，而這本是祖先賜予他們禮物的，結(jié)果卻被美軍劫持了。

他們覺得自己只要模仿美軍的動作就可以召喚神的再次降臨，比如翻樹葉——其實是在模仿美軍翻閱作戰(zhàn)文件。

他們模仿這些行為，一直堅持到今天，從來沒有改變過，以至于已經(jīng)成為一個宗教，人類學(xué)家稱其為貨物崇拜教，也就是說對那些飛機(jī)以及飛機(jī)帶來的貨物的崇拜。他們希望通過模仿現(xiàn)象和表象，得到想要的結(jié)果。

我們在精益敏捷實施里面也經(jīng)常看到貨物崇拜，比如我們產(chǎn)品經(jīng)理不叫產(chǎn)品經(jīng)理，叫PO，項目經(jīng)理不叫PM，而改成Scrum Master，我們的需求不叫需求叫故事。我們也搞各種儀式——比如說站會，搞所謂大規(guī)模的敏捷框架，我們希望對于這種形式的模仿可以帶來不同的結(jié)果。

而我們經(jīng)常看到形式模仿了，但本質(zhì)沒有改變。我經(jīng)歷過很多成功的團(tuán)隊，也有看到過很多不成功的。托爾斯泰說幸福的家庭都是相似的，不幸的家庭各有各的不幸。

在成功的精益敏捷實施中，我的確看到了共性，它就是聚焦價值交付。不成功的根本原因各不相同，如理解不到位，方法錯誤，技術(shù)能力不足等。但是，不成功的表現(xiàn)形式也有共性，那就是最終都會表現(xiàn)出某種程度的貨物崇拜——只在乎形式，而忘記了實質(zhì)。

這算是個開頭，為第一性原理做一個鋪墊。今天我主要分享敏捷的規(guī)模化實施，會從以下四個方面進(jìn)行分享：

1、第一性原理
2、產(chǎn)品開發(fā)的第一性原理
3、精益和?捷的規(guī)模化路徑
4、以第一性原理檢驗規(guī)模化的效果

一、第一性原理

我們不要貨物崇拜，那我們該怎么做呢？我們應(yīng)該探尋第一性原理，回到事情的本源。我來解釋一下什么叫做第一性原理。

第一性原理這個詞很早就存在，但是最近特別熱，可能是因為特斯拉的創(chuàng)始人 ELON MUSK吧 ，接受采訪時，他總會提到第一性原理，認(rèn)為考慮事情應(yīng)該注重其第一性原理。以至于現(xiàn)在硅谷投資人也都學(xué)會了，經(jīng)常會問：“這個項目不錯，可是第一性原理是什么呢？”

第一性原理就是用物理學(xué)的角度看待世界，一層一層撥開事物的表象，看到里面的本質(zhì)，再從本質(zhì)一層一層往上走。這恰恰和貨物崇拜相反。貨物崇拜看到的是表象，第一性原理是要回到事物的本質(zhì)。

看看 ELON MUSK 怎么講第一性原理的。

比如他剛做電動車的時候，人們告訴他別做電動車，因為電池成本太高，電動車不可行。Musk是準(zhǔn)物理學(xué)博士（中途輟學(xué)創(chuàng)業(yè)，未能取得博士學(xué)位），他說我們要回到第一性原理，那么問題是：構(gòu)成電池的基本原材料是金屬元素，這些金屬元素加起來成本是多少，多少錢一度電？比如60美元左右一度電。

我們的任務(wù)就是無限逼近原材料的成本，因為除了原材料成本之外，其它成本都是人類協(xié)作過程之中產(chǎn)生的，就有可能被消除掉，從而逼近原材料成本。這是馬斯克眼中的第一性原理——回到事物的物理本質(zhì)。

再看喬布斯的第一性原理。他說我們做一切事情要圍繞產(chǎn)品——公司、管理、技術(shù)、銷售、創(chuàng)新都要圍繞產(chǎn)品做。

關(guān)于公司，他曾經(jīng)說，“我創(chuàng)建公司唯一的目的是為了產(chǎn)品，公司只不過是一種手段，可以讓真正有創(chuàng)造力的人合作打造產(chǎn)品。”

關(guān)于銷售他說：“我堅信我們打造好的產(chǎn)品用戶一定喜歡，用戶喜歡一定會給錢，所以銷售不是問題”。

關(guān)于創(chuàng)新喬布斯說“我對創(chuàng)新沒有興趣，我只在乎偉大的產(chǎn)品，只要把產(chǎn)品做好了，這件事本質(zhì)做好了其他會跟著來”。

第一性原理就是要回到事物的本質(zhì)，從本質(zhì)出發(fā)再一層一層看看我們應(yīng)該怎么規(guī)劃其他的方面。

產(chǎn)品是商業(yè)成功的根本，至少喬布斯是這么認(rèn)為的，也是這樣做的。

二、產(chǎn)品開發(fā)的第一性原理

那產(chǎn)品開發(fā)的第一性原理應(yīng)該是什么？我覺得要從理解其根本目標(biāo)出發(fā)，才能回答這個問題。

德魯克說，任何組織的績效只能在它的外部反映出來。我們探究產(chǎn)品開發(fā)的目標(biāo)，不能從組織內(nèi)部找，要從它的外部找，要看用戶和價值。管理存在的目的是幫助組織取得成效，他的責(zé)任是協(xié)調(diào)內(nèi)部資源取得成效。所以說他的第一性原理不在于內(nèi)部，而是要取得外部的成效，我們稱之為：“交付有用的價值”。

我們內(nèi)部的種種方式，協(xié)調(diào)資源做計劃，改善技術(shù)或流程都是為取得外部的成效服務(wù)的。對產(chǎn)品開發(fā)來說就是要：“順暢和高質(zhì)量交付有用的價值”，包括三個關(guān)鍵字。

順暢，就是交付的過程外部價值要順暢，不管內(nèi)部怎么去協(xié)作，采取什么樣的流程，用什么樣的技術(shù)，構(gòu)件什么樣的基礎(chǔ)設(shè)施，都是要為價值的順暢交付服務(wù)。

當(dāng)然順暢還要符合質(zhì)量的要求。

最后交付的價值是要有用的，有用的就是用戶在乎的，愿意付錢的，可以為我們帶來利益的。如果用4x100米接力賽做比喻，那我們聚焦應(yīng)該是接力棒的傳遞而不是運動員是不是時刻在動。產(chǎn)品開發(fā)的目的是要把用戶的價值最快的傳遞出去，而不是內(nèi)部資源是不是時刻忙碌。

三、精益和?捷的規(guī)模化路徑

接下來我們要講講精益敏捷規(guī)模化實施路徑，第一性原理為我們的規(guī)模化精益敏捷實施的路徑提供了方向性的指導(dǎo)。

3.1 康威定律的啟示

我們經(jīng)常看到所謂敏捷的規(guī)模化實施方案，會從組織結(jié)構(gòu)的規(guī)模化方案開始。這樣做好嗎？

著名的康威定律告訴我們，組織結(jié)構(gòu)會決定團(tuán)隊溝通的結(jié)構(gòu)，也會決定產(chǎn)品的結(jié)構(gòu)。聽起來有點抽象，我們看兩個具體的例子。

康威在一篇論文中給了一個例子，當(dāng)年有一個團(tuán)隊要做兩個編譯器，一個叫做 COBOL ，一個叫做 ALGOL ， 一共有8個程序員。團(tuán)隊評估認(rèn)為COBOL 復(fù)雜度要比ALGOL復(fù)雜，于是給 COBOL 團(tuán)隊分5個人，給 ALGOL 團(tuán)隊分了3個人，從此以后這個世界上COBOL編譯分5步，ALGOL的編譯分3步。也就是說產(chǎn)品結(jié)構(gòu)拷貝了組織的結(jié)構(gòu)。

再看另外一個例子，我當(dāng)年做項目經(jīng)理的時候帶過硬件團(tuán)隊，為了激勵團(tuán)隊讀過一本硬件工程師勵志書《新機(jī)器靈魂》，它講的是小型機(jī)時代的硬件開發(fā)。

當(dāng)時，一個公司要做小型機(jī)，與如日中天的DEC的VAX11競爭。主人公潛入用戶的機(jī)房，把用戶的 VAX11打開，看到其中一塊塊電路板，于是他放心了。

書中是這樣說的：“威斯特打開機(jī)器，拉開電路板的一刻，他放心了。他從中看到的是DEC組織結(jié)構(gòu)，而不是一塊塊電路板，VAX11過于復(fù)雜，他對VAX11各部分連接方式不以為然。因為電路溝通方式拷貝的是組織溝通的方式”。這是一個真實的故事，康威原理也適用于硬件開發(fā)。

3.2 聚焦用戶價值是規(guī)劃規(guī)模化路徑的必由之路

康威定律告訴我們，一開始去設(shè)計和決定組織結(jié)構(gòu)，那同時也就幾乎決定你的產(chǎn)品結(jié)構(gòu)，至少是限制了產(chǎn)品結(jié)構(gòu)。今天市場和環(huán)境變化太快，業(yè)務(wù)本身也需要靈活，產(chǎn)品本身當(dāng)然也需要靈活性，不能被人為設(shè)計的層次化的組織結(jié)構(gòu)所限制。所以我們認(rèn)為如果上來就去設(shè)計規(guī)模化的組織結(jié)構(gòu)是不對的，應(yīng)該避免從組織結(jié)構(gòu)的規(guī)模化開始考慮這個問題。

你應(yīng)該從用戶價值出發(fā)去考慮，由實際的業(yè)務(wù)需要驅(qū)動，讓用戶價值交付的需要決定組織的協(xié)作方式。在今天這個多變的世界里，用戶價值的交付需要有靈活性，組織結(jié)構(gòu)也應(yīng)該有靈活性，這是對康威原理的一個推論。

康威原理說產(chǎn)品會拷貝組織結(jié)構(gòu)，那我們產(chǎn)品要靈活多變，組織結(jié)構(gòu)也應(yīng)該是靈活的。所以我們永遠(yuǎn)應(yīng)該從用戶價值出發(fā)，來決定我們怎么去做規(guī)模化。

從用戶價值出發(fā)，我看到兩類規(guī)模化的需求。

第一是先后各個順序職能的打通。瀑布開發(fā)模式中，開發(fā)團(tuán)隊批量的進(jìn)行需求的設(shè)計、開發(fā)、測試，這一方式延遲了價值交付和即時有效的反饋。與之對應(yīng)，敏捷倡導(dǎo)迭代開發(fā)方式。希望迭代地交付價值和獲取反饋，比如 Scrum框架。但是真實世界要更復(fù)雜。

更宏觀的看產(chǎn)品交付過程，需求之前還有業(yè)務(wù)規(guī)劃、產(chǎn)品定義等，需求之后還有實施和驗證等。這樣我們發(fā)現(xiàn)如果僅僅在實現(xiàn)階段迭代，整體來看，它還是瀑布，只不過是更大的瀑布，我們稱之為Water-Scrum-Fall，局部的迭代，并不能帶來真正的快速交付和真實反饋。

打通端到端的價值流，這是規(guī)模化要解決的問題之一。這才能產(chǎn)生快速和有效的交付。同時也才能產(chǎn)生有效反饋，基于反饋不斷調(diào)整保證我們交付的價值有用。

還有另外一種情況，比如對于一個典型設(shè)備制造商，就說華為吧，要交付一個移動的解決方案，比如 VOIP 、 VOLTE這樣的解決方案可能要涉及到上千人，比如基站、基站控制器、核心網(wǎng)、網(wǎng)管等網(wǎng)絡(luò)設(shè)備，在電信行業(yè)把單個網(wǎng)絡(luò)設(shè)備成為網(wǎng)元，每個網(wǎng)元背后都是相對獨立的開發(fā)團(tuán)隊。

一個網(wǎng)元也有幾百人在做，功能需求還要被分解到一個個功能模塊。這個產(chǎn)品的價值也是分層次的：
在解決方案層我們稱之為用戶原始需求；
在網(wǎng)元層稱之為功能需求；
在模塊層稱之為可分配需求。
需求也是分層次的。

我們不可能把一千個人變成跨功能，跨職能的單個團(tuán)隊。只有各個團(tuán)隊能夠協(xié)調(diào)一致，并保證各個層次工作的對齊，才能快速交付最終對用戶有意義的價值。

這就引出了規(guī)模化要解決的第二個問題——怎么協(xié)調(diào)各個層面，最終交付有效的用戶價值、用戶需求。這也就是如何協(xié)調(diào)每個層次、不同團(tuán)隊的工作，對齊各個層次上的工作，保證最終用戶價值交付的順暢流動和交付。

總結(jié)下來，規(guī)模化的敏捷實施要解決兩類問題：
打通端到端的價值流，連接價值鏈上的不同職能；
在各個層次上協(xié)調(diào)各個關(guān)聯(lián)的團(tuán)隊，保證他們工作的對齊。
通過這兩點聯(lián)通前后，對齊左右，目標(biāo)是順暢交付對外部也就是對用戶有用的業(yè)務(wù)價值。順暢意味著快速，也意味著高質(zhì)量。

3.3 規(guī)模化精益、敏捷實施的不同路徑及其案例

單個小團(tuán)隊層面和局部環(huán)節(jié)的實施不能帶來真正的價值交付，那這就提出了規(guī)模化的需求。面對這樣的需求我們來考慮怎么樣做，下面我會分享一些例子，其中有華為、平安的，也有創(chuàng)業(yè)公司。

這些例子面對的場景和上下文不同，其具體的方案也不同，但總體上可以分為四種模式，它們的共同特點是以團(tuán)隊級實施為基礎(chǔ)，再需求更大范圍的規(guī)模化應(yīng)用，最終都是為了順暢交付價值。

我們將介紹四種常見的模式，也就是融合、拓展、連接和層次化。

3.3.1 融合

我們先看一個例子，團(tuán)隊的融合，是兩個團(tuán)隊被融合為一個團(tuán)隊。

這是一家做企業(yè)網(wǎng)盤的部門。企業(yè)網(wǎng)盤類似于百度云盤，相對而言，難度在于需求多樣化，比如安全的需求、合規(guī)的需求，跟辦公系統(tǒng)集成等。

它涉及兩類技術(shù)：
一類是后端的技術(shù)，做文件系統(tǒng)、集群控制，以及各類應(yīng)用的基礎(chǔ)服務(wù)；
一類是前端技術(shù)，提供安卓、IOS和Web以及PC的客戶端應(yīng)用。
前后端兩類技術(shù)并不通用，所以很自然他們分成了前后端兩個團(tuán)隊，分別做迭代，分別有一塊看板。

這時，如果有一個需求，比如在線視頻播放需求。它會被分別分解為前端和后端的子需求，前端和后端團(tuán)隊分別做迭代，兩周一個迭代，后端先做，前端再集成。還需要一個多帶帶的缺陷管理系統(tǒng)。

有了BUG先提給前端，前端發(fā)現(xiàn)是后端的問題，再轉(zhuǎn)給后端。問題是后端這時正在做下一批需求，相對新需求，我們認(rèn)為解決Bug的優(yōu)先級更高。但事實執(zhí)行中卻正好相反，因為新需求有明確的時間要求啊，除非有人追——通常是項目經(jīng)理來追。

包括剛才說的排計劃，也就是協(xié)調(diào)前后端的迭代計劃，也需要項目經(jīng)理來做。在這里項目經(jīng)理是非常關(guān)鍵的角色，是一個樞紐，是一個關(guān)節(jié)點，當(dāng)然也是一個瓶頸。

這個看板做的好不好？還是可以的，至少工作任務(wù)的分解和狀態(tài)清楚。但它對產(chǎn)品經(jīng)理友好嗎？不太友好，需求會被拆成什么樣不知道，也看不到需求端到端的流動，看不到前后端團(tuán)隊的協(xié)作，看不到缺陷和需求的關(guān)聯(lián)，最重要的是看不到用戶需求的交付過程。

所以我們要改造它。改造之前我們用戴明的一句話，戴明說：“如果不能以一個清晰的過程展示你從事的工作，你不會真正了解你在做什么”。對這個團(tuán)隊來說它并沒有用清晰的過程展示前后端怎么協(xié)作的，BUG怎么關(guān)聯(lián)的，怎么解決的，價值是怎么提出并交付給用戶的。所以這個看板對團(tuán)隊能起到的作用就非常有限了。

這個團(tuán)隊當(dāng)時29個人，還有6個產(chǎn)品經(jīng)理。我們后來改造了這個看板，前后端要融合在一起，做以用戶需求而不是開發(fā)任務(wù)為主體的看板。

改造后的看板上的主體流動單元不再是開發(fā)任務(wù)，而是用戶的需求。需求首先進(jìn)入需求池，也就是圖中的pool，然后是設(shè)計中、待澄清等，這時還是藍(lán)色的卡片。到了就緒這個階段，藍(lán)色的卡片被轉(zhuǎn)換成了白色的卡片，我們稱之為故事，是打印出來手填的，相對正式一點。從這一步開始故事替代了原先的用戶需求。

接下來看一下這個實現(xiàn)中的故事（Story），后面數(shù)據(jù)、集群、應(yīng)用、Web、PC，這些是什么？是模塊名稱，既有前端的，也有后端的模塊。各個模塊下是故事分解出的開發(fā)任務(wù)，其中藍(lán)色的是開發(fā)任務(wù)，黃色是自動測試任務(wù)，這些任務(wù)之間沒有時間順序關(guān)系，做完了就放在完成這一列。完成之后是待驗證，待驗證是需求（也就是story）。

橫向被稱為泳道，故事和它所屬的任務(wù)共同放入一個泳道。當(dāng)一個泳道中所有的任務(wù)完成后，故事也完成了，可以進(jìn)入待驗證了。泳道就被清空了，可以進(jìn)行下一個故事了。

這個團(tuán)隊開會的時候，會review看板上的內(nèi)容。大家覺得是從左到右還是從右到左的順序更好呢？答案是從右往左，原因是我們的最終目的是完成需求，而非開始需求。

開始是一件非常簡單的事情，但團(tuán)隊交付的速度是完成速度決定的，要趕快把這些接近完成的完成。從右往左，優(yōu)先完成已經(jīng)開始的需求，有問題及時解決問題，這也體現(xiàn)了用戶價值的拉動。

這是一個端到端的看板，最左邊的需求池和設(shè)計由產(chǎn)品負(fù)責(zé)，最右邊的驗收是產(chǎn)品驗收。所以它從產(chǎn)品開始到產(chǎn)品結(jié)束，是用戶價值從提出到交付端到端的過程。同時它也反映了團(tuán)隊協(xié)作、需求的分解和合并、缺陷和問題。

做完這個看板以后我問負(fù)責(zé)這個產(chǎn)品的公司副總裁三個問題：
能不能清晰全面的反映需求和交付的過程？
瓶頸和問題能不能在看板上得到及時的體現(xiàn)？
團(tuán)隊可以根據(jù)看板的信息協(xié)作做決定嗎？

他對前兩個問題的回答是肯定的，但第三個問題還有些不確定，因為團(tuán)隊的協(xié)作需要明確的規(guī)則，后來團(tuán)隊又定義了更加明確的協(xié)作和需求流轉(zhuǎn)規(guī)則，這樣更多的協(xié)作就可以由團(tuán)隊自主完成，圖中是其中的一個例子，它定義了什么樣的需求才能叫就緒。

上面的融合是第一個規(guī)模化的場景，它讓我們看到端到端的價值流動，以及團(tuán)隊協(xié)作交付需求的過程，可以更加順暢地發(fā)現(xiàn)解決瓶頸和問題，更加順暢高質(zhì)量的交付價值。

3.3.2 拓展

再看第二個叫拓展，這是平安的一個例子。

這個看板跟上面的非常像。業(yè)務(wù)看到這個看板后覺得非常好。說：“原來你們把我們叫做需求池，你們知道我們在需求池這個階段做了多少工作嗎？”

業(yè)務(wù)決定也要做一個看板，在他們的看板中，首先就把整個開發(fā)看板中的各個階段壓縮了，變成了一個小小的開發(fā)階段。測試強調(diào)了用戶驗收測試（UAT）外，還加上了生產(chǎn)驗證，也就是在生產(chǎn)環(huán)境中觀察業(yè)務(wù)的運營和驗證實施的效果。而需求在提出給開發(fā)前的工作也被清晰的呈現(xiàn)出來了，比如初始的創(chuàng)意和業(yè)務(wù)設(shè)計，內(nèi)部的業(yè)務(wù)評審，業(yè)務(wù)交互的設(shè)計，視覺設(shè)計等。

這是一個業(yè)務(wù)看到的端到端的看板，這個很好。我們有時候沒有條件一開始就完全打通整個端到端的價值流，這時可以從局部做起，條件成熟的時候需要向兩端拓展，拓展的目的是要從業(yè)務(wù)的角度更加端到端，讓端到端價值的交付過程更加順暢，這是一個拓展的方式，最終還是為順暢交付外部的用戶價值服務(wù)。

3.3.3 連接

再看第三種方式叫連接，這也是平安的例子。

這個團(tuán)隊比較復(fù)雜，有四個異地團(tuán)隊構(gòu)成：業(yè)務(wù)方在深圳，底層服務(wù)在上海，上海開發(fā)完了給成都做應(yīng)用開發(fā)，再給深圳做接收測試。本來上海開發(fā)團(tuán)隊有一塊看板，成都開發(fā)團(tuán)隊有一塊看板，都是物理形式的。

在這樣復(fù)雜的組織結(jié)構(gòu)下，我們自然會擔(dān)心價值交付的速度很慢，因為涉及到這么多團(tuán)隊之間的交互。

作為解決方案，我們要設(shè)法把這兩塊看板連接起來，同時也要業(yè)務(wù)團(tuán)隊包含進(jìn)來。我們用電子看板來完成這一任務(wù)，但物理看板仍然保留著。

電子看板的流程是從業(yè)務(wù)側(cè)開始，需求作為業(yè)務(wù)設(shè)計后，由上海團(tuán)隊進(jìn)行分析，分析之后做API開發(fā)，一旦進(jìn)入API開發(fā)階段，上海開發(fā)團(tuán)隊，也會copy一份到自己的物理看板里面。

物理看板的信息更細(xì)致，會分解成更細(xì)的任務(wù)，而電子看板里只有需求，不體現(xiàn)任務(wù)，它更關(guān)注的是價值流動，而不是具體環(huán)節(jié)的任務(wù)跟蹤。等上海團(tuán)隊開發(fā)完成，需求放入API開發(fā)完成列，這一列也相當(dāng)于成都團(tuán)隊的需求池，成都團(tuán)隊開發(fā)完了再給業(yè)務(wù)方驗證。

電子看板有一個好處，它的度量會變得非常容易得到，也非常及時。

這個叫做累積流圖，累積流圖只漲不跌。最上面的線業(yè)務(wù)已經(jīng)提出需求的個數(shù)，最下面一條線是已經(jīng)交付的需求個數(shù)，中間分析完成的，API開發(fā)完成的，開始測試的，開始UAT測試，已經(jīng)交付的等等。從左到右畫的線一條橫線，它的長度是需求從開始到交付的前置時間。比如10月18號這一天提出了25個需求，到12月18號完成了25個需求，說明一個需求從開始到結(jié)束要一個月。

通過累積流圖，可以看需求在各個階段之間的分布，在最右面的階段是UAT用戶驗收測試，它占據(jù)了差不多一半的時間。說明要想縮短需求的交付實踐，還是應(yīng)該及時做驗收測試，當(dāng)然具體原因就需要具體分析了，也有可能是業(yè)務(wù)并不緊迫，也可能開發(fā)給我的東西不可測試。

但是無論如何縮短UAT這個階段的時間，是我們改進(jìn)交付時長的著手點。所以把它真正連接起來，打通端到端的價值流，以后就可以去分析改進(jìn)，產(chǎn)生系統(tǒng)的改進(jìn)，而不是一個局部的改進(jìn)。這是規(guī)模化的第三個路徑——連接。

3.3.4 層次化

再看看華為這個例子，相對要更復(fù)雜一些，他們的產(chǎn)品是分層次的，價值也是分層次的。

需求可以分為用戶需求、功能性需求和模塊需求。用戶需求被分解成一個個故事稱之為功能需求，用戶需求是最小的交付單位，用戶故事是一個集成和功能驗證單位，最下面還有子模塊任務(wù)，是不可做系統(tǒng)測試的，它可以分配給某個團(tuán)隊，是分配單位。

這種情況下，我們怎么規(guī)模化實施？還是要回到價值順暢交付上來。當(dāng)然這里的價值最終應(yīng)該是用戶需求。這里的需求層次較多，達(dá)到了三層，相應(yīng)的看板也需要分層。

上層是解決方案層看板，其實是做規(guī)劃用的。這里的泳道中，綠色的是用戶需求，藍(lán)色是故事，故事隸屬于用戶需求。我們在解決方案層要約束并行用戶需求的數(shù)目，就是并行的用戶需求數(shù)目不能太多了，因為并行的少就逼迫我們把已經(jīng)開始的盡快完成掉，讓各個團(tuán)隊，各個網(wǎng)元對齊和一致。

泳道數(shù)有限的，起到了約束并行用戶需求的數(shù)目的作用，讓故事向用戶需求對齊，我們追求的是用戶需求的快速完成，而不僅僅是完成更多的故事，但是需求做不完。更重要的是讓故事向用戶需求對齊，盡快和順暢地交付用戶需求。

解決方案層的看板只有一個，起到整體規(guī)劃的作用，處于上層。它的下一層次是項目看板，每個網(wǎng)元都有自己的項目，對一個多帶帶的看板。看板上，藍(lán)色的是故事，黃色的是子模塊的任務(wù)。同樣在項目層面要約束并行故事的個數(shù)，讓任務(wù)向故事對齊，我們追求故事的快速交付。

現(xiàn)在的問題是這兩塊看板能夠聯(lián)動起來嗎？能！因為故事在兩個層次都出現(xiàn)了，在項目層面追求任務(wù)向故事的對齊，讓故事快速完成；在解決方案層追求故事向用戶需求的對齊，讓用戶需求的快速完成。

在這個案例中，需求是層次化的，看板的方案也是層次化的，核心還是價值流動——通過對齊最終實現(xiàn)用戶價值的順暢流動。

四、從第一性原理反饋規(guī)模化的效果

怎么更加順暢高質(zhì)量交付真正的價值這是我們要考慮的，當(dāng)然我們還要建立所謂的反饋機(jī)制，有了剛才說的各種方法，端到端的價值流拉通以后，就為系統(tǒng)改進(jìn)價值流動打下了基礎(chǔ)。

而精益、敏捷實施的改進(jìn)效果也應(yīng)該以價值的流動為基礎(chǔ)來衡量。比如需求從提出、確認(rèn)到交付的前置時間，比如開發(fā)完成到測試開始之間的等待時長等。其中前面提到過的累積流圖，就是反映價值流動的一個例子。

如上圖所示，橫線的長度是時間，縱向是有多少并行的在制品，斜率是速度，累積流通反映的是價值流動和團(tuán)隊協(xié)作的過程，中間有哪些等待、瓶頸或改進(jìn)的空間，以及過去一段時間的改進(jìn)趨勢等。精益的度量和反饋已經(jīng)形成了一個以價值流動為核心的度量體系，這里不再一一列舉。

總結(jié)

我們從第一性原理出發(fā)，今天我們講了規(guī)模化實施的四種方案。規(guī)模化應(yīng)該被用戶需求，被順暢和高質(zhì)量的交付價值驅(qū)動出來的。

不能因為組織的規(guī)模大就要有規(guī)模化的框架，其實很多時候，你會發(fā)現(xiàn)你并不需要很復(fù)雜的方案。只在有實際業(yè)務(wù)需要時再考慮規(guī)模化方案，永遠(yuǎn)選擇夠用但最簡的規(guī)模化方案。

針對不同的場景，選擇與之匹配的最簡方案。比如這兩個看板怎么融合起來，怎么連接上下游，怎么從一個地方開始向上下游拓展，怎么做出一個層次化的方案，但是最終都服務(wù)于順暢的交付。

其實，我們一直在講看板，但看板只是一個載體，它背后是一個價值交付的團(tuán)隊和單元。

現(xiàn)在規(guī)模化敏捷、規(guī)模化精益實施有很多流行的框架。最近 Ron Jeffries 寫了《軟件開發(fā)本質(zhì)論》一書，他評價了大規(guī)模敏捷框架的突然流行。他說大公司開始做敏捷了，他們很自然會想大公司需要大規(guī)模。Jefferise說我相信他們會取得成功，然而那只會是咨詢公司的成功，而不是實施敏捷和精益的公司的成功。大公司需要的并不是大規(guī)模，而是需要真正敏捷的方法和技術(shù)本身。

我非常同意Jefferise的說法，去模仿照搬一個規(guī)模化的框架，正是貨物崇拜。我們應(yīng)該做的是，回到問題的本質(zhì)，回到我們的目標(biāo)，再決定怎么才能順暢、快速、高質(zhì)量的交付價值。

Denning有過類似的描述，他總結(jié)了微軟實現(xiàn)敏捷規(guī)模化的16條原則，其中特別強調(diào)，我們要追求的是敏捷的規(guī)模化，而不是規(guī)模化的敏捷。也就是說我們要讓敏捷成為公司范圍內(nèi)實施的方法，實現(xiàn)正在的敏捷性，并順暢交付價值。而不是要搞一個規(guī)模化的框架，那反而會制約我們。

規(guī)模化的敏捷的需求的確存在，但它應(yīng)該不是被組織的規(guī)模決定和驅(qū)動的，而是需求交付的復(fù)雜性，和產(chǎn)品及服務(wù)的真實復(fù)雜性驅(qū)動出來。

我們?yōu)榱隧槙澈透哔|(zhì)量地交付有用的價值，是我心目中的產(chǎn)品開發(fā)的第一性原理，是不能被忽略的基本出發(fā)點，也不能被違反。我們認(rèn)為有了高質(zhì)量的交付價值，并打通端到端的交付過程，不斷反饋讓價值順暢流動，并以快速的價值反饋和驗證來探索真正的價值，這才是我們要做的東西。

以下是我的書《精益產(chǎn)品開發(fā)原則方法和實施》前言寫的東西，我稱之為精益和敏捷宣言，我用它來結(jié)束本文的分享。

敏捷宣言是2001年發(fā)布的，當(dāng)時叫敏捷軟件宣言，今天我們看價值的角度需要對它進(jìn)行拓展，這些年互聯(lián)網(wǎng)特別是移動互聯(lián)網(wǎng)的發(fā)展日新月異，對產(chǎn)品開發(fā)提出了更高的要求。
個體和互動重于流程，但是我們要連接和打通組織的各個職能以確保協(xié)調(diào)一致的行動。
我們尊崇可工作的軟件，重于面面俱到的文檔，但是更重要的是要交付價值，要聚焦端到端價值流動以快速靈活交付真正客戶的價值。
客戶合作重于合同和談判，在今天選擇權(quán)越來越向用戶側(cè)轉(zhuǎn)移的時候，我們要與客戶建立共同目標(biāo)，以最大優(yōu)化業(yè)務(wù)成果。
我們尊崇響應(yīng)變化，但是響應(yīng)變化是被動的，今天要有計劃和系統(tǒng)主動的試錯以支持我們有效的學(xué)習(xí)和創(chuàng)新。
所以今天時代不同了，我們提出比過去高得多的要求。敏捷規(guī)模化需求是真實存在的，但還是要避免不必要的各種規(guī)模化的框架，為了規(guī)模化而規(guī)模化，更不要做所謂的貨物崇拜。所以我們要回到問題的第一性原理——順暢和高質(zhì)量交付有用的價值。