Scrum的闭环反馈控制

Scrum是管理复杂挑战的简单框架 。 软件交付是一个复杂的挑战。 软件交付包含许多复杂的活动，以在复杂的环境下创建和开发复杂的产品。 Scrum通过实施适合其复杂性的唯一过程类型，即经验性过程控制 ，来拥抱并强调软件交付的复杂性。

复杂

影响交付软件的因素很多。 需求，技能，经验，人员，团队，技术，集成，市场状况，公司战略，预算，法规和相关性，仅举几例。 尽管所有已知变量都必须考虑对工作的影响，但并非所有已知变量都由工作人员控制。 对于某些已知变量，需要太多细节才能完全理解它们。 即使变量是已知的，它的行为（现在或将来）也可能是未知的，或与预期的不同。

产品是由具有认知能力的人创造的。 人不是机器人，也不是可替换的机器。 结果很难用精确和详细的方式描述。 在工作之前，开始或什至随着工作的进行。 创建的每个产品都是唯一的，只有在发布时才能确立赞赏的地位。 所进行的活动无法高度精确地预测到。 之前从未以相同的方式在相同的条件下执行过多次。 环境在不断发展。 而且，最烦人的是，并非所有变量都是已知的。 存在高度的不可预测性。

挑战的活力程度要求有适当的流程才能进行控制：

开环系统

开环系统设计用于执行一系列优先步骤，以在一次运行中产生确定的结果。 这样的系统假设影响过程的变量以及过程活动本身具有近乎完美的可预测性。

对于更大的问题，通常创建一系列开环子系统。 子系统的输出是下一个子系统的输入。 尽管从理论上讲，风险应限于较小的子系统，但实际上，整个系统的脆弱性呈指数增长。 在动荡和变化的情况下，偏差和方差会在各个子系统之间累积，例如在时间和质量上。 累积的问题仅在最终子系统的末尾浮出水面并不少见。

预测性计划和各个职能部门之间的工作交接是开环思维的实现。 预测计划只能包括已知变量，已知细节和预期行为，从而造成不存在未知数的错觉。 开环思维要求对计划的所有要素进行漫长的前期考虑，并最终尝试预见不可预见的因素。

开环系统是设计使然的，无法应对软件交付等复杂挑战中常见的中断和未知数。

闭环系统

闭环系统经常会进行检查，因此可以进行调整。 及时将系统的实际结果与所需结果进行比较。 愿望可能会改变。 差异或不希望的结果将在下一次或以后的运行中消除或纠正。 由于该过程是自校正的，因此并非所有的变量和参数都需要精确而详细地知道。 该系统要求并创建透明度。 检查并暴露了现实，以便进行适当的调整。 进行检查的人员已经制定了明确且商定的标准，以进行检查和调整。 出于报告和状态目的进行检查是没有意义的。 没有适应的检查是没有意义的。

Scrum的闭环反馈控制

Scrum通过实施经验性过程控制来拥抱并强调软件交付的复杂性。 Scrum用闭环反馈代替了传统的，相门，分级或类似过程的开环。 Scrum定义了定期检查和适应的机会。 Scrum使玩家能够停止传统的老鼠赛跑。 玩家可以停止，反思，从检查中学习，收集关于输出的反馈并更改路线，重新组织，更新优先级，改进，调整。 Scrum将现实带回了游戏。 Scrum带来了透明度。 当一切进展顺利时，这是令人愉快的。 当一切都没有如期进行时，这至关重要。 它允许重新定位和校正。

在Scrum中，所有工作都在Sprint中进行组织。 冲刺具有时间限制，以确保及时检查和调整。 Sprint形成了长达数周的“检查和适应”周期，其中包含了每日Scrum的24小时“检查和适应”周期：

• 在每日Scrum中 ，进行工作的人员检查他们的进度，并在Sprint的容器中确定下一步要做的最重要的工作。 他们使用Sprint Backlog，Sprint目标和进度可视化在Sprint中进行自组织。 日常节奏确保他们在超过24小时内不会失去同步。
• Sprint是一个周期，从识别和内化在Product Backlog上实例化的最重要的想法开始。 Sprint会检查实际发布或可能发布的产品增量，以及产品的构建方式，过程，交互作用以及所使用的技术。 与所有检查一样，它们是前瞻性的。 它们用于适应的目的。

Scrum的所有事件都为检查和适应过程设定了频率，其中工件包含要检查和适应的信息。 Scrum描述了执行检查和修改所需的责任。

在Sprints中组织工作使人们可以喘口气，与传统的老鼠赛跑决裂，并以可持续的速度工作。 引入了明确的反思时刻，这对于人类在诸如软件交付之类的高度复杂的认知，创造性工作中蓬勃发展至关重要。 在Sprint中，例如通过商定的工作和开发标准，会创建其他反馈循环。

注意 ：以上文字摘自我的书“ Scrum –袖珍指南（智能旅行伴侣） ”。 如果您有更多时间花费，请考虑阅读。

翻译自: https://www.javacodegeeks.com/2017/10/closed-loop-feedback-control-scrum.html