如何阻止开发规范在中间开发阶段发生变化？

问题：似乎我参与了几乎所有开发工作，无论在开始开发之前花了多少时间进行计划，在项目中期或项目结束时总是需要进行大量更改。这些有时是重大变化，需要大量重新开发。

我不为付钱的客户工作，这是内部开发网站上的内部开发团队。因此，这不是我可以为此付费的费用。最终，我们必须尝试按时完成任务。

问题：你们发现哪些最佳方法可以最小化并防止规格更改在开发中途或开发后出现？

赫尔穆特·冯·莫尔特克（Helmut von Moltke）曾说过一句著名的军事谚语：“没有任何作战计划能够与敌人接触”。同样，我认为不可能制定不需要更改的规范-除非您可以预测未来并读懂利益相关者的想法（即使那时他们可能还没有下定决心，即使他们声称自己做到了）。我建议改为以多种方式使用它：

1. 明确区分哪些可以更改，哪些不能更改。与利益相关者清晰地沟通，使他们尽快明确签署不变的事情。
2. 提前准备更改。使用允许更轻松地更改可变零件的代码方法，投资可配置性，封装和清晰的协议，这些协议将允许独立地更改和替换零件。
3. 经常与利益相关者交谈，征求反馈和批准。这样既可以使您保持同步，又可以避免为时已晚时声称“哦，这不是我们想要的”。如其他答案所述，敏捷的方法和频繁的迷你发布将帮助您实现这一目标。
4. 安排时间表以适应不可避免的变化。如果您认为可以，请不要害怕早点说“我们将需要更多时间”-如果您给出的时间表不切实际，那么最好一开始就知道它（并让您记录下来）结束。
5. 如果更改范围太广，并威胁到截止日期，请后退并说“这样的更改是可能的，但是会将截止日期推迟X倍，请自行选择”。
6. 进行正式的请求更改，确定更改优先级以及将更改分配给版本或发行版的过程。如果您可以告诉人们“我不能在此版本中做到这一点，但很乐意按计划将其发布到下一个版本中”，那总比对他们说“您为时已晚，您的更改无法进行”要好得多，再见”，并会让他们成为您的朋友-他们很高兴您能及时发布，以便您可以自由地到达下一个有他们更改的版本-而不是您的敌人。

尽早交付某些东西（我会犹豫使用任何词），并经常交付。也就是说-使用某种迭代开发方法。

这是敏捷开发的基础，但可以（几乎）与任何方法一起使用。

通过将项目分解为一系列的小型项目，您可以更好地控制，因为您可以尽早将某些内容放在客户端面前，因此您不会陷入漫长的开发计划中，而当客户改变主意时（例如他们会）。

当他们看到系统不断发展时，某些需求将发生变化，某些需求将变得多余，而其他需求将增加优先级。但是，通过缩短项目生命周期，您将能够应对这些变化。

可以完全确定任何重要规模的软件项目的理论是一个完整的幻想。对于几乎整个软件开发历史，从大到小的组织都没有发现这种理论。

您必须在旅途中找到某种方式来适应变化！之所以会这样，是因为大多数利益相关者，即使他们说“是的，这就是我想要的”，实际上直到他们面前，他们都不知道他们想要什么。这就是为什么我们有这么多人采用迭代方法的原因。

无论您是迭代产品还是进行其他任何操作，都必须找到某种方式来适应这些变化，因为试图找到不发生变化的方法只是要求重力将其自身关闭几分钟，以便您可以飞行。

不要试图阻止变化，要接受变化。您未来的计划越多，您的计划就越有可能改变。因此，少计划，而不是多计划。采用敏捷开发方法，您可以频繁交付少量工作代码，从而使客户有机会每两周更改一次规范。

您在问错问题。规格更改将始终发生在任何规模的软件开发项目中。

通常是因为业务需求发生了变化，但是我也看到了发生这种情况的原因是，客户（内部或外部）很难在没有看到要迭代的东西的情况下将其可视化，因此他们的愿景是随着与客户的互动而缓慢变化开发解决方案。

您应该问的问题不是“如何锁定规范”，而是“如何构建我的代码和流程以响应不断变化的环境而又不丢弃已经编写的所有内容？”

然后，这将带您进入流行语“宾果游戏”领域：敏捷方法论，迭代开发和技术解决方案，例如基于组件的/模块化编码，持续集成...等等。

我并不是说这些是解决您所有问题的灵丹妙药，但是之所以出现这些问题，是因为希望能够处理您所描述的情况，因此至少值得进行一些调查。

抱歉，如果没有提供具体的解决方案，但我倾向于认为，接受和管理变更的思维方式将比避免这种方式产生更大的收益。

变化只是一个惊喜...如果这是一个惊喜！

我建议考虑：

• 这些变化究竟来自何处？
• 您为什么不早一点意识到它们？
• 您为什么不为这些更改做出贡献（并可能做出更多更改）？

改变是我们做事的本质。从什么时候开始您完全按照第1天的设想编写算法的？

但是，如果您想避免永远不会因更改而“沮丧”于沮丧的开发人员，那么我认为您需要离决策制定行动更近。毕竟，我敢肯定您有很多想法可以使产品变得更好。在桌子上坐下来，或者永远接受您将只需要应对那些“意外变化”。

多数民众赞成在打个电话，客户总是想要更多，但是您应该考虑以下几点：

