什么是看板
- 將流程可視化
1. 把工作拆分成小塊，一張卡片寫一件任務，再把卡片放到墻上。
2. 每一列都起一個名字，顯示每件任務在流程中處于什么位置。 - 限制 WIP（在制品，work in progress）： 明確限制流程中每個狀態上最多同時進行的任務數。
-
度量生產周期（完成一件任務的平均時間，又稱循環周期），對流程進行調
優，盡可能縮短生產周期，并使其可預測。
什么是srum
- 把組織拆分成小規模的、跨功能的自組織團隊。
- 把工作拆分成一系列小而具體的交付物。按優先級排序，估算每項任務的相對
工作量。 - 把時間拆分成固定大小的短迭代（通常為 1-4 周），在每個迭代結束時對基本可
以交付的代碼進行演示。 - 在每個迭代結束后跟客戶一起檢查發布目標，并據此優化發布計劃，更新任務
優先級。 - 每個迭代結束后進行回顧，進行過程優化。
我們不是靠一個龐大的團隊，花大量時間造出龐然大物；而是用小團隊在短時間內做出小塊的東西來，在有規律的集成中組裝出全貌。
看板和srum的區別和關系
-
相同點
Scrum 和看板都是過程工具：
工具=用于完成任務或達成目的的任何東西
過程=工作方式
Scrum 和看板都是過程工具，它們講的是做哪些事情能夠在一定程度上幫助 你提高工作效率。Java 也是工具，它讓編程更加簡單。牙刷也是工具，它讓你夠得到牙齒，方便清潔。二者都是經驗主義的：
這種方式有很多叫法：改善（Kaizen。即持續改進，精益術語）,內省與調整（Inspect & Adapt，Scrum 術語），經驗式過程控制（Empirical Process Control），乃至科學方法（The Scientific Method）。
它最核心的一點就是反饋環。改變 => 檢查結果 => 從中學習 => 繼續改變。一般而言，反饋環越短越好，這樣可以快速調整過程。-
都允許在多個產品上并行工作:
下面是兩個產品，綠色和黃色，每一個都有自己的產品 backlog，也有自己的團隊。
WX20190416-185016.png
萬一你只有一個團隊呢？其實，你可以把產品 backlog 當作團隊 backlog 看待。如果
團隊在維護多個產品，就把這些產品都合并到一個列表里面。這會迫使我們把產品
放在一起考慮優先級。我們可以采取多種做法：
其一，每個 Sprint 聚焦一個產品：
其二，每個 Sprint 里面，兩個產品的特性都要做：
在一張圖上可以有多個產品流動。我們可以用不同顏色的卡加以區分：
也可以用“泳道”來區分：
-
都是既精益又敏捷
Scrum 和看板跟精益思想和敏捷宣言里面的價值觀和原則是相當吻合的。
1）Scrum 和看板都是拉動式計劃系統，跟精益的 JIT（準時化）庫存管理原則是
一致的。這表示團隊決定從什么時候開始干活，干多少活。等他們準備就緒
的時候就把工作“拉”過去，而不是從外部“推”進來。就像打印機只有在準備
打印的時候才把下一頁拉進去一樣（當然，打印機還是有些小小庫存的）。
2）Scrum 和看板都基于持續的、經驗主義的過程優化，這跟精益的改善原則是
一致的。
3）Scrum 和看板都強調響應變化勝過遵循計劃（雖然看板的響應速度一般要比
Scrum 快），這是敏捷宣言的四項價值觀之一。
-
不同點
Scrum 規定了三種角色：產品負責人（描繪產品遠景，定義優先級）、團隊（實現產品）、Scrum Master（消除障礙，帶領過程運作）。
看板沒規定任何角色。
這可不是說你不能或是不應該在看板里有產品負責人的角色。這只是說你不是非有不可。不管是用看板還是 Scrum，你都可以根據需要增加任意角色。-
Scrum 規定了固定時長的迭代:
固定時長的迭代是 Scrum 的基礎。你可以選擇迭代長度，但一般都會在一定時間內讓迭代長度固定不變，繼而形成節奏。
? 迭代伊始：綜合考慮產品負責人定義的優先級和自己的生產率，團隊從產品backlog 里面挑選出一定數量的條目，創建迭代計劃。
? 迭代進行中：團隊全心投入所承諾的任務。迭代范圍已固定。
? 迭代結尾：團隊向相關干系人演示他們可以工作的代碼，理想情況下，這些代碼基本上是可以發布的（經過測試可以交付）。然后團隊進行回顧，討論如何改進過程。
所以 Scrum 的迭代就是一段長度固定的單聲部旋律，混合了三種活動：計劃、過程改進、（理想中的）發布。
看板沒有規定固定時長的迭代:
你可以選擇什么時候做計劃，什么時候改進過程，什么時候發布。 你還可以選擇是有規律的采取行動（如每周一發布），還是按實際需要進行（如有了有用的東西之后就發布）。
WX20190415-190428.png -
看板按流程狀態限制 WIP，Scrum 按迭代限制 WIP:
WX20190415-190742.png
? 太低的看板上限 => 發呆的人 => 低生產率
? 太高的看板上限 => 發呆的任務 => 長生產周期 -
反饋機制
Scrum 的基本反饋環就是 Sprint：WX20190415-192304.png
看板的實時度量指標：
? 平均生產周期。每次有任務到達“Done”這一列（不管它叫什么吧，反正是最右邊那一列）的時候就更新數據。
? 瓶頸。典型癥狀就是 X 列里面堆滿了卡片，但是 X+1 列里空空如也。找找板上哪里有“氣泡”吧。
WX20190416-132316.png
-
Scrum 在迭代內拒絕變化：
WX20190416-133600.png
Scrum團隊一般會說，“對不起，這樣不行。我們已經承諾了這個sprint要做完A+B+C+D。
不過你可以把它放到產品 backlog 里面。如果產品負責人覺得它優先級很高的話，我
們會從下一個 sprint 開始做。
看板的原則是“一件出去，一件進來”（由 WIP 驅動），所以看板團隊的響應時間（多
久才能響應優先級的變化）就等于他們要花多長時間才能把手頭的事情做完。
-
Scrum 板在迭代之間重置
WX20190416-134320.png
Sprint 結束以后，板子就會進行清理──所有卡片全部去掉。
看板圖的樣子幾乎是一成不變的──你不需要把板子清理干凈，重新開始
-
Scrum 規定了跨功能團隊
WX20190416-134955.png
Scrum 板對所有感興趣的人全都是可見的，但只有它的所屬 Scrum 團隊才能編輯──這是他們管理迭代承諾的工具。
看板不強制要求跨功能團隊，看板圖也不是獨歸某個團隊所有。看板圖對應的是流程，不必非得是一個團隊。
-
Scrum 的 backlog 條目必須能跟 Sprint（生產周期） 搭配的上
Scrum 團隊只會承諾他們認為能在一個迭代里面做完（基于他們對“完成”的定義）
的任務。如果任務太大了，一個 Sprint 放不下，團隊跟產品負責人就會尋找方法拆
分，直到能放下為止。如果任務都比較大，迭代就會較長（雖然一般都不會超過四
周）。
WX20190416-135931.png
- Scrum 規定了估算和生產率
在 Scrum 里面，團隊要對每個承諾的任務估算其相對大?。?工作量），到迭代結束
的時候，把每個任務的大小相加，就得到了生產率。生產率是度量團隊能力──我們
每個 Sprint 能交付多少東西──的指標。
看板沒有規定估算這回事，但是看板沒有規定任何具體的方式，所以就去 Google 吧
- ****Scrum 規定了經過優先級排序的產品 backlog***
- Scrum 規定了每日立會
- Scrum 規定了燃盡圖
敏捷宣言
我們一直在實踐中探尋更好的軟件開發方法，
身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶合作 高于 合同談判
響應變化 高于 遵循計劃
也就是說，盡管右項有其價值，
我們更重視左項的價值。
