具體描述
産品特色
精益七大原則：消除浪費、增強學習、盡量延遲決策、盡快交付、授權團隊、嵌入完整性、著眼整體
看闆六大實踐：可視化、限製、管理流程、製定明確規則、落實反饋循環、持續演進
SCRUM+看闆：看闆牆的設計，看闆一日遊
個人看闆的應用：第一步為視覺化工作流程，第二步為半成品限額
持續改進
編輯推薦
根據精益（Lean）觀念而來的精益軟件開發儼然已成為軟件開發項目的主流精神。通過看闆方法（Kanban Method），精益理念可以落實到整個開發流程，
提高應變能力、減少無謂的資源及時間浪費，全力開發團隊開發效能。
內容簡介
本書作者從事軟件開發多年，善於吸取敏捷和精益這兩種開發方法的精髓，對看闆的理解和應用具有實用而豐富的經驗。他在本書中依托精益開發中的主流工具，介紹瞭看闆的概念、遵循的基本原則、看闆的適用範圍和具體使用等。精益軟件開發是當下軟件開發項目的主流。看闆可以使得精益理念落實並貫穿於整個開發流程，從而提高應變能力、減少無謂的資源及時間浪費、完全發揮團隊的開發效能。本書適閤所有軟件從業人員（從項目經理到工程師）閱讀，可以幫助他們從容應對韆變萬化的客戶需求。
作者簡介
李智樺，在軟件開發領域已有多年的實踐經驗，他對信息及軟件應用開發的熱情和投入令人佩服，包括新興的行動及雲端開發技術的研究，近年來投身於敏捷、精益及看闆方法的推廣並擔任講師，本書可以讓更多人瞭解這些軟件開發及項目管理的實用方法並應用於工作領域之中，值得閱讀！擁有超過30年的軟件開發工作資曆。從早期的大型銀行係統到近年來專注於微軟各項新技術的研究，是微軟Windows Azure雲端及其他新開發技術的指定講師，擔任多屆TechDay、TechED等大型研討會主場演講。過去是資深的開發人員、大型係統及企業的總架構師，有長期同時帶領多個團隊的ScrumMaster大型項目經驗。他對信息技術的熱誠及堅持，至今仍對新技術的動手實操不遺餘力，是少數擁有如此豐富資曆、能講、能教、隨時能上手的信息界老兵。
李淳 Certified Scrum Master、Certified Scrum Product Owner，曾先後在用友、易車等公司任程序員、研發經理、架構師、産品經理，敏捷和精益倡導者，團隊敏捷轉型實踐者，公眾號“互聯網plus管理新範式”（iPlusLeadership）維護人。代錶譯著有《軟件需求（第3版）》
目錄
第1章 精益軟件開發 11-1 精益的由來 2
1-2 精益軟件開發 3
1-3 精益軟件開發七大原則 5
1-4 結論 27
第2章 看闆方法 29
2-1 看闆的由來 30
2-2 何為“看闆方法” 30
2-3 看闆方法四大基本原則（Foundational Principles） 32
2-4 為何要使用看闆方法 39
2-5 哪些地方可以運用看闆方法 45
2-6 結論 48
第3章 看闆方法的六大核心實踐 49
3-1 可視化目前的工作流程 50
3-2 限製半成品（WIP）數量 58
3-3 管理工作流程 65
3-4 讓規則明確 69
3-5 落實反饋循環 71
3-6 由協作改善，經實驗演進 72
3-7 結論 75
第4章 如何實施看闆方法 79
4-1 看闆牆的設計 80
4-2 Scrum 運作模式的看闆牆設計 91
4-3 看闆一日遊 94
4-4 運行看闆方法的簡單規範 106
4-5 結論 111
第5章 個人看闆：類項目管理 113
5-1 個人看闆 114
5-2 製作第一個個人看闆 115
5-3 個人看闆與軟件開發：類項目管理 124
5-4 結論 140
第6章 個人看闆與生活：讓生活與工作相得益彰 143
6-1 開始使用看闆 144
6-2 生活與效能 148
6-3 個人看闆進階 156
6-4 結論 157
第7章 預測未來：減少變異性，增加可預測度 161
7-1 係統思考 163
7-2 內部變異 167
7-3 外部變異 174
7-4 結論 177
第8章 持續改進 179
8-1 看闆方法的問題管理 181
8-2 運用看闆方法自然形成簡單的團體規範 183
8-3 沒有銀彈（No Silver Bullet） 186
附錄 189
附錄A 精益咖啡 190
附錄B Scrum But 和 Kanban But 194
附錄C 用戶故事圖譜：對付需求模糊的好幫手 199
附錄D 敏捷開發需要哪些文件 203
精彩書摘
第1章精益軟件開發
1-1 精益的由來
“精益”（Lean）這個詞匯是約翰?剋拉夫西剋（John Krafcik）1988年在他的一篇文章 裏率先提齣來的，但他所稱的精益製造（Lean production），指的是製造業的精益理論，而軟件界的精益（Lean）則稱為精益軟件開發（Lean Software Development），它源自於波彭迪剋夫婦（Mary Poppendieck 和 Tom Poppendieck）在 2003 年的著作《精益軟件開發工具》（Lean Software Development：An Agile Toolkit），書中闡述瞭精益軟件開發的七大原則，精益屬於敏捷開發的成員之一。
敏捷軟件開發（Agile software development）是從 1990 年代開始逐漸取代傳統開發方法的一些新型軟件開發方法，是一種應對快速變化需求的軟件開發能力。相對於傳統開發方法，敏捷軟件開發最大的差異在采用迭代式的開發模式，而不是一次定江山的瀑布式開發模式，以及接受客戶對需求閤理的變更（讓客戶對需求做齣不同優先等級的區分，並盡力去滿足它）。
敏捷（Agile）一詞起源於 2001 年初，敏捷方法發起者和實踐者在美國猶他州雪鳥滑雪聖地的一次聚會，有 17 位當代軟件代錶人物共同簽署瞭敏捷宣言，並成立瞭敏捷聯盟。但在此之前，早在 1991 年麻省理工學院齣版的“改變世界的機器”（The Machine That Changed the World）研究報告中，就已經把日本豐田公司的豐田生産方式係統（TPS）歸納成為一套精益生産（Lean Production）方法。
嚴格來說，精益（Lean）比敏捷（Agile）要早誕生許多年，但現在擁戴精益的人士也已經加入瞭敏捷聯盟的陣營（見圖1-1），雖然他們依然遵循著精益精神的七大原則而不是敏捷的四大宣言和十二項原則，但實質上他們都共同擁護敏捷式的開發方法及精益精神，二者並無抵觸。
圖1-1 敏捷傘下的兩大陣營
1-2 精益軟件開發
精益軟件開發並沒有具體的開發方法或步驟，而是一堆原則，原因是它認為沒有所謂的最佳實踐。“原則”具有較廣泛的普遍性，能指導對某一學科的思考和領悟，而“實踐”則是為執行原則而采取的實際措施，需要針對某一領域進行調整，尤其必須考慮到具體實施的環境。精益軟件開發是由軟件開發領導者，例如軟件開發部經理、項目經理和技術領導者，而不是一般程序開發人員所創設的思想工具。
因為精益軟件開發沒有具體的實行方法，這會讓你覺得它隻是一些原則和教條，執行起來應該是最簡單的，影響也不大，即便做錯瞭也是無害。如果這麼想的話就錯瞭，因為“原則”所影響的是企業的文化層麵，比起單純的開發方法影響大得多瞭。
依照圖1-2的區分，右邊第二位隸屬於精益開發體係下的看闆方法（Kanban），是距離鬍作非為（Do Whatever，“鬍來”，也就是完全沒有規範）最接近的敏捷開發方法。越往右側的開發方法就錶示規範越少，我們稱為輕量級（light weight）的軟件開發方法，越往左邊的開發方法則是規範越多，相對於輕量級的開發方法有較多的約束，我們稱為重量級（heavy weight）的開發方法，例如RUP（Rational Unified Process，統一軟件開發過程）。
本章的主旨在於闡述如何將精益的精神由原則轉換為適用於特定環境下的敏捷實踐。說得更精確些，就是針對七大原則加以實踐的詮釋，目標是看闆係統，尤其是依靠經驗法則換來的經驗知識 。
圖1-2 依照規範的多寡由左至右排列各種開發方法
圖1-3 在精益網絡的時代，充斥著各式各樣的對象
如圖1-3所示，在沒有使用過之前，實在很難判斷是不是用錯瞭組件？
1-3 精益軟件開發七大原則
以下為精益軟件開發的七大原則：
1. 消除浪費（Eliminate waste）
2. 增強學習（Amplify learning）
3. 盡量延遲決策（Decide as late as possible）
4. 盡快交付（Deliver as fast as possible）
5. 授權團隊（Empower the team）
6. 嵌入完整性（Build integrity in）
7. 著眼整體（See the whole）
乍看之下，你可能覺得這些原則感覺上像口號一樣，真的有用嗎？讓我告訴你，當你在繪製看闆時（也就是將你的工作流程放到看闆上成為一個或多個垂直字段時），你所依據的便是對這幾條原則的瞭解程度。如果你覺得很陌生的話，下次改變看闆外觀時，一邊看著這些行列一邊思索是否需要改善哪裏？改的原因是什麼？想達成哪一條原則？多練習幾次就熟瞭。記得一次隻改善一個地方就好，這樣比較容易看齣是哪個異動所造成的結果，這一點跟改 bug 是一樣的，一次同時修改好幾個地方，就搞不清楚誰纔是真正的元凶！
1-3-1 消除浪費（Eliminate waste）
何謂浪費？凡是對客戶或産品不具備提升任何價值的行為，基本上都是一種浪費！
Bug 是第一大浪費
程序開發人員最大的浪費，便是在開發工作時製造一大堆 bug，然後再費盡心力把它解決掉。有趣的是，解決這些 bug 之後還能獲得相當的充實感！反倒是很少有人會迴過頭來檢討這些 bug 實際上都是自己所造成的。會有這些 bug 産生，其實是軟件的復雜性所造成的，是我們把程序寫復雜瞭。而如何減少 bug 呢？就是想辦法把程序寫簡單一點，隻有很簡單的程序，bug 纔會相對減少。如果程序復雜瞭，最後便隻能靠測試來守住質量，這一點也間接說明開發和測試實際上是一體兩麵，開發者必須負起減少 bug 的第一綫任務，因為它纔是最大的浪費。
現在的程序開發工作太復雜瞭
開發軟件最重要的是知道要做什麼，然後去做，就這樣簡單！
但經過歲月不斷的纍積之後，我們把這個過程變復雜瞭。是那些有智慧的學者不斷地把經驗奉獻齣來，針對各種不同問題提齣解答（設計模式便是這樣誕生的），智者怕我們重蹈覆轍便想辦法把經驗積纍下來，原意是為瞭照顧後進，結果卻是把開發工作越弄越復雜（HTML 的演進史就是這個縮影）。十年前的軟件開發項目，經過十年後規格並沒有太大改變，但我們卻可以把它弄得越來越有學問，看起來越專業，專業到必須有相當的學習過程纔足以開發十年前就能做到的事！程序在執行速度上變快瞭，但是在質量這一點上卻始終沒有太大的提升，原因是我們把自己弄復雜瞭，我們一再地把開發程序的門檻弄高瞭，而復雜所帶來的最大罪惡便是浪費，所以消除浪費便成為近代工程師要學習的第一要務。
“簡單”是對付 bug 的有效法則
想要減少 bug，就是把程序弄簡單些讓自己隨時都能看得懂。開發軟件時，bug 總是自動在過程中被隱含進來。通常，一知半解寫程序是製造bug的最大元凶，這種 bug 最難以檢測齣來，再來則是邏輯思維被打斷也是在寫程序時很容易産生bug的時候。所以在進行工作分解時，最重要的是“簡單化”，簡單是減少 bug 的最佳處方。話雖如此，但很多時候軟件開發就是這麼復雜，該如何是好呢？
“錯誤的估算”便是一個簡單不下來的原因。韆萬不要在沒有做適度的拆解問題（工作項目）下進行時程的預估，因為那完全是在猜猜看！猜是人類最糟糕的預估瞭，最少也要有參考依據（有參考依據可以讓預估準確許多，例如找到可以比較的案例），但是必須經過拆解成為較小的工作單元，參考纔足以成立。所以在減少浪費的前提下，“先拆解再簡單化”是開工之前（或是進行工時預估前）的必備動作，正確的拆解可以避開那些不必要的復雜性乾擾。
項目經理（PM）習慣嚮開發人員要求預估需要多少開發時間，想藉助工程師每個人的預估，然後閤計起來，以得到團隊的整體開發時程（當然再加上一點自己習慣性的保險時間）。這是一種將項目分解成多個區塊，然後針對各個區塊進行預估的作法。這樣所估齣來的工時乍看之下是會比較準確，但是卻忽略瞭工程師本身所估算的數據本來就是基於一種猜測得來的數值，根本上就已經不準確瞭。所以，雖然已經經過拆解，但這是基於工程師個人的猜測而來，當然就沒有太大的意義。
什麼樣的估算纔比較準確呢？老實說，隻有進行一段時間，有更深一層的瞭解後再來估算自然會準確許多。這種較準確的估算通常發生在項目進行五分之一到三分之一之間，這是一件耐人尋味的事，此時工程師對項目的把握度就可以大幅提升，這個時候的預估就可以接近於“承諾”瞭。
工程師的承諾與預估
項目開始時工程師無從參考比較，此時的工時估算應該隻能說是猜測；一旦項目開始進行後，隨著對項目的瞭解增加，通常工程師在開發工作進行到五分之一到三分之一之間，由於對任務越來越熟悉，自然就可以做比較有把握的預估，這個時候的估算就可以稱之為“承諾”。
寫程序想要減少 bug，專注（Focus）是最有效的良方。這裏討論的專注是指“短時間”的專注，而不是廢寢忘食、長時間瘋狂做某一件事的專注。短時間指的是 25 分鍾的專心工作，這一點請參考蕃茄工作法 。
如何識彆浪費？
豐田生産係統的策劃人之一新鄉重夫（Shigeo Shingo），他首創製造業的七種浪費類型，而波彭迪剋夫婦則將它轉換成軟件業的七大浪費類型，對照如下錶所示。
製造業七大浪費 軟件業七大浪費
1 庫存 半成品、部分完成的工作（Partially Done Work）
2 額外過程 額外過程（Extra Processes）
3 生産過剩 多餘功能（Extra Features）
4 運輸 任務調換（Task Switching）
5 等待 等待（Waiting）
6 移動 移動（Motion）
7 缺陷 缺陷（Defects）
判彆是否浪費十分重要，它是你避免浪費的基礎。接下來的說明雖然看起來冗長，但請務必讀完，每個項目的最後會括號說明相對於看闆方法的運用手法，譬如你不知道該如何建立看闆的垂直字段或調整 WIP（半成品）值，即可參考以下的幾條原則，將它們作為依據。
……
前言/序言
精益軟件開發不同於一般的敏捷開發方法，它是屬於文化層麵的改革，它沒有特定的方法或流程，有的隻是産品開發的概念及原則，非常適閤主管層級的敏捷開發思想。精益軟件開發沒有具體的開發方法，它隻有指導原則，乍看之下很像勵誌的書籍，但它的影響卻遠遠勝過所有的開發方法，因為它將直接影響企業的文化，這一點就比其他開發方法的影響要深遠多瞭。無需訝異它的威力，因為它來自豐田産品係統 TPS（Toyota Production System）。“精益軟件開發”沒有規定實務性的做法，而是描述瞭更重要的實際流程定義、原則及價值觀。原因是它一直認為很難有一種方法能夠完全做到“敏捷”，而“原則”則具有較高的普遍性，因此一直到波彭迪剋夫婦（Mary 和 Tom Poppendieck）的《精益軟件開發工具》（Lean Software Development：An Agile Toolkit）一書齣版，纔有瞭比較明確的七大原則，就是我們所熟悉的消除浪費、增強學習、盡量延遲決策、盡快交付、授權團隊、嵌入完整性、著眼整體等精益軟件開發的七原則。
本書要描述的是在精益軟件開發裏獨樹一格的“廣告牌方法”（Kanban Method），它是 2005 年由安德森（David J. Anderson）所創的一種漸進式的流程控製方法，它所依據的正是這七大精益原則。我把精益軟件原則的說明放在開始的第一章，是希望讀者能“由頭到尾”體驗在真實的情境下，如何依據這七個原則來做決定，讓它成為你實施精益軟件開發時的宗旨，而不至於失去敏捷的初衷。
真正引起我想寫這本書的原因是，因為 Scrum 在迭代的任務闆（Task board）上描述得太少瞭，實施 Scrum 的團隊往往沒有把任務闆上的字段跟實際開發時的工作流程做正確的對照，以至於常常有各說各話的現象，也就是說任務闆沒有反應齣正確的狀況。當第一次看到廣告牌方法的時候，我就立刻在自己所教的 Scrum 課程中將實施廣告牌的方法隱含進來。說真的，這兩個理論真是契閤，我常常在課程中完全不提到廣告牌方法，隻是采用它繪製價值流程及半成品限額的理論，就成功地讓廣告牌方法運用在 Scrum 的開發流程中，學員們可能從頭到尾都沒有意識到我們正在實行廣告牌方法。這一點果然如安德森所言，它是一種漸進式的改革方法沒錯！而且，實行廣告牌方法所受到的阻力要比實施其他敏捷方法少很多，而且成效更佳，如果你懷疑的話，歡迎你繼續往後看。
李智樺
用戶評價
當我拿到這本《精益開發與看闆方法》時，我內心是充滿好奇又帶點審慎的。精益和看闆，這兩個概念在軟件開發領域早已耳熟能詳，但要真正理解並將其融會貫通，卻不是一件易事。這本書的齣現，恰好填補瞭我在這方麵的知識空白。作者的寫作風格非常獨特，他沒有采用那種枯燥乏味的理論講解方式，而是通過大量的比喻和類比，將復雜的概念變得異常形象。讀這本書的過程，就像在進行一場思維的探險，每一個章節都像是一個新的發現。我尤其欣賞作者對於“持續改進”這一核心理念的闡述。他深入淺齣地解釋瞭為何“一次性解決問題”並非長久之計，而是需要建立一種持續迭代、不斷優化的文化。書中關於如何構建這樣一種文化，以及如何鼓勵團隊成員積極參與改進過程的建議，讓我受益匪淺。此外，書中對於“價值流”的分析也讓我茅塞頓開。我之前總是陷在任務的細節中，而這本書讓我看到瞭如何從全局視角審視整個産品生命周期，識彆並消除那些不增值的環節。這不僅僅是對開發流程的優化，更是對整個組織效能的提升。這本書給我帶來的，是一種全新的視角和思考方式，讓我更加期待在實踐中去驗證這些理念。
評分這是一本我一直期待入手的書，終於在朋友的推薦下拿到瞭。《精益開發與看闆方法》，書名就足夠吸引人瞭，它承諾瞭效率的提升和流程的優化。拿到書的當天，我就迫不及待地翻開，首先映入眼簾的是作者那流暢而富有條理的文字。他沒有一開始就堆砌那些晦澀難懂的理論，而是從一個非常貼近實際的場景切入，仿佛我就是那個身處睏境的項目經理，正努力想讓團隊的交付速度變得更快，客戶的滿意度更高。書中的案例分析尤其讓我印象深刻，每一個都真實而生動，仿佛就在我的眼前上演。我能夠清晰地看到，在一個又一個看似棘手的問題麵前，精益和看闆的原則是如何被巧妙地應用，最終化解僵局，迎來曙光。作者在解釋看闆的各個環節時，也做到瞭細緻入微，從“可視化工作流”到“限製在製品數量”，再到“持續改進”，每一個步驟都講解得通俗易懂，並且提供瞭許多實用的工具和技巧，比如如何設計一個有效的看闆、如何識彆瓶頸、如何進行有效的溝通等等。讀完前麵幾章，我就感覺自己仿佛掌握瞭一套全新的工具箱，迫不及待地想把它應用到實際工作中去。這本書的價值，不僅僅在於理論的傳授，更在於它提供的可操作性，這讓我覺得非常物超所值。
評分《精益開發與看闆方法》這本書，給我最直接的感受就是“清晰”和“實用”。作者的文筆如同流水般自然，將精益和看闆這兩個看似龐大的體係，拆解成瞭一個個易於理解的模塊。我尤其欣賞作者在描述“限製在製品數量”（WIP Limit）時所下的功夫。他不僅僅是告訴讀者“為什麼”要限製，更是深入淺齣地講解瞭“如何”去限製，以及限製之後會帶來哪些意想不到的好處。讀到這部分時，我腦海中立刻浮現齣自己團隊目前的狀態，以及如果實施WIP Limit，可能會發生的改變。書中還提供瞭許多圖錶和流程圖，將復雜的概念可視化，這對於我這種視覺型學習者來說，簡直是福音。我喜歡這種“紙上得來終覺淺，絕知此事要躬行”的閱讀體驗，這本書就像是一本操作手冊，在指導我如何一步步構建更高效、更敏捷的開發流程。作者在書中反復強調的“透明化”和“反饋循環”，更是讓我看到瞭改進的希望。過去，我們團隊常常因為信息不透明而導緻誤解和延誤，這本書提齣的解決方案，讓我看到瞭打破這些壁壘的可能性。
評分我一直認為，在快速變化的軟件開發領域，能夠持續保持競爭力，關鍵在於不斷學習和適應。而《精益開發與看闆方法》這本書，恰恰是我尋找的那種能提供持續價值的寶藏。作者在書中不僅僅是在介紹精益和看闆的原理，更是在傳遞一種思維方式，一種應對復雜性和不確定性的哲學。我尤其喜歡書中關於“識彆和解決瓶頸”的章節。作者用生動的語言描繪瞭團隊在開發過程中可能遇到的各種瓶頸，並提供瞭多種多樣的識彆方法和解決策略。這讓我意識到，很多時候我們遇到的問題並非無解，隻是需要換一個角度去看待。更讓我驚喜的是，作者並沒有將看闆方法僅僅局限於軟件開發，他還探討瞭在産品管理、市場營銷甚至個人工作效率方麵的應用。這種跨領域的視角，極大地拓寬瞭我的視野，讓我看到瞭精益和看闆方法的普適性。書中最後一部分關於“文化建設”的討論，更是點睛之筆。它讓我明白，再好的方法，如果缺乏相應的文化支撐，也很難真正發揮作用。這本書所提供的，不僅僅是方法論，更是指導我們如何構建一個更加高效、更加人性化的工作環境的智慧。
評分說實話，我對《精益開發與看闆方法》這本書最初的期待是很高的，但同時我也做好瞭心理準備，畢竟這類書籍往往充斥著理論和概念，真正能落地實踐的內容並不多。然而，當我開始閱讀這本書時，我的看法就徹底改變瞭。作者的敘述方式非常生動，他似乎是一位經驗豐富的教練，在一步步引導著我，讓我從一個旁觀者變成一個積極的參與者。書中對於“消除浪費”的講解，讓我反思瞭許多過去在項目開發中習以為常的低效行為。比如，那些無休止的會議、過度的文檔、以及不必要的返工，都被作者一一剖析，並提齣瞭切實可行的改進建議。我特彆喜歡書中關於“看闆”的實際應用的部分，作者不僅介紹瞭如何設計和使用看闆，還分享瞭許多在不同團隊中遇到的挑戰以及如何剋服這些挑戰的經驗。這些內容非常接地氣，讓我覺得這些方法是可以被復製和推廣的。更重要的是，作者強調瞭“以人為本”的理念，他認為精益和看闆的最終目的是為瞭更好地服務團隊和客戶，而不是為瞭追求效率而犧牲人的價值。這種人文關懷，讓這本書在眾多技術書籍中顯得尤為可貴。
評分很好的一本書，值得耐心看看
評分看闆方式可以結閤用戶故事，實踐中摸索。
評分一如既往地好
評分技術大牛之書，實力經典值得藉鑒
評分質量不錯，物流很快，滿足要求
評分很好的一本書，值得耐心看看
評分書好，送貨及時
評分這次618買瞭好多書，超值。
評分不錯！
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 靜流書站 版權所有