第一部分 二者對比

第1章 究竟什么是Scrum，什么是看板？

1. Scrum簡述。P2
   • 把組織拆分成小規模的、跨功能的自組織團隊。
   • 把工作拆分成一系列小而具體的交付物。按優先級排序，估算每項任務的相對工作量。
   • 把時間拆分成固定大小的段迭代（通常為1-4周），每個迭代結束時對基本可以交付的代碼進行演示。
   • 在每個迭代結束后跟客戶一起檢查發布目標，并據此優化發布計劃，更新任務優先級。
   • 每個迭代結束后進行回顧，進行過程優化。
2. 我們不是一個靠一個龐大的團隊，花大量時間造出龐然大物；而是用小團隊在短時間內做出小塊的東西來，在有規律的集成中組裝出全貌。P3
3. 看板簡述。P3
   • 將流程可視化。
     • 把工作拆分成小塊，一張卡片寫一件任務，再把卡片放到墻上。
     • 每一列都起一個名字，顯示每件任務在流程中處于什么位置。
   • 限制WIP（在制品，work in progress）——明確限制流程中每個狀態上最多同時進行的任務數。
   • 度量生產周期（完成一件任務的平均時間，又稱循環周期），對流程進行調優，盡可能縮短生產周期，并使其可預測。

第2章 Scrum和看板有什么關系？

1. Scrum和看板都是過程工具。P5
   工具=用于完成任務或達成目的的任何東西。
   過程=工作方式。
   Scrum和看板都是過程工具，它們講的是做哪些事情能夠在一定程度上幫助你提高工作效率。
2. 在比較工具的時候得謹慎一些。比較是為了更好地理解，而不是評判優劣。P5
3. 跟所有的工具一樣，Scrum和看板既不完美，也不全面。它們沒有把需要做的事情全部告訴你，只是給了一些明確的約束和指導。比如說，Scrum的約束是固定時長的迭代和跨功能團隊，看板的約束是要有可見的板，隊列大小要限制。P6
4. 有意思的是，工具的價值恰恰在于它限制了你的選擇。如果有一款過程工具，讓你什么事情都能做，那它就沒多大用了。我們管這種工具叫做“做啥都行”，或者美其名曰“做正確的事”?！白稣_的事”這個過程肯定管用。它就是銀彈！要是沒生效，那肯定是因為你沒按照這個過程工作。P6
5. 使用恰當的工具可以幫助你成功，但不能確保成功。人們很容易把項目成敗跟工具成敗弄混。P6
   • 有一款偉大的工具，項目可能成功。
   • 有一款差勁的工具，項目可能成功。
   • 有一款差勁的工具，項目可能失敗。
   • 有一款偉大的工具，項目可能失敗。
6. Scrum比看板更規范。P6
   我們可以從每個工具都有哪些規則角度來進行比較。規范性指的是“要遵守更多的規則”，適應性指的是“要遵守的規則較少”。在100%規范性的情況下，你就更笨不用動腦子了，不管做什么事情都按規則行事；而100%的適應性就意味著做什么都行，沒有任何規則約束。你肯定能看出來，這兩種極端都是很荒謬的。P6
7. 敏捷方法有時被稱作輕量級方法，主要原因就在于它們不如傳統方法那么規范。敏捷宣言的第一條就是“個體和交互勝過過程和工具”。P7
8. RUP的規范性相當強——它有30多種角色，20多種活動，70多種工件；需要學習的東西不勝枚舉。當然，你肯定不會全都用上，為自己的項目選一個合適的子集就行了。但不幸的是，操作起來可是頗有難度。“唔，我們會需要配置審計決定這個工件么？我們會需要變更控制經理的角色么？還定不下來啊，最好還是先留著吧?！边@可能就是為什么RUP比起敏捷方法來——例如Scrum和XP——用到最后往往令人不堪重負了。P7
9. XP（極限編程）比Scrum又規范一些。它囊括了Scrum的大部分內容，還多了很多相當具體的工程實踐，。例如測試驅動開發和結對編程。P7
10. Scrum的規范性比XP弱，因為它沒有規定任何具體的工程實踐。但它又比看板規范，因為它規定了迭代和跨功能團隊之類的東西。P7
11. Scrum和RUP的主要區別在于，RUP給你的東西太多了，你得自己把不需要的東西去掉；而Scrum給你的東西太少了，你得自己把需要的東西加進來。P7
12. 看板幾乎對任何做法都是開放的。它僅有的約束就是將流程可視化和限制在制品。它離做什么都行只有幾步之遙，但任有令人驚異的力量。P7
13. Scrum本身已經足夠濃縮了，如果你去掉一些東西，然后還叫它Scrum，那這個詞就失去了意義，只會帶來困擾。你可以給它起個別的名字，比如“Scrum衍生品”，或者“Scrum子集”，要不就“Scrum似是而非”也行。P8

第3章 Scrum規定了角色

