這是敏捷開發日常跟進系列的第三篇。 （欄目目錄）

故事板和看板其實不是一個東西，前者是最初的敏捷開發裡邊的東西，受到了後者的啟發產生的；而後者是製造業的東西，具體內容請參考末尾的百度百科。但是在敏捷開發裡邊提到這兩樣東西，可以認為大致相同。

故事板

簡單說，故事板是展示迭代中的使用者故事和任務的方法，在《硝煙中的Scrum和XP》的封面上就印著一個典型的故事板：

一般故事板分為三列：

To Do還沒做的, Doing正在做的, Done做完的（有各種各樣的中英文寫法，大同小異）

有些團隊的分工比較多，會出現一些中間狀態，比如“還沒做的/正在開發的/等待測試的/正在測試的/等待評審的”是一種典型的開發與測試分離的故事板。

故事板的用法

要解決的問題

故事板可以幫助解決一些燃盡圖解決不了的問題（見上篇）：

1. 有哪些故事正在做，還沒有做，已經開工了但沒完成……？故事板的三列正好解決問題。

2. 最後剩下了哪些故事沒完成？最左邊剩下的就是。

3. 有沒有人不是一個一個完成故事，而是同時開工了很多故事？（這個是最後很多故事都開工了但都差一點完成不了的主要原因）這個複雜一些，下面講。

同時開工很多故事，很容易造成思緒散亂、最後全部完不成的情況，確切說瀑布模型就是同時開工所有故事的典範。

為了防止這一點，如果是手工做的故事板，，那麼注意中間一個“正在做的”列一點要窄一些，這樣當裡邊的故事擠不下的時候，就是一個危險的很多故事都在開工的訊號。

還有一種做法，是每個人只准放一個故事在中間，做完一個，才能再做一個。這個嚴格堅持有難度，因為經常遇到被卡住的情況，但是作為一種思路和精神應該儘量堅持。

4. 如果有跟進人，誰負責跟進哪個？可以在卡片上寫上當前負責人、跟進人的名字。

通常的做法有很多種，比如每個人用自己顏色的即時貼，可以比較容易地看出每個人有多少個故事，分別處於什麼狀態。不過，這樣就需要在“尚未開始的”裡邊提前分配人員了，不太利於後期的互動和互相關注；當然還可以在開始的時候重新用有顏色的即時貼重新抄一個，看大家的習慣了。

介質

儘管有很多故事板/看板工具，使用紙質方法仍然是一個很好的選擇，原因就是作為“迭代中的任務”這種東西，其生存期很短，基本上2個月後價值為0，人們也就用紙片來對付了。

不過如果想在未來做幾件事情，那麼及早採用電子故事板/看板還是有必要的，這些事情包括：

1. 希望統計和分析哪些故事容易完不成、每個月的完成情況等

2. 大型團隊，分散式團隊

3. 希望留下歷史資料作為以後估算的參考值和參考故事

下面這個是免費工具火星人中的故事板，做了兩個案例來說明一下情況。

上面這個圖是不好的情況，開發中的故事一大堆，沒幾個完成的，很容易造成最後所有故事都差一點。

下面這個要好的多，每個人只開工了1個（每種底色是一個人，案例中只有cheny和yock兩個人），剩下的要末完全做完了，要麼一點沒做，即使到期末不能全部完成，也不會把太多時間卡在半截的故事上。

2012-03-07補充：

昨天下午仔細調整了美術效果，現在的故事板外觀如下：