GitChat · DevOps | 如何結合 Scrum 和 Kanban

來自 吳穹、申導、侯伯薇 在 GitChat 上精彩分享
原文：如何結合 Scrum 和 Kanban
更多IT技術分享，盡在微信公衆號：GitChat 技術雜談

背景介紹 by 吳穹

這篇文章背後的故事是這樣的：某同窗寫了一篇比較Scrum和Kanban的文章。這是一個老話題了，最近有一些思考，感受不吐不快。就想寫一篇小文，拉上幾位老友，一塊兒和你們扯扯這個話題。

比較Scrum和精益Kanban是一個僞命題

Scrum是一個框架，在此框架中人們能夠解決複雜的自適應難題，同時也能高效並創造性地交付儘量高價值的產品。而精益看板是一組促進組織變革的思惟（框架）。所以，不理解上述背景，而直接比較二者是好笑的。讀者須要意識到，Scrum是一個交付框架，而精益看板是一組變革思惟。Scrum相對具體，而精益看板相對抽象。

Scrum的歷史做用

不能否認，在敏捷運動的發展過程當中，Scrum起到了很大的做用。我把它稱爲跨越瀑布的柺棍。Scrum的3355框架，簡單明瞭，對剛剛脫離瀑布開發模式的團隊來講，比較容易適應。

Scrum實施中的最大陷阱

Scrum實施中有三個常見問題：

1. Scrum成爲小瀑布；
2. 團隊職責混亂；
3. 忽視技術實踐。

下圖就是Scrum實施成小瀑布的實例，例如10天Sprint被規劃成2天需求澄清，2天設計，4天開發，2天測試。這樣的後果每每是需求延期，開發時間不足，開發移交質量差，測試不充分等等。Scrum成功實施的關鍵是引入精益流動思想，保證每一個Backlog Item獨立流動，在10天迭代中基本保證天天都有Backlog Item完成能夠移交測試。惋惜的是，如此重要的原則在Scrum框架裏面居然沒有說起，不能不說這是Scrum框架的一個重大缺陷。

Scrum實施的另外一個常見問題是團隊職責混亂，這是由於Scrum框架中給出了一個過度理想的角色模型：惟一產品負責人，自組織開發團隊，不對交付結果負責的Scrum Master。我見過的大多數團隊都無法按照這樣的組織結構運做，這種團隊在Scrum中叫Scrum-but,特製沒有嚴格按照Scrum要求運做的團隊，Scrum不能保證其實施效果。這實際上是一個很是好的賣假藥邏輯，本藥包治百病，只要天天連續服用25個小時，如不能按說明服用，服用無效不退款。

實際上，不一樣企業有不一樣特色，咱們應該作的是按照精益思想，分析價值流動中的問題，而後對症下藥，調整優化組織結構。

Scrum實施的另外一個常見問題是忽視技術實踐，在Scrum實施過程當中未能同步推動。以致於最先XP社區，有所謂「不舉」的Scrum的提法。Scrum實施過程當中，必定要分析研發團隊交付過程當中面臨的技術挑戰，在Scrum實施過程當中同步改進。

用精益的思想指導Scrum實施

給你們推薦 三本書，在實施Scrum以前，你須要先去理解軟件開發的本質，以後你就能夠了解Scrum實踐背後原理，而後你就可以更成功地實施Scrum了。

感謝

要感謝的人不少，首先要感謝我家人對我一直以往的支持。要感謝David Anderson，Alistair Croll等國際大師的不吝賜教，要感謝路寧和何勉兩位引我走上精益之路，要感謝王大爺讓我更多關注人的視角，也要感謝全部其餘Agilean的小夥伴們多年來的支持。

分析 by 申導

第一性原理

A first principle is a basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.

這是來自於量子力學計算的一種說法，意思是從頭算，只採用最基本的事實，而後根據事實推論。

早在古希臘哲學家亞里士多德的書中，第一原理是這樣表述的："在每一系統的探索中，存在第一原理，是一個最基本的命題或假設，不能被省略或刪除，也不能被違反。"

