12

所以我有一个问题。或者更确切地说，我的朋友有问题，因为我永远不会在互联网论坛上写我的公司。

在我朋友的公司，规范写作，容我们说，有点未充分利用。首先编写代码，然后再提出问题，这是一种根深蒂固的文化，无论是为了库例程还是新工具，都可以强加给长期受苦的设计师。

这当然会导致功能部分正确、不正确或完全丢失的情况（“哦，在尝试任何您可能想要撤消的操作之前先保存”）。这通常会导致那些糟糕的设计师失去生产力，或者在测试阶段主要花费在修复错误上来正确地实现事物。

我的朋友发现他关于编写（和测试）规范的建议普遍受到好评。他的大多数同事都接受了在纸上发现错误假设的美妙感觉，而不是在测试期间的周日晚上 11 点。革命万岁！

然而，有一些人会在他们的任务和键盘之间拉屎任何东西。他们嘲笑实际设计任何东西的想法，并愉快地编写代码。大多数是资深的、长期受雇的开发人员，不愿“浪费时间”。

问题在于，这第二批异端总是比第一批更快地产生东西（或至少是某种东西）。随后，这变成了“为像图像调整器这样简单的东西编写规范是没有意义的！哦，那些宽度！=高度或图像使用 RLE 的错误只需要一些调整”。

现在的问题:)

除了在项目结束时说“告诉你”之外，还有哪些好的短期方法可以证明编写功能或技术规范的实践如何在长期内带来更好的软件？

干杯!

4

11 回答 11

15

目标是编写正确的软件……规范只是尝试查找/定义正确事物的一种工具。

我认为作为一个团队，需要决定如何构建正确的东西，以及如何在每个人之间进行沟通。

即，专注于真正的问题，然后就如何解决它达成共识。而不是说，“这是一个问题的解决方案，让我们去做吧！”，这通常不会得到每个人的认可。也可能是规范也不是解决问题的正确方法。

于 2009-02-23T22:36:48.630 回答
10

规范击败牛仔的一个领域是“范围蔓延”以及与之相关的成本。

规范是客户和开发人员之间的合同。如果您没有明确的合同，您如何知道合同何时已履行？

此外，拥有详细的规范可以更轻松地让两个或多个开发人员同时处理项目的不同部分。而且，它为测试人员提供了一些东西来比较软件，以确保该死的东西有效！

于 2009-02-23T22:50:02.577 回答
5

这是相当困难的，因为办公室文化和工作习惯很难改变。但是，如果您对此非常认真，请尝试让管理层同意试验，其中将规范用于小型项目/模块，并且随着时间的推移对维护成本（时间、错误等）进行量化。

你可能不会以这种方式让其他开发人员站在你这边，但 $$ 比更抽象的开发实践更容易理解。poo-poo'ers 的管理层负责该团队的持续就业和绩效评估，因此这是说服他们改变或让他们在其他地方工作的一种方法。

于 2009-02-23T22:32:40.747 回答
3

如果您有能力，请尝试让所有开发人员在对其他人的例程有任何疑问时直接询问原始编码人员。少数仍然认为规范和文档不重要的程序员可能愿意尝试几次，如果他们一直被困在回答“新手问题”中。

这正是几年前我在一家大型开发公司工作的场景，人们很快了解到他们要么必须大量记录他们的代码，要么冒着“浪费时间”来响应许多小问题的风险。

当然，这只有在你能让足够多的人尝试的情况下才可行:)

于 2009-02-23T22:40:59.557 回答
1

我认为如果您与整个团队一起编写规范可能会有所帮助。花时间一起做，小组讨论。我们通常在每次迭代开始时与整个团队举行这样的会议，如果需要，我们会与一些开发人员讨论更多细节。根据我的经验，没有必要讨论每一个细节，因为这对某些人来说很无聊。

于 2009-02-23T22:37:22.750 回答
1

这通常需要时间——而这始终是问题所在。

编辑：

对于您自己的公司，我的意思是您的朋友，每当有东西必须改变并且规格不可用时，都需要记录下来。每当规范或文档可以节省时间时，记录该事件。记录花费的时间（研究人员和被询问、帮助的人（如果有的话）等在需要的时候不拥有它是值得的。

