| 2022-04-27
关于敏捷团队或 SCRUM 框架如何改进的理论并不缺乏，尤其是当它与实现「成功的迭代」相关时。有趣的是，这些文章中的大多数都没有关注「成功迭代」的定义。如果我们不知道我们要去哪里，是否有可能知道如何到达某个地方？
我没有做出假设或创建一个成功迭代的一般列表，而是关注我们定义成功的两种方式以及我们的两个关键要素。
因素#1：经常重温用户故事
彼得·德鲁克（Peter Drucker）将世界的注意力带到了这样一个事实，即所做的事情与所做的事情非常不同。作为工程师，我们通常关注精度和解决问题或满足要求的不同方法。然而，当我们开始与客户合作时，我们经常会立即注意到从未问过三个基本问题：
- 首先，为什么我们要做这件事？
- 用户是谁？
- 它如何满足价值主张？
我们在与 IT 组织合作时看到的最大问题是交付团队不会质疑「为什么」——他们希望把它做好。但是，我们发现交付团队自身拥有的业务视角越多，其假设/实施决策就越准确。
对价值的看法和理解会带来创造力和创新，因为它们提供了团队目标，就像地平线上的灯塔一样。目标用于指导团队找到解决方案，而不是如何规定。
所以，第一个关键因素就是：经常与产品负责人一起重温用户故事。
伟大的生活绘画艺术家非常了解这个概念。他们将大部分时间花在检查和重新发现他们的场景上，而不是专注于画图。艺术家这样做是因为他们明白大脑对图像的解释本质上是有缺陷的，因为一旦艺术家停止观看它，它就会扭曲实际图像。过度解释会导致与真实图片的对齐不足。
交付团队也会遇到同样的挑战。更正确的做法是：增加与产品负责人重温用户故事的频率，以重申「目标是什么」。
每天找团队成员或产品负责人，重新同步用户故事背后的原因和受众用户。尝试以同样的方式理解这个用户故事（但不要过度分析），然后再去执行。
因素#2：最小化解决方案
W. Edwards Deming 说：「慢就是顺，顺就是快。」
从理论上讲，戴明指出，慢慢练习（直到你达到精确）就会带来速度。在冲刺的情况下，这句话也很好地描述了准确估计和问责制在兑现承诺方面的重要性；无论工作完成得有多快。
大多数客户将他们的需求表达为「更好且更快地交付软件」。这可能不是一个合理的表述方式。我们应该询问他们：他们是否寻找的是「交付的质量和及时性」。
这里的微妙差别在于，在与我们的利益干系人和最终用户合作时，我们发现假设在正确的时间交付高质量、有价值的结果就足够了。
这个简单的协议是很强大的，因为它使我们能够满足利益相关者的目标，同时还实施了提高质量的解决方案。达到更高的质量是可能的，因为目标不再是速度，正如我们所知，速度是「真实质量」的敌人。
第二个关键因素是通过了解您的代码来最小化解决方案。
了解代码并不容易，尤其是走进一个拥有遗留代码平台的组织里。但是，了解代码仍然很重要。以可预测的方式及时交付的秘诀是找到最小的解决方案，同时也达到用户故事的价值主张。
当被要求提供一个解决方案路线图来概述我们将交付每个迭代的内容时，我们总是要求有一个「启动迭代（迭代 0 ）」。在「启动迭代」期间，根据客户的需求，我们通常会执行以下三个练习之一来熟悉代码：
- 缺陷修复
- 测试用例自动化
- 集成原型
这个「启动迭代」对我们很重要，因为我们可以隔离问题区域，并发现更有效地利用原有代码的方法。我们寻找不同类型的技术债务，例如过于复杂的代码、反模式、紧密耦合、依赖性扩散、糟糕的代码注释以及单元测试覆盖率的数量。当你知道要修改代码中的缺陷时；你最小化最终的解决方案。
在每个迭代中花一些时间对你将在下一个迭代中可能要修改的代码区域进行探索。如果你不知道在下一个迭代要交付什么，请确保重新审视第一个关键要素（并期望您的产品负责人提供更多）。
原文链接：https://fortegrp.com/keys-to-a-successful-Iteration-outcome/