著名創新企業家馬斯克眼中的第一原理是這樣的："咱們運用「第一原理思惟」而不是「比較思惟」去思考問題是很是重要的。咱們在生活中老是傾向於比較——別人已經作過了或者正在作這件事情，咱們就也去作。這樣的結果是隻能產生細小的迭代發展。"

總之，「第一原理」的思考方式是用物理學的角度看待世界的方法，也就是說一層層剝開事物的表象，看到裏面的本質，而後再從本質一層層往上走。

研發系統是一個複雜系統，須要靈活應對和探索，所以對於產品研發(動詞)的第一性是什麼？答案是，在反饋循環(loop)進化和學習。

幾千年前的《道德經》曰：「反者道之動，弱者道之用。天下萬物生於有，有生於無。」 意思是世事無常，萬物都在不斷的循環之中變化。後有達爾文的進化論，今有互聯網精益創業試錯手段，無不體現了敏捷思惟就是在不肯定和複雜環境中，創建低成本地響應變化的能力，讓價值能順暢地流動，保持輕鬆和優雅，這種靈活性稱爲敏捷性(agility)。

複雜域下的決策和領導力

敏捷人士應該對Cynefin領導力框架和Stacy Matrix矩陣不陌生，是把事物分爲四個領域：

1. 簡單
2. 繁雜
3. 複雜
4. 混亂

複雜狀況下，因果關係是互爲循環關係和互相交叉的，表現出巨大的不肯定性和複雜度。美國軍方稱之爲VUCA時代，投入重金研究在不一樣場景下如何進行決策。在產品研發和軟件工業中，一直都出於複雜領域中，傳統 的過程改進和科學管理理論徹底不適用，因而引入複雜科學及衍生的管理3.0來解釋如何進行管理。

在90年發展起來的敏捷思惟和方法論中，Scrum是發展比較好的一支，其獨特的三大角色設定，特別是跨職能團隊的設定，很是好地貫徹了「用複雜應對複雜」這個原則，發揮團隊的自主性和積極性，而不是用僵化的流程來管控。正如人腦如今已經沒法理解基於人工智能的AlphaGo如何戰勝了全人類的圍棋高手同樣。

另外，Scrum還提倡對三個方面進行 拆分(breakdown)：

1. 時間，把長達幾個月的項目週期拆分爲短的時間盒(timebox)。這是治療拖延症，強調節奏感，強迫各方融合協做的靈丹妙藥；
2. 內容，把大塊的需求分拆爲小的用戶故事，（在軟件中還包括把軟件模塊進行解耦和抽象）。《道德經》曰"圖難爲其易，圖大爲其細"；
3. 團隊，把大型組織分拆爲跨職能的小團隊（亞馬遜創始人貝索斯說的"Two pizza team"也是這個意思）。

經過這種拆分，其實就是在將事物從複雜領域拉向簡單領域，讓人腦可以理解和處理。我稱之爲「降維打擊」，即縮小範圍，減小變量，分而治之。把事物從cynefin框架的complex域降到simple域。這是scrum的核心武器，我講Scrum培訓時都會提到這件事情。

Scrum與Kanban之爭

二者都借鑑了精益思想，其目標包括低成本、短迭代地快速交付和響應，以最大化客戶價值。顯著減小任務批量規模，去除瓶頸以加快交付客戶價值產出的速度。再也不進行規模經濟競爭，而是在適應能力、避免庫存和小單位工做方面的競爭。可視化、timebox都應該爲這個目標而服務。

其實Scrum與Kanban是POV（視角）不一樣，非要比較的話，Scrum的視角是從responsiveness，更可能是破解複雜性，而kanban視角是從flow，更可能是整流順暢性。因此這兩種方法的視角和想要達到的狀態不一樣，但互有支持和重疊，本質最終都指向第一性原理。

改進是精益的核心之一，至於怎麼改進，精益思想給了一些手段，好比"go see"與可視化管理等，然而相對於Scrum方法，精益與看板對循環（loop）這件事提的都很少。至於價值流建模，Kanban對研發過程是一種落地手段，可是還有不少是Kanban難以進行建模的，好比持續交付流水線、TDD和重構過程、模塊化設計等。

