如何在保持敏捷的同时避免技术债务,例如:避免违反YAGNI和避免BDUF?[关闭]

看起来,如果你坚持“计划,做,适应;计划,做,适应”的敏捷思想(迭代,迭代评审),你会在默认情况下避免这些事情。BDUF与 agile estimating & planning 如果你真的很敏捷,你就不会自动成为BDUF。

我强烈推荐Mike Cohn关于敏捷计划的书籍:

1. User Stories Applied
2. Agile Estimating and Planning

在你澄清了在迭代中避免使用YAGNI和BDUF之后。。。

BDUF公司 …如果我觉得在我开始工作之前,某个特性没有被明确定义,我会创建一个小的“特性”或故事来说明所需工作的设计类型部分。所以也许小故事有一个 story point

避免 侵犯雅格尼 backlog of work 待完成。然后,您将说服客户看到它的好处;正如客户会推动在某个特定时间点完成某个特性一样。

你好像说“雅尼”意味着“又快又脏”。我看不出来。

作为一个敏捷程序员,我练习测试驱动开发、代码评审和持续集成。

• 作为一个过程,测试驱动开发(TDD)是避免YAGNI的一个好方法。“以防万一有用”的代码往往未经测试,也很难测试。
• TDD还很大程度上消除了对BDUF的强制:当你的过程是从坐下来开始做一些真正能带来价值的事情时,你不能沉迷于BDUF。
• 持续集成意味着你设计你的过程,使你的产品在任何时候都是可发布的。这意味着你有一个集成的质量过程,试图防止主线的质量下降。

• 自动测试套件未涵盖的代码。不要让这种情况发生,除非非常本地化的组件特别难以测试。未测试的代码是损坏的代码。
• 嗅到并需要重构以更容易修改或理解的代码和测试。这是一种良性的技术债务。用你的经验来知道什么时候该积累,什么时候该回报。

特洛伊·德蒙布伦评论道:

回避 YAGNI KISS . 雅尼增加了 technical debt . 在避免雅格尼和保持低技术债务之间没有紧张关系。

我想我可能还是没有抓住你问题的重点。

几周前,根据你对HanselMinutes的定义,对技术债务进行了有趣的讨论-- What is Done

我找到罗伯特·马丁的 Test Driven Development (TDD)方法有助于解决这些问题。

为什么?

• 我认为可测试代码更干净。
• 当你确实需要改变(重构)时,你需要依靠测试

不管考试什么时候写(之前还是之后),我都能找到写作 这个测试帮助你做出实际的决定。E、 我们选择A或B设计是因为 A更容易测试。

XP的“传统”答案是重构与自动化单元测试相结合。

但从哲学上讲,这是一个非常有趣的问题。我不认为你需要 技术债务,只要保持在可控水平。史蒂夫·麦康奈尔(Steve McConnell)的文章在这一点上很好——这个类比之所以奏效,是因为在一家公司里积累金融债务是正常的,也是可以接受的,只要你接受成本和风险——技术债务也没问题。

也许答案本身也存在于雅格尼原理。在你还清技术债务之前,你不需要重构。当你在系统的某个领域进行大量的技术性工作时,看看重新设计在短期内会有多大的不同。如果它足够让它有价值,就把它还清。麦康奈尔提出的保留一份债务清单的建议将有助于你知道什么时候该考虑这个问题。

我不认为这是一个绝对的答案-像很多事情一样,这是一个基于你的经验,直觉和你在每个特定情况下的分析的判断。

就这么做吧 simplest thing that works . 我同意阿延德说的话 the key to being agile

在我工作的地方,我相信我们避免债务的方法是快速地在周期中旋转,即向潜在的最终用户展示功能,并得到一个签名,表示应该将其推到测试中,或者拒绝在给出更新的需求时说明错误所在。通过在一个迭代中重复这样做,通过尝试这个和那个,可以发现关于用户想要什么的很多更改。

关键的一点是,尽量做到用户想要做的事情,因为做的更多违反了YAGNI并带来了BDUF,而我认为反复改进需求的想法是敏捷的核心。

过程很重要,保持最佳实践很酷,但比其他任何事情都重要,常识驱动设计过程。软件是由人开发的,所以YAGNI应该:

我可能不需要,但也许我会,因为在我的具体业务/公司/部门,这件事确实发生了,或者我需要它,但我只是没有时间,没有那么快和肮脏的黑客来赚钱和保住我的工作,或者我可能需要它,以后的重构将是一个痛苦的驴10倍以上的成本只是现在做抓挠,我现在有时间了。

编辑: 顺便说一句,TDD与YAGNI相反,你甚至在不知道是否需要它们之前就在构建测试。说真的,别再听学者的话了!!没有神奇的方法来生产软件。

事实上,你正在实现客户想要的,即通过他们的反馈,将TD保持在最低限度,

问题实际上可能在更高的层次上:管理层和产品所有者关心的是截止日期,而不是开发人员自己。

在我的上一份工作中,我从事遗留代码的工作,但我接触过一些使用(据说)敏捷和TDD开发全新代码的人。

但是 进度的衡量标准是用户情景实现的速度,即新功能添加的速度。重构的关键在于它不添加任何新功能。是的,这是非常重要的,但是它并没有像向产品所有者展示新功能甚至是相应的测试代码行那样产生直接的影响。

随着最后期限的临近,加之加班成为标准,人们有动力在重构部分省钱。这样做得越多,就越能快速地了解用户故事,这似乎是管理层关心的。

现在,这个 这会导致技术债务,因为在很多情况下,为了完成下一个用户场景,有必要返回并重构(真正重写)前一组用户故事的代码。管理层对此很生气,因为从他们的角度来看,这个用户故事看起来和之前的没有太大的不同,所以为什么对它的估计要长10倍呢?

是 认真对待重构,但这并不能阻止你在其他团队之后被困在清理上 不是的