Scrum和项目管理可以共存吗？

Question

Scrum和项目管理可以共存吗？

你能两全其美，还是将这两种方法结合起来？

Answer 1

需要考虑的几件事：

• Scrum是关于授权团队，而不是命令和控制管理风格。
• Scrum中没有经理，有一个ScrumMaster，它是一个服务领导者。
• ScrumMaster负责Scrum过程，确保它被正确使用并最大化其好处。
  • the ScrumMaster必须消除障碍，以便团队能够以高效的方式完成他的工作。
  • Scrum以最少的一组实践/角色/仪式实现透明度，并且Scrum中没有真正的PMO类型的工作，大多数项目管理办公室的工作都是(被认为)浪费。

所以，请远离你的PM习惯:)

在领养过程中，我建议像书(Shu)中那样做，不要试图现在就改编(Ri) (参见Shu Ha Ri上的Alistair Cockburn )。我甚至不会在一开始就考虑像Scrumban这样的东西(使用Kaban进行连续流的Scrum的修改版本，没有更多的迭代)。

PS:敏捷方法都受到精益运动的影响(大多数，如果不是全部，敏捷宣言签字人的书架上都有改变世界的机器)。有些人可能会说敏捷方法是精益概念(用于新产品开发)到软件开发的转置；另一些人可能会说敏捷和精益共享相同的理论(例如，请参阅Jeff Sutherland的文章The First Scrum: Was it Scrum or Lean?)。对我来说，它们有明显的相似之处(很容易将整个Toyota Production System "House"映射到敏捷实践中)，我发现精益有助于理解敏捷是如何工作的，以及如何有效地实现敏捷流程。因此，我将精益作为一个额外的工具箱。但对我来说，如果实现得当，Scrum已经具备了一切让你的开发过程变得精益的东西。因此，没有必要混合它。只需应用它(Shu)。

Answer 2

是的，Scrum和PMO可以住在一起。他们关心的是不同的东西，所以两个交汇点的边缘将不得不做出一点让步。在十字路口会有一些冲突。传统的PMBOK方法不太适合像软件开发这样的产品开发领域，但PMBOK中有相当多的智能统计控制，可以被教导管理流程而不是进度的熟练项目经理是宝贵的。

无论是Scrum、精益还是丰田组织，都不认为等级制度或直接权力是禁区。多年来，软件开发人员对“自组织”的定义进行了极大的扩展，直到它与“自我决定”变得难以区分，而“自我决定”从来都不是软件开发人员的本意。

例如，丰田是一个非常有等级的组织，非常依赖于指挥和控制。不同的是，它是一个学习型组织，丰田的经理们被要求掌握自己职责范围内的工作，并有责任向工人传授这项工作。丰田的团队成员设想他们的工作和过程可能会得到改进，他们的经理会通过科学的过程来指导他们，以证明他们的想法。它有助于过程不是被塑造成适合组织，而是组织转变以适应不断改进的过程。

在任何组织中，总是有命令和控制的元素。甚至Scrum团队也会受到它的影响。即使工作团队本身是完全扁平的，产品负责人仍然可以发号施令。软件团队有前辈和后辈，他们的观点并不完全平等。在精益团队中，管理者被期望成为工作的大师，或者像丰田所说的那样，拥有“高超的技术能力”。如果管理层不熟练或者离工作太远，那么他们很可能会对工作做出糟糕的决定。这是真正的问题所在，自我导向的工作团队(SDWT)是员工试图将自己与糟糕的管理隔离开来的可预见的结果。SDWT不是最好的答案，但它可能是组织可能实现的极限。

最后，Scrum不是一种项目管理方法--至少不是从PMBOK或精益的严格性的角度来看的。但是，在软件开发中应用PMBOK而不进行重大修改来说明产品开发的性质通常是一件愚蠢的事情，因此在软件团队中取代PMBOK的努力是可以理解的。

充其量，Scrum是一种时间盒计划方法。如果这是你需要的东西，那么它仍然是有价值的，但软件工作管理中没有任何固有的东西表明你需要像冲刺和迭代这样的计时器。事实上，人们对看板和基于流程的管理等无迭代方法的兴趣的高涨证明了这一点。

最后，现在围绕Scrum建立了许多正统的东西，这些东西并不是Scrum的创始人和领导者引入的，而且通常也不会得到他们的支持。PMO的运作方式也可以这么说。专注于流程和学习文化的原则，一旦方法论成为主流五年左右，你可能就能够避免围绕着方法论的死胡同和神话。

Answer 3

有没有人尝试过整合不同的想法(scrum、六西格玛、项目管理计划、精益管理？)

基本上，上述所有这些都源于20世纪80年代初的日本质量运动。这一切都是为了通过降低日本的waste, called Muda来提高质量

精益是丰田对质量哲学的执行，六西格玛是通用电气基于当时的企业文化将精益美国化的尝试。

20年后，IT行业已经意识到，所有这些“精益”思维对于更快地构建更高质量的软件来说是一个很好的想法。已经被贴上了Agile的标签。

XP (极限编程)和SCRUM只是敏捷技术的两种不同实现。

传统的管理和软件管理正面临着这些新的思维方式。

你不可能拥有一切。您的关注点要么是命令和层级(按您的要求做，传统方法)，要么是协作和合作，以减少浪费并为客户提供令人惊叹的东西(让我们一起来做IT，新模式)。

如果你想更深入地了解这一点，最好的方法是重读原始的精益哲学，然后看看你认为它们如何最好地应用于项目管理。许多最好的项目管理想法已经被认为是最初的精益运动的一部分，阅读“丰田之路”这本书，看看精益，你就可以找到自己的答案。

谷歌:首先是七种类型的muda。