-1

我正在修改软件工程考试，其中一个问题让我想知道。它显示了一个燃尽图，其中团队在 10 天内没有在用户故事上取得任何进展。问题是“概述并证明 ScrumMaster 此时可能考虑采取的任何行动”。

我想过采取激烈的行动，比如停止冲刺。然后是分配结对编程来帮助用户，并考虑更多地分解用户故事。有人有其他建议吗？（这个问题在过去的论文中值四分）。

4

3 回答 3

2

没有足够的信息来给出完整的答案，但根据我的经验，作为 Scrum Master，我要做的第一件事就是查看燃尽图，该图表绘制了随时间变化的任务时间（而不是随时间变化的故事点）。

正常烧毁小时数但故事点数保持不变的情况很常见。通常被称为“迷你瀑布”，因为团队要在 Sprint 结束之前进行测试，因此直到 Sprint 结束之前都没有“完成”任何故事。

如果我对场景的猜测是正确的，那么作为 Scrum Master，我会花时间在 Sprint Retrospective 上讨论团队为何以这种方式工作，以期让他们集中精力尽快“完成”故事可能并减少在制品。

于 2013-01-09T08:52:31.657 回答
2

我个人讨厌这样的抽象问题——因为你实际上没有足够的信息来给出一个“好的”答案。冲刺多长时间？团队一直在做什么？缺乏进展的根本原因是什么？如果你是团队的 Scrum Master，这些都是你已经知道的事情。你永远不应该只是在十天后查看燃尽图，然后弄清楚该做什么。

例如：

  • 也许团队的任务是在项目范围之外执行“紧急”任务

  • 也许有部分完成但由于瓶颈而未完成的故事（例如，故事没有完成，因为没有可用的测试人员，或设计师，或用于最终签字的 PO）

  • 也许故事太大并且花费了太长时间 - 或者故事变得异常复杂并且暴露了系统的一个区域，该区域是一个大泥球并且难以调整

真正的答案将取决于实际的工作环境。如果我被迫给出答案，那将是这样的：

  1. 写一个提醒，找出我犯错的原因，直到问题发生十天后才发现有一个问题需要解决。

  2. 写一个提醒，在 sprint 回顾中提出这个话题——因为显然有不好的事情正在发生

  3. 找出瓶颈/问题是什么，并尝试解决它。如果我们有一个非常擅长自主解决问题的团队，我可能会建议切换到每个人都集中在一个故事上的工作模式，这样我们至少可以完成一些事情。

...但真正的答案是“这取决于”;-)

于 2013-01-09T21:16:23.763 回答
1

为什么会发生这种情况的根本原因分析？是技能差距吗？关于该主题的知识，作为一个团队，他们是否知道如何处理这些用户故事，他们是否在 sprint 计划会议期间将用户故事分解为任务，PO 在整个过程中的协作是否足够参与？

需要一个良好的冲刺计划，以及随后的产品待办事项梳理会议，如果这些已经发生，他们可以避免这些问题。

此外，如果团队对技术环境/领域等不熟悉，他们可以采用各种技术，也许是故事的尖峰或跟踪子弹让他们达到舒适水平？

最后让他们作为一个团队失败，并在 sprint 回顾中重新振作起来。

这就是 scrum master 可以发挥作用的地方，一个好的 scrum master 会记录每日的障碍日志并积极主动地不允许这种情况发生。

这是我的两分钱。希望对你的考试有帮助！

于 2013-01-09T19:48:39.150 回答