如何证明编写规范胜过代码牛仔?[关闭]

这是相当困难的,因为办公室文化和工作习惯很难改变。如果你真的认真对待这个问题,试着让管理层同意一个试验,在这个试验中规范被用于一个小的项目/模块,并且维护成本(时间、错误等)随着时间的推移被量化。

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

目标是编写正确的软件……规范只是一个工具,用来尝试找到/定义正确的东西。

我认为作为一个群体,需要决定你如何去构建正确的事物,以及你如何在每个人之间进行沟通。

也就是说,关注真正的问题,然后就如何解决问题达成共识。不要说,“这是解决问题的方法,让我们来做吧!”这通常不会得到每个人的很多认同。也可能是规格说明也不是解决问题的正确方法。

规范战胜牛仔的一个领域是” scope creep “以及与之相关的成本。

规范是客户和开发人员之间的合同。如果你没有一个明确的合同,你怎么知道合同什么时候已经履行了?

此外,拥有详细的规范可以使两个或更多的开发人员更容易同时处理项目的不同部分。而且,它给了测试人员一些东西来比较软件,以确保这个该死的东西能工作!

如果你有能力,试着让所有的开发人员,当他们对其他人的程序有任何疑问时,直接问原始的编码人员。少数仍然相信规范和文档不重要的编码人员可能愿意尝试几次,如果他们一直坚持回答“新手问题”。

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

当然,这是可行的,只要你能有足够的人来尝试它:)

我想如果你能和整个团队一起写规格说明可能会有所帮助。花点时间一起做,分组讨论。我们通常在每次迭代开始时与整个团队召开这样的会议,如果需要,我们会与一些开发人员讨论更多细节。在我的经验中,没有必要讨论每一个细节,因为这正是一些人感到无聊的地方。

这通常需要时间——这总是问题所在。

编辑:

对于你自己的公司,我的意思是你的朋友,每当有什么需要改变,规范不可用时,都需要记录下来。只要规范或文档节省了时间,就记录该事件。记录花费的时间(包括研究人员和被要求、帮助等的人员(如果有))。然后,您需要进行成本/效益分析,以确定最初不执行规范所节省的时间是否值得在需要时不使用。

在某些情况下,写一封信可能会有回报,而在其他情况下,你可能会发现它不是“需要的”。在实践中,回报可能是如此巨大,以至于总是最好在开始时就这样做。

现在-警告:

• 你可能有不情愿的人。不要试图说服他们。
• 您需要一个标准使用的存储库—不管在哪里或如何使用,但它必须是一致的和众所周知的,这样才能找到它们。
• 它们必须保持更新和维护

将这两种文化分为两个不同的组,提出您喜欢的性能指标,并将它们放在一边。最好的小组获胜。

或者把它们指向上千个不同的定量/定性研究中的任何一个,科学地证明了他的观点。

或者,解雇所有的牛仔和/或其他智者,不管他们是谁,都要求使用最低级别的规范。根据项目的复杂性,您可能只会意识到缺乏任何规范和文档是多么有害,直到大多数最初的开发人员离开了任何方式。

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

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

如果他们的雇佣合同设计得当,执行得当,你的朋友就不会在项目结束时坚持告诉开发者“我告诉过你的”,而是会给他们一张粉红色的卡片。

除此之外,你不应该等到项目结束后才知道有问题,也不应该改变个人。

或者建议你的朋友退出并加入一家有更符合他偏好的开发方法和实践的商店。”也许他是在错误的地方。”

规范是关于知道做了什么。如果你不知道做了什么,你怎么知道回家的时间?

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

把它变白——实施它——然后回家。

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

通过保持流程的敏捷性(每周回顾、及早交付、快速查找等),您可以获得两个方面的最佳效果。

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

原型设计很少能以同样的原因工作,他们无法判断这个功能是否还没有完成,或者根本无法完成,所以他们有点疯狂地告诉你这都是错误的,你应该在实际需要快速调整的时候重做每件事。或者他们会告诉你到发布点为止一切都很好,当他们最终意识到它不可用时。

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

我不是说你不能写下需求,但是向你的实际用户展示它们没有意义。如果您单独处理这个特性,那么您可以很好地将所有的规范保存在您的头脑中。

简而言之 :不要写规格,监视你的用户。确保所有团队成员都这样做。

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

敏捷方法论认为,我们不应该因为疯狂使用文档而给自己带来负担。相反, 要求 应该清楚地描述和分配给各个团队和开发人员,并定期进行代码审查。当你有一个称职的架构师在船上时,这是很好的工作,但是如果项目领导没有资格确定团队不同部分所提出的不同方法的相对技术价值,这可能是灾难性的。

代码应该是自记录的。应遵守规范标准。应仔细考虑和列举要求。但您不需要的是一个200页的文档,描述每个模块中每一行代码上发生的事情,或者比代码本身更详细的注释。开发人员应该能够阅读这些东西。如果他们不能,你的问题就在别处。