《精益開發實戰：用看板管理大型項目》從實踐角度展示如何使用看板管理大型項目。書中內容共分為兩大部分。第一部分是案例研究，講述看板和精益原則在具體項目中的運用；第二部分是技術詳解，詳細介紹第一部分提到的因果圖等實踐做法。 《精益開發實戰：用看板管理大型項目》適合軟體開發組織中的項目團隊主管、經理和其他變更負責人，也適合一切對敏捷開發感興趣的人士。
基本介紹
- 中文名：精益開發實戰:用看板管理大型項目
- 外文名：Lean from the Trenches Managing Large-Scale Projects with Kanban
- 作者：克里伯格 (Henrik Kniberg)
- 類型：經濟管理
- 出版日期：2012年9月1日
- 語種：簡體中文
- ISBN：9787115291776
- 譯者：李祥青
- 出版社：人民郵電出版社
- 頁數：168頁
- 開本：16
- 品牌：人民郵電出版社
基本介紹,內容簡介,作者簡介,專業推薦,媒體推薦,名人推薦,圖書目錄,
基本介紹
內容簡介
剖析實際項目，揭示敏捷和精益方法精髓
手把手教你用看板/Scrum玩轉大型項目
《硝煙中的Scrum和XP》作者新作
手把手教你用看板/Scrum玩轉大型項目
《硝煙中的Scrum和XP》作者新作
作者簡介
Henrik Kniberg
資深敏捷教練、諮詢專家，精益和敏捷原則的積極實踐者，目前效力於瑞典的Crisp公司。在過去的10年間，Henrik曾為瑞典的3家IT公司擔任過CTO，幫助過很多公司走上敏捷精益軟體開發之路。Henrik是獲認證的Scrum教練，與Scrum的聯合創始人Jeff Sutherland共同進行培訓和教練工作，並經常作為主講嘉賓主席業內的各種國際性會議。除本書外，他還著有《硝煙中的Scrum和XP——我們如何實施Scrum》和Kanban&Scrum，making the most of both。先和家人居住在瑞典首都斯德哥爾摩，業餘時間在兩家樂隊擔任低音鍵盤手。
資深敏捷教練、諮詢專家，精益和敏捷原則的積極實踐者，目前效力於瑞典的Crisp公司。在過去的10年間，Henrik曾為瑞典的3家IT公司擔任過CTO，幫助過很多公司走上敏捷精益軟體開發之路。Henrik是獲認證的Scrum教練，與Scrum的聯合創始人Jeff Sutherland共同進行培訓和教練工作，並經常作為主講嘉賓主席業內的各種國際性會議。除本書外，他還著有《硝煙中的Scrum和XP——我們如何實施Scrum》和Kanban&Scrum，making the most of both。先和家人居住在瑞典首都斯德哥爾摩，業餘時間在兩家樂隊擔任低音鍵盤手。
專業推薦
媒體推薦
太棒了！我就知道這本書會在軟體開發領域產生重大影響。這是過去一年中最重要的一本書！
——瑪麗·帕彭迪克（Mary Poppendieck），《精益軟體開發》系列書籍作者
我從頭到尾讀完了這本書。一句話，太棒了！紮實、真切、有趣、易讀、流暢，極好地平衡了理論與實踐。
——肯特·貝克（Kent Beck），美國著名軟體工程師與作家
卓越之作。向作者致敬！你不辭辛勞地記錄下了大型項目獲得成功需要作出的各種日常決策。希望這本書會成為判斷眾多項目成功與否的基準。
——沃德·坎寧安（Ward Cunningham），電腦程式員和維基（Wiki）概念的發明者，也是設計模式和敏捷軟體方法的先驅之一
《精益開發實戰》讓我無法釋手。這本書介紹了如何以精益而敏捷的方式運行大型項目。對於正處於實戰中的大型企業人員來說，這種成功案例意義深遠。
——伊夫斯·哈諾（Yves Hanoulle），PairCoaching.net變更大師
這本書讓我們看到了一個將敏捷流程的精髓套用於真實場景的卓越案例。如果你曾困惑於“我做的對不對？”之類的問題，這本書就會告訴你答案。所有技術團隊主管，只要想了解敏捷流程如何實際運作，都應該現在就買這本書！
——科林·耶茨（Colin Yates），英國QFI諮詢公司首席工程師
很震撼！終於出現了一個思路真實可用、不乾巴的、注重實效的成功案例。
——西蒙·克羅默蒂（Simon Cromarty），敏捷海盜網
這本書講述用敏捷和精益原則管理真實項目，我非常喜歡，書的內容非常實用，可讀性極高。強調真實經驗而非理論讓人耳目一新，非常吸引人。我絕對要向朋友們推薦這本書，而且會將書中的獨到見解運用到我自己的專業諮詢項目中去。
——凱文·畢姆（Kevin Beam），Lambda42公司獨立軟體開發工程師
——瑪麗·帕彭迪克（Mary Poppendieck），《精益軟體開發》系列書籍作者
我從頭到尾讀完了這本書。一句話，太棒了！紮實、真切、有趣、易讀、流暢，極好地平衡了理論與實踐。
——肯特·貝克（Kent Beck），美國著名軟體工程師與作家
卓越之作。向作者致敬！你不辭辛勞地記錄下了大型項目獲得成功需要作出的各種日常決策。希望這本書會成為判斷眾多項目成功與否的基準。
——沃德·坎寧安（Ward Cunningham），電腦程式員和維基（Wiki）概念的發明者，也是設計模式和敏捷軟體方法的先驅之一
《精益開發實戰》讓我無法釋手。這本書介紹了如何以精益而敏捷的方式運行大型項目。對於正處於實戰中的大型企業人員來說，這種成功案例意義深遠。
——伊夫斯·哈諾（Yves Hanoulle），PairCoaching.net變更大師
這本書讓我們看到了一個將敏捷流程的精髓套用於真實場景的卓越案例。如果你曾困惑於“我做的對不對？”之類的問題，這本書就會告訴你答案。所有技術團隊主管，只要想了解敏捷流程如何實際運作，都應該現在就買這本書！
——科林·耶茨（Colin Yates），英國QFI諮詢公司首席工程師
很震撼！終於出現了一個思路真實可用、不乾巴的、注重實效的成功案例。
——西蒙·克羅默蒂（Simon Cromarty），敏捷海盜網
這本書講述用敏捷和精益原則管理真實項目，我非常喜歡，書的內容非常實用，可讀性極高。強調真實經驗而非理論讓人耳目一新，非常吸引人。我絕對要向朋友們推薦這本書，而且會將書中的獨到見解運用到我自己的專業諮詢項目中去。
——凱文·畢姆（Kevin Beam），Lambda42公司獨立軟體開發工程師
名人推薦
“我從頭到尾讀完了這本書。一句話，太棒了！紮實、真切、有趣、易讀、流暢，極好地平衡了理論與實踐。”
一肯特·貝克（Kent Beck），敏捷先驅，著名軟體工程師、作家
“卓越之作。向作者致敬！你不辭辛勞地記錄下了大型項目獲得成功需要做出的各種日常決策。希望這本書會成為判斷眾多項目成功與否的基準。”
——沃德·坎寧安（Ward Cunningham），維基概念發明者，設計模式和敏捷軟體方法先驅
“這本書讓我們看到了一個將敏捷流程的精髓套用於真實場景的卓越案例。如果你曾困惑於‘我做得對不對’之類的問題，這本書就會告訴你答案。所有技術團隊主管，只要想了解敏捷流程如何實際運作，都應該現在就買這本書！”
——科林·耶茨（Colin Yates），英國QFI諮詢公司首席工程師
一肯特·貝克（Kent Beck），敏捷先驅，著名軟體工程師、作家
“卓越之作。向作者致敬！你不辭辛勞地記錄下了大型項目獲得成功需要做出的各種日常決策。希望這本書會成為判斷眾多項目成功與否的基準。”
——沃德·坎寧安（Ward Cunningham），維基概念發明者，設計模式和敏捷軟體方法先驅
“這本書讓我們看到了一個將敏捷流程的精髓套用於真實場景的卓越案例。如果你曾困惑於‘我做得對不對’之類的問題，這本書就會告訴你答案。所有技術團隊主管，只要想了解敏捷流程如何實際運作，都應該現在就買這本書！”
——科林·耶茨（Colin Yates），英國QFI諮詢公司首席工程師
圖書目錄
第一部分我們如何工作
第1章項目背景
1.1時間線
1.2我們如何切割大象
1.3我們如何讓客戶參與進來
第2章組織團隊
第3章每天出席雞尾酒會
3.1第一撥：功能開發團隊每日立會
3.2第二撥：不同專業角色的同步立會
3.3第三撥：項目同步立會
第4章項目進度板
4.1我們的節奏
4.2如何處理緊急問題和障礙
第5章擴展任務看板
第6章跟蹤總體目標
第7章定義“可供”與“完成”
7.1 可供開發
7.2可供系統測試
7.3兩個定義如何提升團隊協作
第8章處理技術故事
8.1示例1：系統測試瓶頸
8.2示例2：版本發布前一天
8.3示例3：7米長的類
第9章處理Bug
9.1持續系統測試
9.2立馬修復Bug！
9.3為何要限定Bug跟蹤系統中的Bu9數量
9.4 Bug可視化
9.5預防Bug重現
第10章持續改進流程
10.1 團隊回顧
10.2流程改進研討會
10.3掌控改變速率
第11章管理在制品
11.1採用在制品限額
11.2為什麼在制品限額只適用於功能卡
第12章捕捉並使用流程度量
12.1速率（每周功能數）
12.2為何不使用故事點
12.3周期時間（每個功能所需時間）
12.4累計流量
12.5流程周期效率
第13章Sprint與版本發布規劃
13.1需求清單梳理
13.2挑選前十個功能
13.3為何將需求清單梳理工作移出Sprint規劃會議
13.4規劃版本發布
第14章我們如何做版本控制
14.1主幹無垃圾
14.2 團隊分支
14.3系統測試分支
第15章為何我們只用真實看板
第16章經驗教訓
16.1了解目標
16.2不斷實驗
16.3擁抱失敗
16.4解決真正的問題
16.5擁有專職變革推動者
16.6讓人們參與進來
第二部分技術詳解
第17章敏捷與精益概述
17.1敏捷概述
17.2精益概述
17.3 Serum概述
17.4 XP概述
17.5看板概述
第18章縮減測試自動化需求清單
18.1 怎么辦
18.2如何每個疊代周期都提高測試覆蓋率
18.3第1步：列出測試用例
18.4第2步：測試分類
18.5第3步：按優先順序對列表進行排序
18.6第4步：每個疊代周期自動化若干測試
18.7這能解決問題嗎
第19章用規劃撲克估算需求清單大小
19.1不用規劃撲克進行估算
19.2用規劃撲克進行估算
19.3特殊牌
第20章因果圖
20.1解決問題，而不是解決症狀
20.2精益問題解決方法：A3思維
20.3如何使用因果圖
20.4示例1：發布周期長
20.5示例2：上線版本有缺陷
20.6示例3：缺乏結對編程
20.7示例4：很多問題
20.8實際問題：如何創建並維護因果圖
20.9陷阱
20.10為何採用因果圖
第21章結語
附錄 術語表：如何避免高深術語
第1章項目背景
1.1時間線
1.2我們如何切割大象
1.3我們如何讓客戶參與進來
第2章組織團隊
第3章每天出席雞尾酒會
3.1第一撥：功能開發團隊每日立會
3.2第二撥：不同專業角色的同步立會
3.3第三撥：項目同步立會
第4章項目進度板
4.1我們的節奏
4.2如何處理緊急問題和障礙
第5章擴展任務看板
第6章跟蹤總體目標
第7章定義“可供”與“完成”
7.1 可供開發
7.2可供系統測試
7.3兩個定義如何提升團隊協作
第8章處理技術故事
8.1示例1：系統測試瓶頸
8.2示例2：版本發布前一天
8.3示例3：7米長的類
第9章處理Bug
9.1持續系統測試
9.2立馬修復Bug！
9.3為何要限定Bug跟蹤系統中的Bu9數量
9.4 Bug可視化
9.5預防Bug重現
第10章持續改進流程
10.1 團隊回顧
10.2流程改進研討會
10.3掌控改變速率
第11章管理在制品
11.1採用在制品限額
11.2為什麼在制品限額只適用於功能卡
第12章捕捉並使用流程度量
12.1速率（每周功能數）
12.2為何不使用故事點
12.3周期時間（每個功能所需時間）
12.4累計流量
12.5流程周期效率
第13章Sprint與版本發布規劃
13.1需求清單梳理
13.2挑選前十個功能
13.3為何將需求清單梳理工作移出Sprint規劃會議
13.4規劃版本發布
第14章我們如何做版本控制
14.1主幹無垃圾
14.2 團隊分支
14.3系統測試分支
第15章為何我們只用真實看板
第16章經驗教訓
16.1了解目標
16.2不斷實驗
16.3擁抱失敗
16.4解決真正的問題
16.5擁有專職變革推動者
16.6讓人們參與進來
第二部分技術詳解
第17章敏捷與精益概述
17.1敏捷概述
17.2精益概述
17.3 Serum概述
17.4 XP概述
17.5看板概述
第18章縮減測試自動化需求清單
18.1 怎么辦
18.2如何每個疊代周期都提高測試覆蓋率
18.3第1步：列出測試用例
18.4第2步：測試分類
18.5第3步：按優先順序對列表進行排序
18.6第4步：每個疊代周期自動化若干測試
18.7這能解決問題嗎
第19章用規劃撲克估算需求清單大小
19.1不用規劃撲克進行估算
19.2用規劃撲克進行估算
19.3特殊牌
第20章因果圖
20.1解決問題，而不是解決症狀
20.2精益問題解決方法：A3思維
20.3如何使用因果圖
20.4示例1：發布周期長
20.5示例2：上線版本有缺陷
20.6示例3：缺乏結對編程
20.7示例4：很多問題
20.8實際問題：如何創建並維護因果圖
20.9陷阱
20.10為何採用因果圖
第21章結語
附錄 術語表：如何避免高深術語
