如何在仍然忠于敏捷的情况下避免技术债务，即:避免违反YAGNI和避免BDUF？

Question

技术债务马丁·福勒，通过史蒂夫McConnell

YAGNI (你不会需要它) 通过维基百科

大设计前沿( 通过维基百科 )

更新:为了澄清这个问题，我想我也可以这样说，并保留我的意思：

作为一个敏捷实践者，你如何在“快速”和“肮脏”(无意中冒着技术债务，同时试图坚持YAGNI)和每一次迭代中的过度工程()之间找到正确的平衡？

Answer 1

看起来，如果您坚持敏捷(迭代、迭代评审)的“计划，做，适应；计划，做，适应”的想法，那么默认情况下您将避免这些事情。BDUF与敏捷评估与规划的思想背道而驰，如果您真的很敏捷，那么您就不会自动成为BDUF。

发布和迭代计划会议的目的是确保您为该迭代向项目添加了最有价值的特性。如果你记住这一点，你就会免费避开YAGNI。

我强烈推荐Mike关于敏捷规划的书：

1. 用户故事应用
2. 敏捷评估与规划

更新:在您澄清了在迭代中避免YAGNI和BDUF之后的。

BDUF...If我觉得在我开始工作之前，它的一个特性没有得到明确的定义，我会创建一个小的“特性”或故事来说明所需工作的设计类型部分。因此，也许小故事的故事点估计值是1，而不是真正的功能的5，这样，设计就会被时间限制在更小的故事中，你就会被驱使去处理这个特性本身。

为了避免违反YAGNI，我将非常清楚地了解客户对迭代中某个特性的期望。只做能映射到客户期望的工作。如果您认为应该添加一些额外的内容，则为其创建一个新特性，并将其添加到要执行的积压的工作中。然后，您将说服客户看到它的好处；就像客户会在某个时间点推动一个特性一样。

Answer 2

基于几周前在HanselMinutes上完成的定义-HanselMinutes。该节目的基础是，如果你重新定义‘做’，以提高感知的速度，那么你将积累技术债务。由此得出的结论是，如果您对“完成”没有一个正确的定义，那么您很可能会获得一个项目列表，无论设计方法如何，在发布之前都需要完成这些项目。

Answer 3

你似乎说"YAGNI“意味着”快速和肮脏“。我看不出来。

作为一个敏捷的程序员，我实践测试驱动的开发，代码评审和持续集成。

• 测试驱动开发(TDD)作为一个过程，是避免YAGNI的一个好方法。就在那里的代码“万一它会有用”往往未经测试，很难测试。
• TDD还在很大程度上消除了对BDUF的强制:当您的过程是通过坐下来并开始做一些真正具有价值的事情时，您不能沉迷于BDUF。
• TDD，作为一种设计实践，意味着当您获得问题的经验并重构真正的代码时，就会出现大的设计。
• 持续集成意味着您设计您的过程，使您的产品在任何时候都是可发布的。这意味着您有一个完整的质量过程，试图防止主线的质量下降。

根据我的经验，技术债务的主要形式是：

• 自动化测试套件未涵盖的代码。不要允许这种情况发生，除非非常本地化的组件很难测试。未经测试的代码是被破坏的代码。
• 违反编码标准的丑陋代码。不要让这种事发生。这就是为什么您需要将代码评审构建到持续集成过程中的原因之一。
• 代码和测试，嗅觉和需要重构，以更容易修改或理解。这是技术债务的良性形式。利用你的经验知道什么时候该积累，什么时候该回报。

不知道这是否回答了你的问题，但我写得很开心。

特洛伊DeMonbreun评论道： 不，这不是我的意思..。“快速和肮脏”=(无意中冒着技术债务的风险，同时试图遵守YAGNI )。这并不意味着YAGNI只是快速和肮脏的。“快速和肮脏”是我在描述技术债务时引用Martin Fowler的话。

避免雅格尼是接吻的另一种说法。YAGNI增加了技术债务。在避免YAGNI和保持低技术债务之间没有紧张关系。

我想我可能还是忽略了你问题的重点。