這是敏捷開發日常跟進系列的第四篇。（欄目目錄）
跟進表是大型敏捷團隊的一種實踐。在乙個80多人的網路遊戲團隊中，他們為了清晰地顯示整個團隊的運作方式，使用了這種方法。
以上面的網路遊戲團隊為例，說明一下跟進表上的資訊：
1. 哪些故事完成了
在故事板中也能表達，但缺少結構性。故事板中的故事都是平等的，較難顯示大小、父子包含關係等。
2. 誰在跟進
案例中這個人一般是策劃人員，故事的建立者和驗收者。
3. 誰在開發
案例中這個一般是若干個開發人員、指令碼、美術的群體，也可能只有其中乙個工種。
4. 某個任務大概可能在何時開始、結束。
在故事板、燃盡圖上均無法表達。
5. 哪些故事被擱置了
可能遇到了困難，也可能有其他原因，甚至可能做了一半幹別的被忙忘了。
這是乙個在「火星人」研發中已經完成的迭代的跟進表案例。
例項一
對於跟進圖的5個作用，上面這個已經擴充套件了的燃盡圖只能完成第乙個，就是「哪些故事完成了」，而一般的燃盡圖連這個作用也沒有。
為了完成另外四個目標，就需要下面的跟進表。
先看左邊的藍框，裡邊是所有迭代中的故事（sprint backlog），為什麼要顯示成這個樹狀結構呢？因為如果是小團隊，只有10～20個故事，那麼人們即使從只有3個字的故事名稱比如「新介面」上，大家也能記住和理解說的是什麼意思。但是如果故事多了，就比較困難，會導致故事的名字不得不很長，比如「計畫會-講解故事-的新介面」，而這樣表達看似還行，但由於沒有清晰的父子包含關係，多了也亂。所以藍框中以父子關係的方式表達，對於大型產品的研發更清晰一些。
藍框右邊兩列是負責人（對應跟進人，案例中的策劃人員）和當前負責人（開發人員），由於我們的團隊小，不存在兩個部門，所以沒有設定跟進人，所以也就沒有「負責人」。
三個黃框（一橫兩豎）所框住的**的底色有的是綠色，有的是粉紅色，綠色是加班，粉紅色則是假期或休假。左邊豎框標明15日大家集體加班，原因是右邊豎框中大家19日集體放假外出春遊；橫向的黃框則標明yock在這個月有大量休假，他只能在特定日期完成工作。為什麼要管理這些呢？有時候看似燃盡圖正好指向0點，但那個地方可能正好是春節、五
一、元旦什麼的，有了對假期的整體把握，對重要的上線活動就降低了風險。
紅框中的故事看上去就有點異常，因為儘管整個迭代結束了，它的剩餘時間居然還是「1人天」，所以這個故事沒有完成，它停在了17日。
例項二
下面的圖，是調整了一些資料，並將系統時間調整到2.26，模擬乙個正在進行中的迭代。
從最右邊可以看到有4個故事沒有完成，其中兩個是尚未開始（最上面和最下面兩個淺色的），另外兩個則是遇到了障礙，卡在了17日和24日，之後沒有進展。
作為專案經理和技術經理，在跟進表中看到遇到障礙的故事，就要及時詢問和協調；作為程式設計師，也應該在每日立會上報告被卡住的故事。
沉默的程式設計師，又聾又瞎的專案經理（越大型團隊的專案經理就越嚴重），是造成大型專案糾纏不清最終失敗的重要原因。
敏捷開發日常跟進系列之四 跟進表
這是敏捷開發日常跟進系列的第四篇。欄目目錄 跟進表是大型敏捷團隊的一種實踐。在乙個80多人的網路遊戲團隊中，他們為了清晰地顯示整個團隊的運作方式，使用了這種方法。以上面的網路遊戲團隊為例，說明一下跟進表上的資訊 1.哪些故事完成了 在故事板中也能表達，但缺少結構性。故事板中的故事都是平等的，較難顯示...
敏捷開發日常跟進系列之四 跟進表
這是敏捷開發日常跟進系列的第四篇。欄目目錄 跟進表是大型敏捷團隊的一種實踐。在乙個80多人的網路遊戲團隊中，他們為了清晰地顯示整個團隊的運作方式，使用了這種方法。以上面的網路遊戲團隊為例，說明一下跟進表上的資訊 1.哪些故事完成了 在故事板中也能表達，但缺少結構性。故事板中的故事都是平等的，較難顯示...
敏捷開發使用者故事系列之九 開發與跟進
這是使用者故事系列的第九篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 產品負責人常常被描述成在計畫會前準備好使用者故事，在計畫會上講解並幫助開發團隊估算後就萬事大吉，只等月底接收 可工作軟體 的樣子，其實如果真的這樣，很容易出問題。這是發生在迭代週期中間的常規活動，產品負責人會與團隊密切...