如果这些是完全独立的产品，那么使用 Scrum 我会进行非常短的冲刺（1-2 周）和序列开发工作。因此，两周的项目 A，然后是项目 B，然后是 C，然后又是 A - 也许是两个冲刺，然后是 C，等等。在这种情况下，单个待办事项是没有意义的，应该为 A、B 和 C 保留单独的待办事项。至少认识一个这样工作的团队。
您是否需要更多 PO 很大程度上取决于对产品的了解。也许你的每个项目都需要一个人，也许你有一个对 A、B 和 C 足够了解的人来担任 PO。
如果产品不同，那么当您尝试通过从每个冲刺的不同待办事项中获取不同的故事来做到这一点时，您最终会得到分裂的团队。当然，人们会专注于给定的项目，而且很难对完成有一个好的定义（如果我们可以在这个冲刺中为 A 和 B 提供新的增量，但不能为 C 提供新的增量，我们就完成了吗？）。如果您无法通过短冲刺对项目进行排序，那么我会寻求看板来尝试对此进行一些组织。
One missing bit is whether this is technically one product (like one codebase, even if large) or not.
If those are completely separate products then using Scrum I'd go in very short sprints (1-2 wks) and sequence development work. So two weeks project A, then project B, then C, then again A - maybe for two sprints, then C etc. In such a situation a single backlog makes no sense, separate backlogs should be kept for A, B and C. I know at least one team that works like this.
Whether you need more POs is rather a function of knowledge about products. Maybe you need someone for each project, maybe you have someone who knows well enough A, B and C to be the PO.
If different products then when you try to do it by taking different stories from different backlogs every sprint what you will end up with is split team. Naturally people will specialize in given project, also it will be very hard to have a good definition of done (are we done if we can ship new increments for A and B but not C this sprint?). If you can't sequence projects with short sprints, then I would look towards Kanban for trying to put some organization into this.
If this is one product/one codebase - then things are much easier. Even if the team will have to touch different areas of the codebase because of different projects they will be still working on the same products so all mechanics of Scrum will apply nicely. One backlog, one PO.
One downside of this to be noted is that people on the team will context-switch and there is a penalty from doing this no matter what process you use. Whatever process you pick should try to minimize this as long as possible (as long as business will be able to hold). Nice thing about Scrum is that it has this built in agreement with the PO that context switches can occur only at sprints border - in other words team will get 1-2 wks to concentrate before having to switch to another project.
Also, don't forget about all technical practices of agile. Unit tests. Automatic builds & tests. Code reviews. Clever use of repos. High standards re. quality. All those are a must in such a challenging environment.
Do one release of one project, when done, do the next
Split up your development team
Or a combination of both :)
Agile/Scrum are nice buzzwords, but don't seem very related to your question. Since they apply to the scope of a project, not to a bunch of projects.
I have experience with the second option, up to a level where there are more projects then developers, which isn't what you want. But with decent code review sessions it does seem to work.
A little more detail might help. Is it one big production team, that is sharing lots of projects between them? Is it a small team (5 ish) with lots of projects?
Why do you have lots of projects? Are they working on different time frames, with some being the 'real work' and others being the 'if your not busy do this as a background task'.
I suppose the key here might be the project to developer ratio.
We have a single department of about 15, which runs 3-4 projects at any one time. People generally belong to a project at any one time, but can move between them as projects go through different phases, and as different skills are needed. Test in particular seem to switch projects a lot.
As for a strict process...make the process fit your needs. If we have a better idea of your needs we might be able to make better suggestions.
One critical piece is that the multiple product owners need to be aware of each other and be able to work together outside of the scope of the development. If they're segregated out into their own fiefdoms and each one trying to be louder than the others to get the attention "their product" deserves, then you're going to have problems.
By the time any development work is put before the team, these things should already be straightened out. The developers shouldn't care (or, in some cases, even bother to know) what tasks are for what owners or what projects, etc. They can care and know these things, sure, but it shouldn't be critical.
The product owners and various other high-level roles need to start each sprint with a plan of which stories should be done during that sprint. It doesn't matter how many stories from any given project are included, sorting that out is a scheduling concern for those stakeholders. Working with the architect or senior developer or such, they should simply decide what stories get implemented in the current/next sprint.
IMHO, Scrum is more effective when you have at least 3 to 4 iterations of two weeks with a team of 4 to 6 developers. So for projects of +- 400 man/day
I think it's a bad idea to do multiple projects at a time.
Please also check this previously answered question:
I suggest to manage one product development with one team and one product backlog. Don't create separate projects for feature requests of one project. Instead have one team working on different requests from different customers by prioritizing the user stories.
Though, if those are completely separate products you develop, try to split up the team so each teams can concentrate on one product at a time.
发布评论
评论（6）
一个缺失的一点是，这在技术上是否是一种产品（就像一个代码库，即使很大）。
如果这些是完全独立的产品，那么使用 Scrum 我会进行非常短的冲刺（1-2 周）和序列开发工作。因此，两周的项目 A，然后是项目 B，然后是 C，然后又是 A - 也许是两个冲刺，然后是 C，等等。在这种情况下，单个待办事项是没有意义的，应该为 A、B 和 C 保留单独的待办事项。至少认识一个这样工作的团队。
您是否需要更多 PO 很大程度上取决于对产品的了解。也许你的每个项目都需要一个人，也许你有一个对 A、B 和 C 足够了解的人来担任 PO。
如果产品不同，那么当您尝试通过从每个冲刺的不同待办事项中获取不同的故事来做到这一点时，您最终会得到分裂的团队。当然，人们会专注于给定的项目，而且很难对完成有一个好的定义（如果我们可以在这个冲刺中为 A 和 B 提供新的增量，但不能为 C 提供新的增量，我们就完成了吗？）。如果您无法通过短冲刺对项目进行排序，那么我会寻求看板来尝试对此进行一些组织。
如果这是一个产品/一个代码库 - 那么事情就容易多了。即使团队由于不同的项目而必须接触代码库的不同区域，他们仍然会开发相同的产品，因此 Scrum 的所有机制都将很好地应用。一份积压订单，一份采购订单。
需要注意的一个缺点是团队中的人员会进行上下文切换，无论您使用什么流程，这样做都会受到惩罚。无论您选择什么流程，都应该尽可能长时间地尽量减少这种情况（只要业务能够维持下去）。 Scrum 的优点在于它与 PO 一致，即上下文切换只能在 sprint 边界发生——换句话说，团队在切换到另一个项目之前将有 1-2 周的时间来集中精力。
另外，不要忘记敏捷的所有技术实践。单元测试。自动构建和测试。代码审查。巧妙使用回购协议。高标准重新。质量。在如此充满挑战的环境中，所有这些都是必须的。
One missing bit is whether this is technically one product (like one codebase, even if large) or not.
If those are completely separate products then using Scrum I'd go in very short sprints (1-2 wks) and sequence development work. So two weeks project A, then project B, then C, then again A - maybe for two sprints, then C etc. In such a situation a single backlog makes no sense, separate backlogs should be kept for A, B and C. I know at least one team that works like this.
Whether you need more POs is rather a function of knowledge about products. Maybe you need someone for each project, maybe you have someone who knows well enough A, B and C to be the PO.
If different products then when you try to do it by taking different stories from different backlogs every sprint what you will end up with is split team. Naturally people will specialize in given project, also it will be very hard to have a good definition of done (are we done if we can ship new increments for A and B but not C this sprint?). If you can't sequence projects with short sprints, then I would look towards Kanban for trying to put some organization into this.
If this is one product/one codebase - then things are much easier. Even if the team will have to touch different areas of the codebase because of different projects they will be still working on the same products so all mechanics of Scrum will apply nicely. One backlog, one PO.
One downside of this to be noted is that people on the team will context-switch and there is a penalty from doing this no matter what process you use. Whatever process you pick should try to minimize this as long as possible (as long as business will be able to hold). Nice thing about Scrum is that it has this built in agreement with the PO that context switches can occur only at sprints border - in other words team will get 1-2 wks to concentrate before having to switch to another project.
Also, don't forget about all technical practices of agile. Unit tests. Automatic builds & tests. Code reviews. Clever use of repos. High standards re. quality. All those are a must in such a challenging environment.
我想你可以做两件事：
或者两者结合:)
敏捷/Scrum 是很好的流行词，但似乎与你的问题不太相关。
因为它们适用于一个项目的范围，而不是一堆项目。
我对第二种选择有经验，达到了项目数量多于开发人员的水平，这不是您想要的。但通过适当的代码审查会议，它似乎确实有效。
I guess you can do two things:
Or a combination of both :)
Agile/Scrum are nice buzzwords, but don't seem very related to your question.
Since they apply to the scope of a project, not to a bunch of projects.
I have experience with the second option, up to a level where there are more projects then developers, which isn't what you want. But with decent code review sessions it does seem to work.
更详细一点可能会有所帮助。
这是一个大型制作团队，他们之间共享很多项目吗？这是一个有很多项目的小团队（5 人左右）吗？
为什么你有很多项目？他们是否在不同的时间范围内工作，其中一些是“真正的工作”，另一些是“如果您不忙，请将其作为后台任务”。
我想这里的关键可能是项目与开发人员的比例。
我们有一个大约 15 人的部门，同时运行 3-4 个项目。人们通常在任何时候都属于一个项目，但随着项目经历不同的阶段并且需要不同的技能，他们可以在不同的项目之间移动。特别是测试似乎经常切换项目。
至于严格的流程...让流程适合您的需求。如果我们更好地了解您的需求，我们也许能够提出更好的建议。
A little more detail might help.
Is it one big production team, that is sharing lots of projects between them? Is it a small team (5 ish) with lots of projects?
Why do you have lots of projects? Are they working on different time frames, with some being the 'real work' and others being the 'if your not busy do this as a background task'.
I suppose the key here might be the project to developer ratio.
We have a single department of about 15, which runs 3-4 projects at any one time. People generally belong to a project at any one time, but can move between them as projects go through different phases, and as different skills are needed. Test in particular seem to switch projects a lot.
As for a strict process...make the process fit your needs. If we have a better idea of your needs we might be able to make better suggestions.
一个关键因素是多个产品负责人需要相互了解，并且能够在开发范围之外进行合作。如果他们被隔离在自己的领地中，并且每个人都试图比其他人更响亮地获得“他们的产品”应有的关注，那么你就会遇到问题。
当任何开发工作提交给团队时，这些事情应该已经理顺了。开发人员不应该关心（或者，在某些情况下，甚至费心去知道）哪些任务是针对哪些所有者或哪些项目等。他们可以关心并了解这些事情，当然，但不应该不要挑剔。
产品负责人和其他各种高级角色需要在每个冲刺开始时制定一个计划，说明在该冲刺期间应该完成哪些故事。任何给定项目中包含多少个故事并不重要，对这些利益相关者来说，将其整理出来是一个日程安排问题。与架构师或高级开发人员等合作，他们应该简单地决定在当前/下一个冲刺中实施哪些故事。
（顺便说一句，我有一个针对此类事情的 51 区提案：http://area51.stackexchange .com/proposals/9543/development-methodologies）
One critical piece is that the multiple product owners need to be aware of each other and be able to work together outside of the scope of the development. If they're segregated out into their own fiefdoms and each one trying to be louder than the others to get the attention "their product" deserves, then you're going to have problems.
By the time any development work is put before the team, these things should already be straightened out. The developers shouldn't care (or, in some cases, even bother to know) what tasks are for what owners or what projects, etc. They can care and know these things, sure, but it shouldn't be critical.
The product owners and various other high-level roles need to start each sprint with a plan of which stories should be done during that sprint. It doesn't matter how many stories from any given project are included, sorting that out is a scheduling concern for those stakeholders. Working with the architect or senior developer or such, they should simply decide what stories get implemented in the current/next sprint.
(On a side note, I have an Area 51 proposal for just this sort of thing: http://area51.stackexchange.com/proposals/9543/development-methodologies)
恕我直言，当您的团队由 4 到 6 名开发人员组成的团队在两周内进行至少 3 到 4 次迭代时，Scrum 会更有效。因此，对于每天 +- 400 人的项目，
我认为一次执行多个项目是一个坏主意。
另请检查之前回答的问题：
当您有多个项目吗？
IMHO, Scrum is more effective when you have at least 3 to 4 iterations of two weeks with a team of 4 to 6 developers. So for projects of +- 400 man/day
I think it's a bad idea to do multiple projects at a time.
Please also check this previously answered question:
How does Scrum work when you have multiple projects?
看来您混合了产品和项目概念。
我建议用一个团队和一份产品待办事项来管理一项产品开发。不要为一个项目的功能请求创建单独的项目。相反，让一个团队通过优先考虑用户故事来处理不同客户的不同请求。
不过，如果您开发的是完全独立的产品，请尝试将团队分开，以便每个团队可以一次专注于一种产品。
It's seems you mix product and project concepts.
I suggest to manage one product development with one team and one product backlog. Don't create separate projects for feature requests of one project. Instead have one team working on different requests from different customers by prioritizing the user stories.
Though, if those are completely separate products you develop, try to split up the team so each teams can concentrate on one product at a time.