整個敏捷開發裏，最核心的就是看板機制。所謂的看板機制，就是將團隊內的各個角色成員，安排在類似一條生產線上，各司其職，通力合作。
看板一詞來源於，日本的豐田製造。最早爲了解決，生產機器之間的協作生產問題，發明了“kanban”：B機器在空閒時，發出一張“kanban”卡，A機器接收到此卡就進行推送任務。
整個看板的原型，有兩個重要的點：1.To Do 起始點 2.Done 終點。在兩點之間夾雜着任務的生成過程。
To Do
可以稱爲待辦清單，但在敏捷開發裏，一般稱之爲 積壓板。注意，這裏的To Do 裏的內容，基本上是已經確定要處理的事，和需求清單有一定區別。
需求，往往是使用級別的事務。而且很多需求需要經過分析後，轉換爲若干待辦事項。比如：“想要一輛自動駕駛的車”，這是一個需求，但是經過分析，可能會拆分爲，“自動駕駛系統實現”，“車架生產”這兩項工作項。而且，整個敏捷團隊開發就是爲了快速小步迭代，有時一個需求拆分出的多個工作項，爲了實現快速迭代，不一定會將這些工作項統一放到一個迭代中。
積壓板區域，最大的作用就是告訴團隊成員，“我們還有多少工作沒做”。
Done
這是個事務完結區，主要是開發完成的工作項（待辦清單內容進入實際開發中，就稱爲工作項），基本上都是已上線的工作項。
之所以有這個區域，一是因爲敏捷開發時，有些功能是灰度上線——有可能帶着不經意察覺的問題，萬一上線的出了大問題，可以調度工作項。另一原因就是，能夠告知整個團隊，此次迭代完成了哪些工作項，能夠在後期團隊項目總結時，有根可尋。
Doing
在起止點之間的部分，就是生成過程了，也就是開發過程。
可以用泳道來標識各個狀態。而泳道是由團隊角色決定的，常規開發團隊中有 產品、開發以及測試。那中間的狀態泳道往往是由這三類角色所需要的狀態構成。
有了看板原型，我們可以看到各個整個團隊成員的工作，能夠了解每個人工作量，大致預覽項目進度。
但是撐起整個看板的，不是看板本身，而是工作項。
如果說，看板是整個敏捷開發的核心，核心的核心就是工作項。工作項是大家實際的工作指導，以及實際開發過程的數據載體。從一開始界定要實現的目標，就記錄在工作項上，再到中間的開發過程都應反饋在工作項本身，以及後面所暴露的開發缺陷，一個工作項都可以承載。
既然看板是工作項的展示容器，工作項的狀態就等於看板的泳道。一個工作項在正常進行中，是從頭跑到尾，但是難免有些工作項因爲種種原因被關閉了，所以此時會有一個回收站來收集這些工作項。
這些泳道中，最核心的就是三條 產品（設計分析）、開發、測試。
表設計部分
看板只是個容器，看板所承載的工作項纔是具體的業務，雖然說工作項可以存在各個泳道，但是從數據存儲上，它其實就是一張表，通過不同的字段來區分,例如，工作項的時間 雖然有九個日期，因爲整體業務表現都是依序進行的，所以除了兩個完結時間點，其他的從新建（積壓板狀態）直到測試完成 採用的是 ADate、BDate...GDate,關閉採用的是ClDate/發佈則是用RelDate。
而對於工時，這張表就是工作項表的細表，因爲一個工作項可能產生多個工時，也就會產生多行工時數據。
To be Continued
當然，以上所述這些，都是一些指導性原則，任何東西都有個性化的一面，就像加勒比海盜裏說的那樣
法典只不過是一些指導，它並不是必須遵守的規定
