团队规模和项目迭代长度
您认为项目迭代长度与项目团队规模有关吗？ 如果是这样，怎么办？ 您还使用哪些其他关键因素来识别不同项目的正确迭代长度？
Do you think that project iteration length is related to project team size? If so, how? What other key factors do you use to recognize correct iteration length for different projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
迭代长度主要与团队沟通和完成软件工作版本的能力有关。 更多的团队成员意味着更多的沟通渠道（布鲁克斯定律），这可能会增加您的迭代时间。
我认为，无论是否交付给客户，两周迭代都是一个很好的目标，因为它可以进行非常好的健康检查。
最终，迭代长度将取决于您希望在下一次迭代中实现的功能，在早期阶段，当您熟悉团队和技术堆栈时，您的迭代可能会从 1 周跳到 1 个月。
Iteration length is primarily related to the teams ability to communicate and complete a working version of the software. More team members equals more communication channels (Brooks's Law) which will likely increase your iteration time.
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.
Ultimately, the iteration length will depend on the features you wish to implement in the next iteration, and in the early phases your iterations may jump around from 1 week to 1 month as you become comfortable with the team and the technology stack.
两周的迭代对我和我通常做的项目来说是最舒服的，但我不同意不交付是一个好的结果——重点需要留在事情的“工作软件而不是流程”方面。
如果产品所有者/用户不可用，我会考虑延长迭代时间，即使只是每隔几周进行一次展示，因为快速迭代在技术方面允许的健康检查需要在与客户的互动方面进行。这生意。
2-week iterations are most comfortable for me and the kinds of projects I usually do, but I disagree that not delivering is a good outcome - the focus needs to stay on the "working software over process" side of things.
I would consider making iterations longer if the product owner / user isn't available, even if only for a showcase every couple weeks, as the same health checks that fast iterations allow on the technical side need to happen on the side of the engagement with the business.
我的经验是，迭代的长度在某种程度上取决于团队规模、
外部依赖性，例如我们必须与不使用基于迭代的开发周期（阅读瀑布）的内部系统集成的情况，这是我们观察到的另一个因素。
我们的团队在迭代开发方面确实是菜鸟，所以一开始迭代的时间非常长（12 周）。 但后来我们发现无需担心，迭代次数大大缩短（4-6 周）。
因此，影响迭代时间的另一个因素是您对迭代开发概念的熟悉程度。
My experience is that the length of the iterations are somewhat dependent on team size,
External dependencies, like in cases where we had to integrate with in house systems that was not using a iteration based development cycle (read waterfall) where another factor we observed.
Our team were real noobs when it came to iterative development, so in the beginning the iterations where really long (12 weeks). But later on we saw that there was no need to worry, and the iterations shrunk considerably (4-6 weeks).
So another factor in how long the iterations are is how familiar you are with the concept of iterative development.
短迭代的主要驱动力之一是简化模块/功能/程序员之间的集成。 显然，你的团队越大，你的整合度就越高。 这是一个权衡：短迭代意味着您经常集成，这很好 - 但如果它是一个大团队，即使没有新代码，您也会在集成开销上花费大量团队费用。 更长的迭代显然意味着每次的集成次数更少，但风险也更大。
如果您的团队非常大，您可以尝试分支集成，即经常集成小型子团队，并减少团队之间的集成......但是这样您就会在分支之间出现不一致，并且您会在那里失去很多好处。
另一个需要考虑的关键因素是复杂性 - 显然复杂，后端系统的集成风险较高，简单的 Web-UI 页面风险较小。
（我意识到我没有给你一个明确的答案，没有。这总是需要权衡的，我希望我能给你一些思考的空间。）
One of the main drivers for short iterations, is easing integration between modules/features/programmers. Obviously, the bigger your team, the more integration you will have. It's a tradeoff: short iterations mean you're integrating often, which is good - BUT if its a big team you'll be spending a LOT of team on integration overhead, even without new code. Longer iterations obviously mean more integration each time less seldom, and a lot more risky.
If your team is very large, you can try branched integration, i.e. integrating small subteams often, and integrating between the teams less often... BUT then you'll be having inconsistencies between branches, and you lose much of that benefit right there.
Another key factor to consider is complexity - obviously complex, backend systems are riskier integration, simple Web-UI pages are less risky.
(I realize I didnt give you a clear cut answer, there is none. It's always tradeoffs, I hope I give you some food for thought.)
迭代长度应该根据许多因素来决定......而团队规模实际上只是“迭代开销”考虑因素的一部分。
本文解释了其中的许多内容。
IMO 的重要内容：
Iteration length should be decided on many factors... and team size is really only part of the considerations made for the "Overhead of Iterating".
This article explains many of them.
The important ones IMO:
与可以完成多少工作有关，但这里还有一些其他关键因素，例如他们正在从事什么类型的项目，例如 Windows 应用程序、控制台应用程序或 Web 应用程序以及代码库的开发程度与当前团队的风格相比，在规模、复杂性和麦粒肿方面，以及团队在方法论和他们正在做的工作方面拥有哪些专业知识，因为缺乏经验可能会让每个人都精通该流程，代价高昂。
There is relation in terms of how much work can get done but there are a couple of other key factors here like what type of project are they working on, e.g. Windows Application, Console Application, or Web Application as well as how developed is the codebase in terms of size, complexity and stye compared to the current team's style, and what expertise does the team have both within the methodology and the work that they are doing as inexperience may be costly in terms of getting everyone proficient with the process.