Kanban敏捷開發

本文作者：Wenzhe 個人網站： Hackjutsu Dojo

Kanban是敏捷開發（Agile Development）的一種實現模式。

早在1940年，日本豐田公司已借鑒超市庫存的管理方法來改善自身的工作流程。超市在管理庫存的時候，總希望庫存量盡可能與消費者的需求接近，以減少不必要的庫存。只要庫存量能夠及時根據消費者的需求量來調節，超市就能極大地提高倉庫的運行效率，從而最終為自身和消費者都創造價值。豐田公司采用了這種及時管理模式（ Just In Time ， JIT ）。

在豐田公司內部，當一個組完成現有任務并準備好接受下一個任務時，它會把這個信息通過向其他組遞出一張卡片，或者Kanban，來傳達。雖然現代Kanban工作流程有了很大改進，但是它依然保留著 Just In Time 的核心理念。

簡單來說，及時制度（JIT）主要的核心是“讓正確的物資，在正確的時間，流動到正確的地方，數量是剛剛好的數量。” – Wikipedia

這種管理模式同樣適用于管理軟件開發。

盡早發現瓶頸

假設一個小組的工作流程為一個pipeline。如果里面的testers一周只能測試5個features，那么即使developers一周能實現10個新features，整個小組一周也只能交付5個features。這里，testers就是pipeline中的瓶頸。

假如這個瓶頸沒有被發現，那么testers面前的任務就會堆積如山，盡管如此，整個小組的效率并沒有得到提高。

如果問題得不到解決，developers辛辛苦苦實現出來的新features無法及時投放市場，最終將可能導致錯失商機。更有嚴重的是，如果testers為了提高效率，降低對質量的要求，將有可能導致低質量的代碼進入到產品中。 從另外一個角度來說，如果團隊及時發現瓶頸所在，就能對此作出調節。比如，他們可以調派更多的testers，或者讓部分developers幫助完成部分的test automation工作。

所以，我們回到一開始的主題，看看Kanban如何及時地向團隊反饋當前的瓶頸！

舉一個栗子

Kanban管理模式簡潔而有力。一個簡單的Kanban系統甚至可以由一張大紙板，和貼在上面的便簽組成。

在這個系統中，大紙板上畫有多個列表。一個列代表一個的工作步驟，一張便簽即代表一個的任務。每個任務都經過這個工作流程從最左邊的列流向最右邊的列。每個列頂部有一個數字limit，代表該列最大便簽容量。

這個容量limit是Kanban和管理模式最大的不同。通過限制某步驟的最大容量，Kanban能夠防止過度生產（overproduction），并動態地揭示流程的瓶頸。

Limiting work-in-progress reveals the bottlenecks so you can address them.

在下面的栗子中，Test一欄已經達到了它最大的工作容量3，不能夠放入新的任務。Analysis和Development因為Test進度的原因，無法把已經完成的任務挪到下一欄，也到達了它們的最大容量（3和5）而不能放入新任務。通過Kanban表格，團隊發現Test成為了瓶頸，并開始思考如何幫助testers改進測試環節的效率。

當testers完成了一個任務之后，這個任務便簽就被挪到Deploy一欄。

由于現在Test一欄終于可以接受新任務了，Test、Development、Analysis從各自上一欄中挪入一個新的任務便簽。

從上面的例子可以看出，Kanban能夠動態地展示團隊工作流程的瓶頸。一旦Project Manager發現某個環節影響到團隊進度，ta可以及時調配資源改進這個環節。

四大核心原則

Kanban從脫胎自豐田公司的工程管理方法以來，在不同領域都有發展出具有領域特色的實現形式。雖然形式多樣，但是它們始終遵循著下面一些核心原則。（Kanban有四大原則和五大原則兩種不同說法，這里我們采用了較為流行的四大原則說法）

為了表述準確，我們這里直接引用了文章 LeanKit：What is Kanban？ 中對這四大原則的闡釋。

• Visualize the workflow
• Limit Work in Process
• Focus on Flow
• Continuous Improvement

Visualize the workflow

By creating a visual model of your work and workflow, you can observe the flow of work moving through your Kanban system. Making the work visible—along with blockers, bottlenecks and queues—instantly leads to increased communication and collaboration.

Limit Work in Process

By limiting how much unfinished work is in process, you can reduce the time it takes an item to travel through the Kanban system. You can also avoid problems caused by task switching and reduce the need to constantly reprioritize items.

Focus on Flow

By using work-in-process (WIP) limits and developing team-driven policies, you can optimize your Kanban system to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.

Continuous Improvement

Once your Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times and more. Experiments and analysis can change the system to improve the team’s effectiveness.

Scrum vs. Kanban

Kanban 和 Scrum 雖然有很多相似的概念，但是它們是兩種不同的項目管理方法。這里，我們引用文章 Atlassian: A brief introduction to kanban 中的一個表格來比較兩者之間的不同。

有的團隊把Kanban和Scrum兩種方法糅合成一種叫做Scrumban的方法。這個方法吸取了Scrum中固定長度的 Sprint 和各種角色（ Product Owner 、 Sprint Master 等等）概念，同時也吸收了Kanban中“Focus on Flow” 和 “Limit Work In Progress”等原則。但是，剛開始采用Agile的團隊建議只采取Scrum和Kanban中的一種，在熟練掌握所選方法后才根據團隊特點進行相應的糅合或創新。

參考資料

更多精彩內容，歡迎訪問官網 http:// BitTiger.io 或關注 “論碼農的自我修養” 微信公眾號：bit_tiger