在“发布”附近从 Scrum 到看板 [关闭]

Question

我在一个大型软件项目中担任 Scrum Master。我们目前正在运行 Scrum。 在我们应该结束我们的实施阶段之前，我们还有大约一个月的时间处于开发阶段。

我在过去几周强烈考虑改用看板（或 GTD），原因是：

1. 我们有一个绝对的截止日期
2. 现在已经接近尾声，很难提前两周（或一周）进行计划。议程、优先事项和未完成的任务几乎每天都在变化。我们每天都会发现必须记住要完成的新任务，然后才能说我们的开发阶段已经完成。
3. 看板让我更容易识别哪些任务正在等待响应，哪些任务正在等待验证等。

有人有这方面的经验吗？这是个好主意吗？

我们的 sprint 并不完全是可交付的增量（我知道它们应该是，但这不是我想在这里讨论的）

Answer 1

尽管我可以被认为是看板的支持者，但在做出这样的举动之前我会三思而后行。

一方面：

• 看板非常巧妙地处理快速变化的任务优先级。对于经典的时间盒方法（此处：Scrum）不能很好地工作的环境，这是一个很好的答案。

• 引入简单的看板系统并不需要太多努力。

• 看板本身不是软件开发和/或项目管理的方法，应该放在首位。但是，您似乎已经有了这个“东西”，因为目前您的项目已经组织好了。

另一方面：

• 将新工具添加到您的工具箱总是会增加一些麻烦，而且由于您处于项目的最后，现在添加这些麻烦可能不是一个好主意。

• 看板与几乎任何其他工具一样，当且仅当您在引入它之前获得团队支持时才会为您带来价值。我的意思是看板是没有用的，除非团队中的每个人都定期更新它。

• 如果你对你所做的事情很熟悉，即遵循 Scrum，从其中的一部分辞职，即时间盒，可能会对团队的生产力产生负面影响。同时，您需要一段时间才能熟悉一种新方法，因此您可能会怀疑何时获得转换到其他方法的价值。

总而言之，我肯定会考虑将看板用于此类工作，因为在优先级一直在变化的情况下，它可以为您提供很好的可见性和高度的灵活性。但是，我不会说，就您而言，这是一个确定的决定。如果您从更长远的角度计划它，那么尝试看板将是不费吹灰之力。

就个人而言，我可能会尝试并将其视为实验。如果它有效，你就继续这样做。如果不这样做，您就退回到您擅长的领域，并最终在另一个项目中尝试看板，并进行更多准备。