持续 Scrum——一种更有效的敏捷工作方式

原文：https://medium.com/hackernoon/continuous-scrum-1784ba46fbe5

Scrum 是一个非常棒的主意。它吸收了敏捷的思想，并将它们放入一个易于应用的包中。当正确使用时，它改善了团队内部的交流，它将允许你相当容易地迭代开发，并将继续改进你的过程。

然而，它也不是没有缺点。让我们看一看。

短跑会降低生产率

至少在某种意义上。当你来自一个未经打磨的牛仔风格的开发时，它肯定会增加生产力，尽管大部分的收益来自于提高你的团队的关注度。然而，当你的团队已经在以一种训练有素的方式做正确的事情时，sprint 接近尾声的那几天会比其他时候效率低得多。

这是为什么呢？我观察了几个原因。

开始下一件事的时间太少了。如果你提前完成了当前 sprint 的所有任务，还剩下一些时间，那么等待下一次 sprint 的诱惑会很大。遵循常规过程比试图更早开始要容易得多。短跑之间的周末被视为真正的休息时间，从周五到周一没有工作，这使得情况变得更糟。这是一件令人欣慰的事情。
没有动力去做超出预期的事情。诚然，Scrum 大师的工作是避免这种情况，但这可能非常困难。通常很难区分人们是不能做更多还是只是不想做。
不管我们愿不愿意，你的团队经常被评判为有能力交付他们承诺的东西。做更多事情的动机有限。

持续的短跑训练限制了创造力和创新

一个良好的 Scrum 过程是可重复和可预测的。所有预测要发生的事情都会发生，如果没有发生，异常会被及时正确地传达。如果你做到了这一点，你做得很好。然而，你应该意识到你也扼杀了(或者至少大大降低了)随机创新的潜力。这就是过程所做的；你必须考虑承诺，征得产品负责人的同意，并基本上跳过一些缓慢但肯定会让你失去所有动力的铁环，一次一个。

通常这种权衡是值得的，如果你得到的是专注和可预测性。然而，如果你的生意偶尔依赖于团队中某个人的真知灼见，你可能会有麻烦。对此有一些解决方案，比如 spikes ，但这又是试图形式化一些难以形式化的东西。

那么我们该怎么办呢？

这个问题问得好。你想让你的团队有创造性思考的自由，你想在不失去焦点的情况下最大化生产力。坏消息是这不可能完全实现。然而，我觉得问题主要是由围绕 sprints 构建所有开发工作引起的。虽然迭代对于任何像样的软件过程来说都是必不可少的，但是与整个团队一起迭代就有点麻烦了。

替代方案:持续的 Scrum

所以我的想法是持续的 Scrum。与纯粹的 Scrum 相比，唯一的变化是它去除了冲刺计划。当你完成一项任务时，你开始下一项，就这样。你每天都做倒立，每隔一周就有一次回顾会，你做所有其他你通常会做的事情，但是你不再计划冲刺了。如果你熟悉看板，我认为持续 Scrum 是看板和 Scrum 的混合。

优势应该很明显。工作压力现在是平均分布的，因为没有“冲刺结束”的时刻，所以生产率应该是相等的。此外，因为不需要和团队的其他成员一起开始和结束工作，所以以特别的方式为个人定制任务有更大的灵活性，这样创造力应该会受益。

听起来很棒！你试过吗？

很遗憾，还没有。我们还没有在我的公司尝试的原因是它确实有它的缺点。有趣的是，它们都与纪律有关。

首先是送货。通过冲刺，你被迫在两周后完成并交付你的工作。在持续的 Scrum 过程中，没有这样的点。但是你当然应该迭代地保持交付。然而，这可以通过使用敏捷发布系列的概念来缓解，但是你的工程师仍然应该尽可能经常地交付。

此外，从 backlog 中获取任务的步骤现在突然被分配了。如果每个人都跳过困难的任务，这会导致饥饿。在 sprint 计划期间，同行的压力(以及来自产品负责人的压力)减轻了这一点，但是持续的 Scrum 没有这样的激励。一个可能的解决方案是设立一个负责分发任务的中心联系人，但这似乎并不理想。另一个想法是每周进行一次计划会议，只有那些接近任务尾声的人会参与评估并承担新的任务。但是我还没有解决这个问题。

最后，你分配更多的所有权。在常规团队中，让团队而不是个人拥有工作已经是一个很难解决的问题。这让事情变得更糟。没有一个时刻，所有人都坐在一起，作为一个群体，决定在未来几周内要完成哪些任务。但是你确实希望团队作为一个团体拥有这种所有权，至少可以促进合作。如果你已经在常规的 Scrum 过程中为这个问题而挣扎，你可能不应该为持续的 Scrum 而烦恼。

然而，如果你有一个纪律严明、承担团队责任、渴望更有生产力和创造力的团队，这可能就是你的入场券。