我正在修改软件工程考试，其中一个问题让我想知道 . 它显示了一个燃尽图表，该团队在10天的用户故事中没有取得任何进展 . 问题是“概述和证明ScrumMaster在此时可能考虑采取的任何行动” .
我已经考虑过激烈的行动，比如停止冲刺 . 然后是分配结对编程来帮助用户并考虑更多地分解用户故事 . 有人还有其他建议吗？ （这个问题在过去的论文中值得四分） .
我个人讨厌像这样的抽象问题 - 因为你不知道缺乏进展的根本原因是什么？如果你是团队的scrum主人，这些都是你已经知道的 . 十天后你永远不应该只是看着燃尽图，然后找出要做的事情 .
例如：
也许团队的任务是在项目环境之外执行“紧急”任务
也许有些故事已经部分完成但由于瓶颈而没有完成（例如故事没有完成，因为没有可用的测试人员，或设计师或最终签字的PO）
也许故事太大而且花费的时间太长 - 或者说故事结果非常复杂，并且暴露了系统的一个区域，这是一个很大的漏洞，很难调整
真正的答案取决于实际的工作环境 . 如果我被迫给出答案，那就像是：
写一个提醒，弄清楚为什么我会犯规，并且只知道在问题发生十天后有一个问题需要解决 .
写一个提醒，让这个主题在sprint回顾中引起 - 因为一些不好的东西显然正在发生
弄清楚瓶颈/问题是什么，并尝试解决它 . 如果我们有一个非常擅长自我导向问题解决的团队，我可能会建议转换到一个工作模式，每个人都聚集在一个故事上，这样我们至少可以完成一些事情 .
......但真正的答案是“它取决于”;-)
没有足够的信息来提供完整的答案，但根据我的经验，我作为Scrum Master做的第一件事就是查看随时间推移绘制任务小时数的燃尽图（而不是故事点随时间变化） .
看到几小时被正确烧毁但故事点保持静止是很常见的 . 通常被称为“迷你瀑布”，因为团队正在离开测试直到Sprint结束，因此在Sprint结束之前不会有任何故事“完成” .
如果我对场景的猜测是正确的，那么，作为Scrum Master，我会花时间在Sprint Retrospective上阐述为什么团队以这种方式工作，以便让他们集中精力让故事尽快“完成” . 可能并减少WIP .
根本原因分析为什么会发生这种情况？这是技能差距吗？关于这个主题的知识，作为一个团队，他们知道如何处理这些用户故事，他们是否在sprint计划会话期间将用户故事分解为任务，PO协作是否足够参与整个过程？
需要一个良好的sprint计划，以及随后的产品backlog修饰会话，如果这些已经发生，他们可以避免这些问题 .
如果他们是技术环境/领域等新手，团队可以采用各种技术，故事或追踪子弹的高峰可能会让他们达到舒适的水平？
最后允许他们作为一个团队失败，并在sprint回顾期间接受 .
这是一个scrum master可以有效的地方，一个好的scrum master会采取日常障碍日志并积极主动地不允许这种情况发生 .
这是我的两分钱 . 希望对您的考试有所帮助！
3 回答
我个人讨厌像这样的抽象问题 - 因为你不知道缺乏进展的根本原因是什么？如果你是团队的scrum主人，这些都是你已经知道的 . 十天后你永远不应该只是看着燃尽图，然后找出要做的事情 .
例如：
也许团队的任务是在项目环境之外执行“紧急”任务
也许有些故事已经部分完成但由于瓶颈而没有完成（例如故事没有完成，因为没有可用的测试人员，或设计师或最终签字的PO）
也许故事太大而且花费的时间太长 - 或者说故事结果非常复杂，并且暴露了系统的一个区域，这是一个很大的漏洞，很难调整
真正的答案取决于实际的工作环境 . 如果我被迫给出答案，那就像是：
写一个提醒，弄清楚为什么我会犯规，并且只知道在问题发生十天后有一个问题需要解决 .
写一个提醒，让这个主题在sprint回顾中引起 - 因为一些不好的东西显然正在发生
弄清楚瓶颈/问题是什么，并尝试解决它 . 如果我们有一个非常擅长自我导向问题解决的团队，我可能会建议转换到一个工作模式，每个人都聚集在一个故事上，这样我们至少可以完成一些事情 .
......但真正的答案是“它取决于”;-)
没有足够的信息来提供完整的答案，但根据我的经验，我作为Scrum Master做的第一件事就是查看随时间推移绘制任务小时数的燃尽图（而不是故事点随时间变化） .
看到几小时被正确烧毁但故事点保持静止是很常见的 . 通常被称为“迷你瀑布”，因为团队正在离开测试直到Sprint结束，因此在Sprint结束之前不会有任何故事“完成” .
如果我对场景的猜测是正确的，那么，作为Scrum Master，我会花时间在Sprint Retrospective上阐述为什么团队以这种方式工作，以便让他们集中精力让故事尽快“完成” . 可能并减少WIP .
根本原因分析为什么会发生这种情况？这是技能差距吗？关于这个主题的知识，作为一个团队，他们知道如何处理这些用户故事，他们是否在sprint计划会话期间将用户故事分解为任务，PO协作是否足够参与整个过程？
需要一个良好的sprint计划，以及随后的产品backlog修饰会话，如果这些已经发生，他们可以避免这些问题 .
如果他们是技术环境/领域等新手，团队可以采用各种技术，故事或追踪子弹的高峰可能会让他们达到舒适的水平？
最后允许他们作为一个团队失败，并在sprint回顾期间接受 .
这是一个scrum master可以有效的地方，一个好的scrum master会采取日常障碍日志并积极主动地不允许这种情况发生 .
这是我的两分钱 . 希望对您的考试有所帮助！