在没有要求的情况下编写软件是应该具备的技能还是应该避免的情况？

我发现一些软件开发人员非常擅长此事，并且经常以其提供具有抽象要求的有效概念的能力而倍受赞誉。坦白说，这让我发疯，而且我不喜欢随便“弥补”。我曾经以为这是有问题的，但是我已经开始感觉到了转变，而且我想知道在很少给与指导的情况下是否需要调整我的思想（和编程）过程。我应该开始学习这种技能吗？还是坚持将需求的收集和业务规则放在首位的想法？

技能不是没有要求就编写软件。取而代之的是从项目所有者那里获取需求，而不管是否有正式的需求文档。

收集需求绝对是您的头等大事，但您不一定需要事先注意所有客户需求。风险当然是，如果您未能与客户进行正确的对话，您可能会错过一些至关重要的信息，这些信息会使您的系统架构无用，但是定义产品甚至获得产品并不罕见。大部分开发工作都无法进行，同时将主要的系统架构决策推迟到了最后可能的时刻。这是一种精益开发方法，旨在确保您在获得更多可靠信息之前，不会在产品开发中过早地承诺使用可能不兼容的体系结构。在OP所描述的情况下，

是的，您有时确实需要凝视一下，才能真正了解客户真正要求的东西，这就是原型尖峰和缓慢的（有时是痛苦的）增量提取需求的地方您确实会开发出良好的客户关系技能，并且耐心地意识到，使用任何复杂的软件构想，一开始客户对软件的实际需求了解不多。大多数情况下，客户并不总是拥有必要的专业知识或软件开发过程知识，因此客户会尽早致电给您，以依靠您的专业知识来定义他们的要求。

这很模棱两可……

我可以说两件事：

1. 有很多非常有天赋的技术人员，因为他们等待着完美的需求，所以他们的职业生涯中断了。或者他们打出“抱歉，不能做到，不在要求中。” 现实是需求编写非常困难。满足良好要求所需要的精度与大多数业务人员所创造的任何东西都不一样。技术与业务之间架起了一座桥梁，使其他人以100％的方式满足他们的人通常会迷失方向。

2. 有些软件人比他们的客户学得更好或更好。即使他们不是100％的最佳开发人员，这些人也值得拥有金子。我见过软件人期待着该国最好的品牌经理的定量营销需求。他们并不是所有解决方案的最佳编写者，但他们是英雄，因为他们可以越过桥梁。

生活不是关于黑白。如果您在自己周围画一个狭窄的盒子，您将受到限制。另一方面，一个拒绝满足技术创造需求的组织也受到限制。您必须查看喜欢的灰色位置。

需求是旅途中的步骤，愿景是方向

对于许多应用程序来说，过于详细的技术规范太过重要了，因为进行快速讨论可能会导致其仔细排版的文档毫无用处。相反，从愿景开始。如果每个人都了解整体情况，那么可以通过讨论来满足需求。

作为开发人员，您必须学习使用这些讨论来跟踪需求。这意味着向客户提出领先的问题，使他们思考今天的决策如何适合整体愿景。这些越详细的讨论越早进行，那么整体构想就会越快地形成统一的设计。

您应该在某种问题跟踪器中跟踪这些讨论的结果，以便其他人在错过原始讨论时可以对其进行评论。这样，您或团队中的其他成员就可以保存您的记录了，以便您在需要澄清时参考。

因此，要学会根据愿景进行编码，但要准备赶上这些要求。

史蒂夫·乔布斯（Steve Jobs）认为，客户无法准确描述他们希望未来产品的外观，因此交付这些产品是您的工作。因此，除非您一直提供定制软件，否则请忘记正式的规范，而要先创建原型，然后让客户与他们一起玩并告诉您他们的想法。您必须让合适的人做原型，他们需要帮助。我是凭经验说的-我是原型制作猴子，喜欢创建直观的界面，并且与产品中的某个人合作，他们了解客户的需求并可以在纸上或使用Excel进行解释。

