☆☆☆☆☆




點擊這裡下載

類似圖書 點擊查看全場最低價

---

産品特色

精益七大原則：消除浪費、增強學習、盡量延遲決策、盡快交付、授權團隊、嵌入完整性、著眼整體

看闆六大實踐：可視化、限製、管理流程、製定明確規則、落實反饋循環、持續演進

SCRUM+看闆：看闆牆的設計，看闆一日遊

個人看闆的應用：第一步為視覺化工作流程，第二步為半成品限額

持續改進

編輯推薦

　　根據精益（Lean）觀念而來的精益軟件開發儼然已成為軟件開發項目的主流精神。
　　通過看闆方法（Kanban Method），精益理念可以落實到整個開發流程，
　　提高應變能力、減少無謂的資源及時間浪費，全力開發團隊開發效能。

內容簡介

　　本書作者從事軟件開發多年，善於吸取敏捷和精益這兩種開發方法的精髓，對看闆的理解和應用具有實用而豐富的經驗。他在本書中依托精益開發中的主流工具，介紹瞭看闆的概念、遵循的基本原則、看闆的適用範圍和具體使用等。精益軟件開發是當下軟件開發項目的主流。看闆可以使得精益理念落實並貫穿於整個開發流程，從而提高應變能力、減少無謂的資源及時間浪費、完全發揮團隊的開發效能。本書適閤所有軟件從業人員（從項目經理到工程師）閱讀，可以幫助他們從容應對韆變萬化的客戶需求。

作者簡介

　　李智樺，在軟件開發領域已有多年的實踐經驗，他對信息及軟件應用開發的熱情和投入令人佩服，包括新興的行動及雲端開發技術的研究，近年來投身於敏捷、精益及看闆方法的推廣並擔任講師，本書可以讓更多人瞭解這些軟件開發及項目管理的實用方法並應用於工作領域之中，值得閱讀！
　　擁有超過30年的軟件開發工作資曆。從早期的大型銀行係統到近年來專注於微軟各項新技術的研究，是微軟Windows Azure雲端及其他新開發技術的指定講師，擔任多屆TechDay、TechED等大型研討會主場演講。過去是資深的開發人員、大型係統及企業的總架構師，有長期同時帶領多個團隊的ScrumMaster大型項目經驗。他對信息技術的熱誠及堅持，至今仍對新技術的動手實操不遺餘力，是少數擁有如此豐富資曆、能講、能教、隨時能上手的信息界老兵。

　　李淳 Certified Scrum Master、Certified Scrum Product Owner，曾先後在用友、易車等公司任程序員、研發經理、架構師、産品經理，敏捷和精益倡導者，團隊敏捷轉型實踐者，公眾號“互聯網plus管理新範式”（iPlusLeadership）維護人。代錶譯著有《軟件需求（第3版）》

目錄

第1章 精益軟件開發 1
1-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 的開發流程中，學員們可能從頭到尾都沒有意識到我們正在實行廣告牌方法。這一點果然如安德森所言，它是一種漸進式的改革方法沒錯！而且，實行廣告牌方法所受到的阻力要比實施其他敏捷方法少很多，而且成效更佳，如果你懷疑的話，歡迎你繼續往後看。
　　李智樺

精益開發與看闆方法 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

好書收藏！！！

評分☆☆☆☆☆

太好瞭，對工作有幫助。

評分☆☆☆☆☆

一如既往地好

評分☆☆☆☆☆

還不錯，配送很快，價格閤理。

評分☆☆☆☆☆

這次618買瞭好多書，超值。

評分☆☆☆☆☆

聽過作者演講後買的，核心思想和演講內容一樣，不過全書內容比較口語化，颱灣人的口吻不太適應

評分☆☆☆☆☆

不錯不錯不錯不錯不錯不錯不錯

評分☆☆☆☆☆

不錯

評分☆☆☆☆☆

看闆方式可以結閤用戶故事，實踐中摸索。

類似圖書 點擊查看全場最低價

查看全網最低價