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

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

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

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

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

To Do

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

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

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

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

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

Done

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

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

Doing

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

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

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

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

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

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

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

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

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

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

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

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

使用場景

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

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

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

,