Kanban的理論基礎不少來自於Don的那本書，其出發點是系統的flow，經過可視化來推進這個變化。Kanban更可能是一種可視化的協做模型。它對現有過程進行建模，看板試圖經過可視化手段以及WIP限制（因），達到「流動」和「拉動」這種狀態（果）。但並未對具體實踐給出太多的指導和設定，好比沒有固定時間盒，沒有要求團隊要重組，也沒有要求需求拆分。固然你也採能夠用迭代，稱之爲Kanban Cadence。若是是不嚴格的時間盒，更像FDD/XP；若是應用固定時間盒，那麼也就更偏向Scrum的玩法。（kanban創始人其實也試圖在融入更多循環的概念）

Kanban更傾向於關注長週期的狀態，好比累計流圖的運用，而經典scrum則主要關注於一個迭代的狀態，好比燃盡圖的運用，在這兩個方面卻是存在互補。

Scrum更可能是一種產品與組織的學習和改進模型，毫不是項目管理方法。也借鑑了精益思想、PDCA戴明環、時間盒/GTD等。

時間盒是Scrum除了三大角色設定（包括跨職能團隊）、拆分以外的另外一大特色，強調節奏感，這是軟件交付的核心，等你們節奏感有了，天然流式交付。時間盒也有助於人們的共識對齊。任何產品和組織協做，最難的一步就是alignment，這是全部方法都求之不得的。借用王大爺的話："Scrum給了咱們不須要理解就能獲得一些「東西」的框架，經過給你一次又一次失敗的機會來調整本身，alignment在動盪之中天然會造成"。短的時間盒也是更調整和響應變化帶來更大的餘地。

Scrum創始人Ken說Scrum是一種暴露問題的手段，而Kanban也說本身是可視化管理，這不同嗎？

實戰中的選擇

我本身在輔導團隊時，會以Scrum爲核心框架，創建基本的迭代運做方式，造成頻密的溝通和反饋機制是第一步，附以Kanban（更可能是採用了其可視化的功效，其實經典Scrum中的任務板就是一個簡化的可視化板）做爲協做模型來暴露問題，以及輔導各類XP工程實踐來提升持續集成、整潔代碼、自動化等能力。更重要的是，我本人認爲除了這些硬知識，軟技能更可以引起變革，因此經過引導來造成共識，利用教練技術來培養人是必不可少的。

現實中，確定不是一個團隊那麼簡單，每每會涉及Scaling（大規模擴展）的話題，這個時候，kanban通常會採用多級看板可視化，而Scrum則會涉及如何分割和定義Product Ownership的思考。

Scrum強調各類Ownership的明晰，這戳到了不少組織的痛處，所以的確很難應用，就像理想的共產主義，可能你們永遠都是在前進路上而沒法達不到終點，因此Scrum-But也是一個常態，小瀑布也比大瀑布進步了不是？多數的kanban應用也就是停留在可視化階段，角色融合好幾年也發生不了，限制WIP上限更只是一個美好的願望。

看看你的生活、社會，那有完美的事情呢，打折扣是必定的，因此不用焦慮，而是要接納現實的不完美，而且意識到還有不少須要改善的地方，這纔是敏捷和精益思惟。若是哪一個公司簡單套一下，就宣稱本身已經敏捷或精益了，那是胡扯。

漸進變革？

看板是漸近變革的工具？看板只是一塊板子。你看它，它就是看板，你不看它，它什麼都不是。Scrum中每一個迭代後作回顧，難道不是漸近變革？PMP要求每一個項目以後都作屍檢，難道不是漸近變革？百日維新與南北戰爭中，都有人掉腦殼，區別只是腦殼顏色和數量的問題。Scrum與看板（以及各類轉型）都是先革命再漸近。Scrum要從新分配職責角色，看板呢，Duang~，你立起來一塊大板子，逼着你們天天早上要對着板子（不是，要對着同事）講工做，搞得事事都透明兮兮的，難道不是一種革命？管理3.0說了，看板是一種新的協做模型，引入看板就是一種革命。