1. Scrum規定了三種角色：產品負責人（描繪產品愿景，定義優先級）、團隊（實現產品）、Scrum Master（消除障礙，帶領過程運作）?？窗鍥]規定任何角色。這可不是說你不能或是不應該在看板里有產品負責人的角色。這只是說你不是非有不可。不管是用看板還是Scrum，你都可以根據需要增加任意角色。P9
2. 但是增加角色的時候得小心，要確保新增的角色能帶來價值，而且不要跟其他方面有沖突。你覺得你真的需要項目經理么？在大項目里面也許挺好，因為這個人可以在多個團隊和多個產品負責人之間進行協調。但在小團隊里面這個角色也許就是浪費，甚至更糟——導致局部優化和微觀管理。P9
3. Scrum和看板有一個共同的思路：“少就是多”。有疑慮的時候，先從少做起。P9

第4章 Scrum規定了固定時長的迭代

1. 固定時長的迭代是Scrum的基礎。你可以選擇迭代長度，但一般都會在一定時間內讓迭代長度固定不變，繼而形成節奏?；旌狭巳N活動：計劃、過程改進、（理想中的）發布。P10
   • 迭代伊始：綜合考慮產品負責人定義的優先級和自己的生產率，團隊從產品backlog里面挑選出一定數量的條目，創建迭代計劃。
   • 迭代進行中：團隊全心投入所承諾的任務。迭代范圍已固定。
   • 迭代結尾：團隊向相關干系人演示他們可以工作的代碼，理想情況下，這些代碼基本上是可以發布的（經過測試可以交付）。然后團隊進行回顧，討論如何改進過程。
2. 看板沒有規定固定時長的迭代。你可以選擇什么時候做計劃，什么時候改進過程，什么時候發布。P10

第5章 看板按流程狀態限制WIP，Scrum按迭代限制WIP

1. Scrum的WIP按單位時間限制，看板的WIP按流程狀態限制。P13

第6章 二者都是經驗主義的

1. Scrum和看板都是經驗主義的產物，你用的時候需要先進行試驗，然后根據自己的環境作調整。P14
   • Scrum說，你應該有跨功能團隊。那團隊里面應該有什么人？不知道，自己試吧。
   • Scrum說，團隊選擇Sprint里面放多少東西。那到底要放多少東西？不知道，自己試吧。
   • 看板說，你應該限制WIP。那到底上限是多少？不知道，自己試吧。
2. 最核心的一點就是反饋環。改變=>檢查結果=>從中學習=>繼續改變。一般而言，反饋環越短越好，這樣可以快速調整過程。Scrum的基本反饋環就是Sprint，跟XP（極限編程）合并的話就會再多幾個：P15
   • Sprint
   • 每日立會
   • 持續集成
   • 單元測試
   • 結對編程
3. 看板給你的幾個很有用的實時度量指標。P15
   • 平均生產周期。每次有任務到達“Done”這一列的時候就更新數據。
   • 瓶頸。典型癥狀就是X列里面堆滿了卡片，但是X+1列里空空如也。找找板上哪里有“氣泡”吧。
     太長的反饋環會導致過程改進速度過緩。太短的反饋環會導致過程變化太快，沒有時間穩定，白做無用功。

第7章 Scrum在迭代內拒絕變化

1. Scrum團隊也可以允許產品負責人在sprint中期更改優先級（雖然這往往都會被當作異常情況）?？窗鍒F隊也可以對修改優先級時機做限制。看板團隊甚至可以使用固定期限固定承諾的迭代，就跟Scrum那樣。P20

第8章 Scrum板在迭代之間重置

1. Sprint結束以后，板子就會進行清理——所有卡片全部去掉。看板圖的樣子幾乎是一成不變的——你不需要把板子清理干凈，重新開始。P21

第9章 Scrum規定了跨功能團隊

1. Scrum團隊是跨功能的，要完成迭代全部任務所需的技能，這個團隊要全都具備?？窗宀粡娭埔罂绻δ軋F隊，看板圖對應的是流程，不必非得是一個團隊。P22

第10章 Scrum的backlog條目必須能跟Sprint搭配的上

1. Scrum和看板都以增量開發為基礎的，即將工作拆分成小塊。Scrum團隊只會承諾他們認為能在一個迭代里面做完的任務。如果任務太大了，一個Sprint放不下，團隊跟產品負責人就會尋找方法拆分，直到能放下為止。P23
2. 看板團隊努力縮短生產周期，保持順暢流動，而這些因素會間接推動團隊把任務拆分成相對較小的片段。但是看板對任務規模沒有明文規定一定要在某個時間內做完。P23

第11章 Scrum規定了估算和生產率

1. 在Scrum里面，團隊要對每個承諾的任務估算其相對大小，到迭代結束的時候，把每個任務的大小相加，就得到了生產率。看板沒有規定速算這回事。所以如果需要作承諾的話，就得想一想怎么作預測了。有的團隊用Scrum的方式作估算，度量生產率。有的把每個任務都拆分得大小相近——于是生產率就很好算了。P24

第12章 二者都允許在多個產品上并行工作

