问敏捷项目管理

EN

我们已经将scrum扩展到公司的其他部门，包括建模、纹理和动画艺术家。我们不得不稍微调整一下这个方法，但它确实工作得很好。我们有一些问题是通过使用敏捷方法解决的。一些较小的部门(音频、特效)已经很好地工作了，所以我们没有试图修复没有损坏的部分。敏捷会给他们增加不必要的开销。

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

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

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

通常，标准的Scrum解决方案是在Scrum没有直接指定的问题上“让团队决定”。通常，处理此类问题的指导方针来自敏捷世界中的其他文化和价值或原则系统，例如XP或精益软件开发。其他为Scrum团队提供有用东西的文化包括Real Options，增量资金方法，Evo。

一些PMBOK的东西对Scrum团队中的“项目经理”或PO是有用的，但是必须小心，因为PMBOK的东西暗示了一个与Scrum所基于的价值系统相当不同的价值体系。在敏捷文化中寻找解决方案通常是最好的。不过，PMBOK中的一些内容仍然适用于敏捷环境。

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

敏捷开发和PMBOK不应该混为一谈。如果你这样做了，你很可能最终会使用Scrummerfall。我看到这种情况发生在转换为敏捷的传统项目经理身上。他们就是不明白，似乎又回到了旧的模式。

然而，在我看来，SCRUM并没有涵盖项目管理所需的所有内容。它在某种程度上缺乏一个整体战略来统治。一种可能性是将SCRUM与EVO project/value management或其他价值管理方法相结合。然而，它将需要与客户签订不同类型的法律合同。然后，项目更像是一个连续的过程，它被时间框住，受到预算的限制，或者当客户觉得他获得的收益少于他的投资时结束(使用业务案例和目标度量)。一个额外的好处是，客户将更多地将您视为长期合作伙伴，而不是短期供应商。