何勉：第一性原理和精益敏捷的規模化實施

摘要： 什麼是第一性原理？第一性原理如何指導咱們的精益敏捷開發？阿里資深解決方案架構師、暢銷書《精益產品開發：原則、方法與實施》做者何勉，結合實踐案例，詳述第一性原理和精益敏捷的規模化實施。

導讀：什麼是第一性原理？第一性原理如何指導咱們的精益敏捷開發？阿里資深解決方案架構師、暢銷書《精益產品開發：原則、方法與實施》做者何勉，結合實踐案例，詳述第一性原理和精益敏捷的規模化實施。

前言

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

咱們講第一性原理，先從它的反面「貨物崇拜」提及。

貨物崇拜發生在西南太平洋的小島，二戰時期美軍在這裏駐軍，美軍撤走之後小島發生一個很奇特的現象，小島的原住民部落中興起一個宗教儀式——他們用草木搭起飛機模型，並做爲圖騰來崇拜。

他們每一年按期會在本身的身體上畫出USA三個大字母立隊行軍，拿着木頭槍遊行，並拜飛機，手裏還會拿樹葉翻來翻去，你們猜猜他們在幹什麼？

他們以爲美軍不須要打獵、捕魚卻有充分的物資，這些物資都是島民沒有見過的好東西。他們認爲美軍只是普普統統的人，美軍的種種行爲是在召喚神靈——也就是被他們稱爲鐵鳥的飛機，鐵鳥帶來無窮無盡的物資，而這本是祖先賜予他們禮物的，結果卻被美軍劫持了。

他們以爲本身只要模仿美軍的動做就能夠召喚神的再次降臨，好比翻樹葉——實際上是在模仿美軍翻閱做戰文件。

他們模仿這些行爲，一直堅持到今天，歷來沒有改變過，以致於已經成爲一個宗教，人類學家稱其爲貨物崇拜教，也就是說對那些飛機以及飛機帶來的貨物的崇拜。他們但願經過模仿現象和表象，獲得想要的結果。

咱們在精益敏捷實施裏面也常常看到貨物崇拜，好比咱們產品經理不叫產品經理，叫PO，項目經理不叫PM，而改爲Scrum Master，咱們的需求不叫需求叫故事。咱們也搞各類儀式——好比說站會，搞所謂大規模的敏捷框架，咱們但願對於這種形式的模仿能夠帶來不一樣的結果。

而咱們常常看到形式模仿了，但本質沒有改變。我經歷過不少成功的團隊，也有看到過不少不成功的。托爾斯泰說幸福的家庭都是類似的，不幸的家庭各有各的不幸。

在成功的精益敏捷實施中，個人確看到了共性，它就是聚焦價值交付。不成功的根本緣由各不相同，如理解不到位，方法錯誤，技術能力不足等。可是，不成功的表現形式也有共性，那就是最終都會表現出某種程度的貨物崇拜——只在意形式，而忘記了實質。

這算是個開頭，爲第一性原理作一個鋪墊。今天我主要分享敏捷的規模化實施，會從如下四個方面進行分享：

一、第一性原理
二、產品開發的第一性原理
三、精益和敏捷的規模化路徑
四、以第一性原理檢驗規模化的效果

1、第一性原理

咱們不要貨物崇拜，那咱們該怎麼作呢？咱們應該探尋第一性原理，回到事情的本源。我來解釋一下什麼叫作第一性原理。

第一性原理這個詞很早就存在，可是最近特別熱，多是由於特斯拉的創始人 ELON MUSK吧 ，接受採訪時，他總會提到第一性原理，認爲考慮事情應該注重其第一性原理。以致於如今硅谷投資人也都學會了，常常會問：「這個項目不錯，但是第一性原理是什麼呢？」

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

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

好比他剛作電動車的時候，人們告訴他別作電動車，由於電池成本過高，電動車不可行。Musk是準物理學博士（中途輟學創業，未能取得博士學位），他說咱們要回到第一性原理，那麼問題是：構成電池的基本原材料是金屬元素，這些金屬元素加起來成本是多少，多少錢一度電？好比60美圓左右一度電。

咱們的任務就是無限逼近原材料的成本，由於除了原材料成本以外，其它成本都是人類協做過程之中產生的，就有可能被消除掉，從而逼近原材料成本。這是馬斯克眼中的第一性原理——回到事物的物理本質。

