我们是否认为项目迭代长度与项目团队规模有关？如果是这样，怎么办？我们还使用其他哪些关键因素来识别不同项目的正确迭代长度？

解决方案

迭代长度主要与团队交流和完成软件工作版本的能力有关。更多的团队成员等于更多的沟通渠道(布鲁克斯定律)，这可能会增加迭代时间。

我认为2周的迭代(无论我们是否交付给客户)都是一个不错的目标，因为它可以进行非常好的健康检查。

最终，迭代长度将取决于我们希望在下一次迭代中实现的功能，并且在早期阶段，随着我们对团队和技术体系的适应，迭代可能会从1周跳到1个月。

短迭代的主要驱动力之一是简化模块/功能/编程器之间的集成。显然，团队越大，我们将拥有更多的集成。这是一个权衡：短迭代意味着我们经常进行集成，但这是一个很好的选择，但如果拥有一支庞大的团队，即使没有新代码，我们也会花费很多团队进行集成开销。较长的迭代次数显然意味着每次集成次数越少越少，并且风险也更大。

如果团队很大，我们可以尝试分支集成，即经常集成小的子团队，而较少地在团队之间进行集成...但是那样我们会在分支之间存在不一致的地方，并且我们会因此失去很多好处。

要考虑的另一个关键因素是复杂性显然很复杂，后端系统的集成风险较高，简单的Web-UI页面的风险较小。

(我知道我没有给我们明确的答案，没有答案。这总是权衡取舍，希望我能给我们一些思考的机会。)

我的经验是，迭代的长度在一定程度上取决于团队的规模，

外部依存关系，例如在我们必须与内部系统集成的情况下，即不使用基于迭代的开发周期(读取瀑布)的情况下，我们会观察到另一个因素。

在进行迭代开发时，我们的团队是真正的菜鸟，因此在开始的迭代中，迭代确实很长(12周)。但是后来，我们发现没有必要担心，并且迭代大大缩短了(4-6周)。

因此，迭代进行多长时间的另一个因素是我们对迭代开发的概念有多熟悉。

I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.

2周的迭代对于我和通常执行的项目来说最舒适，但是我不同意未交付是一个很好的结果，因此重点应该放在"在过程中工作的软件"方面。

如果产品拥有者/用户不可用，我会考虑延长迭代时间，即使每隔几周只进行一次展示，因为与技术方面进行快速迭代所允许的相同运行状况检查需要在这生意。

迭代长度应由许多因素决定……团队规模实际上只是"迭代开销"考虑因素的一部分。

本文介绍了其中许多内容。

海事组织的重要事项：

• 总发行长度
• 优先级可以保持多长时间不变
• 迭代的开销

可以完成多少工作有关系，但这里还有其他几个关键因素，例如他们正在从事的项目类型，例如Windows应用程序，控制台应用程序或者Web应用程序，以及与当前团队的样式相比，代码库在大小，复杂性和样式方面如何开发，以及团队在方法论和所做工作方面都具备哪些专业知识因为缺乏经验可能会使每个人精通该过程，因此代价很高。