本文筆者依據工作中項目實踐的所思所想,并結合案例等分享了團隊看闆使用中需要注意的一些問題,供大家一同參考和學習。
整個敏捷開發軟件裡,若是用于敏捷團隊管理,最核心的就是看闆機制。
所謂的看闆機制,就是将團隊内的各個角色成員,安排在類似一條生産線上,各司其職,通力合作。
看闆一詞來源于,日本的豐田制造。最早為了解決,生産機器之間的協作生産問題,發明了“kanban”:B機器在空閑時,發出一張“kanban”卡,A機器接收到此卡就進行推送任務。
整個看闆的原型,有兩個重要的點:To Do 起始點和Done 終點,在兩點之間夾雜着任務的生成過程。
To Do可以稱為待辦清單,但在敏捷開發裡,一般稱之為 積壓闆。注意,這裡的To Do 裡的内容,基本上是已經确定要處理的事,和需求清單有一定區别。
需求,往往是使用級别的事務。而且很多需求需要經過分析後,轉換為若幹待辦事項。
比如:“想要一輛自動駕駛的車”,這是一個需求,但是經過分析,可能會拆分為,“自動駕駛系統實現”,“車架生産”這兩項工作項。
而且,整個敏捷團隊開發就是為了快速小步疊代,有時一個需求拆分出的多個工作項,為了實現快速疊代,不一定會将這些工作項統一放到一個疊代中。
積壓闆區域,最大的作用就是告訴團隊成員,“我們還有多少工作沒做”。
Done這是個事務完結區,主要是開發完成的工作項(待辦清單内容進入實際開發中,就稱為工作項),基本上都是已上線的工作項。
之所以有這個區域,一是因為敏捷開發時,有些功能是灰度上線——有可能帶着不經意察覺的問題,萬一上線的出了大問題,可以調度工作項。另一原因就是,能夠告知整個團隊,此次疊代完成了哪些工作項,能夠在後期團隊項目總結時,有根可尋。
Doing在起止點之間的部分,就是生成過程了,也就是開發過程。
可以用泳道來标識各個狀态。而泳道是由團隊角色決定的,常規開發團隊中有 産品、開發以及測試。那中間的狀态泳道往往是由這三類角色所需要的狀态構成。
有了看闆原型,我們可以看到各個整個團隊成員的工作,能夠了解每個人工作量,大緻預覽項目進度。
但是撐起整個看闆的,不是看闆本身,而是工作項。
如果說,看闆是整個敏捷開發的核心,核心的核心就是工作項。
敏捷開發的核心思想中,為了快一開始就抓住最核心的功能,從小畫大,由内向外,逐級構建,就像是滾雪球一樣。
所以,為了滾好這個雪球,一般會把一整個項目,拆分成多個沖刺(或叫疊代,二者有一定區别,下次再分析)
一個項目,可能被拆分為多個沖刺,每個沖刺裡的需求,被拆分為多個工作項。
項目>沖刺>工作項。(需求可被直接存放在項目裡,也可以在沖刺裡)
工作項是大家實際的工作指導,也是實際開發過程的數據載體。從一開始,界定要實現的目标,就記錄在工作項上,再到中間的開發過程都應反饋在工作項本身,以及後面所暴露的開發缺陷等信息,一個工作項都可以承載。
而看闆隻是工作項的展示容器,工作項的狀态就等于看闆的泳道。而工作項的狀态,就是由實際業務角色決定的,這也就是上面提到的“泳道是由團隊角色決定”。
一個工作項從頭跑到尾,狀态的不斷變化,就體現在了“生産過程”的看闆上,也使此看闆有了具體的使用意義——以豐富的方式展現團隊的進度,利于站立會召開,以及團隊協作的信息交流。
使用場景
- 為整個團隊協作服務。能夠在看闆上,進行便捷化的操作,例如拖拽變更狀态、快速編輯信息、分派人員等。
- 為實際開發工作作為指導。明确團隊成員每人每天要做的工作,整個團隊的待辦清單。
- 項目進度的管理。整個看闆,其實也是某一段沖刺的大進度條。開發團隊每日的站立會議使用工具,項目經理的進度監控闆。
本文由 @29号同學 原創發布于人人都是産品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!