再看喬布斯的第一性原理。他說咱們作一切事情要圍繞產品——公司、管理、技術、銷售、創新都要圍繞產品作。

關於公司，他曾經說，「我建立公司惟一的目的是爲了產品，公司只不過是一種手段，可讓真正有創造力的人合做打造產品。」

關於銷售他說：「我堅信咱們打造好的產品用戶必定喜歡，用戶喜歡必定會給錢，因此銷售不是問題」。

關於創新喬布斯說「我對創新沒有興趣，我只在意偉大的產品，只要把產品作好了，這件事本質作好了其餘會跟着來」。

第一性原理就是要回到事物的本質，從本質出發再一層一層看看咱們應該怎麼規劃其餘的方面。

產品是商業成功的根本，至少喬布斯是這麼認爲的，也是這樣作的。

2、產品開發的第一性原理

那產品開發的第一性原理應該是什麼？我以爲要從理解其根本目標出發，才能回答這個問題。

德魯克說，任何組織的績效只能在它的外部反映出來。咱們探究產品開發的目標，不能從組織內部找，要從它的外部找，要看用戶和價值。管理存在的目的是幫助組織取得成效，他的責任是協調內部資源取得成效。因此說他的第一性原理不在於內部，而是要取得外部的成效，咱們稱之爲：「交付有用的價值」。

咱們內部的種種方式，協調資源作計劃，改善技術或流程都是爲取得外部的成效服務的。對產品開發來講就是要：「順暢和高質量交付有用的價值」，包括三個關鍵字。

順暢，就是交付的過程外部價值要順暢，無論內部怎麼去協做，採起什麼樣的流程，用什麼樣的技術，構件什麼樣的基礎設施，都是要爲價值的順暢交付服務。

固然順暢還要符合質量的要求。

最後交付的價值是要有用的，有用的就是用戶在意的，願意付錢的，能夠爲咱們帶來利益的。若是用4x100米接力賽作比喻，那咱們聚焦應該是接力棒的傳遞而不是運動員是否是時刻在動。產品開發的目的是要把用戶的價值最快的傳遞出去，而不是內部資源是否是時刻忙碌。

3、精益和敏捷的規模化路徑

接下來咱們要講講精益敏捷規模化實施路徑，第一性原理爲咱們的規模化精益敏捷實施的路徑提供了方向性的指導。

3.1 康威定律的啓示

咱們常常看到所謂敏捷的規模化實施方案，會從組織結構的規模化方案開始。這樣作好嗎？

著名的康威定律告訴咱們，組織結構會決定團隊溝通的結構，也會決定產品的結構。聽起來有點抽象，咱們看兩個具體的例子。

康威在一篇論文中給了一個例子，當年有一個團隊要作兩個編譯器，一個叫作 COBOL ，一個叫作 ALGOL ， 一共有8個程序員。團隊評估認爲COBOL 複雜度要比ALGOL複雜，因而給 COBOL 團隊分5我的，給 ALGOL 團隊分了3我的，今後之後這個世界上COBOL編譯分5步，ALGOL的編譯分3步。也就是說產品結構拷貝了組織的結構。

再看另一個例子，我當年作項目經理的時候帶過硬件團隊，爲了激勵團隊讀過一本硬件工程師勵志書《新機器靈魂》，它講的是小型機時代的硬件開發。

當時，一個公司要作小型機，與如日中天的DEC的VAX11競爭。主人公潛入用戶的機房，把用戶的 VAX11打開，看到其中一塊塊電路板，因而他放心了。

書中是這樣說的：「威斯特打開機器，拉開電路板的一刻，他放心了。他從中看到的是DEC組織結構，而不是一塊塊電路板，VAX11過於複雜，他對VAX11各部分鏈接方式不覺得然。由於電路溝通方式拷貝的是組織溝通的方式」。這是一個真實的故事，康威原理也適用於硬件開發。

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

康威定律告訴咱們，一開始去設計和決定組織結構，那同時也就幾乎決定你的產品結構，至少是限制了產品結構。今天市場和環境變化太快，業務自己也須要靈活，產品自己固然也須要靈活性，不能被人爲設計的層次化的組織結構所限制。因此咱們認爲若是上來就去設計規模化的組織結構是不對的，應該避免從組織結構的規模化開始考慮這個問題。

