最小团队规模和Scrum 的项目持续时间（以工时为单位）？
您认为使用 Scrum 的最小/合适的团队规模和项目持续时间是多少？
我们正在考虑将 Scrum 用于我们的下一个软件项目（大约 1600 - 1800 工时），团队规模为 7 名成员。由于团队规模相当大（与项目持续时间相关，但无法避免），您会更喜欢 Scrum 吗？
What would you say is the minimum / appropriate team size and project duration for using Scrum?
We're thinking about using Scrum for our next software project (about 1600 - 1800 Man-hours) with a team size of 7 members. Since the team size is pretty big (in relation to the project duration, but cant avoid that), would you prefer Scrum?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一个团队 7 名成员对于 SCRUM 来说是完美的。您考虑其他流程而不是 SCRUM 的唯一原因是：
最后，在 SCRUM 中，您首先进行一些尝试，以找到完美的平衡。 （这来自于 SCRUM 是经验过程）
7 members in a team is perfect from SCRUM. The only reasons why you would consider some other process instead of SCRUM:
Finally, in SCRUM you first experiment little bit in order to find the perfect balance. (That comes from SCRUM being empirical process)
根据我的经验，5 名成员和 1 周的冲刺绝对是最低要求。
Scrum Master、产品负责人、2 名开发人员和 1 名测试人员。如果您的人员较少 - 您就不需要 SCRUM。
7个人不是很多，我们还有更多。
For my experience, 5 members and 1 week sprint is an absolute minimum.
Scrum Master, Product Owner, 2 Developers and 1 Tester. If you have less people - you just don't need SCRUM.
7 members is not very big, we had even more.
根据温斯顿·罗伊斯（Winston Royce，1970 年原始瀑布论文的出版商）的说法，瀑布方法应该仅用于 - 我引用 - 最简单和直接的项目（这个这是一个真实而悲伤的轶事：瀑布是一个不如何做事的例子）。
因此，我想说，对于简短、简单和直接的项目，即团队可以在一次冲刺（通常 1-4 周）内完成的项目，您可能使用另一种方法，因为您不会获得任何收益。反馈周期中没有任何优势，并且通常没有机会检查和调整您的流程。
至于团队规模，我认为能管理的规模就是好的。项目范围将决定需要多少人才能在一个冲刺中完成它。
According to Winston Royce (publisher of the original Waterfall paper in 1970), the waterfall methodology should be used only for - and I quote - the most simple and straightforward projects (this is a true and sad anecdote: Waterfall was meant as an example of how not to do things).
I would therefore say that for short, simple and straightforward projects, the kind that the team can complete in one sprint (usually 1-4 weeks), you may use another methodology, as you will not be gaining any advantage from the feedback cycles, and will generally have no opportunity to inspect and adapt you process.
As for the size of the team, I think that any size that can be managed is good. The project scope will dictate how many people are required in order to complete it in one sprint.