前言：新常態下的精益產品開發和創新
2008 年，我開始在自己的產品開發部門嘗試敏捷實踐，當時這樣做是前衛的，有爭議的。9 年后的今天，大部分組織爭論的焦點不再是要不要變得更敏捷，而是“如何才能做到”，后者從來都是個難題。
10 年間，敏捷實踐不斷完善，但實施難度卻變大了。不是我們的進步不夠快，而是現實要求越來越高。移動互聯網技術改變了我們的生活，對各個行業的沖擊更加劇烈。新的商業模式和技術革新不斷涌現，新入者隨時有機會脫穎而出，傳統的優勢廠商則隨時面臨巨大的挑戰。
美國軍方曾經用四個特性來概括冷戰后的世界：易變 (Volatility)；不確定 (Uncertainty)；復雜 (Complexity)；模糊 (Ambiguity)。它們的首字母合在一起是 VUCA，“VUCA World”在 20 世紀 90 年代是常用的軍事術語，用以形容全球政治和軍事格局。21 世紀以來， VUCA 被更多用于形容商業格局和企業所處的生態，成為我們當下移動互聯時代和即將到來的機器智能時代的最佳注腳。
在 VUCA 的世界中，黑天鵝和跨界打劫司空見慣。勝出者的共同特點是擁有快速反應和把握機會的能力以及系統化的試錯、創新和價值創造能力。擁有這些能力就有機會快速上位，反之則隨時可能被淘汰出局。而隨著信息技術向縱深的發展，再傳統的行業也不可能置身事外，這是企業運營和產品開發面臨的“新常態”。
面對新常態，人們不再懷疑敏捷的必要性，而且要求的更多。產品的持續創新事關生死，產品開發部門不應該再被看成組織內部的成本中心，而是要成為價值探索、發現、創造和驗證的創新中心，是企業的核心競爭力所在。
今天我們講敏捷與 10 多年前相比，對它的要求發生了根本改變。 2001 年《敏捷宣言》發布時，針對的是軟件開發，所以它的全稱是《敏捷軟件開發宣言》， 17 位起草人也全部是軟件開發專家，宣言的本質是尋求更好的軟件開發方法，強調了軟件開發中的有效溝通、迭代交付和靈活應變。上圖是宣言的內容，它引領了軟件開發方法學的思潮，直到今天仍舊在發揮重要的作用，但今天我們再講敏捷，要求有了以下本質上的提高。
我們尊崇“個體和互動”，更要“連接和打通組織的各個職能，以確保協調一致的行動”。
我們尊崇“可工作的軟件”，更要“聚焦端到端的價值流動，以快速、靈活和持續地交付真實的客戶價值”。
我們尊崇“客戶合作”，更要“與客戶建立共同目標，以最大化業務成果”。
我們尊崇“響應變化”，更要“有計劃和系統地主動試錯，以支持有效地學習和創新”。
“一致行動，快速、靈活和持續地交付真實的客戶價值，最大化業務成果，有效地學習和創新”，這是新常態對產品開發組織的敏捷性要求。與這一要求相對應， 10 年間我們看到了另一個顯著的變化——精益思想和實踐被廣泛和深入地應用在產品開發當中，無處不在。
�6�1 精益成為幾乎所有規模化敏捷框架（如 SAFe、LeSS 等）背后的重要方法學支撐。
�6�1 精益看板方法得到越來越廣泛的應用，為敏捷變革和提升組織交付能力提供了新的路徑。
�6�1 精益創業成為熱點，精益創業理念和實踐開始被廣泛接受和實施。
�6�1 DevOps 實踐開始普及，而精益價值流動的思想在 DevOps 實踐體系中扮演了重要的角色。 2016 年下半年，我開始在自己的公眾號“精益產品開發和設計”（微信號LeanAction）發文，總結精益設計和精益看板方法實踐，受到了圈內圈外超出預期的關注，很多朋友從這些文章開始實施精益開發方法，我幾乎每天都能收到不同形式的反饋。有
的甚至成立學習小組，每周學習一篇文章，堅持了數月。這讓我決定更系統地總結精益產品開發實踐，最終形成今天您手上的這本書。
本書的目的是為組織的精益和敏捷實施和提升提供原則、方法和實施步驟的有效指引，幫助企業打造移動互聯網時代的產品交付和創新能力。它的適用范圍涵蓋幾個人的創業團隊到華為與招行這樣的大型組織。
寫作本書時，我對自己有三個要求：其一，所有實踐都必須有真實案例支持；其二，所有案例都必須來自本人的實踐；其三，只選取那些被證明有效且易于實施的實踐。
本書案例全部來自華為、招商銀行、平安科技、上海愛數軟件以及幾家創業公司，作者與這些公司都有兩年以上持續而深入的合作。
本書適合的讀者
本書適合以下讀者：
�6�1 希望開始實施精益或敏捷開發的組織或項目管理人員
�6�1 已經實施敏捷和精益開發，但遇到困難和阻力的組織或項目管理人員
�6�1 已經實施敏捷和精益開發，希望進一步深化和拓展的組織或項目管理人員
�6�1 希望了解精益和敏捷產品開發方法和實踐的產品開發從業人員
�6�1 希望提高產品開發交付和創新能力的各類角色
如何閱讀本書
本書分成三部分，分別介紹精益產品開發的原則、方法和實施。
第 I 部分“精益產品開發的原則”介紹敏捷和精益開發的目標、思想和原則，并由這些原則出發，構建完整的精益產品開發實踐體系。
第 II 部分“精益產品開發的方法”介紹看板方法實踐體系，用看板方法來承載組織的交付流程和價值交付能力的持續改進。
第 III 部分“精益產品開發的實施”將從破解資源效率和流動效率的悖論出發，介紹精益產品開發的實施步驟，并詳細介紹需求管理、質量改進、團隊管理等方面的實踐和實施。在這一部分，我還請到了兩位大咖分享他們的的洞見和實踐。其中，呂毅分享了關于 Scrum 的洞見，并比較了 Scrum 和看板方法，王津銀分享了 DevOps 的實施原則。他們兩位在各自的領域都是國內最頂級的實踐者和專家。
本書三個部分具備一定的連貫性，同時也可以獨立存在。大家可以根據自己的需要和興趣有重點地閱讀或作為備查。但是，我個人認為從頭閱讀收獲會更大。
目錄
第Ⅰ部分 精益產品開發的原則
第1 章 從傳統向敏捷軟件開發的演進 ...............3
傳統軟件開發方式面臨的挑戰 .................3
從傳統到敏捷 .........5
理解敏捷必須回歸業務視角 ....................6
敏捷產品開發的業務目標一：更早地交付價值 .............7
敏捷產品開發的業務目標二：靈活地應對變化 .............9
敏捷實踐體系 .......10
第 2 章 精益產品開發的核心原則（上）：聚焦價值流動效率...............15
聚焦用戶價值端到端的流動 ..................15
從資源效率到流動效率 .........................20
協調多個團隊才能提升流動效率 ...........22
第 3 章 精益產品開發的核心原則（下）：探索和發現有用的價值........27
做一個能賣出去的產品 .........................27
開發、測量和認知循環 .........................29
從傳統的產品定義方法到精益創業........30
精益創業實踐集合 32
第 4 章 精益思想和精益產品開發實踐體系......35
精益思想的來龍去脈.............................35
精益的三個層面....39
精益產品開發實踐體系 .........................41
第 5 章 經典天文學演進對產品開發方法學的啟示 ................49
經典天文學的三個里程碑......................49
經典天文學演化過程給產品開發的啟示.54
尊重歷史，更要面向未來......................56
第Ⅱ部分 精益產品開發的方法
第 6 章 看板方法和看板實踐體系....................61
看板方法的起源....61
看板形成拉式生產方式帶來的收益........64
產品開發中的看板方法 .........................65
第 7 章 可視化價值流動（上）：案例.............75
案例背景介紹 .......76
初始的看板系統設計.............................76
看板系統的重新設計.............................77
案例總結 ..............79
第 8 章 可視化價值流動（下）：看板系統建模...................83
看板系統設計的原則和步驟 ..................83
步驟一：分析價值流動過程 ..................84
步驟二：選取可視化設計元素...............87
步驟三：建模價值流動 .........................94
第 9 章 顯式化流程規則..97
組織并明確流程規則.............................98
團隊共同擁有規則 ..............................102
持續改進流程規則 ..............................103
第 10 章 控制在制品數量（上）：為什么要控制 ................107
束水攻沙 ............107
產品開發中的在制品 ...........................110
在制品帶來的問題 ..............................113
第 11 章 控制在制品數量（中）：控制什么 .117
暫緩開始、聚焦完成 ...........................117
以用戶價值為單位控制在制品數量 ......118
控制而不僅僅是限制 ...........................119
第 12 章 控制在制品數量（下）：如何控制 ..123
湖水巖石效應 .....123
限制在制品的原則 ..............................124
限制在制品的常見形式 .......................125
確定初始限制值 ..126
第 13 章 管理價值流動（上）：看板站會 .....129
站會的目標 .........130
站會的組織形式 ..130
站會重點關注的信息 ...........................131
站會過程 ............132
第 14 章 管理價值流動（中）：就緒隊列填充 ...................135
什么是就緒隊列和就緒隊列填充 .........136
建立就緒隊列填充的節奏 ....................137
組織就緒隊列填充 ..............................140
第 15 章 管理價值流動（下）：發布規劃會議 ...................145
發布規劃會議的內容和節奏 ................145
部署和發布應該是兩個不同的概念 ......147
解耦部署和發布 ..148
特性開關 ...........150
完美的敏捷愿景 ..152
第 16 章 建立反饋，持續改進（上）：定性反饋和改進 ....155
如何建立良好的反饋 ...........................156
關于順暢程度的反饋 ...........................157
關于質量的反饋 ..159
將改進落實為具體行動 .......................160
第 17 章 建立反饋，持續改進（下）：定量的綜合反饋和改進...........163
累積流圖 ............163
控制圖 168
前置時間分布圖 ..170
第 18 章 看板方法的規模化應用 ...................173
融合兩個看板系統 ..............................173
連接多個看板系統 ..............................175
向上下游拓展看板系統 .......................177
層次化看板系統 ..178
第Ⅲ部分 精益產品開發的實施
第 19 章 實施精益產品開發，提高價值交付能力 ................185
衡量和評價組織的交付能力 ................185
流動效率和資源效率的關系 ................186
從資源效率入手的改進無法持續 .........187
打破組織效率改進的困局 ....................188
第 20 章 精益和敏捷需求：精益產品開發的源頭 ................199
在問題域分解需求 ..............................199
找到真正的問題 ..201
從問題到解決方案的進一步分解：影響地圖 .............204
挖掘、組織和規劃需求：用戶故事地圖 ....................208
端到端的需求流動 ..............................210
第 21 章 精益質量改進 .213
產品開發中的質量模型 .......................213
實施精益質量改進的前提 ....................217
落實精益質量改進的步驟 ....................219
第 22 章 打造高效的自組織團隊 ...................227
自組織困難的根源 ..............................227
打開團隊自組織的密碼 .......................229
自組織是管理提升的結果 ....................232
第 23 章 對 Scrum 的洞察，以及 Scrum 和看板方法的比較 ...............237
Scrum 活動設計 .238
Scrum 角色選擇 .241
對比 Scrum 和看板方法 ......................242
第 24 章 實施 DevOps 的實踐原則 ...............245
基礎原則 ............246
實施原則 ............250
支撐原則 ............256
第 25 章 在具體上下文中實施精益產品開發 ..261
對產品交付過程的抽象 .......................261
實施精益產品開發的步驟 ....................262
精益產品開發實施中的基礎和持續性的工作 .............266
附錄一 生成精益度量圖表的模板工具 ...........269
附錄二 物理看板和電子看板的比較及常見電子看板工具介紹 .............273
附錄三 精益產品開發相關圖書推薦 ..............277
后記...............279
第1 章 從傳統向敏捷軟件開發的演進
在產品開發中，“敏捷”和“精益”這一對熱詞如影隨形。精益產品開發離不開對敏捷軟件開發的深入理解，所以我們的精益之旅也將從敏捷軟件開發開始。本章講述軟件開發從傳統進化到敏捷背后的業務動因以及敏捷軟件開發實踐體系。
傳統軟件開發方式面臨的挑戰
傳統軟件開發方法是與軟件工程的概念一同誕生的（圖1-1）。1968 年，北約（NATO）召開全球第一屆以“軟件工程”命名的會議，這次會議通常被視為軟件工程誕生的標志。會議上提出了“軟件危機”的概念。隨著軟件復雜度的不斷提高，軟件項目普遍出現預算超支、質量低、性能差、不符合實際需求和延期等問題，造成所謂的“軟件危機”。
圖1-1 傳統開發方法的產生歷程
當時，業界普遍認為，軟件行業應該借鑒工程領域的經驗，“系統地應用工程管理方法”，以此來應對軟件危機。這是軟件工程誕生的背景，在這一思路下產生的軟件開發方法就是傳統軟件開發方法。它們共同的特點是強調計劃、管控和結構化的工程方法，并遵循嚴格的生命周期概念，把軟件開發分割為順序階段構成的過程，瀑布式開發方法是其中的代表之一。
相比作坊式的開發，傳統方法開發方法進步明顯。它讓產品開發有矩可循，讓項目和產品的成功可以重復，讓組織的能力可以被評估，這些當然是好的。圖1-1 是傳統開發方法的大致發展歷程，到了上世紀90 年代初，CMMI 和PMI 項目管理知識體系[1] 成為傳統產品開發管理方法的典型代表。
然而，傳統方法并沒有從根本上解決軟件危機，軟件項目的失敗率依然居高不下，甚至越來越糟糕。在這方面被引用得最多的是Standish Group 定期發布的IT 項目報告[2]，該報告在1994 年第一次發布時的數據顯示，項目成功比例只有16%，有31% 在發布前就被“砍掉”，剩下的53% 平均超出了預算189%。
人們認識到，遵循嚴格生命周期的概念，把開發分割為順序階段構成的過程，實施起來不現實，造成了以下直接的危害。
�6�1 希望通過對各個階段設置關卡，嚴格控制，以期更早地發現問題，卻滯后了集成和測試，讓錯誤的發現延遲到最后，這是很多項目失敗的根源。
�6�1 希望一開始就能設定完整和正確的需求，這對軟件產品越來越不可能，因為用戶也不知道或說不清楚自己想要什么。事實上，對需求的挖掘和理解，應該是一個持續的過程，需要不斷的反饋。
�6�1 把成功定義為“遵循最初的計劃和范圍”。為了確保項目的“成功”而避免或拒絕進行合理的變更，卻忽略了“達成商業目標才是真正的成功”。這已經成為業務成功的一個嚴重障礙。
另一方面，傳統產品開發方法強調控制，所以一旦流程出現問題，自然的應對就是進一步加強管控，流程本身有自我復雜化的趨勢，反而會壓制關鍵軟件開發人員的主觀能動性。
面對以上問題，對傳統軟件開發方法的反思，幾乎與其本身一樣悠久。比如，瀑布模型的提出者Wiston Royce 1970 年在他的論文[3] 中，只是把瀑布模型作為一個理論模型提出，并警告人們它絕對不適合用來進行大型軟件開發。在論文的后半部分，Royce 提出了一個包含原型和各階段之間反饋的修正模型。遺憾的是，業界當時渴望的是一種建構式工程方法，瀑布模型迎合了這一要求，導致反對瀑布模型的Royce 反倒被業界稱為“瀑布模型之父”。至于Royce 的忠告，也只有等到30 年后敏捷運動興起時才又被人們重新提起。
從傳統到敏捷
面對傳統軟件工程方法的現實問題，一批輕量級的軟件開發方法陸續涌現（圖1-2），它們共同的特點是遵循演進和迭代的模型。其中，上世紀90 年代出現的Scrum 和極限編程在實踐上最為成功，它們都是迭代和增量的軟件開發框架。兩者的區別是，Scrum只包含管理實踐，而極限編程同時涵蓋工程和管理實踐。
圖1-2 敏捷產生和發展的歷程
上世紀90 年代，另一個主要變化是PC 軟件流行和第四代編程語言的出現，面向對象和設計模式運動的興起，使小型開發項目蓬勃發展，同時互聯網應用和開源社區也在此時興起，有別于傳統的開發模式不斷涌現，優秀個人在程序開發中的作用越來越明顯。
這些因素都讓非傳統開發方法有了實驗的土壤。其結果是，一方面質量問題層出不窮，促使源自全面質量管理體系的CMM/CMMI 在這一時間迅速繁榮和推廣；另一方面也產生了許多不同于傳統方法的有效實踐，讓業界看到新的可能。敏捷運動這時呼之欲出，它既是對傳統的反叛，也是對野蠻生長的規范。
2001 年2 月，17 位輕量級軟件工程方法的代表人物齊聚美國猶他州的雪鳥滑雪勝地，在兩天的會議之后，發布了對后來產生巨大影響的《敏捷軟件開發宣言》[4]，如圖1-3所示，敏捷宣言陳述了他們共同認可的軟件開發方法理念，同樣重要的是，他們找到“敏捷”這個詞來總領這些理念。
敏捷概念在2001 年出現，可謂適逢其時。當時一方面，傳統方法變得越來越臃腫笨重，卻沒有解決軟件危機；另一方面，人類正在進入互聯網時代，軟件業對響應變化和創新的要求迅速升級，這是更根本的原因，畢竟需求才是行業發展最好的助推劑。很快，敏捷成為一場運動，被迅速推廣和應用。
圖1-3 《敏捷軟件開發宣言》
理解敏捷必須回歸業務視角
《敏捷宣言》屬于價值觀層面的宣導，對敏捷的推廣和公眾的認知起到了很大的作用。但對于敏捷是什么，卻從來沒有統一的定義。2010 年，軟件工程大師Ivar Jacobson 在一篇博文中這樣說：“過去你問我支不支持敏捷，我會說哪些支持，哪些不支持，并給出我的理由。但現在你再問，我就只能回答支持。因為，如今敏捷的意思已經演變成“軟件開發中一切好的東西（Everything good about software development）。”Ivar 一語道破了真相。如圖1-4 所示，敏捷成了一個集合性的概念，一切好的，都歸入敏捷，而一切失敗，都歸于不敏捷。這在商業上或許不錯，卻不利于概念的明晰和有效實施。
畢竟，要真正理解敏捷，還是要回歸業務目標。產品開發的最終目標是業務成功，這是沒有異議的。接下來我們將從目標出發，理解敏捷的意義所在，并以此來指導我們具體落實敏捷實踐。
圖1-4 霧里看花，敏捷是一個集合性名詞
新書資訊