最近朋友打算在專案組中推廣Trello的看板管理方法。由於之前自己專案組也實踐過半年的Trello看板管理方法，就與他交流了使用經驗。其實，去年半年的Trello使用體驗還是不錯的，有不少的心得。不過，沒有系統的總結過，未能很好的分享出來。趁著春節大假，該補補了。

       Trello，是免費的線上多人協作看板系統。操作體驗非常好，加之看板管理的理念簡潔易懂，使trello是個分分鐘上手的東西。

在實踐Trello之前，參考了《精益開發實戰——用看板管理大型專案》。結合自己的實際情況，設計瞭如下的Trello看板管理方案。

Trello看板管理方案

       trello.Board 表示一個專案或一些相關的專案。

       trello.List 是任務列表。從左到右，List 組成的一個工作流，任務在列表之間轉移，走完任務的生命週期。我經過多次的調整，建立瞭如下的List：

待定任務
    ||
    \/
未處理需求任務、未處理優化&&學習任務、未處理Bug任務
    ||
    \/
本週待處理任務
    ||
    \/
本週處理中任務
    ||
    \/
本週測試中任務
    ||
    \/
本週已完成任務
    ||
    \/
歷史測試中任務
    ||
    \/
歷史已完成任務
 

“待定任務”任務列表用來收集一些可能做也可能不做的任務，多是一些關於專案的較長遠的任務。如確實需要開發，則移動到相關的下游的未處理任務列表。

“未處理需求任務”是工作需求分解後的任務，即關於實際業務的需求，一般就是領導交代下來的任務。

“未處理優化&&學習任務”，這個就是自己優化系統性能的人，以及與專案密切相關的新技術學習任務。這個列表中的任務，體現了你對自己的要求。

“未處理Bug任務”，Bug，都是傷心事，就不多說了。

“本週待處理任務”、“本週處理中任務”、“本週測試中任務”和“本週已完成任務”是周迭代的相關的4個列表。經過，多次的調整，發現以周圍迭代週期是比較合適的。週一上午，花個把小時討論並安排一週的工作。從未處理任務列表中移動任務到“本週待處理任務”列表。開發進行開發的時候，就將任務移動到“本週處理中任務”。開發完成後，將任務移動到“本週測試中任務”，進行任務相關的測試。測試完成後，將任務移動至“本週已完成任務”。測試失敗，可以將任務打回到“本週處理中任務”。

“歷史測試中任務”和“歷史已完成任務”。其實，“歷史測試中任務”本是不應該出現的分類。專案的需求驗收測試需要協調外部資源，無法做到每週一迭代。每週完成任務開發後，自己只能做功能測試。本週結束，未進行驗收測試的任務，就只能累積在“歷史測試中任務”列表中，等待外部資源的協調。“歷史已完成任務”就是已驗收完成的任務。

       trello.Card 表示一個任務卡片。每個任務卡片都可以有一個簡短的任務描述顯示在外，只要合理的設計，任務簡述就可以在卡片上顯示很多的任務資訊。經多次修改後，任務簡述模板如下：

任務ID：“XX：20150221_任務簡述”，所屬系統：？？？”。[Milestone:v1.0][AAA:BBB]

任務ID是這個任務的標識，會出現在關於這個任務的討論，關於這個任務的程式碼提交日誌等等，關於這個任務的一切東西中。其中，“XX”表示任務的型別，包括：需求、優化、學習和Bug。後續的中括號對中，可以新增任務相關的屬性和狀態。如，任務所屬里程碑“[Milestone:v1.0]”，任務完成日期“[完成日期：2015-221]”等等。

       周迭代的情況下，在週三下班的時候就要審視一下剩餘的工作任務。多“加”少補，T_T。經過多周的練習，大家應該都能比較正確的估計工作量。只要每週能按時完成周迭代，總體的專案進度也不會出現大的偏差。

       由於看板是對所有成員完全開放的，所以應用看板管理時需要全體成員主動參與進來。每個人要完成屬於自己的卡片的詳細內容填寫和卡片在不同列表中的移動。讓看板儘量實時的展現專案當前的狀態。至少要保證週五下班時的看板和當前專案的進展一致，使得下一週的周迭代能有正確的起點。

簡化的看板方案的不足

       以上的看板管理方法可能比較適合10人以下的專案組，任務管理比較粗放，也沒有可實踐的流程改進方案。《精益開發實戰》中描述的是40~60人左右的專案組管理方法，所以更大型的專案組看板管理可能需要如書中所述的更加系統的方法。你需要在看板管理的基礎上不斷迭代開發流程，找到開發流程的瓶頸，不斷提高開發效率。