你應該從用戶價值出發去考慮，由實際的業務須要驅動，讓用戶價值交付的須要決定組織的協做方式。在今天這個多變的世界裏，用戶價值的交付須要有靈活性，組織結構也應該有靈活性，這是對康威原理的一個推論。

康威原理說產品會拷貝組織結構，那咱們產品要靈活多變，組織結構也應該是靈活的。因此咱們永遠應該從用戶價值出發，來決定咱們怎麼去作規模化。

從用戶價值出發，我看到兩類規模化的需求。

第一是前後各個順序職能的打通。瀑布開發模式中，開發團隊批量的進行需求的設計、開發、測試，這一方式延遲了價值交付和即時有效的反饋。與之對應，敏捷倡導迭代開發方式。但願迭代地交付價值和獲取反饋，好比 Scrum框架。可是真實世界要更復雜。

更宏觀的看產品交付過程，需求以前還有業務規劃、產品定義等，需求以後還有實施和驗證等。這樣咱們發現若是僅僅在實現階段迭代，總體來看，它仍是瀑布，只不過是更大的瀑布，咱們稱之爲Water-Scrum-Fall，局部的迭代，並不能帶來真正的快速交付和真實反饋。

打通端到端的價值流，這是規模化要解決的問題之一。這才能產生快速和有效的交付。同時也才能產生有效反饋，基於反饋不斷調整保證咱們交付的價值有用。

還有另一種狀況，好比對於一個典型設備製造商，就說華爲吧，要交付一個移動的解決方案，好比 VOIP 、 VOLTE這樣的解決方案可能要涉及到上千人，好比基站、基站控制器、核心網、網管等網絡設備，在電信行業把單個網絡設備成爲網元，每一個網元背後都是相對獨立的開發團隊。

一個網元也有幾百人在作，功能需求還要被分解到一個個功能模塊。這個產品的價值也是分層次的：
在解決方案層咱們稱之爲用戶原始需求；
在網元層稱之爲功能需求；
在模塊層稱之爲可分配需求。
需求也是分層次的。

咱們不可能把一千我的變成跨功能，跨職能的單個團隊。只有各個團隊可以協調一致，並保證各個層次工做的對齊，才能快速交付最終對用戶有意義的價值。

這就引出了規模化要解決的第二個問題——怎麼協調各個層面，最終交付有效的用戶價值、用戶需求。這也就是如何協調每一個層次、不一樣團隊的工做，對齊各個層次上的工做，保證最終用戶價值交付的順暢流動和交付。

總結下來，規模化的敏捷實施要解決兩類問題：
打通端到端的價值流，鏈接價值鏈上的不一樣職能；
在各個層次上協調各個關聯的團隊，保證他們工做的對齊。
經過這兩點聯通先後，對齊左右，目標是順暢交付對外部也就是對用戶有用的業務價值。順暢意味着快速，也意味着高質量。

3.3 規模化精益、敏捷實施的不一樣路徑及其案例

單個小團隊層面和局部環節的實施不能帶來真正的價值交付，那這就提出了規模化的需求。面對這樣的需求咱們來考慮怎麼樣作，下面我會分享一些例子，其中有華爲、平安的，也有創業公司。

這些例子面對的場景和上下文不一樣，其具體的方案也不一樣，但整體上能夠分爲四種模式，它們的共同特色是以團隊級實施爲基礎，再需求更大範圍的規模化應用，最終都是爲了順暢交付價值。

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

3.3.1 融合

咱們先看一個例子，團隊的融合，是兩個團隊被融合爲一個團隊。

這是一家作企業網盤的部門。企業網盤相似於百度雲盤，相對而言，難度在於需求多樣化，好比安全的需求、合規的需求，跟辦公系統集成等。

它涉及兩類技術：
一類是後端的技術，作文件系統、集羣控制，以及各種應用的基礎服務；
一類是前端技術，提供安卓、IOS和Web以及PC的客戶端應用。
先後端兩類技術並不通用，因此很天然他們分紅了先後端兩個團隊，分別作迭代，分別有一塊看板。

這時，若是有一個需求，好比在線視頻播放需求。它會被分別分解爲前端和後端的子需求，前端和後端團隊分別作迭代，兩週一個迭代，後端先作，前端再集成。還須要一個單獨的缺陷管理系統。

