所以我有一个问题。或者说我的朋友有问题，因为我永远不会在互联网论坛上写我的公司。
在我朋友的公司规范写作中，我们应该说，有点未充分利用。有一种根深蒂固的文化，即首先编写代码并稍后提出问题，无论是图书馆日常工作还是给长期受苦设计师施加新工具。
这当然会导致功能部分正确，不正确或完全丢失的情况（“哦，只需在尝试任何您想要撤消的内容之前保存”）。这通常会导致那些糟糕的设计师或测试期间的生产力下降，其中错误修复主要用于正确实施。
我的朋友发现他的写作（和测试）规范的建议一般都很受欢迎。他的大多数同事已经接受了在纸上发现错误假设的美妙感觉，而不是在测试中期的周日晚上11点。 Viva La Revolution！
然而，有一些人在他们的任务和键盘之间放任何东西。他们嘲笑实际设计任何东西的想法，然后快乐地放弃编写代码。这些都是资深的，长期雇佣的开发人员，他们不愿意“浪费时间”。
问题在于，第二组异教徒总是比第一组更快地产生（或至少某些东西）。随后，这就变成了理所当然：“为像图像缩放器这样简单的东西编写规范是没有意义的！哦，那些宽度！=高度或图像使用RLE的错误只需要一些调整”。
现在的问题是：）
除了在项目结束时说“告诉你”之外，从长远来看，有哪些好的短期方法可以证明编写功能或技术规范的做法如何能够带来更好的软件？
干杯！
答案 0 :(得分：15)
目标是编写正确的软件....规范只是尝试查找/定义正确内容的一种工具。
我认为作为一个群体，需要决定如何构建正确的事物以及如何在每个人之间进行沟通。
即关注真正的问题，然后就如何解决问题达成共识。而不是说，“这是一个问题的解决方案，让我们去做！”，通常不会从每个人那里获得大量购买。也可能是规范也不是解决问题的正确方法。
答案 1 :(得分：10)
规范击败牛仔的一个领域是“scope creep”以及与之相关的成本。
规范是客户与开发人员之间的合同。如果你没有明确的合同，你怎么知道合同何时满足？
此外，通过详细的规范，可以让两个或更多的开发人员同时处理项目的不同部分。并且，它为测试人员提供了一些东西来比较软件，以确保该死的东西有效！
答案 2 :(得分：5)
这很困难，因为办公室文化和工作习惯很难改变。如果您对此非常认真，请尝试让管理层同意将规范用于小型项目/模块的试验，并且随着时间的推移量化维护成本（时间，错误等）。
你可能不会以这种方式让其他开发人员站在你一边，但是比更抽象的开发实践更容易理解$$。对poo-poo'ers的管理负责该团体的持续就业和绩效评估，这是说服他们改变或让他们在其他地方工作的一种方式。
答案 3 :(得分：3)
如果您有权力，请尝试让所有开发人员，当他们对其他人的惯例有任何疑问时，直接向原始编码人员询问。少数仍然认为规格和文档不重要的程序员可能会愿意尝试几次，如果他们一直都在回答“新手问题”。
这正是我几年前在一家大型开发公司工作的情景，人们很快就知道他们要么必须大量记录他们的代码，要么冒着“浪费时间”来回应很多小问题的风险。 / p>
当然，这只有在你能够得到足够的人来尝试时才可行：）
答案 4 :(得分：1)
我认为如果你能与整个团队一起编写规范可能会有所帮助。花点时间一起做，并分组讨论。我们通常在每次迭代开始时与整个团队召开此类会议，如果需要，我们会与一些开发人员讨论更多细节。根据我的经验，没有必要讨论每一个细节，因为这对某些人来说很无聊。
答案 5 :(得分：1)
通常需要时间 - 这始终是问题所在。
编辑：
对于您自己的公司，我的意思是您的朋友，需要在需要更改某些内容并且无法获得规范时进行记录。每当规范或文档节省时间时，记录该事件。记录所花费的时间（由研究人员和被询问，帮助等人的人员（如果有的话）。然后，您需要进行成本/收益分析，了解时间是否“保存”最初是不做规范在需要的时候值得拥有它。
在某些情况下，写一个可能是值得的，而你可能会发现其他情况并非“需要”。在实践中，收益可能是如此之大，以至于最好只在开始时完成。
现在 - 警告：
答案 6 :(得分：1)
将两种文化分成两个不同的组，提出您首选的效果指标并将其设置为松散。最好的团队赢得所有这一切。
或者将它们指向千种不同的定量/定性研究中的任何一项，科学地证明了他的观点。
或者替代地解雇所有牛仔和/或其他明智的人要求使用最低级别的规范，无论其惹恼谁。根据项目的复杂性，您可能只会意识到，在大多数原始开发人员离开之前，缺乏任何规范和文档是多么有害。
或者将一个应用程序模块与一个纯粹的外包团队签订合同，看看缺乏规范和文档对他们的绩效和满足关键指标的能力有多么不利。
或向客户询问产品质量/成本等。
如果他们的雇佣合约得到妥善设计和执行，那么你的朋友不会在项目结束时告诉开发人员“我告诉过你”，而是可以给他们粉红单。
除此之外，您不必等到项目结束才知道存在问题，也不必进行人员变更。
或建议您的朋友退出并加入一家拥有更符合其偏好的开发方法和实践的商店。 “也许他只是在错误的地方。”
答案 7 :(得分：1)
规范是关于知道做了什么。如果你不知道做了什么，你怎么知道回家的时间？
在最简单的情况下，开发人员是否与利益相关者交谈以了解他们想要什么？如果是这样，那么无论他们决定什么都是'规范'。
怀特白了 - 实施它 - 然后回家。
答案 8 :(得分：0)
只是，告诉你的朋友他们必须避免走向另一个极端，在规格完美且100％完成之前无法做任何事情。并且编码每周都会延迟，因为有人在规范中添加了其他内容。有时候这种方法可能需要2到3个月，然后高级管理层的人会非常沮丧，并会说“我不在乎，我只是想要完成产品”，情况将是最糟糕的。
通过保持流量敏捷（每周审核，提前交付，快速查找等），您可以充分利用这两个方面。
答案 9 :(得分：0)
规格是浪费时间。大多数使用该软件的人无法分辨他们想要什么，但他们可以判断他们得到的是否足够好。
原型很少因同样的原因而起作用，他们无法判断这个功能是否尚未完成或者根本不会完成，所以他们会弹道告诉你这一切都是错的，你应该重做一切。实际上他们只需要快速调整。或者他们会告诉你，当他们最终意识到它不可用时，发布点一切都很好。
设计的最佳方式是走出去看看他们过去是如何做的，并尝试将您的应用程序融入他们的工作流程中。每个团队成员都应该这样做。
我并不是说你不能写下要求但是向你的实际用户展示它们没有意义。如果您单独使用该功能，那么您可以很好地掌握所有规格。
简而言之：不要编写规范，监视用户。确保所有团队成员都这样做。
答案 10 :(得分：0)
在规格上花费太多时间浪费时间。我曾经在一个项目中工作过一个专业服务应用程序的销售，编写和发货，之后老板们要求我们编写规范。问题是，编写规范需要更长时间，需要更多人，并且比原始应用程序花费更多，而原始应用程序永远不会再次使用。
敏捷方法论说，我们不应该因为文档疯狂而给自己增加负担。相反，应明确描述要求并将其分配给各个团队和开发人员，并定期进行代码审查。当你拥有一名称职的建筑师时，这很有效，但如果项目领导没有资格确定团队不同部门提出的不同方法的相对技术优点，那么这将是灾难性的。
代码应该是自我记录的。应遵守代码标准。要求应仔细考虑并列举。但是你不需要的是一个200页的文档，描述每个模块中每个特定代码行发生的事情，或者比代码本身更详细的评论。开发人员应该能够阅读这些内容。如果不能，你的问题就在别处。