Scrum和项目管理能够共存吗?

Mic*_*bly 4 agile scrum methodology

Scrum和项目管理能够共存吗?

你能充分利用两个世界还是将这两种方法结合起来会产生更多混乱?

Scrum能否更好地与项目经理一起做PMO类型的工作并与产品所有者和scrum master交叉功能?我相信专门的PMO会跟踪合规性,工件和质量.这将使Scrum团队能够继续工作而不必担心后勤或文书工作.有没有人试图纳入不同的想法(Scrum,六西格玛,pmp,精益?)

Pas*_*ent 7

需要考虑的一些事项:

  • Scrum是关于赋予团队权力而不是命令和控制管理风格.
  • 在Scrum中没有经理,有一个ScrumMaster是一个仆人领导者.
  • ScrumMaster负责Scrum流程,确保正确使用并最大限度地发挥其优势.
  • ScrumMaster必须消除障碍,以便团队能够以富有成效的方式完成工作.
  • Scrum通过最少的实践/角色/仪式来实现透明度,并且没有真正的文书工作.
  • 在Scrum中没有真正的PMO类型工作,大多数PMO工作都被认为是浪费.

所以,请保持你的PM习惯:)

在收养过程中,我建议按照书中的说法(Shu),不要试图改编它(Ri)(参见Shu Ha Ri的 Alistair Cockburn ).我甚至不会考虑Scrumban(Scrum的修改版本,使用Kaban进行连续流动,不再需要迭代).

PS:敏捷方法都受到精益运动的影响(大多数,如果不是全部,敏捷宣言签署者的货架上都有改变世界的机器).有人可以说敏捷方法是将精益概念(用于新产品开发)转换为软件开发; 其他人会说Agile和Lean有相同的理论(例如参见Jeff Sutherland的文章The First Scrum:Scrum or Lean?).对我来说,有明显的相似之处(很容易将整个丰田生产系统"House"映射到敏捷实践上),我发现精益有助于理解敏捷如何运作以及如何有效地实施敏捷过程.所以我使用精益作为一个额外的工具箱.但对我来说,如果实施得当,Scrum已经做好了让您的开发过程精益求精的一切.所以没有必要混合它.只需应用它(舒).


Sco*_*are 6

是的,Scrum和PMO可以共同生活.然而,他们关注的是不同的事情,所以两者相遇的边缘将不得不给予一点点.交叉路口会有一些冲突.传统的PMBOK方法不适合像软件开发这样的产品开发领域,但PMBOK中有相当多的智能统计控制,熟练的项目经理可以被教导管理流程而不是计划是宝贵的.

Scrum和Lean以及丰田组织都没有暗示任何等级或指导权限都是禁止的.软件开发人员多年来一直在大大延伸"自组织"的定义,直到它与"自我决定"完全无法区分,而"自决"从来就不是故意的.

例如,丰田是一个非常等级的组织,在很大程度上依赖于指挥和控制.不同之处在于,它是一个学习型组织,丰田的管理者必须掌握其职权范围内的工作,并有责任向工人传授这项工作.丰田的团队成员设想可能改进他们的工作和过程,他们的经理通过科学过程来指导他们的想法.它有助于使流程不适合组织,但组织转变为适应不断改进的流程.

任何组织中始终都有一个命令和控制元素.即使是Scrum团队也会受其影响.即使工作团队本身非常平坦,产品负责人仍然可以召集球.软件团队有老年人和青少年,他们的意见并不完全相同.在精益团队中,经理人应该成为工作的主人,或者像丰田所说的那样,拥有"高耸的技术能力".如果管理层不熟练或离工作太远,那么他们可能会对工作做出错误的决定.这是真正的问题,自我导向工作小组(SDWT)是工人寻求将自己与管理不善隔离开来的可预测结果.SDWT不是最佳答案,但它可能是组织可能实现的极限.

最后,Scrum不是一种项目管理方法 - 至少不是从PMBOK或精益的严格角度来看.但是,将PMBOK应用于软件开发而不进行重大修改以解释产品开发的性质往往是一个愚蠢的错误,因此在软件团队中取代PMBOK的努力是可以理解的.

最好的是,Scrum是一种时间箱规划方法.如果它是您需要的东西,那仍然很有价值,但软件工作管理中没有任何固有的东西表明您需要时间框,如冲刺和迭代.实际上,像Kanban和基于流程的管理这样的无迭代方法的兴趣上升是对此的证明.

最后,Scrum的创始人和领导者并没有引入Scrum创建的大量正统观念,而且往往得不到他们的支持.关于PMO如何运作也可以这样说.专注于流动和学习文化的原则,你可能能够避免一旦他们已经进入主流五年左右的方法论的盲目的小巷和神话.


Evo*_*lve 5

有没有人试图纳入不同的想法(Scrum,六西格玛,pmp,精益?)

基本上所有上述内容都源于20世纪80年代初的日本品质运动.通过减少浪费提高质量,在日本称为Muda

Lean是丰田实施的质量哲学和六西格玛,是通用电气基于当时企业文化将美国精益美化的尝试.

快进20年,IT行业已经意识到所有这些"精益"思维都是更快地构建质量更好的软件的好主意.在标有敏捷的地方.

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

传统的管理和软件管理正在迎合这些新的思维方式.

你无法拥有一切.您可以将重点放在命令和层次结构(DO AS YOUR TOLD,传统方法)与协作之间,共同努力减少浪费并为客户提供令人惊叹的产品(让我们共同努力,新模式).

如果您想深入了解这一点,最好的方法是回读原始的精益哲学,然后看看您认为它们如何最好地应用于项目管理.许多最好的项目管理理念已被视为原始精益运动的一部分,阅读"丰田之路"一书,并展望精益,在那里你可以找到自己的答案.

谷歌:七种类型的穆达一开始.