有了BUG先提給前端，前端發現是後端的問題，再轉給後端。問題是後端這時正在作下一批需求，相對新需求，咱們認爲解決Bug的優先級更高。但事實執行中卻正好相反，由於新需求有明確的時間要求啊，除非有人追——一般是項目經理來追。

包括剛纔說的排計劃，也就是協調先後端的迭代計劃，也須要項目經理來作。在這裏項目經理是很是關鍵的角色，是一個樞紐，是一個關節點，固然也是一個瓶頸。

這個看板作的好很差？仍是能夠的，至少工做任務的分解和狀態清楚。但它對產品經理友好嗎？不太友好，需求會被拆成什麼樣不知道，也看不到需求端到端的流動，看不到先後端團隊的協做，看不到缺陷和需求的關聯，最重要的是看不到用戶需求的交付過程。

因此咱們要改造它。改造以前咱們用戴明的一句話，戴明說：「若是不能以一個清晰的過程展現你從事的工做，你不會真正瞭解你在作什麼」。對這個團隊來講它並無用清晰的過程展現先後端怎麼協做的，BUG怎麼關聯的，怎麼解決的，價值是怎麼提出並交付給用戶的。因此這個看板對團隊能起到的做用就很是有限了。

這個團隊當時29我的，還有6個產品經理。咱們後來改造了這個看板，先後端要融合在一塊兒，作以用戶需求而不是開發任務爲主體的看板。

改造後的看板上的主體流動單元再也不是開發任務，而是用戶的需求。需求首先進入需求池，也就是圖中的pool，而後是設計中、待澄清等，這時仍是藍色的卡片。到了就緒這個階段，藍色的卡片被轉換成了白色的卡片，咱們稱之爲故事，是打印出來手填的，相對正式一點。從這一步開始故事替代了原先的用戶需求。

接下來看一下這個實現中的故事（Story），後面數據、集羣、應用、Web、PC，這些是什麼？是模塊名稱，既有前端的，也有後端的模塊。各個模塊下是故事分解出的開發任務，其中藍色的是開發任務，黃色是自動測試任務，這些任務之間沒有時間順序關係，作完了就放在完成這一列。完成以後是待驗證，待驗證是需求（也就是story）。

橫向被稱爲泳道，故事和它所屬的任務共同放入一個泳道。當一個泳道中全部的任務完成後，故事也完成了，能夠進入待驗證了。泳道就被清空了，能夠進行下一個故事了。

這個團隊開會的時候，會review看板上的內容。你們以爲是從左到右仍是從右到左的順序更好呢？答案是從右往左，緣由是咱們的最終目的是完成需求，而非開始需求。

開始是一件很是簡單的事情，但團隊交付的速度是完成速度決定的，要趕快把這些接近完成的完成。從右往左，優先完成已經開始的需求，有問題及時解決問題，這也體現了用戶價值的拉動。

這是一個端到端的看板，最左邊的需求池和設計由產品負責，最右邊的驗收是產品驗收。因此它從產品開始到產品結束，是用戶價值從提出到交付端到端的過程。同時它也反映了團隊協做、需求的分解和合並、缺陷和問題。

作完這個看板之後我問負責這個產品的公司副總裁三個問題：
能不能清晰全面的反映需求和交付的過程？
瓶頸和問題能不能在看板上獲得及時的體現？
團隊能夠根據看板的信息協做作決定嗎？

他對前兩個問題的回答是確定的，但第三個問題還有些不肯定，由於團隊的協做須要明確的規則，後來團隊又定義了更加明確的協做和需求流轉規則，這樣更多的協做就能夠由團隊自主完成，圖中是其中的一個例子，它定義了什麼樣的需求才能叫就緒。

上面的融合是第一個規模化的場景，它讓咱們看到端到端的價值流動，以及團隊協做交付需求的過程，能夠更加順暢地發現解決瓶頸和問題，更加順暢高質量的交付價值。

3.3.2 拓展

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

這個看板跟上面的很是像。業務看到這個看板後以爲很是好。說：「原來大家把咱們叫作需求池，大家知道咱們在需求池這個階段作了多少工做嗎？」

業務決定也要作一個看板，在他們的看板中，首先就把整個開發看板中的各個階段壓縮了，變成了一個小小的開發階段。測試強調了用戶驗收測試（UAT）外，還加上了生產驗證，也就是在生產環境中觀察業務的運營和驗證明施的效果。而需求在提出給開發前的工做也被清晰的呈現出來了，好比初始的創意和業務設計，內部的業務評審，業務交互的設計，視覺設計等。

