5

敏捷/Scrum 是答案吗？Scrum 如何处理这个问题？

一个产品负责人，一个产品待办事项与多个产品负责人和产品待办事项？

它如何为您工作？请分享你成功失败的故事？

我正在尝试将一个流程放在一起来管理多个工作队列，从基础设施项目、简单的功能增强到大型项目，以及一个由 6-7 名开发人员组成的小型开发团队。

4

6 回答 6

2

缺少的一点是这在技术上是否是一种产品（就像一个代码库，即使很大）。

如果这些是完全独立的产品，那么使用 Scrum 我会进行非常短的冲刺（1-2 周）和序列开发工作。所以两周的项目 A，然后是项目 B，然后是 C，然后是 A——可能是两个 sprint，然后是 C 等等。在这种情况下，单个积压是没有意义的，应该为 A、B 和 C 保留单独的积压。至少知道一个这样工作的团队。

您是否需要更多的采购订单是产品知识的功能。也许你每个项目都需要一个人，也许你有一个足够了解 A、B 和 C 的人来担任 PO。

如果是不同的产品，那么当您尝试通过从不同的待办事项中获取不同的故事来实现时，每个 sprint 最终都会导致团队分裂。人们自然会专注于给定的项目，而且很难对完成有一个好的定义（如果我们可以在这个 sprint 中为 A 和 B 提供新的增量，但不能为 C 提供新的增量，我们就完成了吗？）。如果您无法对短冲刺的项目进行排序，那么我会期待看板尝试将一些组织纳入其中。

如果这是一个产品/一个代码库- 那么事情就容易多了。即使团队由于项目不同而不得不触及代码库的不同区域，他们仍将致力于相同的产品，因此 Scrum 的所有机制都将很好地适用。一份积压工作，一份采购订单。

需要注意的一个缺点是团队中的人员将进行上下文切换，无论您使用什么流程，这样做都会受到惩罚。无论您选择什么流程，都应该尽可能地减少这种情况（只要业务能够坚持）。Scrum 的好处在于它与 PO 达成了一致，即上下文切换只能在 sprint 边界发生——换句话说，团队将在必须切换到另一个项目之前有 1-2 周的时间来集中精力。

另外，不要忘记敏捷的所有技术实践。单元测试。自动构建和测试。代码审查。巧妙地使用 repos。高标准重新。质量。在如此充满挑战的环境中，所有这些都是必须的。

于 2010-07-08T19:34:29.847 回答
1

更多细节可能会有所帮助。是不是一个大制作团队，在他们之间共享很多项目？它是一个有很多项目的小团队（5 人左右）吗？

为什么你有很多项目？他们是否在不同的时间范围内工作，有些是“真正的工作”，有些是“如果你不忙的话，把它作为后台任务来做”。

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

我们有一个大约 15 个部门，随时运行 3-4 个项目。人们通常在任何时候都属于一个项目，但是随着项目经历不同阶段以及需要不同的技能，他们可以在他们之间移动。特别是测试似乎切换项目很多。

至于严格的流程……让流程适合您的需求。如果我们对您的需求有更好的了解，我们可能会提出更好的建议。

于 2010-07-08T17:13:57.763 回答
1

我想你可以做两件事：

  1. 做一个项目的一个版本，完成后做下一个
  2. 拆分你的开发团队

或者两者的结合:)

敏捷/Scrum 是不错的流行语，但似乎与您的问题不太相关。因为它们适用于一个项目的范围，而不是一堆项目。

我对第二种选择有经验，直到项目数量多于开发人员的水平，这不是您想要的。但通过体面的代码审查会议，它似乎确实有效。

于 2010-07-08T17:17:06.103 回答
1

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

当任何开发工作交给团队时，这些事情应该已经理顺了。开发人员不应该关心（或者，在某些情况下，甚至懒得知道）什么任务是针对什么所有者或什么项目等的。他们可以关心并知道这些事情，当然，但这不应该是关键的。

产品所有者和其他各种高级角色需要在每个 sprint 开始时制定一个计划，即在该 sprint 中应该完成哪些故事。包含任何给定项目的多少故事并不重要，将其分类是那些利益相关者的日程安排问题。与架构师或高级开发人员等合作，他们应该简单地决定在当前/下一个 sprint 中实现哪些故事。

（附带说明一下，我有一个 51 区的提案就是针对这类事情：http ://area51.stackexchange.com/proposals/9543/development-methodologies ）

于 2010-07-08T17:20:34.263 回答
0

恕我直言，当您与一个由 4 到 6 名开发人员组成的团队进行至少 3 到 4 次为期两周的迭代时，Scrum 会更有效。所以对于 +- 400 人/天的项目

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

还请检查这个先前回答的问题：

当您有多个项目时，Scrum 如何工作？

于 2010-07-08T18:58:27.780 回答
0

看起来你混合了产品和项目概念。

我建议用一个团队和一个产品待办列表来管理一个产品开发。不要为一个项目的功能请求创建单独的项目。相反，让一个团队通过优先处理用户故事来处理来自不同客户的不同请求。

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

于 2010-07-24T18:05:39.130 回答