感謝

我在成爲ScrumAlliance的CTC認證敏捷教練這一路，很是感謝李國彪(Scrum/agile)、吳穹(Kanban/lean)多年的支持和鼓勵，教會了我從不一樣視角看問題和學習，同時也感謝全部社區夥伴們的相互扶持，還有從個人各位客戶身上學到了不少不少。

參考閱讀

• 認知科學)有一個核心信條：只在單一的層級上進行研究，不可能完全地理解精神和腦。認知科學是一個跨學科領域，包含了來自各領域的貢獻，包括心理學、神經科學、語言學、精神哲學、計算機科學、人類學、社會學和生物學。
• "Waterfall, Lean/Kanban, and Scrum", Ken Schwaber, 2010
• 《管理3.0》
• 《複雜理論》
• 《系統思考》
• 《從管理1.0到管理3.0的大躍進。管，或者無論，問題都在那裏，不增不減。》

經歷 by 侯伯薇

首先，感謝博士的邀請，讓我也一塊兒來和你們聊聊Scrum和Kanban之間的區別與聯繫。我會從自身經歷的角度來講說。

我接觸Scrum早於接觸Kanban，在此以前，我對Agile的理解更多來自於極限編程。你們也知道，由於是極限，因此對於我的的要求比較高，不只是技術能力，並且也包括了我的做爲程序開發者的基本素質。因此，最先的時候，我會認爲想要實施敏捷，就須要團隊中的每一個個體都有足夠高的能力和意識，那樣纔可以保證Agile的順利實施，而在普通的技術團隊裏面，並無那麼簡單。

然而，當時就有朋友和我說，若是實施的是Scrum，能夠在某種層度上下降對個體的要求，也可讓更多組織實施Agile，這樣就下降了敏捷轉型的門檻。

正是由於這樣，我才潛下心認真學習了Scrum，並得到了一系列的Scrum認證，認證的過程自己就是不斷學習和提高的過程。通過了解，我發現，Scrum確實經過一個框架達到了目的。其中的三三五五既照顧到了「心」的層面（價值觀），也照顧到了腦的層面（知識），至於實際的手的層面（實踐），一方面已經有了基本流程的定義，另外一方面咱們能夠在實際狀況下根據具體的問題填充不一樣的技術實踐進來。

然而，在通過了一段時間以後，我發現其實想要完整地——或者說原封不動地——採用Scrum，還存在比較大的困難。由於Scrum定義的三個角色在現有的團隊中至少有一個是沒有的；而現有團隊中存在的多個角色到了Scrum中是會被幹掉的。這就讓PM、PL等管理職位很尷尬，一時間風聲鶴唳草木皆兵，生怕公司實施了敏捷轉型以後，一天早上起來就會沒了飯碗。因此，大多數採用Scrum的組織都是對其進行了必要的調整，更多的是採用了其中的迭代開發的流程，以及保證節奏感和儀式感的各個會議，從而可讓團隊在現有的組織結構下不斷持續改進。

敏捷宣言會強調，在敏捷團隊中的溝通很是重要，而Scrum中定義了你們按期溝通的會議或者說儀式，卻沒有定義具體的工具。所以，很多團隊都使用了任務板來促進團隊中的溝通。最先看到的任務板都是「Todo - Doing - Done」的簡單形式。

接下來我接觸了Kanban方法，其中的第一條實踐「流程可視化」給出了很是大的啓發。原來咱們可使用物理或者電子的白板來展現全部的進度，而且在上面能夠管理全部任務的流動，在其中發現擁堵、等待、分享等嚴重影響進度的因素，從而採起相應的措施來對症下藥，保證團隊效率的提高。

深刻學習Kanban方法以後，愈來愈發現其中的奧妙之處，比方說：如何限制在製品，包括每一個人身上的任務數量和每一個狀態下的任務數量；如何管理流動；如何策略可視化等等。不少內容都是爲了保證開發團隊任務的順暢進行，從而在最短的時間內把最有價值的功能交付給用戶，得到反饋以持續改進。

