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

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

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

前言

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

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

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

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

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

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

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

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

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

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

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

1、第一性原理
2、產品開發的第一性原理
3、精益和?捷的規模化路徑
4、以第一性原理檢驗規模化的效果

一、第一性原理

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

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

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

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

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

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

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

關于公司，他曾經說，“我創建公司唯一的目的是為了產品，公司只不過是一種手段，可以讓真正有創造力的人合作打造產品。”

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

關于創新喬布斯說“我對創新沒有興趣，我只在乎偉大的產品，只要把產品做好了，這件事本質做好了其他會跟著來”。

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

產品是商業成功的根本，至少喬布斯是這么認為的，也是這樣做的。

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

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

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

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

順暢，就是交付的過程外部價值要順暢，不管內部怎么去協作，采取什么樣的流程，用什么樣的技術，構件什么樣的基礎設施，都是要為價值的順暢交付服務。

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

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

三、精益和?捷的規模化路徑

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

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 層次化

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

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

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

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

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

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

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

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

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

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

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

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

總結

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

不能因為組織的規模大就要有規模化的框架，其實很多時候，你會發現你并不需要很復雜的方案。只在有實際業務需要時再考慮規模化方案，永遠選擇夠用但最簡的規模化方案。

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

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

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

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

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

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

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

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

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