从Scrum到看板接近“释放”

Question

我是一个大型软件项目的Scrum。我们目前正在运行Scrum。在完成我们的实施阶段之前，我们还剩下一个月的时间。

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

1. 我们有一个绝对的截止日期
2. 现在很难提前两周(或一周)计划，因为我们已经接近尾声了。议程、优先事项和尚未完成的任务几乎每天都在变化。我们每天都会发现一些我们必须记住的新任务，然后才能说我们的开发阶段是finished.
3. Kanban，让我更容易地确定哪些任务正在等待响应，哪些任务正在等待验证等等。

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

我们的冲刺并不完全是可运输的增量(我知道它们应该是，但这不是我想在这里讨论的)。

Answer 1

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

一方面：

• 看板非常巧妙地处理快速变化的任务优先级。在这样的环境中，经典的时间限制方法-- Scrum --不能很好地工作-- well.
• Introducing简单的看板系统不需要花费太多的精力。
• 看板本身并不是一种软件开发和/或项目管理的方法，应该放在某些东西的顶端。但是，您似乎已经有了这个“东西”，因为目前您已经组织了您的项目。

另一方面：

• 在你的工具箱中添加新工具总是会增加一些麻烦，而且，既然你已经到了项目的尾声，现在增加麻烦可能不是个好主意。
• 看板，和其他工具一样，只有在引入之前得到团队的认可，才会给你带来价值。我的意思是看板是无用的，除非它被团队regularly.
• If中的每一个人更新--你对你的工作很熟悉，即跟随Scrum，从其中的一部分辞职，即时间限制，可能会对团队的生产力产生负面影响。同时，要熟悉一种新方法需要一段时间，所以当您想要转换到其他方法时可能会有一个问题。

总之，我肯定会考虑看板这样的工作，因为它提供了相当好的可视性和高度的灵活性，在优先级一直在变化的情况下。然而，我不会说，在你的情况下，这是一个确定的决定。如果你从更长远的角度规划它，那么尝试看板将是一件轻而易举的事情。

就我个人而言，我可能无论如何都会试着把它当作一个实验。如果有效，你就继续做下去。如果没有，你会退回到你擅长的地方，最终在另一个项目中尝试看板，做更多的准备。