☆☆☆☆☆
簡體網頁||繁體網頁



點擊這裡下載

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

---

編輯推薦

　　看闆方法是近年來軟件開發社區流行的新型管理方法，它能在不大幅改變原有開發流程的情況下，有效提高開發效率。它最突齣的兩個特點：實施阻力小、切實有效。這也正是它迅速走紅的原因。

內容簡介

　　《看闆方法：科技企業漸進變革成功之道》由看闆方法創始人David J. Anderson親自編寫，是看闆方法的奠基之作。看闆方法脫胎於豐田生産方式和約束理論，是精益方法的進一步延伸。它將軟件開發過程視為一種價值流，並且相信拉動式的管理能産生更好的結果。它通過限製在製品的數量等一係列簡單可行的技巧，發現和緩解軟件開發過程中的壓力和瓶頸，提高生産效率。看闆方法的奇妙之處，在於它與企業原有的開發流程無縫結閤，在不知不覺中提高生産效率。換句話說，它是一種漸進式的改良，不是翻天覆地的革命，因而更容易被企業接受。實施阻力小且切實有效是看闆方法在軟件開發社區中迅速流行起來的原因。

作者簡介

　　大衛·J.安德森（David J. Anderson），有三十多年IT行業從業經驗，曾在多傢大型跨國企業管理軟件開發團隊，擁有豐富的團隊管理經驗。他是精益軟件和係統協會（Lean Software & Systems Consortium）的創始人，並且創辦瞭David J. Anderson & Associates谘詢公司和LeanKanban培訓公司，緻力於傳播和推廣精益思想和看闆方法。

精彩書評

　　★“本書既是看闆方法的快速上手指南，又提供瞭豐富的理論內容。每次閱讀我都有新的收獲。”
　　——Chris Simmons Sophos公司開發經理

　　★“使用看闆方法奇跡般地改善瞭公司的業務狀況。閱讀本書，我現在理解個中原因瞭！”
　　——Alission Vale Phildelis公司創始人

目錄

第一部分 導論
第1章 解決敏捷管理者的睏境
1.1 我對可持續步調的探索
1.2 我對成功變革管理的探索
1.3 從“鼓-緩衝-繩”轉嚮“看闆”
1.4 看闆方法的齣現
1.5 看闆方法被社區采納的過程
1.6 看闆的價值是反直覺的
第2章 什麼是看闆方法
2.1 什麼是看闆係統？
2.2 把看闆應用於軟件開發中
2.3 為什麼使用看闆係統？
2.4 看闆方法模型
2.5 識彆看闆方法的應用實施
2.6 作為權限授予者的看闆

第二部分 看闆方法的益處
第3章 一種成功秘訣
3.1 使用秘訣
3.2 成功秘訣和看闆方法
第4章 在五個季度內，從最差變為最好
4.1 問題
4.2 可視化工作流程
4.3 影響效能的因素
4.4 明確過程策略
4.5 估算是一種浪費
4.6 限製在製品
4.7 建立輸入節奏
4.8 達成新契約
4.9 實施變革
4.10 調整策略
4.11 尋求進一步的改善
4.12 成果
第5章 持續改進的文化
5.1 改善文化
5.2 看闆方法會加速組織成熟度和能力的提升
5.3 社會學變革
5.4 文化變革也許是看闆方法帶來的最大好處

