敏捷项目管理

Question

如果您将Scrum用于项目的软件开发部分，是否仍然使用PMBOK或其他项目管理方法来处理项目中的“其他”任务。业务，营销，培训任务。什么是非软件开发任务的项目管理，即传统的项目管理？

Answer 1

我们已经将scrum扩展到公司的其他部门，建模，纹理和动画艺术家。我们不得不稍微调整这个方法，但它确实很好地工作。我们遇到了使用敏捷方法解决的问题。一些较小的部门（音频，特殊效果）已经正常工作，所以我们没有试图修复未被破坏的部分。敏捷会为他们增加不必要的开销。

公司所有部门都没有必要使用相同的方法，最好的方法是适应每个人的需求。但是Scrum可能是程序员之外的其他人的解决方案，但可能需要一些适应。每日站立，冲刺，积压，这些对于许多类型的工作都是好事。

Answer 2

Scrum不是软件开发方法，而是项目管理方法。

除了Scrum往往引入​​或其他人为因素（搜索“59分钟Scrum”）。 因此，它可以用来处理项目的所有任务，无论它们的性质如何。

Answer 3

虽然了解这些技术非常好，但我能否建议您主要关注的焦点实际上是运行项目并完成任务？

编辑：这是一个严重的问题，而不是一掷千弄。

Answer 4

项目在PMBOK中被定义为固定范围，持续时间和预算。该项目的失败被定义为违背这个“铁三角”三个方面之一。 Scrum是基于敏捷价值观处理各种知识工作的一系列原则和一些具体实践，专门用于可能不是项目或可能具有灵活范围，持续时间或预算的开发工作。

你说得对，Scrum只涉及软件开发过程的几个方面，比如规划。它只定义了一些角色，会议和工件，这是为了尽可能保持灵活性。 Scrum可以也应该在软件开发本身之外解决部分价值流问题。但是，正如您所提到的，它不涉及很多事情，如软件工程实践，并分析业务案例。

通常，标准Scrum解决方案是“让团队决定”哪些事情不是由Scrum直接指定的。通常，处理这些问题的准则来自敏捷世界中的其他文化和价值或原则系统，例如XP或精益软件开发。为Scrum团队提供有用内容的其他文化包括Real Options，增量资助法，Evo。

一些PMBOK的东西对于Scrum团队中的“项目经理”或PO是有用的，但是必须谨慎，因为PMBOK意味着一个与Scrum基于的不同的价值系统。通常最好在敏捷文化中寻找解决方案。尽管如此，一些PMBOK的东西仍然适用于敏捷的环境。

如果您在寻找与“敏捷项目管理”相关的邮件列表，您会发现很多蓬勃发展的社区讨论这些主题。

Answer 5

如果您的软件开发工作只是大型项目的一个方面 - 例如推出一个新的金融产品 - 那么您一定会采用某种项目管理方法来编排所有的工作参与其中。但是，将基于Scrum的软件开发工作纳入根据PMBOK原则管理的项目可能具有挑战性，然而，由于PMBOK规定了线性分阶段的项目执行方法，而Scrum与其他敏捷方法一样，通过迭代促进了渐进式改进。这并不是说两者不能共存。像所有其他事情一样，它归结为实施。只要记住务实，并根据需要调整方法，而不是相反。

Answer 6

敏捷开发和PMBOK不应混用。如果你这样做，你很可能会以Scrummerfall结束。我看到这种情况发生在传统项目经理身上，他们转化为敏捷。他们只是不明白，似乎回落到旧模式。

但是，在我看来，SCRUM并未涵盖项目管理所需的一切。它有点缺乏统治的总体战略。一种可能性是将SCRUM与EVO project/value management或其他价值管理方法相结合。然而，它需要与客户签订不同类型的法律合同。因此，项目更像是一个持续的过程，受时间限制，受到预算的限制，或者当顾客感觉他的收益低于其投资（使用业务案例和目标度量）时结束。另外一个好处是，客户会把你看作是一个长期合作伙伴而不是短期供应商。