敏捷開發平常跟進系列之四：跟進表

 跟進表是大型敏捷團隊的一種實踐。在一個80多人的網絡遊戲團隊中，他們爲了清晰地顯示整個團隊的運做方式，使用了這種方法。

跟進表

以上面的網絡遊戲團隊爲例，說明一下跟進表上的信息：

1. 哪些故事完成了

在故事板中也能表達，但缺乏結構性。故事板中的故事都是平等的，較難顯示大小、父子包含關係等。

2. 誰在跟進

案例中這我的通常是策劃人員，故事的建立者和驗收者。

3. 誰在開發

案例中這個通常是若干個開發人員、腳本、美術的羣體，也可能只有其中一個工種。

4. 某個任務大概可能在什麼時候開始、結束。

在故事板、燃盡圖上均沒法表達。

5. 哪些故事被擱置了

可能遇到了困難，也可能有其餘緣由，甚至可能作了一半乾別的被忙忘了。

……

實例

這是一個在「火星人」研發中已經完成的迭代的跟進表案例。

實例一

咱們先看看這個迭代的燃盡圖（看不清楚請右鍵-圖片另存爲後觀看）：

對於跟進圖的5個做用，上面這個已經擴展了的燃盡圖只能完成第一個，就是「哪些故事完成了」，而通常的燃盡圖連這個做用也沒有。

爲了完成另外四個目標，就須要下面的跟進表。

先看左邊的藍框，裏邊是全部迭代中的故事（Sprint Backlog），爲何要顯示成這個樹狀結構呢？由於若是是小團隊，只有10～20個故事，那麼人們即便從只有3個字的故事名稱好比「新界面」上，你們也能記住和理解說的是什麼意思。可是若是故事多了，就比較困難，會致使故事的名字不得不很長，好比「計劃會-講解故事-的新界面」，而這樣表達看似還行，但因爲沒有清晰的父子包含關係，多了也亂。因此藍框中以父子關係的方式表達，對於大型產品的研發更清晰一些。

藍框右邊兩列是負責人（對應跟進人，案例中的策劃人員）和當前負責人（開發人員），因爲咱們的團隊小，不存在兩個部門，因此沒有設置跟進人，因此也就沒有「負責人」。

三個黃框（一橫兩豎）所框住的表格的底色有的是綠色，有的是粉紅色，綠色是加班，粉紅色則是假期或休假。左邊豎框標明15日你們集體加班，緣由是右邊豎框中你們19日集體放假外出春遊；橫向的黃框則標明yock在這個月有大量休假，他只能在特定日期完成工做。爲何要管理這些呢？有時候看似燃盡圖正好指向0點，但那個地方可能正好是春節、五1、元旦什麼的，有了對假期的總體把握，對重要的上線活動就下降了風險。

紅框中的故事看上去就有點異常，由於儘管整個迭代結束了，它的剩餘時間竟然仍是「1人天」，因此這個故事沒有完成，它停在了17日。

實例二

下面的圖，是調整了一些數據，並將系統時間調整到2.26，模擬一個正在進行中的迭代。

從最右邊能夠看到有4個故事沒有完成，其中兩個是還沒有開始（最上面和最下面兩個淺色的），另外兩個則是遇到了障礙，卡在了17日和24日，以後沒有進展。

做爲項目經理和技術經理，在跟進表中看到遇到障礙的故事，就要及時詢問和協調；做爲程序員，也應該在每日立會上報告被卡住的故事。

沉默的程序員，又聾又瞎的項目經理（越大型團隊的項目經理就越嚴重），是形成大型項目糾纏不清最終失敗的重要緣由。