PMBOK是否更多地用于实现和敏捷，Scrum是否更多地用于工程？

Question

PMBOK是不是更多地是为了在实现软件构建之后将其交付给客户，而敏捷或Scrum更多地是为了首先构建软件？只是想弄明白。

谢谢。

编辑:我主要关心的是PMBOK。他们经常在我工作的地方使用它，但不是为了开发(他们用它来实现)。它们不会开发很多，所以我没有办法问：“嘿，你用什么来开发呢？”我必须自己想出最好的计划。我真的不太关心PMP认证，但如果这是使用PMBOK开发软件的最好方法，我可以证明学习它是合理的。如果scrum或agile是最好的方式，那么我宁愿使用它并取得成功，也不愿拥有一个名为pmp的项目。

Answer 1

好吧，我可以根据我的真实经验来回答这个问题，我既是一名通过PMP认证的企业软件解决方案的实施者，也是一名经验丰富的敏捷项目经理，在一个混合敏捷软件开发项目中管理了一个14人的团队。

在实现COTS (商用现成)软件时，我发现PMBOK可以被密切关注。如果遵循"T“，PMBOK将引导您沿着”瀑布“方法的道路前进。如果你不熟悉Waterfall，这种方法可以让你的大部分项目时间花在项目早期，收集需求，执行设计，评估等。在这个过程中，构建或开发要晚得多。这种方法适用于软件实现的原因是，客户通常希望预先了解项目的成本。确定项目成本的唯一真正准确的方法是最初遵循瀑布approach...at最小。

敏捷/Scrum方法在构建软件方面工作得更好。当我说构建时，我指的是从设计、开发、测试等整个构建过程。我不会深入讨论PMBOK、瀑布或敏捷方法中涵盖的内容之间的差异，因为这不是您所要求的。敏捷在很大程度上是关于迭代设计和构建，而不是前期设计。在敏捷中，您希望快速迭代，并执行JIT (即时)需求收集(使用存储)、设计、构建和测试(TDD)。这减少了浪费的数量，并在项目早期产生了可用的软件。敏捷对软件开发项目有很多好处。

现在，我发现有帮助的是采用瀑布方法，因为您需要构建准确的估计和资源计划。一旦完成，你就可以切换更多的敏捷过程来完成你的项目。

请记住，不要将PMBOK与方法论混淆。PMBOK是一组行业标准流程，可以遵循这些流程来交付项目；它可以不仅仅是软件项目，还可以是工程、市政规划等。PMBOk的许多部分在软件开发领域都是有益的，例如:沟通计划、风险计划、项目收尾等。

这是一个相当广泛的主题，所以我希望这能帮助你为你的项目做出适当的决定。记住，一种尺寸并不能适合所有的尺寸。

Answer 2

我个人建议在进入PMBOK之前了解Scrum和/或Agile (最适合您的组织)。PMBOK中的标准更加传统，阶段描述采用了一种稍微有点伪瀑布的方法，这在现在的IT行业中并不像以前那样被接受，敏捷和Scrum敲开了我们的门……如果您在了解Scrum之后学习PMBOK，那么更容易过滤掉不相关的内容，并从整体上更好地理解这两个概念。

PMBOK和Scrum/Agile都是用于工程和实现的。PMBOK涵盖了IT行业以外的其他领域，仅此而已！此外，Scrum是项目团队中的任何人或每个人都可以学习和实现的东西。但是PMBOK主要是针对项目经理的。

Answer 3

PMBOK只是一个空洞的行业标准，用于让组织A中不知道更好的(错误的)管理人员放心，组织B正在以“正确的”PMI认证的方式做事情。

正如Pedro所说，Scrum是一种敏捷的项目管理技术，它以固定迭代为中心，受到大多数软件专业人员的高度重视。尽管Scrum没有规定任何工程技术，但它通常与XP (极限编程)中概述的工程技术结合使用，例如结对编程和持续集成。

出于业务原因，一些公司至少必须表面上遵循PMI、CMMI或ISO才能赢得工作，但实际上，大多数严肃的软件商店都在幕后实践敏捷技术，如scrum/xp/kanban。