当您只有一个开发团队时,处理多个项目的最佳方法是什么[[关闭]

我想你可以做两件事:

2. 分散你的开发团队

敏捷/Scrum是很好的流行语,但似乎与您的问题不太相关。

我有第二种选择的经验,达到一个项目比开发人员多的水平,这不是你想要的。但是,有了体面的代码审查会议,它似乎确实奏效了。

缺少的一点是,从技术上讲,这是否是一个产品(比如一个代码库,即使很大)。

如果是的话 然后使用Scrum,我会进行非常短的sprint(1-2周)和序列开发工作。所以两个星期的项目A,然后是项目B,然后是C,然后是A-可能是两个sprint,然后是C等等。在这种情况下,一个单独的积压是没有意义的,应该为A,B和C保留单独的积压。我知道至少有一个团队是这样工作的。

你是否需要更多的POs是产品知识的函数。也许你每个项目都需要一个人,也许你有一个非常了解A、B和C的人来做采购员。

如果是不同的产品,那么当你试着从不同的积压中获取不同的故事时,每一次冲刺你最终会得到的是分裂的团队。很自然,人们会专注于给定的项目,而且很难对done有一个好的定义(如果我们能在这个sprint中为a和B提供新的增量而不是C,我们就完成了吗?)。如果你不能用短时间的冲刺来安排项目的顺序,那么我会寻找看板来尝试将一些组织放到这个项目中。

如果这是 一个产品/一个代码库 -那事情就容易多了。即使团队因为不同的项目而不得不接触代码库的不同区域,他们仍将在相同的产品上工作,因此Scrum的所有机制都将很好地应用。一个积压,一个订单。

需要注意的一个缺点是,团队中的人会切换上下文,无论您使用什么流程,这样做都会受到惩罚。无论您选择什么流程,都应该尽可能长时间地将此最小化(只要业务能够保持)。Scrum的好处在于它和PO有一个内在的一致性,即上下文切换只能在sprints边界处发生——换句话说,团队在必须切换到另一个项目之前需要花1-2周的时间来集中精力。

再详细一点也许会有帮助。 是一个大的生产团队,在他们之间共享很多项目吗?是一个有很多项目的小团队吗?

为什么你有很多项目?他们是在不同的时间框架内工作的,有些是“真正的工作”,有些是“如果你不忙的话,把它作为一个背景任务”。

我想这里的关键可能是项目与开发商的比例。

至于严格的流程…让流程符合你的需要。如果我们对你的需要有更好的了解,我们也许能提出更好的建议。

关键的一点是,多个产品所有者需要相互了解,并且能够在开发范围之外协同工作。如果他们被隔离到自己的领地,每个人都试图比其他人更大声,以获得“他们的产品”应有的关注,那么你就会遇到问题。

可以

产品负责人和其他高级角色需要在每个sprint开始时制定一个计划,计划在sprint期间应该完成哪些故事。不管从任何给定的项目中包含多少故事,对这些涉众来说,整理这些故事是一个日程安排问题。与架构师或高级开发人员合作,他们应该简单地决定在当前/下一个sprint中实现哪些故事。

http://area51.stackexchange.com/proposals/9543/development-methodologies )

IMHO,当你和一个4到6个开发人员组成的团队进行至少3到4次两周的迭代时,Scrum会更有效。所以对于+400人/天的项目

我认为一次做多个项目是个坏主意。

请检查之前回答的问题:

How does Scrum work when you have multiple projects?

你似乎把产品和项目概念混为一谈。

我建议用一个团队和一个产品积压来管理一个产品开发。不要为一个项目的功能请求创建单独的项目。相反,让一个团队处理来自不同客户的不同请求,对用户情景进行优先级排序。

不过,如果这些是您开发的完全独立的产品,请尝试将团队分开,以便每个团队一次可以专注于一个产品。