HTML模型：始终创建HTML模型，以定义应用程序的UI部分，向他们展示外观，并征求他们的意见。如果您发现合理的更改，请在HTML原型中进行更改。使用此工具，您可以整理出很多东西，例如UI问题，基本流程和一些附加功能（例如，排序，分页，要显示的记录数等）。

另一端的积极参与：如果您正在为一家商业组织而发展，介入他们的业务，请他们澄清您的疑问，并且一定要问他们想要对他们的流程进行哪些更改（如果需要），这非常重要。

模块化发布：以模块化方式发布代码，发布，测试，获取反馈并再次发布。

这就是为什么几乎不可能提前计划太多，但却根本没有计划的借口。不要太爱您的计划，您不必担心它们会伤您的心。

在公司内部，无论任何人承认，跟踪或必须为其预算，使用IT资源都会产生成本。现实情况是，您的团队只能在一定时间内创建大量代码。所有部门和项目都在此预算中共享。

您无法阻止任何人想要更改需求，但是他们无法逃脱后果。更改会大大增加开发时间。这是他们必须处理或决定不进行更改的事实。一个部门的请求会影响另一个部门吗？您可能必须将他们的项目完全移到其他部门之后，因为更改请求会侵占另一个小组的时间表。

在整个开发周期中积极参与用户活动，并尽可能多地使用敏捷方法论，对我们使用产品确实有帮助。

规格更改是不可避免的，但是通过与用户保持透明，最重要的是，经常对它们进行咨询意味着可以尽早捕获大多数更改。

对我来说，这很容易。
告诉已经订购了该功能的“产品负责人”，但他必须选择在此截止日期之前可能没有的几个计划的功能。
将其视为与PO进行的半冲刺会议，您可以告诉他冲刺不会消耗到0。

附言 如果不是“ PO”，我会说不要和我说话，通过“ PO”

你们发现哪些最佳方法可以最小化并防止规格更改在开发中途或开发后出现？

没有最好的方法。管理层有责任在开发的特定阶段限制对规格的更改。

但是，您应该以预期更改的方式设计软件。这样一来，变化带来的影响就会小得多。迭代和增量开发是一个良好的开始。

我发现，客户是直接或间接导致大多数更改的原因（也是大多数关键错误，BTW）的原因。因此，显而易见的解决方案是消除客户。（他们到底有什么好处？）

由于您无法阻止更改，因此您需要接受更改。我认为您可以做的最重要的事情是：您需要尝试尽早从客户那里获得变更请求，因为在只有很少的代码的情况下进行变更的成本较低。因此，您需要通过使用原型（也许甚至是纸质原型），使用敏捷方法等将设计尽快地呈现给客户。

您可以考虑使用SCRUM之类的方法在开发过程中引入一些规则。在SCRUM中，团队通过将功能的实现划分为多个故事并为每个故事分配一个工作量估算（实现该故事所需的工作时间或工作日数）来制定初始计划。

如果要求后期更改（对于已实施的故事），则需要创建一个新的故事并估算其实施工作。然后，您可以咨询您的经理（产品负责人），并简单地解释一下新功能将花费额外的时间。然后，项目经理有责任接受额外的努力并调整进度（可能取消其他尚未执行的故事）。

即使您的团队不打算完全实施SCRUM或其他开发过程，您也至少可以基于故事介绍计划，估计每个故事的开发工作并根据新故事的需要调整时间表。

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

我花了太多下班后的晚上，感到压力和不满，因为另一个家伙不了解或不在乎软件业务的运作方式。我没有遇到任何更高的人的问题，但是我没有书呆子同伴的支持。生孩子是个bit子，是吗？我可能会很快辞职。

坦白地说，我希望程序员总体上有更多机会。让我们看一下：

“”“我不为付钱的客户工作，这是内部开发网站上的内部开发团队。因此，我不可以为此付费或收取任何费用。最终，我们必须尝试按时完成任务。“”“

如果您与付费客户打交道，并且通过签订合同（http://vimeo.com/22053820?utm_source=swissmiss）支付了费用，那么更改规格将使该客户花费更多时间和更多金钱（或时间可能相同或更少，但金钱却成倍增加）。贵公司正在努力摆脱更改规格的麻烦，而又不会花费更多时间和金钱。

同时，试图按时完成任务会给您和您的同事带来不必要的压力；您无法与朋友/家人度过一个愉快的周末。这确实是不必要的，因为无论您是谁在向您扔工作，都可能根本不知道，这很可悲。

我建议的解决方案：集体准备好面对他们，并解释说没有免费的午餐，而且一切都花钱了；如果在工作中途更改规格，自动机械将花费更长的时间并收取更多的费用；承包商将花费更长的时间如果在工作中更改规格，则要收取更多费用，这是有充分理由的。如果他们不愿意以合理的方式与您合作，那么您作为一个整体将起身离开，他们将不得不雇用开发人员，这些开发人员可以从中断的项目中接机并按时交付。

然后还有敏捷开发的希望，这意味着没有艰巨的最后期限。

我还没有看到程序员会罢工，但是这本来是可以的。软件公司中无能的经理人太多。太多的人想要在Craigslist上或在一家实际公司中一无所获。http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

程序员需要有更多的球。

我发现一种可行的方法（显然不适合所有经理）是“我想我可以做到，是的。这取决于-您为该项目分配了多少额外时间？这是一个相当重大的变化要求。”