在應用Kanban方法的經歷中，我會發現，這種方法會很是容易被團隊所採用，由於它並不會在開始的時候對企業或者組織的結構形成任何影響，並且也不會直接對團隊的運行方式作太大的改變，只是建立一塊看板，就能夠實現最簡單的「流程可視化」的效果，而從中很快就能夠體現出團隊流程中可能存在的問題了。不過，我也發現，其他幾條實踐的實行倒是任重而道遠，比方說：限制每一個狀態下的在製品數量。這條實踐就是好久以後可能都不會在團隊中執行，由於你們身上的任務多這種情況已經習慣了，或者說沒有真的痛，不痛就不太容易改變。

這兩種方法在各自的發展過程當中會不斷有碰撞，相互學習，固然也會有爭論和辯解。而在實際的工做中，我更喜歡融合兩種方法的優點或者說擅長的方面，用特定的方法來解決特定的問題。

比方說，咱們可能會先用「流程可視化」的看板來讓你們發現流程中的問題，讓你們關注任務的流動狀態，找到其中擁堵和等待的問題和致使問題的風險；同時會對需求進行拆分，縮短開發週期（通常到兩週），採用Scrum的方式來開各類各樣的會議，保證團隊的節奏感，而且快速得到業務用戶的反饋；而站會通常會請你們在看板前面開，這樣的話能夠迅速、具體地瞭解到任務狀態的現狀以及變化，並且能夠達到「同一地點」的目的；在回顧會議裏面，咱們可能會請團隊也根據狀況對看板的使用和效果作持續的調整和改進；

這樣就能夠把Scrum和Kanban方法結合在一塊兒，發揮出更大的效用。相信這也是不少企業裏面所採用的方式。「尺有所短，寸有所長」，咱們要作的就是取長補短，達到一加一大於二的效果。

最後借用Google當年對於敏捷的一句話：「當咱們談論作敏捷的時候，自己就已經不敏捷了。」咱們能夠試着把更多的精力放在具體問題的分析上，在出現問題的時候，無論使用的是Scrum仍是看板方法，只要可以解決問題，就都是好方法。

感謝

首先必定要感謝家人對個人支持，大家也是我最大的動力。我要感謝在敏捷路上引領、陪伴我一塊兒前行的各位朋友：滕振宇、吳穹、李國彪、王宇、申健、姜信寶、孟繁強、管婷婷、歐蘭輝、尹學罡等等，名單太長，在此沒法一一列舉，有了大家我在這條路上就不會孤單。

總結 by 王宇

淵源

我先簡單說一下我跟Scrum和Kanban的緣分。

對於Scrum來講，我要感恩Bill（李國彪）是他帶我出來作諮詢和培訓的。從12年年中我就開始了有強度的Scrum培訓過程。若是說師從的話，實際上是Vernon Stinebaker（史文林）給我發的CSM證書。以後我又參加了Bill（李國彪）的CSM課程，滕振宇的CSM課程，黃方的Scrum課程（那個時候他沒拿到CST）。我在12到13年度應該交付了不少Scrum的培訓，半天的，一天的，兩天的，甚至是3天的數量已經記不清楚了。我們就不說其餘的Scrum相關的培訓和認證了哈。反正如今應該都過時了（我今年決定放棄全部收費的認證）。在經歷Scrum的過程，給我很大的衝擊。並非理論自己，而是以前ThoughtWorks對認證和Scrum理論嗤之以鼻的態度。我在這個過程當中加深了對Scrum自己的理解，並嘗試應用於我所指導的團隊。

對於Kanban來講，我要感恩路寧，是他給我傳遞了不少Kanban自己的理論和思惟（在ThoughtWorks的時候，咱們還一塊兒參觀過豐田的配件工廠來了解精益的過程）。他也是我從13年開始的諮詢夥伴，那時的咱們主要服務於平安科技。因此在這裏也感恩一下「平安科技」，謝謝。Kanban大學的證書也是他給我發的。我我的認爲他的理論和David J Anderson 的理論細節仍是有區別的。這裏，若是有什麼講錯弄錯的話，請你們罵他。

關鍵點

