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

2022-07-22 04:45:10 字數 1465 閱讀 1753

這是敏捷開發日常跟進系列的第四篇。(欄目目錄)

跟進表是大型敏捷團隊的一種實踐。在乙個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.哪些故事完成了 在故事板中也能表達,但缺少結構性。故事板中的故事都是平等的,較難顯示...

敏捷開發使用者故事系列之九 開發與跟進

這是使用者故事系列的第九篇。之一,之二,之三,之四,之五,之六,之七,之八,之九 產品負責人常常被描述成在計畫會前準備好使用者故事,在計畫會上講解並幫助開發團隊估算後就萬事大吉,只等月底接收 可工作軟體 的樣子,其實如果真的這樣,很容易出問題。這是發生在迭代週期中間的常規活動,產品負責人會與團隊密切...