如何在一个小团队中处理多个项目

Question

我们刚开始使用scrum进行项目管理。我们是一个非常小的团队（2个开发人员，1个UI / Web-deisgner），我们一次有很多正在运行的项目。

如何在scrum模型中同时运行多个项目？大多数时候我们有一个主要项目和一些小项目。如何有效地组合多个冲刺？

编辑：不要在scrum上修复。我们是一个小型结构，非常灵活。 Scrum只是我的出发点。如果你有其他系统对你或你的小团队有用，我完全愿意接受任何形式的投入。

Answer 1

AFAIK Scrum的基础是团队一次只参与一个项目。无论方法如何，任务切换开销都使得“并行”处理多个项目的效率非常低。

你可以做的是尝试将不同的项目安排到单独的sprint中，即完成一个专门针对project1的sprint，然后完全针对project2的下一个sprint等。如果项目的范围非常不同，你可以考虑改变短跑的长度，例如在一个大项目上进行为期3周的冲刺，然后在一个小项目上进行为期一周的冲刺。

在纯粹的Scrum中，冲刺的长度确实是刻在石头上，但是，IMO的重点不是获得“纯粹的Scrum实现者”徽章，而是为您的团队提供真实的工作流程。

（免责声明：我不是Scrum主人： - ）

根据评论进行更新：我看到了您的问题。您需要快速响应其他产品客户的小型支持（改进/错误修复）请求，同时仍需要以可预测的方式处理更大的项目。

一种可能性是计划Scrum中大项目的冲刺，但是“timebox”有时间用于传入支持任务。例如。如果您平均每个sprint支持其他项目花费5天时间，那么您将为每个sprint分配5天的资源（无论您计算时间）以获得支持。

另一个选择可能是考虑其他方法，例如Kanban，没有冲刺或计划，而团队仅根据客户的需求（或主要）工作。

Answer 2

你需要1周的冲刺。每个sprint只有1个项目。通过一次处理多个项目，您可以更快地交付软件，这是一种谬论。较大的项目可能会花费几个冲刺来开发一个版本，就像你的小版本一样，你可以在每个sprint之后发布。

如果您的项目针对不同的PO /客户，那么您一次只能处理一个项目更为重要;否则你的优先事项几乎总会发生冲突。

Answer 3

  

如何在scrum模型中同时运行多个项目？大多数时候我们有一个主要项目和一些小项目。如何有效地组合多个冲刺？

一种选择是并行运行多个冲刺，即使它不理想，也要成为几个团队的一部分（显然不是100％专注）。我不确定这在你的上下文中是否有意义，但我不相信用Scrum运行小项目会增加价值。

另一个（可能更合适）选项是在产品积压中有一个项目，用于卫星项目/任务所需的工作，从而为它们分配一些时间。如果你需要那个时间，就把它烧掉。如果没有，只需在sprint结束时从主项目中获取一些额外的积压项目。

Answer 4

如果你有很多小工作需要快速完成，那么项目管理就不是正确的范例。您正在处理的是运营管理，通常涉及定义明确的经过试验和检验的现成工作程序。因此，我建议您在管理方面将您需要项目管理的活动与需要运营管理的活动分开。如果你还没有定义工作程序（并经过试验和测试等），那么你可能需要设置一个项目来开发它们（或者如果你想以这种方式来考虑它们的话，可以编写它们。）

软件开发项目（或应该）运行的方式与帮助台的运行方式之间存在很大差异。仅仅因为你是一个在项目管理范例方面经验丰富的软件开发人员（我认为我们大多数人都是这样）并不意味着它是适合所有事情的正确方法。

一旦你完成了转变，你应该会发现你可以继续在你的1或2个项目中缩减（或任何术语），然后转动机器上的手柄以完成其余的工作。

Answer 5

棘手。您的情况可能不是Scrum的完美匹配，但我认为Scrum中有一些元素适用于您的情况。

例如，我发现在Scrum中最有用的一件事是回顾，因为它是在那些改善你工作方式的会话中。但是，为了使回溯变得有用，您需要测量您正在对要设置的一些项目进行的工作。那么为什么不在短时间内做一些与短跑相似的事情，并为你打算在接下来的1-2周做的项目进行冲刺计划（较短的周似乎更适合你的情况）。每天举行一次Scrum会议，以便所有三个人都知道其他人在做什么并且可以适当填写。然后在冲刺之后，您可以坐下来思考如何改进。如果不出意外，Retrospectives的结果会告诉您这是否适合您。

我不相信尝试调整严格的Scrum项目计划，如果这意味着并行运行冲刺或者只使用一个项目进行更短的冲刺，而每隔一周不会触及其他项目。