第三部分 實施看闆方法
第6章 價值流映射
6.1 定義控製起點和終點
6.2 工作項類型
6.3 繪製卡片牆
6.4 請求分析
6.5 根據請求分配産能
6.6 工作項卡片詳解
6.7 電子跟蹤
6.8 設置輸入和輸齣邊界
6.9 應對並行活動
6.10 應對次序無關的活動
第7章 使用看闆進行協調
7.1 可視化控製和拉動
7.2 電子跟蹤
7.3 每日站立會議
7.4 會後討論
7.5 隊列填充會議
7.6 發布規劃會議
7.7 鑒彆分類
7.8 問題日誌的審查與升級
7.9 現場貼紙代理
7.10 跨多個地理位置保持同步
第8章 建立交付節奏
8.1 交付的協調成本
8.2 交付的事務成本
8.3 交付效率
8.4 確定交付節奏
8.5 通過提高效率來提升交付節奏
8.6 進行隨需或臨時交付
第9章 建立輸入節奏
9.1 優先級排序的協調成本
9.2 確定優先級排序節奏
9.3 優先級排序的效率
9.4 優先級排序的事務成本
9.5 提高效率以支持更頻繁的優先級排序節奏
9.6 進行隨需或臨時性的優先級排序
第10章 設置在製品限額
10.1 工作任務的限額
10.2 排隊隊列中的限額
10.3 瓶頸前的緩衝
10.4 輸入隊列大小
10.5 工作流中不設WIP限額的區域
10.6 不要使組織壓力過大
10.7 不設置在製品限額是錯誤的
10.8 産能分配
第11章 建立服務水平協議
11.1 服務類彆的一種典型定義
11.2 為服務類彆設置規則條款
11.3 確定服務交付目標
11.4 設置服務類彆
11.5 應用服務類彆
11.6 根據服務類彆來配置産能
第12章 度量和管理報告
12.1 跟蹤在製品
12.2 前置時間
12.3 準時交付率
12.4 交付速率
12.5 問題和受阻工作項
12.6 流動效率
12.7 初始質量
12.8 破壞負載
第13章 使用兩層係統擴展看闆
13.1 層次化的需求
13.2 將價值交付和工作項的變異性解耦
13.3 兩層卡片牆
13.4 引入泳道
13.5 應對規模變異性的另外一種方法
13.6 和服務類彆結閤在一起
13.7 係統集成
13.8 管理共享資源
第14章 運營迴顧
14.1 會前準備
14.2 在開始時設置好業務基調
14.3 邀請嘉賓擴大聽眾範圍並帶來附加價值
14.4 主要議程
14.5 精益轉型的基礎
14.6 適宜的節奏
14.7 體現管理者的價值
14.8 組織層麵的專注能培育改善文化
14.9 一個早期案例
第15章 啓動看闆變革
15.1 看闆係統的首要目標
15.2 看闆係統的次要目標
15.3 理解目標，闡明益處
15.4 實施步驟
15.5 看闆方法帶來新的談判模式
15.6 啓動看闆實施的談判

第四部分 繼續改進
第16章 三類改進機會
16.1 瓶頸、消除浪費和降低變異性
16.2 看闆方法與公司文化的適配
第17章 瓶頸和非即時可用資源
17.1 能力受限資源
17.2 非即時可用資源
第18章 精益的一種經濟學模型
18.1 重新定義“浪費”
18.2 事務成本
18.3 協調成本
18.4 如何識彆一項活動是否是成本
18.5 破壞負載
第19章 變異性的根源
19.1 變異性的內部根源
19.2 變異性的外部根源
第20章 問題管理和升級策略
20.1 對問題的管理
20.2 問題升級
20.3 問題跟蹤和報告
參考文獻
緻謝
索引
關於作者

精彩書摘

　　1．1我對可持續步調的探索　　2002年，敏捷社區將可持續步調簡單解釋為“每周工作40小時”。 《敏捷宣言的原則》告訴我們：“敏捷過程倡導可持續開發。齣資人、開發者和用戶應共同維持一個長期穩定的步調”。兩年前，Sprinl PCS公司的團隊已經普遍認同瞭我的觀點，“大型軟件開發是一場馬拉鬆，不是短跑衝刺”。如果要求項目成員在持續18個月之久的長期項目中保持步調，那麼絕不能讓他們在頭一兩個月就精疲力竭。必須為項目製訂計劃、預算成本、進行調度和估算，以確保團隊成員每天閤理的工作時間，避免他們過度疲勞。作為經理的我，所麵臨的挑戰是，在實現這一目標的同時，還要能夠確保滿足所有的業務需求。　　1991年，我首次在一傢成立已經5年的創業公司裏從事管理工作，該公司主要製造麵嚮個人計算機與其他小型計算機的視頻采集卡。我從CEO那裏獲得的反饋信息是，領導認為我“非常消極”。我們的開發能力已經達到極限，而領導卻仍然要求增加更多的産品特性，這時我總是以“不行”斷然拒絕他們。2002年以前，我形成瞭一種明顯的模式：一直以“不行”這種拒絕的方式，抵擋來自業務方持續不斷和善變的需求。　　軟件團隊和IT部門似乎總會遭遇被其他組織任意擺布的悲慘命運。即使計劃已經做得無懈可擊、公正客觀，這些組織仍然會對他們極盡軟磨硬泡、恐嚇威逼之能事。即使是基於深入分析、有多年曆史數據支持的計劃，在這些組織麵前也會變得脆弱不堪。大多數團隊則是既沒有透徹的分析方法，又沒有任何曆史數據支持，在那些想要迫使他們承諾未知的（通常是完全不閤理的）交付期限的權術手腕下，他們無疑勢單力薄而隻能任其擺布。　　與此同時，軟件工程師也已經基本上接受瞭瘋狂的進度錶和獻身工作的荒謬言論，並對此司空見慣。軟件工程師好像本不該擁有社交活動和傢庭生活似的，這真是莫大的羞辱！我知道有太多人因獻身工作而影響瞭和傢庭成員的關係，並因此濛受瞭不可彌補的損失。但要人們對那些身處主流的軟件開發極客（geek）錶示同情卻很難。在我居住的美國華盛頓州，軟件工程師的年收入僅次於牙醫。就像20世紀20年代福特汽車裝配綫上的那些工人一一樣，其收入是美國平均工資的五倍，由於他們的報酬豐厚，沒有人會考慮他們工作的單調性或身心的幸福感。很難想象，在諸如軟件開發這樣的知識工作領域會湧現齣勞工組織；沒人會從根本上去解決軟件開發者日常遭遇的生理和心理方麵疾病的問題。　　……

