Kanban是敏捷開發(fā)（Agile Development）的一種實(shí)現(xiàn)模式拔创。
早在1940年，日本豐田公司已借鑒超市庫存的管理方法來改善自身的工作流程富蓄。超市在管理庫存的時(shí)候剩燥，總希望庫存量盡可能與消費(fèi)者的需求接近，以減少不必要的庫存立倍。只要庫存量能夠及時(shí)根據(jù)消費(fèi)者的需求量來調(diào)節(jié)灭红，超市就能極大地提高倉庫的運(yùn)行效率，從而最終為自身和消費(fèi)者都創(chuàng)造價(jià)值口注。豐田公司采用了這種及時(shí)管理模式（Just In Time变擒， JIT）。
在豐田公司內(nèi)部寝志，當(dāng)一個組完成現(xiàn)有任務(wù)并準(zhǔn)備好接受下一個任務(wù)時(shí)娇斑，它會把這個信息通過向其他組遞出一張卡片策添，或者Kanban，來傳達(dá)毫缆。雖然現(xiàn)代Kanban工作流程有了很大改進(jìn)唯竹，但是它依然保留著Just In Time的核心理念。
簡單來說苦丁，及時(shí)制度（JIT）主要的核心是“讓正確的物資浸颓，在正確的時(shí)間，流動到正確的地方旺拉，數(shù)量是剛剛好的數(shù)量猾愿。” -- Wikipedia
這種管理模式同樣適用于管理軟件開發(fā)账阻。
盡早發(fā)現(xiàn)瓶頸
假設(shè)一個小組的工作流程為一個pipeline蒂秘。如果里面的testers一周只能測試5個features，那么即使developers一周能實(shí)現(xiàn)10個新features淘太，整個小組一周也只能交付5個features姻僧。這里，testers就是pipeline中的瓶頸蒲牧。
假如這個瓶頸沒有被發(fā)現(xiàn)撇贺，那么testers面前的任務(wù)就會堆積如山，盡管如此冰抢，整個小組的效率并沒有得到提高松嘶。
如果問題得不到解決，developers辛辛苦苦實(shí)現(xiàn)出來的新features無法及時(shí)投放市場挎扰，最終將可能導(dǎo)致錯失商機(jī)翠订。更有嚴(yán)重的是，如果testers為了提高效率遵倦，降低對質(zhì)量的要求尽超，將有可能導(dǎo)致低質(zhì)量的代碼進(jìn)入到產(chǎn)品中。 從另外一個角度來說梧躺，如果團(tuán)隊(duì)及時(shí)發(fā)現(xiàn)瓶頸所在似谁，就能對此作出調(diào)節(jié)。比如掠哥，他們可以調(diào)派更多的testers巩踏，或者讓部分developers幫助完成部分的test automation工作。
所以续搀，我們回到一開始的主題塞琼，看看Kanban如何及時(shí)地向團(tuán)隊(duì)反饋當(dāng)前的瓶頸！
舉一個栗子
Kanban管理模式簡潔而有力目代。一個簡單的Kanban系統(tǒng)甚至可以由一張大紙板屈梁，和貼在上面的便簽組成嗤练。
在這個系統(tǒng)中，大紙板上畫有多個列表在讶。一個列代表一個的工作步驟煞抬，一張便簽即代表一個的任務(wù)。每個任務(wù)都經(jīng)過這個工作流程從最左邊的列流向最右邊的列构哺。每個列頂部有一個數(shù)字limit革答，代表該列最大便簽容量。
這個容量limit是Kanban和管理模式最大的不同曙强。通過限制某步驟的最大容量残拐，Kanban能夠防止過度生產(chǎn)（overproduction），并動態(tài)地揭示流程的瓶頸碟嘴。
Limiting work-in-progress reveals the bottlenecks so you can address them.
在下面的栗子中溪食，Test一欄已經(jīng)達(dá)到了它最大的工作容量3，不能夠放入新的任務(wù)娜扇。Analysis和Development因?yàn)門est進(jìn)度的原因错沃，無法把已經(jīng)完成的任務(wù)挪到下一欄，也到達(dá)了它們的最大容量（3和5）而不能放入新任務(wù)雀瓢。通過Kanban表格枢析，團(tuán)隊(duì)發(fā)現(xiàn)Test成為了瓶頸，并開始思考如何幫助testers改進(jìn)測試環(huán)節(jié)的效率刃麸。
當(dāng)testers完成了一個任務(wù)之后醒叁，這個任務(wù)便簽就被挪到Deploy一欄。
由于現(xiàn)在Test一欄終于可以接受新任務(wù)了泊业，Test把沼、Development、Analysis從各自上一欄中挪入一個新的任務(wù)便簽脱吱。
從上面的例子可以看出智政，Kanban能夠動態(tài)地展示團(tuán)隊(duì)工作流程的瓶頸。一旦Project Manager發(fā)現(xiàn)某個環(huán)節(jié)影響到團(tuán)隊(duì)進(jìn)度箱蝠，ta可以及時(shí)調(diào)配資源改進(jìn)這個環(huán)節(jié)。
四大核心原則
Kanban從脫胎自豐田公司的工程管理方法以來垦垂，在不同領(lǐng)域都有發(fā)展出具有領(lǐng)域特色的實(shí)現(xiàn)形式宦搬。雖然形式多樣，但是它們始終遵循著下面一些核心原則劫拗。（Kanban有四大原則和五大原則兩種不同說法间校，這里我們采用了較為流行的四大原則說法）
為了表述準(zhǔn)確，我們這里直接引用了文章 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 雖然有很多相似的概念胁附，但是它們是兩種不同的項(xiàng)目管理方法。這里滓彰，我們引用文章 Atlassian: A brief introduction to kanban 中的一個表格來比較兩者之間的不同控妻。
| Item | SCRUM | KANBAN |
|---|---|---|
| Cadence | Regular fixed length sprints (ie, 2 weeks) | Continuous flow |
| Release methodology | At the end of each sprint if approved by the product owner | Continuous delivery or at the team's discretion |
| Roles | Product owner, scrum master, development team | No existing roles. Some teams enlist the help of an agile coach. |
| Key metrics | Velocity | Cycle time |
| Change philosophy | Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. | Change can happen at any time |
有的團(tuán)隊(duì)把Kanban和Scrum兩種方法糅合成一種叫做Scrumban的方法。這個方法吸取了Scrum中固定長度的Sprint和各種角色（Product Owner揭绑、Sprint Master等等）概念弓候，同時(shí)也吸收了Kanban中“Focus on Flow” 和 “Limit Work In Progress”等原則。但是他匪，剛開始采用Agile的團(tuán)隊(duì)建議只采取Scrum和Kanban中的一種菇存，在熟練掌握所選方法后才根據(jù)團(tuán)隊(duì)特點(diǎn)進(jìn)行相應(yīng)的糅合或創(chuàng)新。
參考資料
Kanban敏捷開發(fā)
Atlassian: A brief introduction to kanban
LeanKit：What is Kanban邦蜜？
Kanban Blog：What is Kanban?
