当旧的需求改变新需求的范围时，哪些文档/工件应该提醒我？

Question

一年前，我开发了一个软件应用程序，我提供了一个简单的文档。

例如，它有一个特殊和复杂的登录系统的要求。

现在，客户打电话给我，要求我更改应用程序以支持一种新的用户，然后我(快速)查看我需要更改的表、视图和代码，以交付新的需求，支持一种新的用户，并给出一个估计时间，但我完全忘记了我需要重构这个特殊而复杂的登录系统。

这是一个很大的错误，因为我将花在重构特殊和复杂的登录系统的时间将不会被支付。

我犯了什么错误？我将来怎样才能避免呢？跟踪能力矩阵给出了测试用例与需求之间的关系，但我需要跟踪旧需求与新需求的关系。

Answer 1

合同事项

这是一个很大的错误，因为我花在...上的时间不会被支付。

事实上，最大的错误是你的合同让你有可能把时间花在免费工作上。不管你是在解决一个bug还是学习一个新项目所需的技术:客户必须为你花费的时间买单。

你不应该免费工作。就这么简单。这让你感觉很糟糕，它鼓励你的客户认为你是一个免费工作的人，所以，谁也不需要特别尊重，或报酬，毕竟。一旦你的客户知道你免费工作了一个小时，你的关系就完蛋了。

这也是为什么必须由一位专业从事软件开发合同的实际律师编写一份合同。

技术估计

我犯了什么错误，将来怎样才能避免。

从技术上讲，你的错误是过快地给出了一个估计。您可能还花了几个小时来研究这种影响，并可能会发现数据与身份验证之间的关系。

但是这样的错误无论如何都会发生，所以从技术的角度来看，这并不是一个大的错误。

这与你对一项任务估计两周的情况并没有太大的不同，在你开始任务一周之后，你会发现它需要更多的工作。然后，您只需向涉众(是您的经理还是您的客户)发送经过调整的评估，同时考虑到您发现的内容。

你可能犯了一个错误，给出了一个非常精确的估计。如果你说一次改变需要“八十小时”，这与“十天”是不一样的，和“两周”也不一样。此外，估计值通常表示为一个范围，或包含关于精度的提示：

这项任务从4天到9天不等。

或者：

这项任务需要16天±4天。

这就使估计值的逐步调整更加直观。

另一个重要的方面是你应该能够说不。这特别适用于这两类问题：

“你知道这个任务需要多长时间吗？”

如果你不知道这个任务需要多长时间，不要说“三个星期”仅仅是为了摆脱这个人。

“你能努力把它送得更快些吗？”

如果你回答“是”，这意味着你的最后一次估计是错误的(在这种情况下，你为什么要首先做出错误的估计？)，或者你知道如何提高效率，但除非被特别要求，否则不要这么做，这听起来也不是很专业。

这一切都是关于杠杆

但是，再一次，最重要的是你如何与你的客户互动，这归结为两件事:合同说什么和你的筹码是什么。

例如，比较以下消息：

2月7日，我向您发送了一个8天±3天的估计值，用于将底部菜单迁移到新数据源的任务。任务似乎还需要在顶部菜单中进行更改，因为两者部分依赖于相同的代码。考虑到这些新元素，更新后的估计为11天±2天。

有了这个：

2月7日，我向您发送了一个8天±3天的估计值，用于将底部菜单迁移到新数据源的任务。看来这项任务比我想象的要困难得多，所以我不确定我是否能够按时发布更改。你能再给我三天时间来完成这个任务吗？

第二个糟透了。这表明开发人员没有任何杠杆作用。它没有给出任何估计，但几乎没有乞求额外的时间。这感觉就像开发人员搞砸了原来的估计，而且感觉很糟糕。第一个信息纯粹是非正式的:这里有一个估计，我不在乎你怎么想，我也不需要你的批准，因为我们的合同在这种情况下不需要你的批准。我的早期估计是正确的，而后一个只是考虑到额外的信息。没别的了。

Answer 2

这是一个很大的错误，因为我将花在重构特殊和复杂的登录系统的时间将不会被支付。

有一个巨大的红旗告诉你什么地方出了问题。这个问题在客户请求任何更改之前就嵌入到了这个项目中，在编写代码之前它们就已经存在了.

身份验证和权限是众所周知的(并解决了)问题，即使对于异常复杂的需求集(例如，2因素身份验证、时间锁定、位置限制)。

下一步是防止复发。

您可以对原始开发过程进行反思，并检查设计文档/流程，以了解导致这些组件紧密耦合的因素和需要寻找的警告标志。一般情况下，当一个共同的功能被认为是“特殊的”，这是一个很好的迹象，情况还没有完全理解，例如。

与其将这种情况视为“成本”，不如把它当作一个警钟，让您或任何从事项目工作的人都能从一些专业开发中获益，从而更好地理解开发过程--这是好的开发人员一直在做的事情，并使用这些知识来确保未来的项目更易于扩展，并且代码更易于测试/修复。它使您有机会在将来生成更好的代码。

作为起点，单责任原则(SRP)和关注点分离(SoC)应该将不相关的代码分开，这意味着今后不需要复杂的依赖矩阵。

拿几本关于代码质量的书，花些时间在这些书上，不会浪费时间，而且与一些由于本可以避免的问题而损失了几个月的项目相比，几天的额外开发时间是便宜的。