如何評價Kanban方法？（軟體開發）

01-15

主要指看板在敏捷軟體開發、軟體項目管理中的應用。

有bug追蹤系統誰還要看板

我用cynthia

總體上我不太看好看板在軟體開發里的應用，價值有限，不如 Scrum。

軟體開發不是汽車生產

豐田的看板：

Kanban

現在敏捷開發里用的看板，其實並不是豐田的看板，差距很大。

起源於 1950 年代的豐田看板系統（或方法）是用於生產製造系統，從消費端（如零售店）來拉動（pull）生產部件、零件的實時流動，通過看板（卡片）的記錄和傳遞，可以發現整個生產製造流程的瓶頸，儘可能減少各個生產、倉儲環節的庫存和浪費，從而實現 JIT（Just-In-Time，即時）與精益（Lean）生產和製造。這確實是一種了不起的思想方法，幾十年來在生產製造領域被證明是行之有效的。

然而，軟體開發，尤其複雜的系統設計（Design）和研發，是生產製造（Production）么？這個我們應該先搞搞清楚，Design 與 Production 不是一回事吧。

設計與生產最大的區別在於：在生產環節，比如汽車的製造量產，幾乎整個流程的所有細節都是明確、固定的，具有普遍的確定性（centainty）；而複雜軟體開發，由於處在設計階段，存在大量的不確定性（uncertainty）。

軟體看板與豐田看板的區別

以下是幾張經典的豐田式看板卡片（Kanban or Kanban card）：

Source: http://www.seton.com/kanban-cards-2158c.html上圖的看板卡片是 Seton 公司銷售的商品，旁邊的一段描述準確地解釋了什麼是看板：

Kanban card system is specially designed to record movements of materials through a process, increasing productivity
Kanban is a visual signal to trigger an action
The Japanese word "kanban" is loosely translated as ?card you can see?

日語的看板其實就是這麼一張小卡片。可能不少人也像我過去一樣，望文生義，理解錯了，以為「看板」就像白板一樣，是一大塊，上面擺放著許多卡片，而實際上那塊大板不是看板，是 Kanban board（看板板？），而看板板的上那些小卡片（小紙板）才是真正的看板。中日文的差異啊！

下圖是一張實際的看板：

Source: 5 Easy Rules For Kanban Success, Creative Safety Blog

豐田看板主要是用來在整個產品供應鏈（supply chain）中讓上家零部件供應方向下家需求方供貨的，請求供貨部件的名稱、數量（QTY）和供貨時間期限（約束，Lead Time）等是其中的重點信息。

再來看一下敏捷軟體開發中的看板（簡稱軟體看板）：

Source: http://samuliheljo.com/blog/building-a-kanban-board/

上圖其實是看板板，而上面擺放的各種軟體看板其實就是用戶故事卡片（user story cards）和故事分解後的任務卡片（task cards）。

問題來了，軟體開發的任務卡片或故事卡片與豐田看板（卡片）是一回事嗎？

結論

。。。

kanban是拿來做過程改進的，用來發現軟體開發過程中的哪一個環節是瓶頸，從而著力解決問題。

首先，我贊了張恂的答案，他的回答是不錯的。我的意見比較相似，補充一些如下：

首先要確定大家說的是同一個東西：軟體行業說的看板方法，是David J. Anderson所著書籍《看板方法 (豆瓣)》那個
這個看板方法號稱融合了精益思想、TOC約束理論和敏捷的實踐
從該方法的主張來說，他們認為自己並沒有主張具體的看板板格式，但實際上以他們的主張切入企業時，由於他們並不要求改變企業當前的流程，而是把當前的流程記錄到看板板上，所以會導致看板板上就是類似於瀑布的那種階段移交式的樣子。
我最大的困惑或者說懷疑在於：在生產製造行業，由於其質量控制的特點，通常在發現缺陷時，都是擱置或直接拋棄該缺陷零部件，使用下一個零部件即可，不大存在為了產出某個價值，重複返工該價值所設計的某個零部件的情況。然而對於軟體行業來說，要產出價值（軟體功能），當我們發現缺陷時，我們無法或極少會擱置、拋棄該零部件（例如，廢棄該段代碼，重新開發），然後在看板板上的流程中向後返工，例如從測試進入開發再返工，這是兩個行業的本質區別。
當然，很多看板方法專家會說，當價值進入例如測試階段發現問題，需要重新修改代碼時，卡片仍然停留在測試欄，然後開發人員要去協助測試人員解決該問題，並強調這是看板方法所需要的一種共同解決問題的理念。然而例如我們對比Scrum框架，該框架的要求不是在出現問題時，而是一直都需要是團隊共同前進、共同解決問題，這種做法不是更好嗎？而且如果是停留在測試欄，等待開發人員協助解決，那麼雙方的績效度量如何做呢，這個情況是開發沒做好，還是測試沒做好？開發沒做好那為什麼還要留在測試欄位？如果是測試問題，那麼回退返工這個問題在看板方法里如何解決？如果強調團隊協作，為何不從始至終強調，而只是在出現問題的時候強調？
如果我們說強調協作，大家一切解決問題，那麼開發、測試等各種職能不需要做太多區分的話，等同於把看板方法所提倡的那種看板板進行調整，各職能在看板板上的體現 -- 也即那些階段全部收攏（因為人員都收攏，一起協作了，那麼區分階段也沒有太大意義了）的話，那就只剩下需求欄、進行中欄、完成欄，那這不就是Scrum所提倡的任務板嗎？那麼看板方法與眾不同的地方，使得它不是其他方法的地方到底在哪裡呢？