這是一個業務看到的端到端的看板，這個很好。咱們有時候沒有條件一開始就徹底打通整個端到端的價值流，這時能夠從局部作起，條件成熟的時候須要向兩端拓展，拓展的目的是要從業務的角度更加端到端，讓端到端價值的交付過程更加順暢，這是一個拓展的方式，最終仍是爲順暢交付外部的用戶價值服務。

3.3.3 鏈接

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

這個團隊比較複雜，有四個異地團隊構成：業務方在深圳，底層服務在上海，上海開發完了給成都作應用開發，再給深圳作接收測試。原本上海開發團隊有一塊看板，成都開發團隊有一塊看板，都是物理形式的。

在這樣複雜的組織結構下，咱們天然會擔憂價值交付的速度很慢，由於涉及到這麼多團隊之間的交互。

做爲解決方案，咱們要設法把這兩塊看板鏈接起來，同時也要業務團隊包含進來。咱們用電子看板來完成這一任務，但物理看板仍然保留着。

電子看板的流程是從業務側開始，需求做爲業務設計後，由上海團隊進行分析，分析以後作API開發，一旦進入API開發階段，上海開發團隊，也會copy一份到本身的物理看板裏面。

物理看板的信息更細緻，會分解成更細的任務，而電子看板裏只有需求，不體現任務，它更關注的是價值流動，而不是具體環節的任務跟蹤。等上海團隊開發完成，需求放入API開發完成列，這一列也至關於成都團隊的需求池，成都團隊開發完了再給業務方驗證。

電子看板有一個好處，它的度量會變得很是容易獲得，也很是及時。

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

經過累積流圖，能夠看需求在各個階段之間的分佈，在最右面的階段是UAT用戶驗收測試，它佔據了差很少一半的時間。說明要想縮短需求的交付實踐，仍是應該及時作驗收測試，固然具體緣由就須要具體分析了，也有多是業務並不緊迫，也可能開發給個人東西不可測試。

可是不管如何縮短UAT這個階段的時間，是咱們改進交付時長的着手點。因此把它真正鏈接起來，打通端到端的價值流，之後就能夠去分析改進，產生系統的改進，而不是一個局部的改進。這是規模化的第三個路徑——鏈接。

3.3.4 層次化

再看看華爲這個例子，相對要更復雜一些，他們的產品是分層次的，價值也是分層次的。

需求能夠分爲用戶需求、功能性需求和模塊需求。用戶需求被分解成一個個故事稱之爲功能需求，用戶需求是最小的交付單位，用戶故事是一個集成和功能驗證單位，最下面還有子模塊任務，是不可作系統測試的，它能夠分配給某個團隊，是分配單位。

這種狀況下，咱們怎麼規模化實施？仍是要回到價值順暢交付上來。固然這裏的價值最終應該是用戶需求。這裏的需求層次較多，達到了三層，相應的看板也須要分層。

上層是解決方案層看板，實際上是作規劃用的。這裏的泳道中，綠色的是用戶需求，藍色是故事，故事隸屬於用戶需求。咱們在解決方案層要約束並行用戶需求的數目，就是並行的用戶需求數目不能太多了，由於並行的少就逼迫咱們把已經開始的儘快完成掉，讓各個團隊，各個網元對齊和一致。

泳道數有限的，起到了約束並行用戶需求的數目的做用，讓故事向用戶需求對齊，咱們追求的是用戶需求的快速完成，而不只僅是完成更多的故事，可是需求作不完。更重要的是讓故事向用戶需求對齊，儘快和順暢地交付用戶需求。

解決方案層的看板只有一個，起到總體規劃的做用，處於上層。它的下一層次是項目看板，每一個網元都有本身的項目，對一個單獨的看板。看板上，藍色的是故事，黃色的是子模塊的任務。一樣在項目層面要約束並行故事的個數，讓任務向故事對齊，咱們追求故事的快速交付。

如今的問題是這兩塊看板可以聯動起來嗎？能！由於故事在兩個層次都出現了，在項目層面追求任務向故事的對齊，讓故事快速完成；在解決方案層追求故事向用戶需求的對齊，讓用戶需求的快速完成。

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

4、從第一性原理反饋規模化的效果

