最近在學習實踐精益Kanban方法，結合自己團隊實踐Srum的經歷，整理些資料二者的差異。相較於Scrum, 我更推崇精益Kaban。
Agile是一套理論和原則，就像天邊的北極星。Devops是一種軟件開發和運維團隊間自動化和集成過程的方法。當實現Agile和Devops方法時，Kanban和Scrum提供了管理這些複雜工作的不同的實踐。
簡單來說，Kanban和Scrum是進行敏捷開發或項目管理工作的兩個不同的策略或者方法論。
- Kanban方法意味着持續性與更好的流暢性。
- Scrum則是基於更短，更加結構化的工作衝刺。
Scrum：一種結構化的敏捷方式
Scrum源自於橄欖球的一種爭球方式。現在作爲一種迭代式增量軟件開發過程，通常應用於敏捷軟件開發。Scrum將工作分解成較小的功能單元，並在週期性固定的時間段內持續的交付。
- 把組織細分成小組、跨功能、自我組織團隊。
- 把工作細分成細小、實在的交付成果，交排人員負責需求清單以及跟據重要性排優先級別，由團隊估算每個項目相對工量。
- 把整個開發時間分成固定時長的短迭代（通常於一至四星期），在每個迭代後演示新增可發佈功能。
- 優化發佈以及跟客戶一起更新優先級別，基於每個迭代後發佈的觀察。
- 優化過程，在每個迭代之後進行回顧
在我們考慮考慮採用SCRUM之前，先問自己一個問題：整個開發團隊是否是專職團隊，並且負責該項目。
SCRUM團隊會承諾每個Sprint結束都會交付產品或者價值。如果你的團隊成員有肯能去做別的其他項目，那麼SCRUM團隊無法承諾每個Sprint的交付。另外，在選擇SCRUM時，還需要考慮以下方面：
- 節奏
SCRUM強調的是快速交付，在每個Sprint結束時交付用戶可用的可交付物，每個Sprint一般2周最多4周，有着清晰的開始和結束時間。該框架的背後思想是利用短的時間段強迫把複雜任務分解爲小的user story.
- 關鍵指標
衡量一個SCRUM團隊表現的關鍵指標是velocity（效率），即在一個Sprint中交付的story points的數量。該指標用以指導後續Sprint中可以承諾完成的story points。想象一下，如果一個團隊每個Sprint中平均完成35個storypoints，那麼後續的sprint中我們不會完成45個story points.
- 應對變化
一般情況下，SCRUM團隊儘量不要在Sprint過程中進行範圍變更。如果團隊通過客戶反饋發現他們正在開發的功能沒有他們認爲的那麼有價值，這種情況下需要變更該Sprint的開發範圍，以便優先交付對客戶最優價值的功能或價值。
Kanban：一種持續改善，變化靈活的過程
Kanban方法最初起源於豐田的JIT（Just In Time），之後作爲一種高效管理軟件開發流程的技術和思想應用於互聯網行業。Kanban方法以價值流動爲核心，不斷髮現團隊中的瓶頸工序，進行改進，使價值流動更加順暢和快速。
**工作流程形象化 **
- 把工作細分成任務，寫在卡紙上，貼在牆上
- 把欄命名好，來顯示任務在工作流程中的狀況
限制“在製品”（work in progress，簡稱 WIP）
- 明確設定限制在每個狀態下同一時間能有多少工作任務
度量生產週期（即完成一個任務的平均時間），優化開發過程，縮短開發週期和使它更易於預測。
發佈方式
- 看板過程中，軟件更新只要完成就可以隨時發佈，沒有一個週期或者提前決定的日期。理論上，看板並不需要預先確定一個時間點來交付一個任務或者軟件更新。如果一個特性完成，無論早晚，都無需像SCRUM過程那樣等到Sprint結束再發布。
角色
- 整個團隊對看板負責。有些團隊可能需要一個敏捷教練的角色來幫助看板過程的順利進行，但是不像SCRUM一樣，有一個看板master, 來保證每件事情都平穩運行。看板過程中，整個團隊相互協作，來負責交付看板上的每個任務。
關鍵指標
- 循環週期（Cycle Time）是看板過程的一種重要指標。它指的是一個工作項從開發到結束所花費的平均時間。工作項循環週期的改善意味着團隊的成功。
看板團隊經常用來分析項目進展狀況的工作是累計流圖（CFD）。它可以用來表示每個狀態下的工作項的數量，從而幫助識別出限制工作流的瓶頸。
應對變化
- 看板的工作流可以任何時候進行變更。任何時候都可以添加新的工作項，也可以暫停或刪除正在進行中的項目，這一切取決有優先級。而且，如果團隊交付能力發生變化，可以重新設定WIP（Work In Progress）限制，工作項也可以被隨之調整。
比較差別，探索適合自己的方法
在團隊的項目管理實踐中，我們往往將二者的優勢結合起來綜合的使用，以便幫助團隊更好的完成目標，而不是爲了使用方法而使用方法。
相同點：
- 兩者都符合精益和敏捷思考
- 兩者使用"拉動式"安排日程
- 兩者限制開發中工作數目
- 兩者是透過透明度來驅動過程開進
- 兩者集中提早及衡常的付運軟件
- 兩者基於自我組織團隊
- 兩者要求把工作細分
- 在兩個情況下發布計劃都是基於經驗數據（速度／開發週期）持續優化
不同點：
系統範圍
在討論Scrum和看板之前，有必要澄清系統範圍。在Scrum裏，系統範圍由產品的定義和完成的定義決定；而在看板裏，看板系統的邊界定義了系統範圍。
- Scrum的運作是圍繞產品的，每個迭代開始從產品待辦列表挑選進入下一個迭代的故事，迭代結束將故事做到完成。故事的範圍是由產品的定義決定的，故事在產品的範圍內是端到端的。完成的定義體現的是故事可交付的程度，也就定義了價值流的終點。
- 看板(Kanban)系統的邊界定義了價值流的範圍，由此決定故事的範圍。故事會流過整個看板系統，其終點狀態完成的定義也就相當於Scrum中完成的定義。
需要指出的是Scrum的系統範圍定義通常是基於組織結構的，它涉及到產品的定義和團隊的組建，產品待辦列表要與團隊相對應，因此係統邊界相對嚴格；而看板的系統範圍定義只是基於在統一的看板系統做可視化和管理流動，因此係統邊界相對寬鬆。這也跟兩者不同的變革導入思路有關。
兩者都有一個思想去儘可能地擴展系統範圍，以利於管理整體的價值流動和實現。只是體現出來的對Scrum而言是產品定義的擴展和完成定義的擴展，而對看板而言是看板系統邊界的擴展。
在我看來，無論Scrum還是看板，都希望幫助到價值交付和持續改進，但是它們採取了不同的方式。最顯著的差別在於Scrum採用迭代而看板採用流。
Introduction to Jira Software Boards | Atlassian
價值交付
- Scrum和看板都致力於最大化價值交付，無論是採用迭代還是流，關鍵都在於減少在製品。在製品由進行中故事的個數和故事的大小決定。
- 當採用迭代時，限制故事的個數是間接的，迭代長度間接限制了故事的個數。當採用流時，限制故事的個數卻是直接的。
故事的大小是另一個影響在製品多少的因素。迭代會推動故事的拆分，因爲在迭代結束時要求能夠將故事完成。然而，把故事拆得過小會使拆分變得不自然（也就是爲了拆而拆），反而降低了那些拆分出來故事的價值。故事不能被無限地拆分，一個故事在有價值的前提下能拆多小通常存在自然的限制。採用迭代有可能會人爲地破環故事的自然大小和完整性，而採用流則會更遵照故事自然的顆粒度。
持續改進
Scrum和看板都致力於持續改進，無論是採用迭代還是流，關鍵都在於創造合適的挑戰來驅動改進。當改進目標達成後，改進就會陷入停滯，而持續改進卻需要永不停歇。Scrum和看板都是通過提升目標來再次創造合適的挑戰以使改進繼續，但是提升目標的方式卻不同。
Scrum裏最重要的改進目標是在迭代結束做到完成。這裏有兩個變量，迭代長度和完成的定義。當通過改進做到迭代結束完成後，我們會看完成的定義是否可以擴展。擴展後的完成定義產生了新的挑戰，從而提供了繼續改進的動力。當完成的定義已經達到可以交付時，我們會看是否可以縮短迭代長度，這又能驅動進一步的改進。
看板的改進目標一方面來自於直接的在製品減少。通過在製品限制的降低，系統中更多問題會被暴露出來，從而驅動改進。另一個重要的因素是圍繞前置時間的改進，前置時間的縮短對價值交付和提升靈活性都有幫助，因此是很好的改進目標。
變革導入
最後想說說的是關於Scrum和看板的變革思路, 根本在於改善（小變化）和改革（大變化）的平衡。當引入過大變化，由此產生的挑戰過大，結果適得其反。當過於保守引入過小變化，又使變化過於緩慢，甚至逐步喪失了改革的能力。
Scrum的有效運作需要組織設計，它的第一步在我看來是改革，然後由每個迭代回顧驅動持續改進。看板尊重現有的組織結構，從現狀出發，因此它的第一步更接近改善，然後也是持續改進。對兩者而言持續改進理論上引發改善或者改革都有可能，實際中發生更多的是改善。
當變革涉及系統範圍的擴展時，Scrum要求組織結構的改變，而看板要求的最小改變只是放在統一的看板上進行可視化管理，因此更能反映“可能的藝術”。而當現有的組織結構制約了協作模式並最終影響到價值流動時，組織結構仍然需要被突破。
先導入Scrum還是 Kanban?
從屬性上來看:
Scrum 容易探討未知，處理複雜項目，拿來開發新東西威力無比。
Kanban 是教我們如何自我檢討，可以迅速消除浪費，而得到好的效能。
如果你是開發團隊，當然是先從Kanban 開始。
先檢討團隊的基本動作，整頓好了再來開始作新的東西，從事開發的動作，自然減少浪費。這是精益Lean 的好處。
(有太多開發團隊，只曉得一意往前衝刺，忽略了自己在開發上的浪費，這會造成很難走得久遠，尤其是Startup的團隊尤其如是。)
如果你是運維團隊，當然是先從Kanban 開始。
視覺化是最大的亮點，團隊可以看見工作上的維護流程是一件相當有價值的事，針對個人亦是如此，人們常常因爲養成習慣了，就一直持續做同樣的事情，很少會有機會回過頭來檢討，哪裏做得浪費了應該改進。
看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。
如果你是測試團隊，當然是先從Kanban 開始。
看的見以後纔可以減少猜測的比例。測試團隊在擬定測試計劃之前，一定要對待測的產品或程序有足夠的瞭解，纔可能寫出實用的測試案例，不至於浪費大量的測試資源，或做了過多的重複性測試。
你可能覺得奇怪，爲什麼都是Kanban Method 先行呢?
其實原因很簡單，因爲它"單純“，不是簡單喔! 它沒有想像上的簡單，因爲它可以演進得很有深度，但是它的目的很單純，就是追求效能。不像Scrum 的目的，是要來應付複雜的項目開發作業，基本上的方向就完全不一樣的
相較於Scrum, 我更推崇Kanban, 因爲限制少，推動Kanban的過程本身其實是定義團隊流程規則的過程，不需要特定的角色，容易理解和接受。
將看板方法融入Scrum的開發過程纔是上策
看板方法是一種流程控制，他不是一種具有完備基礎的方法學，雖然他的潛在發展相當可觀，但目前他仍只是一種提供我們產出高效能的流程控制法而已。
他缺少需求描述、沒有完備的會議規劃、少了團隊職責分配，少了很多很多軟件開發上該有的措施，這一點讓他看起來十分空泛，但就是這個特性也讓他十分適合融入其它開法方法中，尤其是Scrum。
看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發方法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精益Lean 一支的重大貢獻。
也就是這樣的典故，讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。
著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書)，書中就大量的採用 WIP(Work-In-Process)的觀念，實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。
看板方法先行
因爲它可以減少組織在推行敏捷上的阻力，它能讓工程師以最好的節奏持續進行開發工作。又能將精益觀念帶入團隊運作。
融入Scrum的開發過程
因爲看板方法的流程控制方式是用來提升Scrum運行時的效能，讓 Scrum 能真正用來克服複雜的軟件程序開發過程。
Scrum 的目的在解決複雜的軟件開發作業
許多人誤把Scrum 當成加速軟件開發的銀子彈。這是錯的!
它的目的不在加速開發(加速開發工作是開發工具的廣告詞)，它的目的是在解決複雜的軟件開發作業，讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品，且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。
開發團隊千萬別因爲實施了看板方法而誤以爲需要把 Scrum 拋棄了，這是一種錯誤的想法，讓他們相輔相成纔能有更大的效益。
先導入 Scrum還是 Kanban? 二者之間並沒有衝突存在，都是通往敏捷開發的路徑，就看你現在最需要的是那一樣，那一樣就先來吧
- 已經在使用 Scrum 作開發工作的人士，學習 Kanban Method 可以讓他們進入精益的領域，有所依據的持續追求更好的效能。
- 先學會Kanban 方法 再跨足 Scrum 的人呢? 則可以看到敏捷開發在處理複雜問題上的具體方法，真正懂得去追求效能之外的正確性與方向。
實踐分享 - 結合業務性質，持續改進，適應外部變化
基於團隊業務情況（服務交付類型），結合自己對兩者的理解，以及實踐中遇到的問題，畫了如下圖：
我們遇到的問題：
- 需求不固定，經常面臨隨時插入高優先級需求
- 客戶反饋需要快速解決，特別是阻塞性的
- 資源緊張，負責平臺模塊多，業務差異較大
探索改進過程
- 混亂期，團隊新組建，需求沒有得到有效跟蹤
- 建設期，逐步開始通過Jira跟蹤需求，嘗試敏捷Scrum, 各種站會，評審會，評估故事點等實踐，此時外部需求可控，從2周迭代發佈（小瀑布）逐步過渡到隨時可發佈狀態 （伴隨着建立了分支模型，分支模型也隨之調整了兩版，建立了和環境對應的持續交付流水線）
- 問題期，業務壓力大，各種Scrum會議感覺作用不大，團隊成員不需要參與所有需求評審，PO需要多個業務板塊切換準備需求
- 調整期，推動研發人員專職負責某個模塊，負責整體迭代把控，拆分成迭代火車，各負其責，把sprin當作一個個專題需求火車
- 改進期，雖然劃分了責任邊界，但是外部需求/事務增加，積壓嚴重（狀態更新不及時），無法從宏觀瞭解整體情況（整個看板都是滿的），所以嘗試使用Kanban方法，梳理業務流程，在原有流程不變情況下，明確定義團隊協作規則，制定不同緯度/角色關注的看板，同時建立個人/團隊儀表盤，關注動態變化
- 需求看板 - 研發/產品經理關注
- Scrum迭代看板 （專注於內部開發迭代）- 研發同學關注
- 客戶問題看板 （劃分優先級泳道）
- 缺陷看板 - 測試同學關注
- 運維/運營看板 - 包括技術債務，改進，支持事項等
- 整體全局看板
經過上述過程，團隊逐步向 “自組織“團隊演化，”分工有序“，簡化花裏胡哨的Scrum儀式, sprint變成了業務發佈火車（劃分迭代範圍之用），把整個團隊跑迭代變成了2-3人的“按照業務領域劃分的迭代”，放棄了故事點評估（實踐證明似乎不太適合我們），相比於scrum偏重於迭代間的改進，我們更看重需求交付速度，不希望有擠壓，降低外部插入的需求或事項帶來的干擾，讓成員更專注。
總結
-
Kanban主要用來可視化你的工作，限制在製品，使其最大效率的流動。Kanban團隊聚焦在減少花在項目（或者用戶故事）上的從開始到結束的時間。他們通過Kanban board 來實現它並持續改進他們的工作流。
-
Scrum通過設置稱爲衝刺（Sprint）的間隔去承諾需要承載的軟件開發。它的目標是通過蒐集和集成客戶反饋去創造一個產品的快速學習環。Scrum團隊採取特定的角色，創造特定的工件，執行特定的儀式來保持事情的推進。
| ** |
Scrum | Kanban |
|---|---|---|
| 規劃 | 它有固定的計劃。它專注於規劃。它從 sprint 計劃開始，以 sprint 回顧結束。召開每日會議，以便團隊瞭解接下來的步驟、優先級以及從先前步驟中獲得的經驗。 | 它沒有固定的計劃，也沒有舉行日常會議。在看板中，隨時可能發生變化，即頻繁發生變化。 |
| 時間線 | 在 Scrum 中，我們處理具有固定持續時間的衝刺，這意味着經過一些固定時間後，我們將向客戶交付一些東西。 | 看板沒有衝刺的概念，因此它沒有將產品交付給客戶的固定時間表。 |
| 任務估計 | 在衝刺計劃期間，決定從產品待辦列表中提取多少活動並添加到衝刺待辦列表中。例如，如果衝刺是兩週，那麼選擇活動的數量，使它們可以在衝刺內完成，即在兩週內完成。 | 它不估計任務。 |
| Scrum Master | 在 Scrum 方法論中，我們有一名 Scrum 主管負責管理團隊並每天主持會議。 | 在看板方法論中，我們沒有任何 Scrum Master。交付有價值的產品是每個人的責任。 |
| 適用性 | 這種方法適用於大型項目，因爲大型項目可以分爲多個衝刺。 | 主要適用於小型項目。 |
| 不斷變化 | 在 Scrum 中，可以在較短的衝刺中輕鬆適應不斷的變化。 | 如果發生任何重大變化，那麼看板方法就會失敗。 |
| 成本 | 在 Scrum 中，任務是估計的，即在一個 sprint 中進行固定數量的活動，因此項目的總成本最小。 | 在看板中，沒有估算任務，因此項目的總成本不準確。 |
| 角色和職責 | 在 Scrum 中，Scrum Master 爲團隊成員分配了特定的角色，而產品負責人則告訴團隊成員必須工作的產品目標。 | 沒有爲團隊成員分配預定義的角色。所有團隊成員都有責任合作交付有價值的產品。 |
| 生產力衡量 | 生產力是通過使用週期時間或完成整個項目從開始到結束所花費的時間來衡量的。 | 生產力是通過沖刺速度來衡量的。 |
| 發佈方法 | 每個衝刺結束後的小版本。 | 它提供持續交付。 |
區別一：實施過程中關注核心的區別
Scrum實施的核心可以概括爲“化繁爲簡”，從幾個維度解釋下：
- 團隊角色的定義，將團隊人員定義爲三個角色，Scrum Master（主要負責消除障礙，帶領團隊運作）、Product Owner（主要負責描繪產品遠景，定義優先級）、Scrum Team（主要負責實現產品）
- 工作任務的拆分，將產品需求拆分成小的用戶故事，並評估優先級
- 時間的拆分，將項目週期拆分成固定時長的迭代週期，每個迭代交付一部分可驗收的功能，通常迭代長度爲1到4周
Kanban方法在實施的過程中更多關注的是可視化的價值流動，從幾個維度解釋下：
- 拉動式生產，下游工作完成後，主動拉動上游的任務移動
- 限制WIP（work in progress），明確設定限制每個狀態下，同一時間內有多少工作量，減少同一狀態同一時間內，任務和價值的堆積
- 可視化的價值流動通常是端到端的流動，直觀的反映用戶的價值（通常是可交付的用戶需求），並且反映出在價值流動過程中的瓶頸和問題，不斷爲團隊改善提供依據
區別二：限制WIP數量的方式不同
Scrum與Kanban方法都會限制在製品數量，不過限制方式有所不同，
- Kanban方法限制的更加直接，同一狀態同一時間內的工作任務有最大限制；
- Scrum是間接性的通過迭代（sprint）來限制。限制WIP的核心目的是加速交付用戶需求的價值流動。
區別三：對任務變更管理的不同
在Kanban方法的中，下游任務完成後（有顯式化的拖動規則），即可拉動上游任務下移，同時，只要生產力允許，即可新增需求。 
在Scrum方法下，當每個迭代的sprint Backlog確認後，當前迭代是不允許新增需求的，新增加的需求可以體現在下個迭代的sprint backlog中。
區別四：改進依據的不同
- Scrum是以生產率作爲計劃和改進的依據，以迭代（sprint）數據作爲依據，分析迭代的相關數據（包括生產率、完成率等）；
- Kanban方法是使用生產週期作爲計劃和過程改進的依據。
Scrum和Kanban方法作爲即敏捷又精益的典型代表，除了上述不同外，還存在很多相同點：
- 二者都和敏捷與精益相對應。敏捷中的持續改進思想在Scrum和Kanban都有所體現，而且是很核心的一個內容；精益中的拉動式生產在Scrum和Kanban中也都分別覆蓋，Kanban方法體現的更加直接，下游直接拉動上游的工作任務。
- 二者都關注儘早的交付價值，儘可能頻繁的發佈可使用的軟件。Scrum將整個項目週期拆分成多個迭代，每個迭代發佈可驗收的軟件；Kanban方法在每個功能開發測試完成後就可以進行部署和發佈。
- 團隊狀態都直觀的反應在Scrum board和Kanban Board上，方便找到問題和瓶頸，並進行改善。
案例
比較了Scrum與Kanban方法之後，如何結合二者在團隊中進行項目管理實踐呢？這裏提供一個案例，從迭代、版本、變更、改進四個方面來介紹
迭代：在Kanban方法中，並未規定明確的迭代，而在Scrum中是規定了固定的迭代週期。在我們的團隊中，迭代週期從一月一迭代，逐步變爲一月兩迭代，到現在的兩個自然週一個迭代，完全固化了迭代週期的概念。
將複雜開發週期很長的開發任務，分解成多個迭代週期，每個迭代週期交付一些可驗收的軟件或者功能。有利於減少風險，並更好的適應變化，及時的根據反饋調整工作目標。
版本：在迭代中，我們以排入版本計劃的功能點（story）作爲工作重點，排入版本的story爲交互已經完成的功能點（story），這些功能點可以直接進入開發和測試環節。這些story便是我們當前迭代可以交付的功能或者軟件。與此同時，產品、交互和視覺同學會繼續拉取需求池中的功能點，開始進行設計，準備下個迭代版本中的內容。使整個價值流動更加順暢。
變更：對待變更，我們同樣有自己的一套流程規範，既沒有像Kanban方法一樣，只要生產力允許，便可以新增需求；也沒有像Scrum一樣，版本內容確定，當前迭代基本不允許變更。
在實際過程中，當存在緊急需求，由產品經理髮起，和各個角色進行評估風險和對現有版本的影響，並採取相應措施降低由於需求變更對整個系統產生的影響，最後由項目經理髮出變更通知的郵件。
改進：我們改進的依據之一是團隊數據，由於我們所有的任務都是通過JIRA進行管理，可以方便的拿個團隊各種數據，包括：總工作量、總完成工作量、完成率、有效工作量、有效工作率、bug數、bug率等，對這些數據進行分析，發現團隊的問題，幫助團隊進行改進。
