1. 圖書信息
英文原著
- 名稱：Kanban: Successful Evolutionary Change for Your Technology Business
- 作者：David J Anderson
- 出版：2010 年
中文譯本
- 名稱：看板方法——科技企業(yè)漸進變革成功之道
- 譯者：章顯洲、路寧
- 出版：2014 年
- 字數(shù)：35.3 萬
2. 個人感想
讀《精益開發(fā)實戰(zhàn)》時知道了看板方法，當時的粗淺理解是「 可視化管理 」，因為我個人更喜歡電子看板，團隊遲遲沒有引入「物理看板」，2015 年使用「電子看板」半年后還是回到了基于甘特圖的老路。由于缺乏理論基礎(chǔ)，總是在按照傳統(tǒng)的項目管理思路使用看板，新瓶裝老酒，感覺怪怪的。
David Anderson 在《看板方法》開篇以春天櫻花季去東京皇居東御苑公園游玩的經(jīng)歷說明「看板并不只供制造業(yè)使用」，由此引出兩個核心概念： Pull System 和 Work-In-Progress Limit 。公園本身就是一個拉動系統(tǒng)，游客便是在制品。游園的高峰期，通過發(fā)放卡片的方式來控制園內(nèi)的人數(shù)，當所有卡片發(fā)放完時，新到的游客必須在園外的橋上排隊等候，等待其他游客離園后回收的入園卡。
第四部分以「公路」和「海灣輪渡」為例說明 Bottelnecks 。先來看看「 能力受限資源 」的例子：
華盛頓 SR-520 公路是連接西雅圖與其市郊柯克蘭（Kirkland）和雷蒙德（Redmond）兩區(qū)的高速公路，每天有 8 個小時處于嚴重的雙向交通瓶頸狀態(tài)。經(jīng)歷浮橋跨過華盛頓湖前，這條高速公路由三車道變窄成雙車道，導致高峰期只發(fā)揮了 20% 的吞吐潛力，堵車長達 7 公里。
「 非即時可用資源 」并非瓶頸，但是，它們看起來很像瓶頸。普吉特海灣的輪渡系統(tǒng)是一個典型的例子：
普吉特海灣的三個輪渡系統(tǒng)把吉賽普（Kitsap）和奧林匹克半島（Olympic Peninsulas）與西雅圖市區(qū)連接在一直。其中一個是連接埃德蒙茲（Edmonds）東側(cè)和金斯敦（Kingston）西側(cè)的處在 SR-104 公路上。在地圖上，這條輪渡航線顯示為 SR-104 公路的一部分。通常它被標記為「收費」，而不是明確說明「到這里你得上船擺渡」。
開車到輪渡時，需要先付費，然后在一個等候區(qū)等候。等待時間大概需要 30 分鐘，因為渡輪需要花 30 分鐘時間渡過普吉特灣；之后渡輪還需要花 10 到 15 分鐘卸下車輛，在返航前又需要花差不多的時間載上全部新的車輛。通常輪渡公司會投入兩艘渡輪，因此每艘渡輪的運輸時間差不多是 50 分鐘一趟。在高峰時間，可能會投入 3 艘渡輪，把每次擺渡的等待時間控制在 35 分鐘左右。
在我的團隊，后臺開發(fā)是「能力受限」，7 人項目組只有 1 人負責后臺，既要設(shè)計 DB、REST API 還要對接 iOS / Android 和 Web 后臺的功能開發(fā)。我本人是「非即時可用」，A 項目產(chǎn)品經(jīng)理找我評審需求時，我可能在和 B 項目架構(gòu)師評審設(shè)計；B 項目找我討論下個月工作計劃時，我可能在做 S 項目發(fā)布……使用物理看板后，站立會議拉動卡片時我們倆將被標注為 阻塞（Block） ，想想還有點兒小緊張呢 :D
再次回到東京皇居東御苑公園的例子，WIP Limit（游客上限）在這個示例中是確定的，但是在軟件項目中任務(wù)通常無法精確估算，和朋友討論時我經(jīng)常被問到：
- 有些功能半小時能修改完，有些要一兩周，怎么統(tǒng)一；
- 今天剛確認的需求明天又變了；
- ……
David Anderson 在書中把上面的問題稱做： Variability 。
第 19 章作者深入討論了「變異性的根源」，分為「內(nèi)部變異」和「外部變異」。結(jié)合 19 章重新閱讀本書第三部分，就能夠理解作者為什么提出了 Value Stram / Work Item Type / Delivery Cadence / Prioritization / Class-of-Service / Operations Review 等關(guān)鍵活動了。
最后，David Anderson 在書中介紹的看板方法起源于「維護項目」，對于產(chǎn)品研發(fā)型項目如何應(yīng)用看板還要進一步學習，希望能夠在下一本書《看板實戰(zhàn)》中找到答案。
3. 讀書筆記
看板是一個日語詞匯，英文字面意思是「信號卡」
3.1. 什么是看板方法
5 項核心特性：
- 可視化工作流程。
- 限制進行中的工作（work-in-progress）。
- 度量和管理流動。
- 明確過程策略。
- 使用模型來識別改進機會。
5 個附加的特性：
- 根據(jù)延遲（機會）成本進行工作項的優(yōu)先級排序。
- 通過服務(wù)分類來優(yōu)化價值。
- 通過產(chǎn)能分配（capacity allocation）來管理風險。
- 鼓勵工藝和過程創(chuàng)新。
- 定量化管理。
3.2. 瓶頸 Bottlenecks
瓶頸分為兩類
- 能力受限瓶頸（Capacity-Constrained）：無法完成更多的工作；
- 非即時可用瓶頸（Non-Instant Availability）：由于可用性的限制（但通常是可預(yù)測的）導致處理能力有限；
| 能力受限 | 非即時可用 | |
|---|---|---|
| 挖掘 / 保護舉措 | 策略變更、增加 WIP 緩沖區(qū) | 策略變更、增加 WIP 緩沖區(qū) |
| 服從舉措 | 策略變更 | 策略變更 |
| 突破舉措 | 自動化、增加產(chǎn)能（資源） | 自動化、增加產(chǎn)能（資源）、改變策略 |
在使用突破舉措之前，首先應(yīng)該考慮使用挖掘舉措。
實施一個戰(zhàn)術(shù)性的瓶頸挖掘舉措和服從舉措計劃時，可以從一個更長遠的視角來規(guī)劃戰(zhàn)略性變革，以真正突破瓶頸約束。
3.3. 重新定義浪費 Redefining "Waste"
以經(jīng)濟學語言來對此進行解釋，以成本（cost）來指代這些「浪費性」活動，將這些成本抽象地分為三大類：
- 事務(wù)成本（transaction costs）
- 前端（front-end）事務(wù)成本：初始準備成本
- 后端（back-end）事務(wù)成本：清理掃尾成本
- 協(xié)調(diào)成本（coordination costs）
- 破壞負載（failure load）
可以通過詢問「如果可以，我們愿意更多地開展這項活動嗎？」的方式來判別一項活動是否真的屬于浪費。如果答案是否定的，那么這項活動就是某種形式的浪費。
3.4. 變異性的根源 Sources of Variability
內(nèi)部變異，也稱為「機會致因變異」，可以通過改變定義軟件開發(fā)生命周期和項目管理過程的系列規(guī)則和策略來控制。
- 工作項規(guī)模 Work Item Size
- 工作項類型的混合 Work Item Type Mix
- 服務(wù)類別的混合 Class-of-Service Mix
- 不規(guī)則的紊流 Irregular Flow
- 返工 Rework
外部變異，也稱為「可歸因變異」，可以通過利用問題管理和解決能力以及風險管理能力來應(yīng)用，可以通過利用根因分析和消除能力來降低或消除可歸因變異。
- 需求模糊 Requirements Ambiguity
- 加急請求 Expedite Requests
- 處理不規(guī)則紊流 Irregular Flow
- 環(huán)境可用性 Environment Availability
- 其他市場因素 Other Market Factors
- 安排協(xié)調(diào)活動的難度 Difficulty Scheduling Coordination Activity
3.5. 價值流映射 Mapping the Value Stream
工作項類型 Work Item Type
- 需求 Requirement
- 功能特性 Feature
- 用戶故事 User Story
- 用例 Use Case
- 變更請求 Change Request
- 產(chǎn)品缺陷 Product Defect
- 維護工作 Maintenance
- 重構(gòu) Refactoring
- 錯誤 Bug
- 改進建議 Improvement Suggestion
- 受阻問題 Blocking Issue
根據(jù)請求分配產(chǎn)能
- 變更請求 60%
- 維護工作 10%
- 產(chǎn)品文本變更 30%
工作項卡片詳解
- 電子跟蹤 ID 號
- 標題（寫在中間）
- 進入日期（寫在左下角）
- 固定交付日期（寫在右下角）
- 負責人（磁貼、標簽帖）
應(yīng)對并行活動
應(yīng)對次序無關(guān)的活動
管理共享資源
3.6. 設(shè)置在制品限額 Setting Work-in-Progress Limits
在每個橫向泳道上為不同工作項類型顯式定義 WIP 限額的卡片墻
- 工作任務(wù)的限額
- 排隊隊列中的限額
- 瓶頸前的緩沖
- 輸入隊列大小
3.7. 建立服務(wù)水平協(xié)議 Establishing Service Level Agreements
根據(jù)不同服務(wù)類別分配產(chǎn)能的看板墻
| 顏色 | 條款 | |
|---|---|---|
| 加急類 Expedite | 白色 | 參 P131 |
| 固定交付日期類 Fixed Delivery Date | 紫色 | 參 P132 |
| 標準類 Standard Class | 黃色 | 參 P132 |
| 無形類 Intangible Class | 綠色 | 參 P133 |
3.8. 度量和管理報告 Metrics and Management Reporting
- 跟蹤在制品 Tracking WIP
- 前置時間 Lead Time
- 準時交付率 Due Date Performance
- 交付速率 Throughput
- 問題和受阻工作項 Issues and Blocked Work Items
- 流動效率 Flow Efficiency
- 初始質(zhì)量 Initial Quality
- 破壞負載 Failure Load
3.9. 啟動看板變革 Starting a Kanban Change Initiative
首要目標
- 優(yōu)化現(xiàn)有流程
次要目標
- 高質(zhì)量交付
- 提升前置時間的可預(yù)測性
- 提升員工滿意度
- 為改善留出富余時間
- 簡化優(yōu)先級排序
- 使系統(tǒng)設(shè)計及動作透明化
- 設(shè)計能夠打造高成熟度組織的流程
15.4 實施步驟 Steps to Get Started
啟動看板實施的談判
- WIP 限額 WIP Limits
- 優(yōu)先級排序 Prioritization
- 交付 / 發(fā)布 Delivery / Release
- 前置時間與服務(wù)類別 Lead Time and Classes of Service
4. 金句
看板方法通過優(yōu)化現(xiàn)有過程來驅(qū)動變革。啟動看板方法的關(guān)鍵要義是， 變化要越少越好 。你必須要抵制住改變工作流程、職位名稱、角色及其職責，以及當前在用的具體實踐的誘感。不要試圖去改變團隊成員與其他合作伙伴、參與者、干系人的內(nèi)驅(qū)力、專業(yè)自豪感和自我心理（ego）， 主要要改變的是在制品的數(shù)量、與上下游業(yè)務(wù)間的接口及交互方式 。因此，必須與團隊一起把現(xiàn)有的價值流圖描繪出來，不要試圖去改變它或重新發(fā)明一種理想化的新過程。
看板方法暴露組織中存在的問題，由此可能會冠以使事情變得更加糟糕的罪名而被迫中止，并且其本身也會被視為是問題的一部分而不是解決辦法。 因此，要謹慎對待這個問題。對于能力比較強且有較高成熟度的組織，由于預(yù)期之外的問題（可歸因變異）很少，所以可以考慮采用約束較為嚴格的 WIP 限制規(guī)則。對于比較混亂的組織，把 WIP 的限制規(guī)則設(shè)得比較寬松為好，開始時，先把 WIP 限額設(shè)得大一些，通過創(chuàng)建持續(xù)改進的驅(qū)動力，將其逐步調(diào)低。
平衡工作與生活，不只是簡單地在數(shù)量上平衡投在工作上的時間和留給家人朋友、愛好、激情，個人追求的時間，還意味著要能夠 提供一種確定性，比如，如果有一名愛好藝術(shù)的團隊成員希望在當?shù)匾凰袑W參加繪畫課程，該課程每周三晚六點半開始，要持續(xù) 10 周，你的團隊能為這位伙伴提供每周準時離開辦公室去上課的確定性嗎？
創(chuàng)造更理想的工作／生活平衡，可以增強公司在本地市場對人才的吸引力，有助于更好地激勵員工，讓他們在 幾個月甚至幾年中都保持高績效水平，只有超負載工作才能完全挖掘出知識工作者的產(chǎn)能——這是一種極其錯誤的觀點。超負載工作的狀況，維持一兩天或許可行，但可持續(xù)性不會超過一兩周，為員工創(chuàng)造工作生活平衡，絕不讓他們超負載工作，這才是明智公司的經(jīng)管決策。
從選代（或時間盒限制）的層面來看，敏捷開發(fā)管理與傳統(tǒng)項目管理非常相似，唯一的重要區(qū)別是，在項目過程中需要舍棄一些東西進行權(quán)衡時，傳統(tǒng)的項目經(jīng)理可能會選擇延期交付、增加資源投入、縮減范圍或三者不同程度地兼而有之； 敏捷項目的明確共識是縮減范圍，保障交付時間。