1. 如果團隊再維護多個產品，就把這些產品都合并到一個列表里面。這會迫使我們把產品放在一起考慮優先級，有時候會給我們幫上很大忙。我們可以采取多種做法：P25
   • 其一，每個Sprint聚焦一個產品。
   • 其二，每個Sprint里面，兩個產品的特性都要做。

第13章 二者都是既精益又敏捷

1. Scrum和看板跟精益思想和敏捷宣言里面的價值觀和原則是相當吻合的。舉些例子：P27
   • Scrum和看板都是拉動式計劃系統，跟精益的JIT（準時化）庫存管理原則是一致的。
   • Scrum和看板都基于持續的、經驗主義的過程優化，這跟精益的改善原則是一致的。
   • Scrum和看板都強調響應變化勝過遵循計劃（雖然看板的響應速度一般要比Scrum快），這是敏捷宣言的四項價值觀之一。
2. 從某個角度來看，Scrum也不那么精益，因為它把批量任務放到固定期限的迭代里面去。但是，如果你不斷縮短迭代周期，本質上就等于向看板靠攏。如果你們開始研究把迭代縮成比1星期還短，那還不如干脆把固定期限的迭代干掉了。P27

第14章 小小差異

1. Scrum規定了經過優先級排序的產品backlog。在看板里面，你可以選擇任何一種定義優先級的方式?？窗蹇梢杂幸部梢詻]有產品backlog，即便有的話，排不排優先級也不一定。看板圖上最左邊那列的用途跟Scrum產品backlog基本相同。不管這列排不排優先級，團隊總要做出某種決定，先拉哪張卡片來做。比如：P28
   • 總是選最上面那張。
   • 總是選最早的那張（所以每張卡都有時間戳）。
   • 隨便選。
   • 花大概20%的時間做維護的任務，80%的時間做新特性。
   • 把團隊的生產力平均分配到產品A和產品B上。
   • 如果有紅色卡片就先選紅的。
2. Scrum規定了每日立會。看板沒有規定每日立會，但絕大多數看板團隊好像也都在這樣做。P29
3. Scrum規定了燃盡圖用作跟蹤迭代進度的主要工具。看板沒有要求任何特殊的圖表。P29

第15章 Scrum板 vs. 看板圖——一個不大不小的例子

1. 看板只規定了兩件事，一個是工作流必須可見，另一個是WIP要有上線。它的目的是在系統中制造無障礙的流動，盡可能縮短生產周期。P37

第16章 小結——Scrum vs. 看板

1. 相似性。P38
   • 都是既精益又敏捷。
   • 都是拉動式計劃。
   • 都限制了WIP。
   • 都以透明的方式驅動過程改進。
   • 都關注于盡早交付、頻繁交付可發布的軟件。
   • 根基都是自組織型團隊。
   • 都需要把工作拆分。
   • 發布計劃都是根據經驗數據（生產率/生產周期）不斷優化的。
2. 差異。P38
   • Scrum規定了固定時長的迭代，看板固定時長的迭代是可選的。計劃、發布、過程改進等活動可以各有各的節奏。它可以由事件驅動，不用非要固定時長。
   • Scrum團隊承諾當前迭代做完一定量的工作?？窗宄兄Z是可選的。
   • Scrum用生產率作為計劃和過程改進的默認度量手段。看板用生產周期作為計劃和過程改進的默認度量手段。
   • Scrum規定了跨功能團隊。看板跨功能團隊是可選的?？梢杂袑Ｂ殘F隊。
   • Scrum任務必須分解，以便在1一個Sprint里面能做完?？窗鍥]有規定任務規模。
   • Scrum規定了燃盡圖?？窗鍥]規定專門的圖表形式。
   • Scrum間接限制（每個Sprint的）WIP?？窗逯苯酉拗疲總€工作流狀態的）WIP。
   • Scrum規定了估算?？窗骞浪闶强蛇x的。
   • Scrum不能往進行中的Sprint里面加認為?？窗逯灰腥烁挥嗑涂梢约尤蝿?。
   • Scrum一個Sprint Backlog歸一個團隊所有?？窗逡粡埧窗鍒D可以由多個團隊或多個公用。
   • Scrum規定了三種角色（PO、SM、Team）?？窗鍥]有規定任何角色。
   • Scrum每個Sprint之間重置Scrum板?？窗蹇窗鍒D一直保留著。
   • Scrum規定了經過優先級排序的產品backlog。看板優先級排序是可選的。

第二部分 案例分析

第17章 技術支持的現狀

1. 縮小問題范圍，減少影響，保存現場，等到某人把問題重現后再解決。P41

第18章 到底為什么要改變？

1. 我們不能只幫助開發團隊，否則技術支撐團隊那邊的核心運營設施改進工作就會拖了后腿。兩手都要抓。改進工作在開發團隊中取得進展以后，管理者就需要把更多的時間投入到創意的分析和反饋，這也意味著他們用來解決問題，及時劃分任務優先級的時間就更少了。管理團隊意識到，他們得再管理混亂到無可救藥之前采取行動了。P42