前幾天在《為團隊與組織導入敏捷的經驗分享》 系列文講到了有關產品生命週期的題目，包含〈產品從無到有〉、〈從驗證完成到開始的準備〉，而開發到發布因為與本主題更具相關性，所以就改到這裡發佈了。

在開始之前，先聊聊一種對於軟體專案管理的方式——看板（KanBan），想先破除關於看板的迷思。當我們想到看板，大概很容易就是想到 Trello、或是 GitLab 的 Issue Board，而對於使用這類工具的最大印象，大概就是將要做的事情，分成了 To Do、Doing、Done 吧！而我們也因此認為看板不外乎這三個狀態，頂多大不了多了一個 Done Done、Checked、Validated 之類的，去表示驗收完成。

很多時候我們想在軟體專案管理上，導入這樣的看板。有時候會很有效，而有時候卻覺得好像有點綁手綁腳，或是覺得這樣的管理只能侷限在簡單的把功能完成，但對後續追蹤卻略顯不夠。

事實上， To Do、Doing、Done 這其實只是看板的最最最基本的形式，而看板對於各狀態的訂定，是極具彈性，沒有制式規定的。或許在一開始嘗試透過這樣的方式去管理是個不錯的入門方式，但是當大家習慣後，我們或許就可以來做點變化，讓團隊針對軟體會有哪些狀態進行定義。

讓我們將狀態向前、向後延伸，比如說將 To Do 拆成整個軟體的待辦清單，以及最多只能放置 7 個項目的 To Do 清單，這 7 個是最優先要去認領實作的，而待辦清單可能又可以分為分析過、尚未分析過的兩種狀態，要先分析過成本、和需求，才可以進到 To Do 清單。又比如說，我們可以將 Doing 和 Done 分為實作中、等待 Code Reveiw、等待驗收、等待部署、部署到了 Staging、部署到了 Production 等等。這些都只舉例，但這樣講之後，或許就激發了我們的認知，並且突破對看板原有的既定印象。

透過這樣訂定，我們就可以知道目前這個軟體的更詳盡的狀態，以及暸解哪部分佇列了特別多項目，是不是遇到了瓶頸、阻礙，從而去改善。

也因為每個團隊的人員組成不一樣、軟體研發方式不一樣、佈署策略不一樣，所以很難有一個標準答案，每個人對於狀態的認知可能也不太相同，所以在訂定這樣屬於團隊的開發流程時，更要整個團隊、所有成員一同進行討論、訂定。這樣不但能交流彼此對於個狀態的想法、更能凝聚對於各階段的共識，減少了溝通成本，也讓未來在軟體開發的管理上，更加透明與容易。