我们俩都不是天才，但我们的想法是一样的-您几乎可以说我们已经有了化学反应，并且对构建事物和构建事物产生了巨大影响。现在，只有中型团队可以负担得起专门开发产品的原型开发人员和非编码人员，但这是值得的。原型设计是软件开发中最便宜的阶段，因此只有正确地获得UI和明显的行为才有意义。我没有读过《代码完成》，但我认为那本书中写着类似的东西。

规格很不错，但是它们从来都不是完美的。关于这个有一个定理。您不能证明规范是完整的，也不能证明该工具没有错误或将停止运行:)

然而，尽管过程中存在这些缺陷，但软件公司仍会始终提供软件。规格永远不会是完美的。该规范也是不自然的和过时的。原型的规格就像对数表是单个图形一样-规格本质上是无聊的小册子，意在进行印刷，而您可以与工具/图形进行交互。请访问http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html以获得灵感。

现在，如果您必须签订合同以掩盖您的屁股，则规格很好。但是规范应该仍然在原型之后而不是之前。弄清楚如何降低原型成本是您的工作。

我经常会发现，在某些情况下，我需要作为一个业务分析师，发现该企业目前是如何工作的，人家怎么想它的工作原理（通常是非常不同的东西），以及他们将如何喜欢它的工作。

通过始终清楚为构建软件而被迫做出的决定，我找到了成功。我解释我的推理，就发现的内容撰写文档，制作图表并将其分发给所有人，等等。

在交出完整的要求之前，您拒绝做任何工作可能不会给您留下很好的印象。但是，通过自己收集好的质量要求（不必引起注意），您将达到高质量软件的相同目标。

是的，正如其他评论者所说，始终在假设软件会更改的情况下构建软件。变化是您可以依靠的一个常数。始终以足够灵活和模块化的方式构建您的软件，以使在突然出现一些新需求时进行更新不会很麻烦。

如果您想在初创公司担任软件开发人员，这是一种技巧。

如果您想在咨询公司工作，那是不惜一切代价避免的情况。这是因为您的公司根据您执行规范/要求的程度而不是您解决客户问题的程度来获得报酬。

如果您在业余时间编写有趣的代码，那么这就是您的要求。如果您没有资格致电您的业余时间项目，请尝试几种方式，看看有什么用。同样，也没有必要一刀切，所有项目都需要一种或另一种方法。通常，如果您在这些项目之一中选择了错误的项目，您会很快发现它。

两者都有。您需要使客户满意，这意味着您需要知道他们想要什么。另一方面，众所周知，客户在交流他们真正想要的东西方面很糟糕。

因此，您想避免不知道客户想要什么的情况，但不可避免地会遇到这样的情况：需求充其量只是“糊涂”，而充其量是欺骗性的。一个好的现实世界程序员需要适应性。

没有要求就不可能编写程序。甚至“ Hello World”也有要求：生产产品。因此，我想您是在以某种类似于UML的大堆栈形式询问形式要求。关于这些，我遇到了两种人：

1）需要正式要求的人。必须准确告知他们该做什么，以及最好如何做。他们喜欢这样的句子：接受参数B的过程A将输出C，而他们讨厌这些：程序应使我们部门的工作更有效。它们通常是公司动物。

2）与1.相反的人。他们讨厌被告知该做什么和怎么做，他们喜欢被告知应该实现什么。他们喜欢与客户交谈，分析他们所说的话，然后开发自己的解决方案。他们通常是自由职业者，不适合公司。

我不会说哪个更好。两者都有其优点和缺点。它们简单地足以满足其他条件。

你可以不开发运营，而无需知道软件的要求; 但是，您可以轻松地开发自己的经验告诉您需求可能成为。敏捷开发结合了“直观”技术，包括80:20规则和通过原型“发现”需求。换句话说，一个经验丰富的开发团队可以对所需内容进行最佳猜测，并生成软件原型。80:20规则说它们将是80％正确的。然后，项目涉众审查有形原型。他们的反馈开始填补我们对要求的理解中的20％差距。因此，实际上，敏捷并不是要编写没有任何要求的软件，而是要使用您以前的经验说：“您想要这样的东西吗？” 在80％的情况下，与通过传统的需求流程进行处理相比，您可以更快地确认并确认真正需要什么。

谁说敏捷在没有要求的情况下编写代码？我知道宣言已经被某些人这样解释了……但这并不对。