如上是我對看板方法作為一種方法論、一種主張的疑問，這不代表我反對看板方法裡面的那些具體實踐。歡迎看板專家看到這個答案之後和我聯繫交流，我非常願意學習和了解更多看板方法，以及其他人對看板方法的看法、理解和經驗，查看我的知乎個人檔案，可以找到我的聯繫信息。

關於專業的第一答

現在的project正好從Scrum轉型到了Kanban或者說是Hybrid模式。

各位老師之前的答案中好像沒有怎麼提到Scrum和Kanban比較重要的一個不同，那就是Scrum是有時間框架的(sprint)，是對要開發的產品有一定掌控並且可以做一段時間的計劃的(sprint planning)。而Kanban的精髓在於有limit in WIP但是不在乎backlog的動態性，這種屬性對於BAU work, bug fixes這種你基本不能作出什麼靠譜的計劃只能來一個對付一個的工作來說就非常好用了。

比如我們現在的project到了最後測試階段，各個team都在support UAT，但是在sprint planning的時候你根本就不知道有多少個bug會出現，所以把這種support搞成一個user story就有點牽強。但是用Kanban的話，即可以不讓team over commit (有WIP limit), 又能很容易的看到瓶頸在哪裡，還能督促Product Owner去更好的做prioritization.

不好意思人長時間在國外，接觸agile也是在國外所以有些詞不知道怎麼用中文表示比較準確。歡迎大家討論。

關於看板的起源：

看板（Kanban，來源於日語）最初是豐田汽車公司的大野耐一於20世紀50年代發明的；當時是從超級市場的運行機制中得到啟示，將看板作為一種生產、運送指令的傳遞工具而被創造出來的;這個看板管理當時跟JIT（Just In Time）結合構成著名的豐田生產方式（TPS—-Toyota Production ）。也就是憑藉這個TPS，豐田完成了從「全日本第一」到「全世界第一」。

經過60多年的發展和改進,今天所談的看板管理大多是指精益看板之父 David J. Anderson 發揚的管理方法，它既繼承了豐田體系的精髓，又增加了諸多針對現代團隊，企業管理非常有益的看板實踐方法。現代化的看板系統始於2004年,最早是在微軟的XIT軟體維護團隊中實施（當時的看板系統還使用了電子化的跟蹤工具），得益於這個先河性的看板系統實施, 微軟的XIT團隊在生產率上有了超過200%的提升,前置時間減少了90%,在可預測性上也有了大幅提升。

看板管理有哪些優勢：

通過使用看板系統,我們可以將團隊的在做任務（work-in-progress）限制在一個設定的能力閾值內,根據已完成任務的交付速率來平衡交給團隊的工作需求(demand on the team)。這樣做可以獲得可持續完成任務的步調,讓所有人都可以實現工作與生活之間的平衡。

看板提供了視覺化的直觀管理感受，它能迅速暴露那些影響團隊效能的問題,因此,在使用看板管理的團隊所面臨的挑戰是如何專註於解決問題以維持穩定的工作流

看板也為質量和過程中出現的問題供了可見性,使得缺陷、瓶頸、變異性以及經濟成本等因素對工作流與交付速率的影響變得更明顯。單就使用看板來限制在做任務這一做法,就能促成更高的質量和更高的效能。流程改進和更好的質量結合在一起,有助於縮短前置時間(lead time), 提高預測性和準時交付能力。
通過看板建立團隊穩定的任務節奏,實現始終如一的可靠交付,這能夠幫助團隊與客戶、依賴的相關部門、供應商、價值流下游合作夥伴建立信任關係。而信任關係對每一方都是非常重要的。
然而看板方法最誘惑的在於：她提供了一種工具,讓我們可以解釋(和辯護) 為什麼與眾不同更好,為什麼在那種情境下某種與眾不同的選擇才是更正確的選擇。

總結：

正確的流程、良好的紀律性、強有力的管理及良好的領導力,這些因素加在一起,才是一個團隊能做好事情的根本。並非只有擁有最好的人才才能產出世界一流的成果。團隊的信任與默契程度對於結果的影響往往到大於團隊中個人的能力。

如上圖所示，團隊協同工具Worktile 讓工作更簡單本身也正是得意於這種信任與默契的產物，這一切都是受益於看板管理。所以我們現在做的就是希望將這種行之有效的方法，這種簡單高效的工作理念與大家一起分享。

這個命題太大了，長話短說，最近的感覺就是Kanban根本沒辦法進行有效的項目管理，即同意 @Antinomy Yang 的觀點只能用來發現過程的中的問題。

因為Kanban沒有監督控制進度的機制啊。

但是我也發現Kanban有個好處，我們現在的team是單一技能多項目團隊，Kanban至少在多個項目和資源管理上是有一定效果的。

看板在精益生產中是為了控制在制品庫存、平衡生產線以及促成拉式生產的，你們程序猿也有這問題？

我感覺看板方法挺不錯，讓工作流動起來，專註完成！

scrum是管理

XP是軟體開發辦法

看板不是一套方法論。只是在你已有的方法論系統上如果出現了問題，通過看板來發現問題，然後解決。理論是，通過看板來發現問題積壓在哪個環節了，消除浪費。

消除浪費，消除浪費，消除浪費。

和有沒有bug追蹤系統無關。

沒有銀彈。看板在研發過程中有它的價值，但也不應該把看板當成一個框，什麼都往裡面裝。