Scrum中的反馈循环

最新推荐文章于 2020-11-10 23:37:35 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2020-11-10 23:37:35 发布

阅读量334

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89116550

版权

在敏捷软件开发中，反馈扮演了重要的角色。很多人都知道反馈如何支持需求变更处理，以及利用回顾调整团队的工作方式。但在敏捷中，反馈的作用还不仅如此。Kris Philippaerts说：“在Scrum中，有效的反馈循环不仅仅是使用Sprint和做回顾会议而已”。

在2014比荷卢经济联盟（即比利时、荷兰及卢森堡）极限编程日大会（Days Benelux 2014 conference）上，Kris 提出了多层次反馈循环。InfoQ采访了他，讨论了Scrum中的反馈循环、进行完整PDCA循环的重要性、处理业务需求的反馈部署以及团队从回顾中获取反馈的好处。

InfoQ：您可否解释一下你所理解的Scrum中的反馈循环是什么意思？

\
Kris： Scrum中的反馈循环，或任何其他的实证过程，都是一种处理数量有限的工作或信息的短期循环。在每一个循环的最后，我们会停止工作、允许我们检查自己的工作并且在下一个循环中改进我们的流程。典型的反馈循环的一个例子就是戴明（Deming）质量环：计划-执行-检查-处理（PDCA）。
\

InfoQ：是什么让这些循环变得如此重要？

\
Kris：反馈循环是实证过程的核心。实证过程反对遵守已定义过程的做法，它的前提在于：在复杂的项目中，例如一个IT项目，需要根据我们每日所做的新的知识不断地适应。复杂的项目是非常难以预测的，因此需要一个流程来拥抱这种不可预测性。
\\
反馈回路给你提供一种方式来实现实证过程。
\

InfoQ：您提到过，做完整的PDCA循环很重要，即从计划到处理（P 到A）。您觉得人们很难做完整的循环的原因是什么，并且表现在哪里？

\
Kris：尽管很多人都理解反馈回路的概念，但是他们并不总是完善地考虑了执行的方式。例如，在Scrum中，我们看到的很显然的一个反馈循环是：Sprint规划会议，Sprint，Sprint评审会议和Sprint回顾会议，他们分别是计划-执行-检查-处理（PDCA）各自过程的化身。但在现实中，这个反馈循环未必完整地覆盖了所有内容。在功能和技术需求层面，你可能侥幸应用了这个循环。但是产品的愿景呢？长期的规划呢？团队的动力呢？在 Scrum中，这些方面通常只覆盖了一半，并且并没有提供现成的、完美的反馈。
\

InfoQ：在Scrum中，您认为有哪些反馈回路？

\
Kris：反馈环路的数量是特定于每个上下文的。对于Scrum的项目，我定义了5个常见的反馈循环：
\\
长期愿景\\
业务需求\\
技术实现\\
长期规划及预算\\
团队动力\

你可能会添加更多的循环，但反思这五个循环可能是一个很好的开始！所有的这些循环都需要包括PDCA所有的4个步骤。问一问你自己这些问题：什么时候开始真正地计划特定工作类型的工作？什么时候执行这些工作，什么时候进行反思以及什么时候花时间做改进？
\

InfoQ：您提到的一个反馈回路是“业务需求”，您可否详细阐述一下这个回路？

\
Kris：业务需求循环是在Scrum中定义最好的一个循环。在Sprint规划会议中，我们规划我们想要实现（计划）的需求，并且在Sprint中，我们实现他们（执行）。在Sprint最后，我们在Sprint评审时（检查）把我们的成果展示给业务人员，以及在回顾会议上，我们制定改进措施项，然后在Sprint规划会议上再次选择这些改进项（处理）。在Scrum中，这个回路是闭合而且非常稳固的。而其他的回路则不是。
\

InfoQ：在技术实现与团队动力环路方面，回顾扮演了重要的角色。您可否解释一下他们是怎样使用的，并且团队从回顾中可以获得哪些好处？

\
Kris：我们看到Scrum中的回顾用来改进团队动力、技术标准和一些功能性主题。这意味着回顾作为检查阶段，（至少）可以用于三个不同的反馈循环。一方面，回顾显示了强大的力量和重要性：这里要说的太多了！另一方面，这也是致命弱点。很多回顾都失败了，是因为团队想要讨论的话题太多（技术问题、团队动力、功能性主题…），并且把他们全都混在一起。你需要一名强有力的引导者，保持团队关注在数量有限的问题上。
\\
回顾的结果也应该引入正确的后续（计划）步骤：技术改进应该在下一个规划会议中进行，功能改进也许需要在某种细化（refinement）会议上进行，以及团队动能问题可能需要一个周期性的团队建设，这些并不是标准Scrum的一部分。
\

InfoQ:如果大家想了解更多有关反馈循环的内容，您可否给一些建议呢？