【发布时间】：2010-01-22 07:11:41
【问题描述】：
如果确实将 Scrum 用于项目的软件开发部分，那么是否仍然使用 PMBOK 或其他一些项目管理方法来处理项目中的“其他”任务，例如业务、营销、培训任务。什么是非软件开发任务的项目管理，即传统的项目管理？
【问题讨论】：
-
我认为这个问题对Software Engineering 来说会很好，如果它不是太旧而无法迁移的话。
【发布时间】：2010-01-22 07:11:41
【问题描述】：
项目在 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 或其他价值管理方法相结合。但是，它需要与客户签订不同类型的法律合同。然后，项目更像是一个持续的过程，有时间限制，受预算限制，或者在客户觉得他的收益少于投资时结束（使用商业案例和目标衡量标准）。另一个好处是客户会将您视为长期合作伙伴，而不是短期供应商。
【讨论】：
-
我尝试阅读 EVO 项目/价值管理，但发现材料非常复杂和冗长。你使用成功了吗？
我们已将 scrum 扩展到公司的其他部门，包括建模、纹理和动画艺术家。我们不得不稍微调整一下这个方法，但它确实工作得很好。我们遇到了通过使用敏捷方法解决的问题。一些较小的部门（音频、特效）已经运行良好，所以我们没有尝试修复没有损坏的部分。敏捷会给他们增加不必要的开销。
公司中的所有部门不必使用相同的方法，最好是适应每个人的需求。但是 scrum 可以成为程序员以外的其他人的解决方案，但可能需要一些适应。每日站立、冲刺、积压，这些对于许多类型的工作来说都是一件好事。
【讨论】：
-
您是如何在其他部门实施 SCRUM 的，您是否有一份人们自愿完成的任务列表，或者您是否分配了任务？
如果您的软件开发工作只是大型项目的一个方面（例如，推出新的金融产品），那么您当然必须采用某种项目管理方法来协调所有涉及的工作.然而，将基于 Scrum 的软件开发工作融入根据 PMBOK 原则管理的项目可能具有挑战性，因为 PMBOK 规定了一种线性、分阶段的项目执行方法，而 Scrum 与其他敏捷方法一样，通过迭代促进增量改进。这并不是说两者不能共存。像其他一切一样，它归结为实施。请记住要务实并根据您的需求调整方法，而不是相反。
【讨论】：
Scrum 不是一种软件开发方法，而是一种项目管理方法。
除了 Scrum 之外，通常还通过 Lego 或其他人工制品（搜索“59 分钟 Scrum”）引入。 因此，它可用于处理项目的所有任务，无论其性质如何。
【讨论】：
虽然学习这些技术很棒，但我可以建议您的主要重点实际上是运行项目并完成工作吗？
编辑：顺便说一句，这是一个严肃的观点，而不是一次性的讽刺。
【讨论】：