本文筆者依據工作中項目實踐的所思所想，并結合案例等分享了團隊看板使用中需要注意的一些問題，供大家一同參考和學習。

整個敏捷開發軟件里，若是用于敏捷團隊管理，最核心的就是看板機制。

所謂的看板機制，就是將團隊內的各個角色成員，安排在類似一條生產線上，各司其職，通力合作。

看板一詞來源于，日本的豐田制造。最早為了解決，生產機器之間的協作生產問題，發明了“kanban”：B機器在空閑時，發出一張“kanban”卡，A機器接收到此卡就進行推送任務。

整個看板的原型，有兩個重要的點：To?Do?起始點和Done 終點，在兩點之間夾雜著任務的生成過程。

To Do

可以稱為待辦清單，但在敏捷開發里，一般稱之為 積壓板。注意，這里的To Do 里的內容，基本上是已經確定要處理的事，和需求清單有一定區別。

需求，往往是使用級別的事務。而且很多需求需要經過分析后，轉換為若干待辦事項。

比如：“想要一輛自動駕駛的車”，這是一個需求，但是經過分析，可能會拆分為，“自動駕駛系統實現”，“車架生產”這兩項工作項。

而且，整個敏捷團隊開發就是為了快速小步迭代，有時一個需求拆分出的多個工作項，為了實現快速迭代，不一定會將這些工作項統一放到一個迭代中。

積壓板區域，最大的作用就是告訴團隊成員，“我們還有多少工作沒做”。

Done

這是個事務完結區，主要是開發完成的工作項（待辦清單內容進入實際開發中，就稱為工作項），基本上都是已上線的工作項。

之所以有這個區域，一是因為敏捷開發時，有些功能是灰度上線——有可能帶著不經意察覺的問題，萬一上線的出了大問題，可以調度工作項。另一原因就是，能夠告知整個團隊，此次迭代完成了哪些工作項，能夠在后期團隊項目總結時，有根可尋。

Doing

在起止點之間的部分，就是生成過程了，也就是開發過程。

可以用泳道來標識各個狀態。而泳道是由團隊角色決定的，常規開發團隊中有 產品、開發以及測試。那中間的狀態泳道往往是由這三類角色所需要的狀態構成。

有了看板原型，我們可以看到各個整個團隊成員的工作，能夠了解每個人工作量，大致預覽項目進度。

但是撐起整個看板的，不是看板本身，而是工作項。

如果說，看板是整個敏捷開發的核心，核心的核心就是工作項。

敏捷開發的核心思想中，為了快一開始就抓住最核心的功能，從小畫大，由內向外，逐級構建，就像是滾雪球一樣。

所以，為了滾好這個雪球，一般會把一整個項目，拆分成多個沖刺（或叫迭代，二者有一定區別，下次再分析）

一個項目，可能被拆分為多個沖刺，每個沖刺里的需求，被拆分為多個工作項。

項目>沖刺>工作項。（需求可被直接存放在項目里，也可以在沖刺里）

工作項是大家實際的工作指導，也是實際開發過程的數據載體。從一開始，界定要實現的目標，就記錄在工作項上，再到中間的開發過程都應反饋在工作項本身，以及后面所暴露的開發缺陷等信息，一個工作項都可以承載。

而看板只是工作項的展示容器，工作項的狀態就等于看板的泳道。而工作項的狀態，就是由實際業務角色決定的，這也就是上面提到的“泳道是由團隊角色決定”。

一個工作項從頭跑到尾，狀態的不斷變化，就體現在了“生產過程”的看板上，也使此看板有了具體的使用意義——以豐富的方式展現團隊的進度，利于站立會召開，以及團隊協作的信息交流。

使用場景

1. 為整個團隊協作服務。能夠在看板上，進行便捷化的操作，例如拖拽變更狀態、快速編輯信息、分派人員等。
2. 為實際開發工作作為指導。明確團隊成員每人每天要做的工作，整個團隊的待辦清單。
3. 項目進度的管理。整個看板，其實也是某一段沖刺的大進度條。開發團隊每日的站立會議使用工具，項目經理的進度監控板。

本文由 @29號同學 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。