避免稳定sprint的12个实际步骤
BY ERIC ISOM 沈义 · 沈潇灵 译 这一切都与质量有关。只有在产品不符合你的质量要求时才需要稳定sprint。 这些是你可以作为项目经理或Scrum主管采取的实际步骤。 其不要求你启动公司范围内自上而下的计划。你可以一次按照这些步骤操作，并查看每个步骤的改进情况。然后其他人会看到你的结果，并问你是如何做到的。 辨认出问题 你创造的质量很差，不得不重做。这就像一个糟糕的制造过程。你构建了一些东西，检查，发现它不符合要求，并重新设计它以满足要求，或者抛弃它。你编写代码，发现它不稳定，现在你正在用稳定sprint重新编写代码。 我们多年前在制造业中吸取了这一教训。不幸的是，我们必须以艰难的方式学习它。戴明和其他质量领导者教授了这些原则。日本人听取了他们的意见，并将他们的制造业变成了世界上最好的。多年之后，我们其他人才会注意到并开始倾听。 现在它在软件开发中再次发生。我们认为稳定sprint（返工）是必要的。我们过分依赖测试（检查）。 我们说，软件是不同的，错误也是不可避免的。无论如何，技术债务都会增长。而且，可以预期稳定sprint。这就像美国的制造行业多年前的借口：缺陷，库存，延迟以及返工是无法避免的。 能不能听到20世纪制造行业的回音？ 我们不会问自己我们在编写代码的方式上需要改变什么。很难想象以任何其他方法。 当有人出现并开始向我们展示道路时，我们就会忽视他们。他们提出的建议太具有破坏性，成本太高，只是行不通。我们公司/行业不同。似曾相识。几十年来，人们同样忽略了戴明。 时间已经到了将我们在其他行业中学到的关于质量的艰苦教训应用到优质软件的开发中。 不要让系统不稳定 首先，即使是持怀疑态度的人也不得不承认你不必让生产系统变得不稳定。你有一个选择。 即使你的测试（检查）在发布之前没有发现稳定性问题，你应该在发现稳定性问题时立即回滚。 这个简单的建议引发了一场经典的辩论。 一方面，不成熟的组织认为修复损坏的系统是可行的（有时甚至是不可避免的）。它们允许生产系统在他们争抢和修补时被打破。 他们匆忙并认为最好尽可能快地修复它，而不是花时间回滚。他们觉得承认必须回滚太尴尬了。 另一方面，成熟的组织优先考虑客户服务和系统的稳定性。他们知道，即使需要等待更长时间才能获得这些新功能，客户也可以通过系统运行得到更好的服务。这是事件管理，你的首要任务是尽快让系统再次运行。 如果你的版本破坏了系统，最好要回滚到之前的版本。不要试图将其在现状中固定。并且不要只是忍受它直到下一个版本。你需要训练自己不要容忍不稳定系统的发布。 在接下来的步骤中，你将需要这个规则，使你达到一定的质量水平，以避免稳定sprint。 找到根本原因 回滚后，你自然会专注于查找和修复即时问题，以便可以重新发布。是的，这是返工。 但我们一步一步迈出这一步。如果你遇到稳定性问题，你必须首先扑灭火灾。 找到并解决问题，然后重新发布系统。 现在是重要的部分。从长远来看，要想拥有一个更稳定的系统，并在将来避免这些问题，你就不能止步于此。如果你这样做，他们会堆积起来直到你确实需要稳定sprint。 现在，你必须找到并解决问题的根本原因。允许编写，测试和发布此不稳定代码而没发现潜在问题的来源是什么呢？...