怎麼更加順暢高質量交付真正的價值這是咱們要考慮的，固然咱們還要創建所謂的反饋機制，有了剛纔說的各類方法，端到端的價值流拉通之後，就爲系統改進價值流動打下了基礎。

而精益、敏捷實施的改進效果也應該以價值的流動爲基礎來衡量。好比需求從提出、確認到交付的前置時間，好比開發完成到測試開始之間的等待時長等。其中前面提到過的累積流圖，就是反映價值流動的一個例子。

如上圖所示，橫線的長度是時間，縱向是有多少並行的在製品，斜率是速度，累積流通反映的是價值流動和團隊協做的過程，中間有哪些等待、瓶頸或改進的空間，以及過去一段時間的改進趨勢等。精益的度量和反饋已經造成了一個以價值流動爲核心的度量體系，這裏再也不一一列舉。

總結

咱們從第一性原理出發，今天咱們講了規模化實施的四種方案。規模化應該被用戶需求，被順暢和高質量的交付價值驅動出來的。

不能由於組織的規模大就要有規模化的框架，其實不少時候，你會發現你並不須要很複雜的方案。只在有實際業務須要時再考慮規模化方案，永遠選擇夠用但最簡的規模化方案。

針對不一樣的場景，選擇與之匹配的最簡方案。好比這兩個看板怎麼融合起來，怎麼鏈接上下游，怎麼從一個地方開始向上下游拓展，怎麼作出一個層次化的方案，可是最終都服務於順暢的交付。

其實，咱們一直在講看板，但看板只是一個載體，它背後是一個價值交付的團隊和單元。

如今規模化敏捷、規模化精益實施有不少流行的框架。最近 Ron Jeffries 寫了《軟件開發本質論》一書，他評價了大規模敏捷框架的忽然流行。他說大公司開始作敏捷了，他們很天然會想大公司須要大規模。Jefferise說我相信他們會取得成功，然而那隻會是諮詢公司的成功，而不是實施敏捷和精益的公司的成功。大公司須要的並非大規模，而是須要真正敏捷的方法和技術自己。

我很是贊成Jefferise的說法，去模仿照搬一個規模化的框架，正是貨物崇拜。咱們應該作的是，回到問題的本質，回到咱們的目標，再決定怎麼才能順暢、快速、高質量的交付價值。

Denning有過相似的描述，他總結了微軟實現敏捷規模化的16條原則，其中特別強調，咱們要追求的是敏捷的規模化，而不是規模化的敏捷。也就是說咱們要讓敏捷成爲公司範圍內實施的方法，實現正在的敏捷性，並順暢交付價值。而不是要搞一個規模化的框架，那反而會制約咱們。

規模化的敏捷的需求的確存在，但它應該不是被組織的規模決定和驅動的，而是需求交付的複雜性，和產品及服務的真實複雜性驅動出來。

咱們爲了順暢和高質量地交付有用的價值，是我心目中的產品開發的第一性原理，是不能被忽略的基本出發點，也不能被違反。咱們認爲有了高質量的交付價值，並打通端到端的交付過程，不斷反饋讓價值順暢流動，並以快速的價值反饋和驗證來探索真正的價值，這纔是咱們要作的東西。

如下是個人書《精益產品開發原則方法和實施》前言寫的東西，我稱之爲精益和敏捷宣言，我用它來結束本文的分享。

敏捷宣言是2001年發佈的，當時叫敏捷軟件宣言，今天咱們看價值的角度須要對它進行拓展，這些年互聯網特別是移動互聯網的發展突飛猛進，對產品開發提出了更高的要求。個體和互動重於流程，可是咱們要鏈接和打通組織的各個職能以確保協調一致的行動。咱們尊崇可工做的軟件，重於面面俱到的文檔，可是更重要的是要交付價值，要聚焦端到端價值流動以快速靈活交付真正客戶的價值。客戶合做重於合同和談判，在今天選擇權愈來愈向用戶側轉移的時候，咱們要與客戶創建共同目標，以最大優化業務成果。咱們尊崇響應變化，可是響應變化是被動的，今天要有計劃和系統主動的試錯以支持咱們有效的學習和創新。因此今天時代不一樣了，咱們提出比過去高得多的要求。敏捷規模化需求是真實存在的，但仍是要避免沒必要要的各類規模化的框架，爲了規模化而規模化，更不要作所謂的貨物崇拜。因此咱們要回到問題的第一性原理——順暢和高質量交付有用的價值。