團隊規模和項目迭代長度

Question

您認爲項目迭代長度與項目團隊規模有關嗎？如果是這樣，怎麼樣？您使用哪些其他關鍵因素來識別不同項目的正確迭代長度？

Answer 1

迭代長度主要與團隊溝通和完成軟件工作版本的能力有關。更多的團隊成員等於更多的溝通渠道（Brooks's Law），這可能會增加您的迭代時間。

我認爲2周的迭代，無論您是否提供給客戶，都是一個不錯的目標，因爲它可以進行非常好的健康檢查。

最終，迭代長度將取決於您希望在下一次迭代中實現的功能，並且在早期階段，當您對團隊和技術堆棧感到滿意時，迭代可能會從1周跳到1個月。

Answer 2

短迭代的主要驅動之一是簡化模塊/特性/程序員之間的集成。顯然，你的團隊越大，你將擁有的集成度越高。這是一個折衷：短的迭代意味着你經常進行整合，這是很好的 - 但是如果它是一個大團隊，那麼即使沒有新的代碼，你也會花費大量的團隊來集成開銷。更長的迭代次數顯然意味着更少的整合，每次更少，而且風險更大。

如果您的團隊非常龐大，您可以嘗試分支整合，即經常整合小團隊，並且團隊之間的整合次數較少......但是那樣會導致分支之間的不一致，並且您失去了大部分好處就在那裏。

另一個要考慮的關鍵因素是複雜性 - 顯然很複雜，後端系統風險較高，簡單的Web-UI頁面風險較小。

（我知道我沒有給你一個明確的答案，是沒有的。它總是權衡，我希望我能給你一些精神食糧。）

Answer 3

我的經驗是迭代的長度有些取決於團隊規模，

外部依賴關係，就像我們不得不與基於迭代的開發週期（讀取瀑布）的內部系統集成的情況一樣，我們觀察到另一個因素。

當談到迭代開發時，我們的團隊是真正的noobs，所以在開始時迭代真的很長（12周）。但後來我們看到沒有必要擔心，並且迭代大大縮短（4-6周）。

所以迭代多長時間的另一個因素是你對迭代開發的概念有多熟悉。

Answer 4

我認爲2周的迭代，無論您是否提供給客戶，都是一個很好的目標，因爲它可以進行非常好的健康檢查。

爲期兩週的迭代對我和我通常所做的項目來說是最舒服的，但我不同意不交付是一個好結果 - 焦點需要留在「工作中的軟件過程」一側的東西。

如果產品所有者/用戶不可用，即使僅在每隔幾周展示一次，我也會考慮延長迭代次數，因爲在技術方面快速迭代允許的相同健康檢查需要發生在側面與業務的接觸。

Answer 5

迭代長度應該由許多因素決定......團隊規模實際上只是「迭代開銷」的考慮因素的一部分。

This article解釋了其中許多。

IMO重要的：

1. 總體釋放長度
2. 多久優先級可以保持不變
3. 迭代

Answer 6

的開銷中有多少工作方面的關係可以完成，但還有一些其他關鍵因素，如他們正在處理的項目類型，例如Windows應用程序，控制檯應用程序或Web應用程序，以及與當前團隊的風格相比，代碼庫在規模，複雜性和風格方面的發展程度，以及團隊在方法學和他們正在進行的工作中都具備哪些專業知識因爲沒有經驗可能會讓每個人都熟練掌握這個流程。