Scrum的關鍵點在於利用若干角色、工件、儀式使得團隊造成紀律性，並副作用於過程的優化。

Kanban的關鍵點在於利用團隊本身對過程經過可視化造成協做平臺，經過控制在製品數量造成流動。

關鍵區別

第一：就如同《思惟發條》的文章《Scrum與Kanban，激進與保守》說的同樣，我是贊同路寧的觀點的。Scrum更爲革命，Kanban更爲保守。Scrum更強調紀律性，而Kanban更強調對現實的認可並漸進式啓動變革的過程。這點其實看似能夠互相融合的方法，其實在根本上有質的區別。

第二：Scrum就是一個框架，而Kanban從必定的角度來講是一種方法或是系統。這一點能夠從培訓的複雜度就能夠看出一些眉目。Scrum給我10分鐘我就能給你講得了解它，知道怎麼作就不是Scrum。對於Kanban，10分鐘估計還在開場熱身呢。並且對於Kanban方法自己的講師數量也能說明一些問題。

第三：玩壞了的結果不一樣。

Kanban容易玩成管理者微觀控制的工具（管理者來設計看板，並推行管理理念），或是不疼不癢的協做平臺。

Scrum容易玩成你們對交付很是疲憊（成了壓迫的手段），或僅僅多了個ScrumMaster角色。

管理的慣性

任何事物都有慣性，管理也不例外。對於基層出身的管理者固然但願可以實現共產主義。而對於已經位高權重的人來講，如何在這個世紀延續上世紀經典的過程管理方法（新瓶裝舊酒）他們還抱有一絲但願。瓜熟蒂落，那些領導天然選用本身認爲靠譜的方式和方法。但對於Scrum來講，真正有效果的是從開始就擁有Scrum文化或價值觀的公司。而Kanban的選用，也在工程能力很強的地方效率異常高（好比在ThoughtWorks內部）。

可悲的是你們看到的大多都是面上的東西，流程、方法、框架。其實無論是Scrum或Kanban我我的認爲對於敏捷轉型來講……

就是一個假命題

我可能會用到看板，也可能會用到Scrum。並利用教練的心法來使團隊更高的提升紀律性，提升協做能力，提升彼此的認同感和榮譽感。我認可導入敏捷的過程要具體狀況具體分析，要靈活的使用咱們的理論和技巧。但注意

武功套路的存在是爲了打退敵人

你不能爬在地上打王八拳，也不能是招式套路展開的品勢展演。若是你沒有武功套路，或是說我本身研究出來的。這不是很差，只是我擔憂你的攻擊力會受到野路子的侷限（固然你多是大師）。另外一方面我追求搏擊的「美感」，若是一點美感都沒有我是忍受不了的（請你們理解天秤座）。

說了這麼多，我就說兩個傻傻的趨勢，供你們思考（我也要反思本身）：

正由於Scrum框架的簡單以及來錢比較方便，一些所謂的「諮詢顧問」抱着革命的心態鬥志昂揚，不知廉恥的實施敏捷導入的過程。他們就像早期的革命者，或傳教士。一方面喊着咱們須要不要臉，另外一方面本身還真的不要臉地銷售本身。
正由於Kanban方法的數據與分析。理科生感受爽啊，可找到理論依據了。難道你能夠否認這些理論嗎？他們腦子裏的勾兌關係如此的精緻且不容他人的質疑。一方面認可看板是團隊改進本身的手段，另外一方面不停經過管理層推行看板系統的優化和進化。

唉……一聲嘆息

舶來品，依舊是舶來品。轉型導入的艱難依舊是艱難異常。我驚歎團隊中有不少人放棄了獨立思考，放棄了敢於承擔。我一方面心痛，另外一方面我徹底相信舶來品對人員主動性的假設在中國是錯誤的。

但我未曾退卻，由於這些人與我共同面對這偉大的挑戰。平安的國柱、偉丹；順豐的小林、傑偉、怡雯；招行的餘強；東軟的繁強、耀東；吳博士；宇安；申健……還有正在閱讀這篇文章的你……

---

實錄：《三人行： Scrum 和 Kanban 的結合實戰解析》

---