第一章 精實軟體開發
精實軟體開發是由軟體開發領導者，例如：軟體開發部經理、專案經理和技術領導者，而不一般程式程式開發人員所創設的思想工具。 p. 3 [ps. 思想工具這個詞讓人有想洗腦別人的遐想XD]
「原則」所影響的是企業的文化層面，比起單純的開發方法影響要巨大多了。 p. 4
只要是對客戶或產品沒有提升任何價值的行為，基本上就是一種浪費！ p. 6「錯誤的估算」便是一個簡單不下來的原因。千萬不要在沒有做適度的拆解問題 (工作項目) 下進行時程的預估，因為那完全是在猜猜看！猜是人類最糟糕的預估了。 … (中略) … 所以在減少浪費的前提下，「先拆解再簡單化」是開工之前 (或是進行工時預估前) 的必備動作，正確的拆解可以避開那些不必要的複雜性干擾。 p. 7
老實說，只有進行一段時間，有更深一層的了解後再來估算自然會準確許多。這種較精確的估算通常發生在專案進行五分之一到三分之一之間，這是一件耐人尋味的事，此時工程師對於專案的把握程度就可以大幅提升，這個時候的預估就可以接近「承諾」了。 p. 8 [我把接近二字變粗體，因為很重要XD]
判斷是否浪費十分重要，它是你避免浪費的基礎。 p. 9
「半成品」的英文是 Work-In-Process (WIP)，雖然翻譯成「在製品」看起來較貼切，但我偏好採用「半成品」這個字眼。所謂「部分完成的工作」，它是一種賭博，一個隨時可能會失效的功能，因為他有可能還沒上場就被換掉了。 p. 9
盈餘時間是最適合用來進行文件的撰寫作業了，工程師要學會交接文件給自己。 p. 10 [這是真的！]
記得，只有在有必要的時候才新增功能，任何一段不需要的程式碼都是一種浪費，千萬要懂得抵抗自以為能夠有先知卓見這種未雨綢繆能力的誘惑。 p. 10
由程式誕生的方式到我們除錯解決缺陷的方式，藝術的成分還是佔據較大的比例，因此軟體開發是一門工藝是目前較被接受的一種說法。 p. 12
軟體開發是一種學習的過程。 p. 14
科學方法是透過觀察、建立假設、設計實驗、進行實驗、然後得到結果。有趣的是，如果你的假設越正確，你就不會學到太多東西。當失敗率達到50%時，你會得到最多的訊息，也就是學到最多。工程師撰寫程式時不也是如此？ … (中略) … 傳統的開發方式正是要求大家透過審慎的態度一次做對，而敏捷開發則是鼓勵透過嘗試、測試、修正的短週期來開發程式，自然你會學到最多。 p. 15 [好像還蠻常聽到一次做對這句話，是錯覺嗎？]
如果測試成本越高，就多花些時間仔細思考、審慎檢查後再動手，如果實驗的成本很低，那它就是最有效的方法！ p. 15 [所以我一直認為單元測試的CP值最高]
沒有比在心情好的時候更能充分吸收知識的了，保持愉悅是一種成功學習的秘訣，所以在每日站立會議時進行鼓舞士氣、提升團隊和諧的行為．對一天的工作絕對有它的提升效益，你應該嘗試看看！ _p. 17＿
延遲決策是為了避免在早期資訊還不夠清楚的狀況下，就迅速做出決定，或是進行評估作業，這會是一種浪費，因為可能會有很多東西之後還要修改或是重做。 p. 18
最後負責時刻是指，當你再不做出決策時，不做決策的成本就要高於作出決策的成本時，就稱之為「最後負責時刻」。 p. 19
精實理論假設：
- 成熟的組織關注的是整體的系統，它不會專注於優化分散的部分。
- 成熟的組織強調的是有效學習，它會授權予工作人員制定決策的權力。 p. 26
從管理學的角度來看，讓團隊自我管理可以在工作上獲得最佳的效益，所以管理者真正該做的事，是去做那些能夠讓團隊增值的措施。 p. 26
簡單的規則讓團隊顯得一致，而一致的目標讓團隊更加團結；混亂與充滿相怨的環境只會讓團隊失去內在成長的動機。 p. 28
很明顯，你的問題不在於採用哪種敏捷法則，而是在於管理，也就是該如何正確的管理團隊。 p. 29
沒錯，這正是我需要的東西。 … (中略) … 因為它已經滿足你真正的需求了，所以你只會注意到他做了些什麼，而不會在乎它的缺陷，也就是所謂的「情人眼裡出西施」，此時的品質就是西施。 p. 29
要建構具有高度感知完整性和概念完整性的系統，應該在客戶與開發團隊之間以及開發團隊的上下游過程之間形成出色的資訊流 (information flow)，而此資訊流必須考慮到系統當前和潛在的用途。具體上怎麼做呢？
- 增加全體開發人員在應用領域方面的知識。
- 接受變更，並將變更看成是一件正常的過程和容納新設計及決策的能力。
- 營造提高通訊能力的環境，以便對人員、工具和訊息進行整合。p. 31
局部優化易造成捨本逐末 … (中略) … 同樣也會發生在個人身上．如果人們在開發一個系統時，處處都優先考慮自己的專業興趣而忽略了整體性的考量，則產品就會出現局部優化，而共同利益就會受到損害。 p. 33
第二章 看板方法
四個基本原則 (Foundational Principles)：
- 原則 1：從既有的流程開始 (Start with existing process)
- 原則 2：同意持續增量、漸進的變化 (Agree to pursue incremental, evolutionary change)
- 原則 3：尊重當前的流程、角色、職責和頭銜 (Respect the current process, roles, responsibilities, and titles)
- 原則 4：鼓勵各層級的領導行為 (Leadership at all levels)
六個實務 (Core Practices)：
- 步驟 1：視覺化
- 步驟 2：限制半成品 (WIP) 數量
- 步驟 3：管理工作流程
- 步驟 4：讓規則明確
- 步驟 5：落實回饋循環
- 步驟 6：由協作改善，經實驗演進 p. 40
看板是一種透過漸進、演化過程來改變組織系統的方法⋯看板的本質是一個單純的想法，那就是半成品 (work-in-process, WIP) 必須被限制。 — — David J. Anderson p. 40
取得協議是第一準則，最好能夠事前先進行溝通，取得團隊成員的同意。通常自我管理的團隊對變革的承受度會較高，但頻繁的變革仍然應該避免，以小幅度的增量方式漸進式地做改革，才是第二原則的訴求。 p. 46
規劃為來通常能帶給人們希望，但在變革之前要確保，不是只有一群主管充滿期待與希望，期待變革後帶來的種種效能，這是十分危險的一件事！不論是哪一種敏捷方法，都會主張由團隊做自我管理，這個主張不是說當主管們辛辛苦苦完成變革後，再把它交接下去給團隊，非也！要形成自主的團隊，當然是從變革之初就開始著手。主管們不用太擔心該如何去設計這樣的情境，其實在變革當下，『尊重』是團隊最渴望的需求了。 p. 47
以人為本，尊重人性一直是敏捷開發的最重要精神，正如敏捷宣言的第一條宣言所說的『個人與互動重於流程與工具』。 p. 48
四個基本原則的最大意義在追求一個好的開始，前三個原則在提醒你避開人為的阻力，第四個原則則告訴你，讓對現有工作有改進熱情的人浮現出來，讓團隊能審視自己現有的工作流程，並找出哪裡可以改善的地方，經過討論後改善缺點變得更好。 p. 49
看板方法能夠協助我們做到一個首要目標，七個次要目標：
- 首要目標：優化現有的流程
- 高質量交付
- 提升前置時間的可預測性
- 提升員工滿意度
- 為改善流出盈餘時間
- 簡化優先級排序
- 使系統設計及運作透明化
- 設計能夠打造高成熟度組織的流程 p. 51
看板方法從一開始的出發點便認為，被壓迫的員工不見得能有高性能的表現；反之，員工在滿意的環境下容易受到激勵而有高性能表現。 p.54
在引入新改革方法的時候，首先要做的便是為團隊找時間，要知道一個沒有時間的團隊根本很難再去學習新的東西。
雖然我們都知道，改革的動作通常都是由上而下運作才容易獲得成功，但精實的精神則告訴我們要透過持續的改善，不只是由上而下，更要由下往上才能形成自我管理的團隊，並獲得全面性的成功。 p. 58
『維護作業』一直是看板方法扁線的最好的一個領域，這也正好是其他許多敏捷開發法最受人質疑的地方。平心而論，維護作業就是接獲請求後，便去設法解決問題，然後在適當的時機做成部署，替換掉先前的問題。這種直接了當的工作，實在也沒有必要運用敏捷開發的漸進式開發方法或是切割成多個迭代來完成它，直覺地採用看板方法的流程控制方式，正是最能滿足客戶急著獲得改善的需求了。 p. 59
所以就目前的看板方法而言，稱它只是一個流程控制法則一點也不為過。因此，我們可以把它歸納為：運用在流程管理和改進的一種高性能方法。 p. 62
第三章 看板方法的六大核心實務
『選定範圍』是一開始最重要的步驟，選定起點與終點的工作可能會影響到實施看板方法的整體效能，經常會不容易做決策，但有一個簡單的原則可以參考，那就是試問一下：它是我們可以控制的項目嗎？ p. 70
對於工作流程而言，盈餘時間是一種浪費，絕對應該消除；但對於專案開發而言，盈餘時間是一種『工程師的福祉』，可以拿來做很多的運用，其中一種能夠幫助工程師持續成長而頗有價值的便是『學習』，在這瞬息萬變的資訊世界哩，成長與學習真是太重要了。 p. 78
雖然我們都知道多工對效能一定有所損失，那看板方法又是如何處理這種現象呢？有二種方法供選擇：
- 將WIP的數值調大到你願意承擔的 Queue 的最大值，然後再視情況依次遞減下來。
- 預設每個人需要承擔的多工數目乘上人數作為WIP值，用最小值的方法做設定，然後再視情況一次遞增上去。p. 79
目的都在不斷嘗試找出產生阻塞時的WIP值，找出來之後再由現況來判斷考慮調上或調下 (找到平衡點)，也就是以曲線能否達到平滑的地步來做WIP值的調整依據。 p. 81
知道到底你要交付甚麼、給誰、以及為什麼。 p. 86
『預測客戶的需求』這句話好像是業務人員才會用到的詞彙，怎麼會在看板方法中出現呢？原因有二：第一是因為我們經常在開發一些不是客戶真正想要的功能，另一個是我們做了一堆功能但從頭到尾沒人會去用它；而這二個問題實際上都可以透過看板方法得到改善。 p. 87 [請搭配前一句一起食用]
身分為代表客戶的 PO 可能是最常挑戰 WIP 限制的人物了，每當遇到阻塞，總是有人會後悔當初把 WIP 值設得太小了，而企圖引發一場是不是要立即修改 WIP 值的爭論。 p. 90
請注意，不設置半成品的限額是錯誤的！使用看板方法之前，千萬不要在還沒有看到改善之前就因為擔心會有預測中的混亂情況而先行放棄，這種不設限 WIP 的做法，就是放棄看板方法了。 p. 91
第四章 如何實施看板方法
在設計看板牆的時候，最好將範圍 (Scope)、工作項目粒度 (Granularity) 大小、工作項目狀態 (Status) 這三個元素一起考慮進來。 p. 102
Scrum 團隊經常不事先安排特定的工作給予特定的工程師，… (中略) …，讓工程是自己去認領，稱之為『全功能的工程師』。 這是很正面的做法，鼓勵大家去學習新東西，它不但可以促進團隊的協作及效能，也能產生相當的激勵作用；而看板方法則是偏向直接分工，也就是讓專業更專業的作法，用來追求更好的效能。 p. 105 [還是可以中庸一點]
看板方法背後有二條基礎性原則：一條是限制 WIP 的數量，另一條是僅當前面的工作欄位有空位的時候，才可以透過拉動系統拉入新的工作項目。 — — David J. Anderson p. 109
半成品數量與前置時間有直接相關，也就是說，當半成品數量減少時，平均前置時間也隨之減少。… (中略) …半成品數量和平均前置時間之間存有相關性，而且是線性相關，在製造業中這種關係稱為利特爾定理 (Little’s Law)。 p. 114
前置時間和品質之間亦存在相關性，前置時間增加，則品質會下降，前置時間越長，品質便會顯著下降。事實上，平均前置時間增加約 6.5 倍，便會導致初始缺陷超過 30 倍的攀升 (很可怕！)。半成品數量越多，平均前置時間越長，因此，提高品質的管理槓桿點 (leverage point) 是減少半成品數量的方法。 p. 115
看板部分的最下面有一個渠道 (swim line)，用來支援緊急的工作事項，它的限額是 1，表示最多只能同時處理一件緊急的工作事項。最下方是『回顧改進事項』，指的是將回顧會議的結果做成紀錄，提醒團隊避免下次再犯。 p. 119 [限額是可以更動的，只是書中的例子是 1]
盡量讓工作角色分明是十分重要的。有太多軟體公司都是老闆兼技術總監的形式，非常容易讓工作角色發生混亂，這是十分划不來的事。 p. 122
讓瓶頸能夠盡快暴露出來的數值 (WIP) 最有價值！因為這樣我們就能從這裡開始進行改善的動作，流程當然就會改進了。 p. 130
遇到阻塞時要訓練團隊成員不是去質疑塞住了，我今天就沒事做了！而是主動去詢問我可以幫上什麼嗎？ p. 131
第五章 個人看板：類專案管理
因此我們要懂得透過設限自己的工作量來更進一步的了解自己的工作狀況，把它適當的反應在看板上面，能夠讓我們做進一步的動態調整，這一點可以協助我們更正確地完成工作，也可以拿來改善我們做事的效能。 p. 151
類文件也是測試案例，新加入的人員以測試人員的角色進入這個專案，然後在熟悉測試案例後就可以配合 Excel/HTML 的分析文件加入撰寫程式人員的行列了。 p. 174
我常稱它們為『交接給自己的文件』，秉持的精神是任何程式都需要有文件來陪伴它：沒有任何原始碼的程式應該獨自存在，而沒有文件的伴隨。 p. 179 [自己平時也是如此]
第六章 個人看板與生活：讓生活與工作相得益彰
傳統的時間管理概念是：只要提高工作效率，你便能掌握生活，從而內心感覺平和，而且會有成就感。但是，效能並不會為你換來滿足感的，人生也不見得會因產能的增加而變得更美好。 — — 史蒂芬．柯維 《時間有約》 p. 188
事情做到一半被中斷 — — 培養短時間集中精神的能力。 p. 189 [番茄時鐘法其實蠻不錯的]
人們花太多時間，試著找出執行平凡目標的方法。 — — Mark Murphy p. 191
所以一切應該從計畫開始，在個人看板上明確標示出你的目標 (Mark Murphy 強調內心渴望是達成目標的第一要務)。 p. 191
而即使是重複的工作，我們也能夠進行得更有效率，這就是學習的可貴，我們透過經驗的回饋，學習後進行改善的行為，減少了浪費也增加了我們的能力。 p. 193
看板方法是一個很特別的軟體管理方法，因為它很容易激起人在情緒上的變化。 p. 194
所以我認為個人看板的目的是：讓你透過視覺化你的生活與工作後，試著運用看板方法來找出甚麼才是你生活中最重要的事，排除其他的浪費，多花一些時間在你認為最重要的事情上面，試圖在方向上及範圍上幫助你能夠看清楚，從而改善你的生活。 p. 199
第七章 預測未來：減少變異性，增加可預測度
如果我們計劃得夠詳細了，是不是就能估算的很精確呢？答案是否定的，因為變異性是難以預測的，而你實在很難詳盡地把所有的影響因子都考慮進去，因此要準確預測一件事情的未來是十分困難的一件事，因為會造成變化的因素太多了，這種因素我們就稱它為『變異性 (Variability)』。 p. 205
結構影響行為，也就是說，我們因為沒看見結構是怎麼運作的，而只是一直認為自己不得不這麼做，所以就決定去做了，這是一種『見樹不見林』的盲目決策。 p. 208
為了解決某一問題而制定的策略，通常會使問題更加嚴重，從而形成一種惡性循環，而管理者卻不自知反而更加用力執行這些引發問題的策略。 p. 209
系統思考的基本模式之一所謂的成長上限 (Limits to Growth)，意思是說即使某一過程能產生預期的效果，它也會產生某種副作用，從而抵銷所取得的成果，並最終減緩成功的到來。 p. 209
很多組織都忽略了，當問題因為採用新策略而消失之後，這個新策略反而成為今天系統的限制。上面這個現象引出了系統思考的另一個模式捨本逐末 (Shifting the Burden)，也就是遇到問題並沒有對症下藥，只是忙於應付問題，看起來是解決了問題，但是實際上是讓問題更難被察覺，反而造成未來更嚴重的問題。 p. 210
David J. Anderson 曾說：『軟體開發和專案管理過程，是以組織的成熟度、團隊中成員的能力，共同決定了內部變異性的數量及變異的程度』。因此請勿將看板方法視為一種軟體開發生命週期 (ALM) 或專案管理的過程，看板方法是一種變革管理的技術。 p. 215
演化輸入展示體驗：有時候複雜性夠多是源自使用者介面而非功能性需求本身，這時候，可以考慮拆分一個故事並用最簡單的介面實現，接下來再建構比較華麗的介面。 p. 218 [個人感想是這一點有時候不見得能成立]
但是它 (User story mapping) 還是有缺點的，當專案範圍太大時，這時候的使用者故事太多太複雜，就會很難做異動及維護的工作 (做起來特別累人)，當然也就失去了它的價值。 p. 220
第八章 持續改進
解決瓶頸的處理方式則必須以較全面性的方式來做考量，先經過嘗試，肯定問題的癥結所在，然後再來擬訂持續改善的方法 (這裡才是主管該專注的地方！)。 p. 231
品質是一種很有趣的東西，當你開始注意時，它就已經開始在改善了。 p. 233 [這句話怎麼聽起來很像魔法的發動咒語XD]
一個繁忙的團隊就好像已經盛滿了水的杯子一樣，它是沒有辦法再加進任何東西了！你必須先把盛滿了的杯子空出一些空間來，才可能再往裡頭加東西。所以在你開始進行改革之前，先要設法幫團隊找出空閒的時間，… (中略) …『半成品』正是那個不會影響產能的工作，說穿了就是減少『半成品』的數量。 p. 234
採用看板方法可以改善組織的文化，並幫助組織走向成熟，形成一種持續改善的文化，這是精實精神造成的文化與組織習慣的改變，比任何一種軟體開發方法影響更為深遠。 p. 237 [這句話要搭配該節標題一起食用：沒有銀子彈]
附錄
如果你的團隊成員都不敢嘗試新的想法，因為他們害怕可能會失敗，你可能是Scrum But。
如果你將數據指標看得比表現優異更重的話，你可能是Scrum But。
如果你凡事都要通過管理階層來做決定的話，你可能是Scrum But。
讀後感
這本書是在 Agile Tour 2015 聽完作者本人演講後買的，不過，還真的沒挪出什麼時間把它看完，直到最近因為一些因素終於有時間把它看完了，所以上述很多摘錄都是心有戚戚焉。看是看完了，也別因為我上面都把好處寫出來就覺得看板方法好棒棒，一定也可以適用在你的團隊，就好像基金的廣告，投資一定有風險，基金投資有賺有賠，申購前應詳閱公開說明書，想用任何敏捷方法前，也許可以參考一下Agile is Dead?。
Jul 19, 2020
