Bruce有话说
敏捷提倡持续改进，Scrum的三大支柱：透明，检视，调整，更是把改进融入到了每一次Sprint，甚至每一天当中。敏捷提倡的改进可以是任何一个方面，可以是很小的一步，不贪求很多，需要的是能够持续的做改进。正如一股老话说的：不积跬步无以至千里。
今天我们就来一起读一下Scrum Patterns中的这一个模式。看看关注改进节奏都要关心哪些要点。总结几个能在本文中得到答案的，希望对小伙伴们阅读本文有帮助：
- 改进内容会有遗忘，但是持续改进仍能够保持改进的总体趋势。
- 改进需要刻意练习。
- 改进是设定长期的，还是短期的例如单个sprint中的目标？
- 改进速率和价值哪个是我们最终追求的呢？
正文
开发团队已经通过可靠的速率级别(参见关于速度的注释)、质量或其他度量显示了可持续性的绩效能力，现在想要进入下一个级别。团队对能力和质量的衡量是透明的，团队希望他们保持这样的透明，以改进他们为荣。团队正在一步一步地进行改善和引入改进.
✥ ✥ ✥
因为建立一个统计上合理的基线需要时间，很难显示每分钟、每小时、甚至从Sprint到Sprint的进步。 此外，sprint通常是最流行的开发团队有效性度量的粒度，特别是速度度量。对于其他崇高的理想也是如此，例如，产品价值、每个评估点的价值、产品质量或团队激情(参见幸福度量模式)。
最后，scrum就像丰田生产系统一样，从根本上来说只有两件事:改善思想和人。改进是重要的，“持续改进”这句话经常从专家的嘴里冒出来。然而，真正持续的改进存在一个矛盾的问题。能够衡量一个改进是很重要的，至少要知道一个给定的变化是使事情变得更好还是更糟。我们总是相对于一些基线来度量改进，我们在任何时间点采取的任何单个过程度量都受到过程变幻莫测的变化影响。这意味着我们需要一个统计基线作为改进的参考。
更重要的是，流程改进有一个至关重要的人的方面:作为一个群体，人们需要时间来吸收变化。持续意识到需要改进是可以的，但你不能持续专注于改进每件事。内化改进的发展方法和采用新技术需要时间。最终，良好的成果是习惯性实践的结果，而习惯的形成本身需要时间。因此，在Daily Scrum中，开发团队成员更多的是针对Sprint目标进行战术调整，而不是专注于改变长期实践、习惯或行为。
如果速率(或其他度量)变化很大，你将永远无法度量改善程序所带来的好处或损害。如果你同时进行多个改进，你无法知道哪些改变对速率或价值、缺陷减少或任何其他值的度量有贡献。
因此:
用过程改进探针来控制速率峰值的交替周期。 我们可能用”频繁的改进”来代替”持续改进”。首先建立一个速度基线，并将其纳入统计控制(速度的经验法则是将其方差减少到20%以内)。然后在产品开发中引入一个新的改进。正如Jon Jagger在[1]第44-45页所描述的那样，开发人员——或者，如果合适的话，产品负责人或scrummaster——致力于有意实践。通过孜孜不倦的重复来练习改进，使之成为习以为常的事情。
From Takeuchi et al., [2], p. 84.
当Scrum团队成员一起引入变更并评估他们长期改进的潜力时，不断的反思是很重要的。有些变化具有不可预见的阻碍，当然，团队应该马上反转一些实践应用后的决定，这些实践的经验证明对速度或长期价值是有害的。
✥ ✥ ✥
在Scrum中，Sprint是战略改善的主要工具。当速度在刻意练习的帮助下稳定下来时，团队既可以享受后续的可预测的Sprint交付，也可以为另一个提高速度的改善做准备。当团队通过改进过程和团队动态，或通过改进产品攀登到一个新的水平时，将会出现动荡。回顾和Sprint评审会都为评估团队在一个新的平台上的收敛提供了机会;然而，这种评估需要在几个连续的审查中进行，以增加对结果稳定性的信心(即，确保它们不是暂时的)。虽然每日Scrum可以影响变化，但回顾和Sprint评审会影响转变——战略变化是持久的变化。对于一个不连续的变化来说，它既不充分，也没有必要将其定性为战略变化。
我们可以讨论两种速度改善方法:一种是减少速率变化的因素，另一种是增加速率的因素。同样的原则适用于任何度量价值的指标。许多改善方法更适合将过程纳入统计控制，而不是提高性能或价值。当Scrum团队试图减少速度上的差异时，这些改善不仅是适当的，而且是重要的。导致速率变化的一些最常见的原因包括缺乏跨职能团队、管理对生产的干扰，以及糟糕的需求。缓解这些问题的改善可以帮助团队建立良好的基线。
复杂的系统充满了惊喜。改变很少是有益的，当现实发生时，最好的改变往往会产生消极的后果。努力测量变更的价值(价值、速度、一致性、缺陷密度)，如果变更实际上使事情变得更糟，就要准备缩减。超越单一维度的度量:您的努力可能会提高速度而降低价值(例如ROI;如果你只衡量速度，你将永远不会注意到整体价值的下降。因此，皮亚杰的学习提供了一个随着时间单调增长的模型，从更高的平台进入下一个层次，而Keegan([3])的学习模型更现实，并认识到学习是一个充满挫折的复杂过程。重申一下:Scrum团队应该在整个改进周期中持续监控ROI和其他价值，因为速度本身并不是价值增加的指标。重要的是要记住，速度是预测的工具，而不是价值的度量工具，而价值是最终目标。
模式“更新速率”是关于简历新速率基线的模式。
与Scrumming the Scrum形成对比。
在模式理论中，这更像是一个“元模式”而不是一个合适的模式。它调节了团队使用基本过程的方式(进行局部更改、审查、反映;或计划-做-检查-行动(PDCA)或计划-做-学习-行动(PDSA)循环，整个增量模式实践都基于此。这种模式通过引入统计变异，将组织变革的结构改进与进步的时间维度结合起来。它为PDCA的“检查”部分增加了一个统计控制维度，这很容易被认为是对系统状态的静态分析。这更符合戴明对PDSA术语的更新，它要求智力投入学习，而不仅仅是遵守检查的形式。
改进流程的团队很可能也会改进产品，并且与持续的产品进步相结合，Kaizen Pulse是产品荣誉感的主要贡献者，并帮助团队实现长期的最大价值。
有关改善脉冲需要在更激进方法中做选择,结构化改进(有时称为kaikaku)和随后的在这些变化上的精化,他通常意味着更多的自然的增量改变(术语改善(カイゼン)被调用以微弱优势超过其通常日本使用和意义(改善))。参见Kaizen和Kaikaku。
The basic pattern comes from [2].
[1] Jon Jagger. “Do Lots of Deliberate Practice.” In Kevlin Henney, ed. 97 Things Every Programmer Should Know, Sebastopol, California: O’Reilly, 2010, pp. 44–45.
[2] Hirotaka Takeuchi, et al. Extreme Toyota: Radical Contradictions That Drive Success at the World’s Best Manufacturer. Chichester, UK: Wiley, 2008, Chapter 4, p. 84.
[3] Gerard Keegan. Higher Psychology: Approaches and Methods, 2d. edition. Glasgow, Scotland: Hodder Gibson, 2009.
Picture credits: Scrum Patterns Group (Esther Vervloed).
