测试驱动与业务需求不断更改

Question

CTO/CIO设置的开发团队的新需求之一是成为测试驱动的开发，但是我不认为业务的其余部分会有所帮助，因为他们没有开发生命周期的意识，而且需求在单个sprint中一直在变化。这让我对浪费时间编写10个测试用例感到沮丧，明天也会变得毫无用处。

我们建议建立流程，以避免这些需求更改，并教育企业开发生命周期。如果企业没能得到这个想法呢？你怎么做？

Answer 1

您的问题似乎表明TDD受开发生命周期的约束。我不确定我同意。

灵活、不断变化的需求的答案是迭代开发。TDD对此或软件计划没有什么可说的；它是一种在任何需求和计划范围内开发软件的工具。如果需求发生变化，软件也会发生变化。这也适用于单元测试。

TDD不开发需求，尽管一些支持者建议它开发需求。相反，需求驱动单元测试，这反过来驱动编写的代码。您不会从测试中开发架构，也不会使用测试开发需求。相反，测试是指定架构和需求的结果。

如果需求在软件开发的原子级(方法/单元测试)发生变化，那么我建议您的需求过于分散。需求应该指定软件是做什么的，而不是它是如何做的。软件如何满足需求是软件开发人员的领域和责任，而不是主要的涉众。

换句话说，我不告诉客户或企业主如何管理他的公司，他也不告诉我如何设计我的课程。

Answer 2

更改需求是一件正常的事情，但是当它们每天都在变化，并且在冲刺过程中更改需求时，这并不是一个有利于软件以任何有意义和定性的方式开发的环境。换句话说，TDD是您这里遇到的问题中最少的一个，它们是最基本的。

您提到sprint，这意味着您正在执行某种敏捷开发，这是一件好事。短时间内处理开发，快速冲刺很好地工作在项目中，当优先级和需求是不稳定的，并可能在项目过程中发生变化。严重的问题是，您的开发和测试团队的需求在冲刺过程中发生了急剧的变化。

一旦sprint启动，sprint的优先级就不应该改变。sprint应该是利益相关者和开发团队之间的一项协议，即以下商定的特性和用户故事将在特定日期交付和测试。在开发开始后，当利益相关者开始改变对sprint的期望时，他们不会维护他们的协议的终结。

因此，利益相关者并没有对他们所要求的东西小心谨慎或深思，所以他们会立即改变他们的期望。那么，开发人员是否有将交付日期推迟到特性的奢侈呢？通常不会。充其量，利益相关者是疏忽大意或无能的，开发商无论如何都要付出加班加点的代价来满足这个日期。有时候，即使是利益相关者也会故意这样做，因为他们知道他们可以从他们的薪水高的开发人员那里得到更多的工作。

当核心需求改变到当前对sprint的工作将毫无用处时，应该立即停止sprint开发，直到可以根据新的需求计划一个新的sprint。毫无疑问，在接下来的一周半时间里，没有理由继续开发业务已经告诉你的软件，无论如何，这些软件对他们都是没有用的。

真正发生的是，业务涉众由于不维护或不满足sprint承诺而使开发团队失败。他们要么完全缺乏能力来确定他们在软件中需要什么，要么他们完全缺乏对开发团队的尊重，以及如何生产高质量的软件。

像这样的商业集团要想赢得对软件开发真正工作方式的尊重，唯一的办法就是雇佣一家外部顾问公司或软件供应商为他们开发软件，并通过sprint支付费用。一旦他们在一些他们无法使用的冲刺开发上损失了钱，他们就会开始意识到保持他们作为利益相关者的承诺是多么重要，并且对他们的特性和需求非常小心和具体。

Answer 3

如果不使用特定的敏捷术语，根本的问题似乎是在迭代期间缺乏对客户责任的理解和/或承诺:一旦为迭代选择了一组可实现的项目(由客户端商定)，客户端同意在迭代结束之前不改变他们的想法。

这使得devs在短时间内有一个固定的目标。

如果需求如此不稳定以至于无法单独生存一天，那么项目的问题远远超出了方法.在这种情况下，退一步到项目的目标，重新考虑提议的特性。