【发布时间】：2008-10-03 19:49:47
【问题描述】：
如今，Scrum 是相当流行的 dev.process，并且经常项目经理突然获得新头衔（Scrum Master）。然而，它不应该只是一个新的标题，而是新的习惯和新的范式。你的 Scrum master 的坏习惯是什么？
【问题讨论】：
【发布时间】：2008-10-03 19:49:47
【问题描述】：
不让 Scrums 保持正轨 - 让他们陷入技术讨论和更长的会议。
【讨论】：
我们的 Scrum Master 最初的一个大坏习惯是认为我们会解决自己的障碍。这是 Scrum Master 应该做的事情之一，但她把它留给了我们，直到它变得无法管理。
我们处理的另一件事是 Scrum Master 认为他们负责骑在开发人员的背上，直到任务得到处理。这会给团队造成不好的气氛，因为他们应该是自我管理的。
对我和我们的团队而言，Scrum Master 的工作是成为团队的盾牌和助手，阻止障碍并尽其所能帮助加快进度。 Ken Schwaber 的Agile Software Development with Scrum 是对 Scrum 的极好介绍，我们的团队使用它，并且在这方面取得了相当大的成功。还有Agile Project Management with Scrum，更适合 Scrum Master 和 Product Owner 角色。
【讨论】：
- 微观管理
- 行使旧式指挥和控制，而不是促进自我指导的团队
- 更多地关注数字/燃尽/积压，而不是组成团队的人
- 没有保护团队免受外界干扰
【讨论】：
分配工作并要求提供每日状态报告，而不是让团队学习如何管理自己的工作。
【讨论】：
- 用超活跃的方式管理团队
- 因为“Scrum 说”和“团队必须投票”而在技术决策上压倒高级开发人员。完全削弱了高级技术人员的能力。
- 试图在实际上不是问题的回顾会上从石头上榨取血液。
- 告诉我分数无关紧要，但在每次审查时，都会对分数进行剖析，每 2 周在审查时分析一次。此外，我们的年度奖金基于我们的积分表现。
Scrum 很好，但它可以无视多年来像魅力一样发挥作用的良好工程实践和技术流程。
【讨论】：
不断在 Sprint 内外交换新的错误。
【讨论】：
Scrum Master 有两种：
- 因采用敏捷而改名的项目经理。
- 独家 Scrum 主管，只负责促进 Scrum 并向项目经理 (shusa) 汇报。
第二点在“真正的”敏捷组织中得到宣扬和实践。它很贵，但有一些优点。
还有，
- 预计 Scrum Master 将始终与 Sprint 团队在一起（不是字面意思）。如果项目经理这样做，他/她将是微观管理。
- Scrum 主管的角色不是管理预算，而是在团队可以完成的工作量方面为 Sprint 团队提供可预测性。
- Scrum 主管应该了解团队成员的优势和劣势，并促进 Scrum 间的最佳实践分享。
所以，我的意思是，如果这些角色混淆了，团队可能不会做得很好。
【讨论】：
对流程的推回部分没有帮助，例如'这些都是客户在这个迭代中想要的所有商店，所以这就是我们必须做的'。
【讨论】：
不断尝试将实际工作时间与故事点估计值联系起来。
【讨论】：
当我参与 Scrum 时，Scrum 主管很快养成了让我们做自己的事情的习惯，而 Scrum 又回到了我们正常的开发程序中。
【讨论】：
-
不错的镜头。当 scrum 应用错误时，这听起来很常见。
-
听起来是个不错的 scrum master。
- 无法在周期内适当地分配任务（通常太多）
- 不能很好地与外部客户打交道（如果某项任务对于单个周期来说太大了，向团队抱怨而不是回击客户）
- 让每日 Scrums 成为一个过大的流程 - 不遵守特定的时间限制（我们更喜欢最多 15 分钟）。
【讨论】：
当前 PM 成为 Scrum Master 时，我真的不喜欢它认为 Scrum 是一种减少他们最初（个人）义务的方法，而无需将时间投入到团队合作和积极减压（计划挫折）上。他们只是躺下并开始称赞自己取得的出色成绩，而每个人都可以看到团队在没有他们在场的情况下会表现得更好。
在我看来，我们最好的 Scrum 大师都是具有强烈责任感的开发人员，或者是非 PM。
再说一次，我曾（在全世界都知道 Scrum 之前）为那些令人震惊的 PM 工作过。我敢肯定，他们今天会成为伟大的 Scrum 大师。
【讨论】：