YAGNI -不能命名的敏捷实践？

Question

随着我越来越多地将敏捷思想融入到我的工作方式中，yagni (“您不会需要它”)似乎变得越来越重要。在我看来，这是最有效的规则之一，可以过滤掉被误导的优先事项，并决定下一步不做什么工作。

然而，雅格尼似乎是一个几乎没有在这里耳语的概念。我执行强制搜索，它只出现在一个问题的标题-然后在一个次要的角色。

为什么会这样呢？我是不是高估了它的重要性？

免责声明。为了抢先回答，我相信我会反对，让我强调，雅格尼是的快速和肮脏的的反面。它鼓励你把宝贵的时间和精力集中在你确实需要的部分上。

以下是一些正在进行中的问题，你可能会问。

我的单元测试是根据用户需求或框架结构选择的吗？

我是否安装(以及测试和维护)单元测试，这些测试仅仅是因为它们脱离了框架而存在的？

有多少代码是由我的框架生成的，我从来没有看过(但可能有一天会咬我，即使是yagni)？

我花了多少时间在工具上而不是用户的问题上呢？

当双编程时，观察者的角色值通常在"yagni“中。

你用CRUD工具吗？它允许(不，鼓励)您将它用作_RU_工具或C__D工具，还是在只需要一到两个代码的情况下创建四段代码(加上四个单元测试)？

Answer 1

TDD在某种程度上包含了YAGNI。如果您正确地执行了TDD，即只编写那些导致所需功能的测试，然后开发最简单的代码以通过测试，那么默认情况下您将遵循YAGNI原则。在我的经验中，只有当我走出TDD框，在测试之前开始编写代码，测试不需要的东西，或者是通过测试的最简单方法的代码，我才会违反YAGNI。

根据我的经验，后者是我在做TDD时最常见的失礼行为--我倾向于跳到前面，开始编写代码以通过下一个测试。这通常会导致我牺牲剩下的测试，因为我有一个基于我的代码的先入为主的想法，而不是需要测试的需求。

YMMV

Answer 2

雅格尼和吻(保持简单，愚蠢)本质上是相同的原则。不幸的是，我经常看到有人提到接吻，就像我看到“雅格尼”一样。

在我所处的荒野中，项目延迟和失败最常见的原因是不必要组件的执行不力，所以我同意您的基本观点。

Answer 3

改变的自由驱动YAGNI。在瀑布工程中，咒语是控制范围。范围由与客户签订合同来控制。因此，客户在范围文档中充分了解到，一旦合同签订，对范围的更改将是困难的。因此，您最终得到的应用程序有一个功能列表，而不是一组有价值的功能。

对于敏捷项目，产品所有者构建一个优先的产品待办事项清单。开发团队根据优先级(即价值)构建特性。因此，最重要的东西先建好。最后，您将得到一个应用程序，该应用程序具有用户所重视的功能。那些不重要的事情从清单上掉了下来，或者没有完成。那是雅格尼。

虽然YAGNI不是一种做法，但这是优先待办事项清单的结果。业务伙伴重视提供给业务的灵活性，因为他们可以更改产品待办事项并重新排序，从迭代到迭代。只要解释一下，YAGNI就是当我们欣然接受改变时所获得的好处，即使在这个过程的后期也是如此。