前言/序言

　　自有軟件開發活動以來，在軟件工程界和軟件開發社區中，一直有不少先行者和實踐者在積極探索如何更高效地組織團隊進行高質量的軟件開發活動。敏捷方法和精益方法正是近十幾年來，從這波潮流中湧現的最精彩奪目的兩項成果。敏捷方法和精益方法的大傘，覆蓋多種軟件開發方法學，其中最具代錶性的有Scrum、極限編程等，它們以《敏捷宣言》定義的價值觀為基石，構成瞭這張大傘的一半幅麵，另外一半幅麵則由以精益價值觀為基石的方法學組成，其中最具代錶性的是由Poppendieck夫婦共同創立的精益軟件開發方法（lean software devleopment）。本書所介紹的看闆方法，則是精益陣營中湧現的一種不可忽視的新方法。
　　看闆方法，由David Anderson創立，它脫胎於大野耐一所創立的豐田生産方式（TPS），以及埃利亞鬍?高德拉特（Eli Goldratt）的約束理論（TOC），並結閤統計質量控製（SQC）、排隊論（QT）、工業工程（IE）、軟件成熟度模型（CMMI）等多個領域的知識，在軟件開發社區中獲得瞭極高的關注度，並迅速傳播開來。
　　David在從事軟件開發管理的實踐經曆中，發現商業組織中的軟件開發團隊經常産生過載現象。這對軟件開發者帶來瞭深深的傷害，反過來也傷害瞭商業組織，因此他期望找到一種雙贏的軟件開發模式，尋找到一種係統性的途徑，能夠帶來可持續的步調，既有利於軟件從業者，也有利於商業組織。同時，作為變革推動者，David還發現，在團隊中導入新技術總是不可避免地會遭遇到阻力。他領悟到，必須尋找到一種能夠使變革阻力最小化的方法纔行，最好的策略便是從團隊當前狀況齣發，采取逐步改善的變革引導方式。這兩個方麵，是David創立看闆方法的兩個基本動機。
　　看闆方法采用瞭精益的思維範式，將軟件開發視為一個價值流（Value Stream），並且基於拉模式來驅動其流動。“價值流”是精益思想和看闆方法的基礎隱喻，基於這個隱喻，引申齣來的是一係列其他元素，例如，拉動（pull）、在製品（WIP）、批量規模（batch size）、前置時間（lead time）、阻塞（block）、瓶頸（bottleneck）、緩衝區（buffer）、吞吐量（throughput）、改善（kaizen）等。改善是精益和看闆方法的精髓，它旨在通過持續性地實施係統性變更來優化生産係統。
　　看闆方法的各種設計元素，為質量和過程中的問題提供瞭可見性，能夠迅速暴露價值流中影響效能的問題，從而引導團隊專注於解決問題以維持穩定的流動。通過幫助軟件團隊建立穩定的工作節奏，實現始終如一的可靠交付，看闆方法能夠在開發團隊與客戶、相關部門、供應商、價值流下遊閤作夥伴之間建立信任關係，從而建立具有高度協作、高度信任、高度授權和持續改進特徵的組織文化。
　　軟件開發中的看闆方法本身還在不斷發展過程中。作為本書的中文版譯者，我非常榮幸能夠把這本奠基之作介紹給中國的敏捷和精益軟件開發社區。期待本書能夠給社區帶來新的視角和啓迪，更期待國內社區對看闆方法的實踐能夠反過來促進看闆方法的進一步發展。
　　祝大傢都能夠精通保持平衡和持續改善的藝術！
　　章顯洲
　　支付寶高級技術專傢
　　2013年11月5日於杭州古蕩
看闆方法：科技企業漸進變革成功之道 [Kanban: Successful Evolutionary Change for Your Technology Business] 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

好好好好好好好好好好

評分☆☆☆☆☆

好

評分☆☆☆☆☆

囤貨還沒有看，快遞還可以啦，挺快的

評分☆☆☆☆☆

不錯不錯不錯不錯不錯

評分☆☆☆☆☆

好極瞭，購物隻在京東瞭，沒有彆的選擇瞭

評分☆☆☆☆☆

書還沒看，不過快遞很給力喲，下次再來

評分☆☆☆☆☆

買瞭在公司看的，結閤公司業務多學習學習企業的業務流程還是很好的。

評分☆☆☆☆☆

還沒看。。。。。。。

評分☆☆☆☆☆

東西不錯，比較滿意的一次購物。

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