scrum敏捷项目管理_为什么敏捷项目经理不是Scrum Master

scrum敏捷项目管理

一位读者问，为什么地理分布团队的敏捷生命周期（第1部分）中的生命周期不是Scrum。 由于以下原因，它不是Scrum：

1. 项目经理和产品所有者启动发布计划，并询问团队发布计划是否正确。 团队不会自行生成发布计划的初稿。 在Scrum中，团队应该自己生成所有计划。
2. 签入不同于Scrum站立，签入的目标也不同。 我确实向团队建议，如果您想创建一个功能分开的跨职能团队，如果您问人们如何一起工作，则可以帮助他们一起工作。 有时这些问题有用，有时却没有。 这取决于团队以及人们是否愿意一起工作。

到目前为止，我没有在示例中提及回顾或积压，因为我认为它们是理所当然的。 是的，这两个团队的两个示例都进行了回顾并积压了产品。 他们也有敏捷功能路线图，这些在我的博客列表中。

真正的区别是Scrum Master和敏捷项目经理之间的区别。 Scrum Master不是项目经理。 Scrum管理员无法自己管理风险。 项目经理将承担风险管理责任，而无需询问团队。

Scrum Master只能效忠团队。 项目经理对团队和组织负责。 这意味着，当组织向项目经理施加压力以使他们做一些愚蠢的事情时，项目经理可能会感到沮丧。 （尽管，我刚刚下载了《 Scrum指南》，自2006年我与Jeff一起获得CSM以来，Scrum Master的职责已大大增加。）

但是，当组织要求敏捷项目经理做一些愚蠢的事情时，敏捷提供了透明性，因此，更容易保持您作为项目经理的诚信。

是否想在待办事项中增加功能？ 与产品所有者一起更改功能路线图，然后与产品所有者一起更改积压。 我希望敏捷项目经理能够与产品所有者在功能路线图和积压订单方面进行协作。

是否想改变团队的速度来取悦一些疯狂的经理？ Scrum Master或敏捷项目经理都通过以下方式保护团队：

• 说明速度不是生产力指标
• 说不，并解释原因
• 玩“ Double Your Velocity”时间表游戏
• 或者选择其他方法来消除此管理障碍。

敏捷使保护团队变得容易。 问题是这样的：Scrum Master除了保护团队之外，还有其他职责吗？还是Scrum Master是全职的？ 敏捷项目经理倾向于全职工作在地理上分散的团队中。 即使在地理上分散的团队中，Scrum Master也不被视为全职。 经理们祝福他们的小小的心灵，似乎并不明白过渡到敏捷，特别是对于具有不同文化规范的孤立的分布式团队而言，这并非易事。 他们将为项目经理腾出空间，但是Scrum Master？ 不好了。 让我发疯。

偷工减料？ 我不知道如何。 团队不符合故事的验收标准，不满足迭代的完成标准，因此无法演示演示。 如何为任何人服务？

帮助团队更快？ 在这里，项目经理可能比Scrum Master更具优势，这仅仅是因为受过教育。 敏捷项目经理是项目经理。 这意味着他（她）正在积极学习项目管理，这意味着他（她）也在学习精益，正在研究正在进行的工作。 （我意识到许多项目经理并没有积极研究项目管理。）我对敏捷项目经理寄予很高的期望，那就是限制在制品（在制品），进行中的工作，测量累积流量。 但是，约翰娜（Johanna）是精益项目经理。 对，那是正确的。 为什么不始终使用我们可用的所有工具？ 这不是为了帮助团队实际上更快地前进，而是要向团队提供有关其在制品的反馈。 如果每个人都在迭代开始时获取一个故事，并且每个人都始终按照自己的故事进行工作，那么团队很可能以最快的速度前进。 值得一提的是，至少是对数据进行回顾。 项目经理将收集数据。 Scrum Master，尤其是未经培训的项目经理的Scrum Master，可能不知道如何收集数据。

我没有反对Scrum Masters。 我的一些好朋友是CST（认证的Scrum培训师）。 但是，他们并不是全部的项目经理，还不是项目经理，也没有研究项目管理领域。 有的。 而且，真正的问题是这样的：在为期两到三天的研讨会中，他们无法传达给可能曾经或可能不是实践项目经理的所有项目知识。

组织并不总是选择项目经理作为Scrum Master。 并且，有充分的理由。 一些项目经理是命令控制项目经理。 我怀疑自己是在过去很久以前。 我早就放弃了，因为它没有用。 有些人从未放弃指挥与控制项目的管理。 这些人不是敏捷项目的好项目经理。 他们是地理分布项目的可怕项目经理，您必须在其中发挥影响力。

您可以拥有按地理位置分布的自我管理团队。 您可以拥有按地理位置分布的自我指导的团队。 但是，他们不是那样开始的。 他们发展成为自我指导和自我管理的团队。 他们开始时是管理层领导的团队。

并且，尤其是当他们是孤岛团队时，他们需要项目经理的协调，一个负责管理孤岛之间风险的人，一个得到组织支持的人，是的，一个对组织忠诚的人。说，“我们需要做这个项目”来编写项目章程。

在地理上分散的团队中，敏捷项目经理可以与团队一起写项目章程，也可以作为草编供人们编辑和批准。 Shane和我建议人们聚在一起一起写。 如果人们亲自聚会，我们会喜欢它。 我们知道这种情况很少发生。 （明智的一分钱，愚蠢的一句话。）因此，我们教人们如何在空间划分时编写项目章程。

因为在没有项目章程之前，筒仓团队没有组织原则。 法国的开发人员，白俄罗斯的测试人员，旧金山的产品经理和项目经理，他们都需要一些凝聚力。 包含项目愿景的章程提供了这一点。 迭代提供了项目心跳。

因此，这就是为什么我不认为地理分布式团队的敏捷生命周期（第1部分是Scrum）的原因。 很近，但是没有雪茄。 我非常尊重Ken和Jeff的工作，因此在不工作时就称其为Scrum。

既然我大部分都从寒冷中恢复过来，那么我可以继续进行有关生命周期的系列文章。

参考： 管理产品开发博客中来自JCG合作伙伴 Johanna Rothman的为何敏捷 项目经理不是Scrum Master 。

翻译自: https://www.javacodegeeks.com/2012/06/why-agile-project-manager-is-not-scrum.html

scrum敏捷项目管理