速度爲小項目

Question

我目前正在學習scrum，並希望向有經驗的專業人士學習該主題。

速度與需要3個月的項目相關（通常有2-3次中間交付給客戶）？
我認爲現在還沒有足夠的時間來統計相關。爲了獲得足夠的統計深度，是否值得在整個項目中記錄每個開發人員的速度？

另一個問題是速度對於小型項目真的很重要嗎？
我們在我們的領域有很多經驗，我們的估計是準確的退出。我們遇到的唯一問題與有時碰到你的風險因素有關，但我們知道我們的風險並知道如何處理它，我不確定這個Scrum會如何幫助解決客戶板上的硬件問題。

我確實看到了很多邏輯的像小迭代中，在產品/項目管理連續整合其他部分非常接近的開發過程，我認爲我們已經做的混戰了很多東西而不自知。

因此，底線，我不看的Scrum作爲一個整體概念，是適合我的需要，但我看到，我可以使用大量的概念（我真的很喜歡積壓），使我們的發展過程中更好。

其實它是討論而不是問題，但SO不是爲此設計的，所以如果它不合適，我很抱歉。

Answer 1

所以，你的問題分爲兩個部分：

1）爲速度值得在3個月的項目？是的，我認爲是。我曾在大部分項目都是2-6個月的團隊工作過。我們有一週的迭代，但我知道短至3天的團隊。然而，敏捷社區正在朝着更加Kanaban拉式系統的方向發展，在這種系統中不需要特定的迭代。我會說開始迭代，然後重新評估

2）所以我需要速度，當我們有良好的估計？可能不會，因爲你的項目較短。但是當20小時的事情發生，並且需要10天，因爲你每天只能工作2個小時，那麼你基本上需要用不同的東西來計算速度。

我高度推薦XP和Scrum Development郵件列表。

Answer 2

更小的迭代次數可以讓您獲得更好的速度測量值，因爲它們提供更多的數據點。跟蹤不必精心製作簡單的燒錄圖，可以快速查看速度。

Answer 3

如果您正在進行一項爲期三個月的項目並進行長達一個月的衝刺，則只能對兩次衝刺使用您的速度計算。但是，如果您使用兩週的衝刺，則會有五個衝刺，您可以在其中應用速度計算。短跑越短，你就會得到更多的數據點。

作爲一名開發人員，我喜歡追蹤一切。它給了我一些關於我的時間估計技能未經過校準的想法。我現在能夠將我的歷史速度應用於我的新估計，使這些估計更合理。

作爲一名團隊成員，我想知道我的隊友估計時間有多好。我曾與那些一直低估他們的時間五倍或更多的人一起工作，如果你想避免不愉快的驚喜，提前知道這一點很重要。

所以是的，我發現速度對任何規模的項目都很重要。

Answer 4

使用速度進行規劃基本上只取決於最小數量的迭代是有價值的。但對於其他反饋機制也是如此 - 將新的學習融入正在運行的項目中需要頻繁的檢查點，這些檢查點在迭代結束時提供。因此，對於較小的項目，無論如何，迭代次數應該更小（獨立於間歇發佈的次數）。我曾經參加了爲期兩週的培訓項目，在那裏我們使用了兩天的迭代。工作得很好。

會用速度給你提供價值嗎？那麼，從這裏很難說。一方面，如果您的估算過程已經運行良好，可能不會。另一方面，也許它會更好。或者它也可以工作，但花費較少的努力。另外請記住，Scrum（與其他進程一樣）是一個包含不同組件互相支持的軟件包 - 因此，雖然您當前的估算過程可以很好地爲您服務，但它可能在Scrum過程中效果不佳，或者影響Scrum的其他方面。而且，不知道Scrum項目究竟期待什麼，你甚至可能不會注意到這是估計過程就是問題所在。

因此，考慮到上述因素，嘗試一段時間的速度並查看它對您的工作方式可能是有意義的。你總是可以回去嘗試舊的方式。請記住，「檢查和適應」是Scrum的重要組成部分。在適應之前，不要忘記檢查。

讓一些有Scrum經驗的人成爲一個好主意。通常他們更容易識別反模式並提出有效的適應。