在某些情况下，写一个可能会有所回报，您可能会发现其他情况下它不是“需要”的。在实践中，收益可能如此之大，以至于最好在一开始就完成。

现在 - 警告：

  • 你可能有不情愿的人。暂时不要试图说服他们。
  • 您需要一个标准使用的存储库 - 位置或方式无关紧要，但它必须是一致且众所周知的，以便可以找到它们
  • 他们必须保持最新和维护
于 2009-02-23T22:38:40.920 回答
1

将两种文化分成两个不同的组，提出您喜欢的绩效指标并将它们放宽。最好的小组获胜等等。

或者将他们指向一千种不同的定量/定性研究中的任何一种，这些研究可以科学地证明他的观点。

或者解雇所有牛仔和/或其他明智的要求，无论它惹恼了谁，都必须使用最低水平的规范。根据项目的复杂性，您可能只会意识到缺乏任何规范和文档实际上是多么有害，直到大多数原始开发人员离开为止。

或者将应用程序模块分包给一个纯粹的外包团队，看看缺乏规范和文档对他们的性能和满足关键指标的能力有多么不利。

或者向客户询问产品质量/成本/等。

如果他们的雇佣合同设计和执行得当，你的朋友就不会在项目结束时告诉开发人员“我告诉过你”，而是可以给他们他们的粉红单。

除此之外，您不必等到项目结束才知道存在问题，也不必进行人员变动。

或者劝你的朋友退出，加入一个开发方式和做法更符合自己喜好的店铺。“也许他只是在错误的地方。”

于 2009-02-24T01:37:04.050 回答
1

规范是关于知道做了什么。如果你不知道做什么，你怎么知道该回家了？

在最简单的情况下，开发人员是否与利益相关者交谈以了解他们想要什么？如果是这样，那么他们决定的就是“规范”。

把它白下来——实施它——然后回家。

于 2009-02-24T01:48:36.313 回答
0

只是，告诉你的朋友，他们必须避免走向另一个极端，在规范完美和 100% 完成之前什么都做不了。而且编码每周都会延迟，因为有人在规范中添加了其他内容。有时这种方法可能需要 2 到 3 个月，之后高层管理人员会非常沮丧，并会说“我不在乎，我只想完成产品”，情况会更糟。

您可以通过保持流程敏捷（每周回顾、尽早交付、快速查找等）获得两全其美

于 2009-02-23T23:19:14.987 回答
0

规格是浪费时间。大多数将使用该软件的人无法说出他们想要什么，但他们可以知道他们得到的东西是否足够好。

出于同样的原因，原型制作很少起作用，他们无法判断此功能是尚未完成还是根本不会完成，所以他们会突然告诉你这一切都是错误的，你应该在他们实际需要时重做所有事情只是一个快速的调整。或者当他们最终意识到它不可用时，他们会告诉你这一切都很好，直到发布点。

最好的设计方式是走出去，看看他们过去是如何做事的，并尝试将您的应用程序融入他们的工作流程中。每个团队成员都应该这样做。

我并不是说你不能写下需求，而是将它们展示给你的实际用户是没有意义的。如果您单独处理该功能，您可以很好地掌握所有规范。

简而言之：不要编写规范，监视您的用户。确保所有团队成员都这样做。

于 2009-02-24T01:30:56.293 回答
0

在规格上花费太多时间是浪费时间。我曾经参与过一个项目，销售、编写和交付一次性专业服务应用程序，之后老板要求我们编写规范。问题是，编写规范需要更长的时间，需要更多的人，并且比原来的应用程序成本更高，而原始应用程序永远不会被再次使用。

敏捷方法论说我们不应该因为文档而疯狂。相反，应该清楚地描述需求并将其分配给各个团队和开发人员，并定期进行代码审查。当您有一个称职的架构师时，这很有效，但如果项目领导没有资格确定团队不同部分所提出的不同方法的相对技术优势，则可能是灾难性的。

代码应该是自我记录的。应遵守规范标准。应仔细考虑和列举需求。但是你不需要的是一个 200 页的文档，描述每个模块中每一个怪异的代码行发生了什么，或者比代码本身更详细的注释。开发人员应该能够阅读这些内容。如果他们不能，那么你的问题就出在其他地方。

于 2010-03-16T21:00:28.170 回答