敏捷项目管理

Question

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

Answer 1

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

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

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

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

如果您查找与“敏捷项目管理”相关的邮件列表，您会发现许多繁荣的社区都在讨论这些主题。

Answer 2

敏捷开发和PMBOK不应该混在一起。如果你这样做，你很可能最终得到Scrummerfall。我已经看到这种情况发生在转换为敏捷的传统项目经理身上。他们只是没有得到它，似乎又回到旧模式。

但是，在我看来，SCRUM并未涵盖项目管理所需的全部内容。它有点缺乏统治的整体策略。一种可能性是将SCRUM与EVO project/value management或其他价值管理方法相结合。但是，它需要与客户签订不同类型的法律合同。然后，项目更像是一个持续时间的过程，受预算限制，或者当客户认为他的收益低于他的投资时（使用业务案例和目标衡量标准）结束。另一个好处是，与短期供应商相比，客户将更多地视为长期合作伙伴。

Answer 3

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

Answer 4

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

公司的所有部门都没有必要使用相同的方法，最好是根据每个人的需求进行调整。但scrum可以成为程序员以外的人的解决方案，但可能需要一些适应性。每日站立，冲刺，积压，这些对于许多类型的工作都是好事。

Answer 5

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

除了Scrum之外，还经常引入Lego或其他文物（搜索“59分钟Scrum”）。 因此，它可用于处理项目的所有任务，无论其性质如何。

Answer 6

虽然了解这些技术很棒，但我能否建议您主要关注的是运行项目并完成工作？

编辑：顺便说一句，这是一个严肃的观点，而不是一次性的讽刺。