显然,您正在处理的项目的大小将是您花费多长时间编写设计文档/规范的重要因素。但是,您是否经历了一切,挑选了所有细节?还是您采用更敏捷的方法并在很早开始写软件并解决问题时就开始编写该软件?

我一直发现,到目前为止,您只能进行设计。不可避免地会错过一些东西,到那时,您能适应情况的含义比规范本身意味着更多。

我对此有正确的观点吗?它实际上是一种意见,还是完美的设计规范始终是最好的选择?

有帮助吗?

解决方案

这取决于您的目标受众,但是我的经验(在中等规模的开发中,比大规模的工作更多)是,详细的设计文档艰巨而无聊的书写,很少阅读,并且往往会过时。项目交付的时间。

这并不意味着他们一文不值 - 如果您要为某人交付某些东西,则需要有一个权威和商定的陈述,说明将要提供的内容充分详细说明,以防万一任何人都对这笔交易不满意并说“说”这就是我们承诺的“并对交付的内容进行评估。

但是,如果我要建立一家公司来构建产品,但是我不必担心详细规范。我想记录 什么 我们打算做,但我不想对 如何 - 这是最有可能更改和遗漏文件过时的部分,无用,甚至不准确,以至于实际上是阻碍性的。我更喜欢使用任何文档格式或IDE支持的任何文档中的代码中的“如何”内容,以便随着代码的更改,可以同时更新文档。它不会停止过时,但会减少它。

理想情况下,您需要一份设计文档,该文档在您的代码完成后可以作为您的手册加倍,但我不知道任何成功管理的人。

其他提示

这绝对取决于项目的大小和结构。

对于客户项目,必须详细规格。我喜欢在设计规范期间大量参与客户。这有助于提出额外的考虑,并使客户更好地了解期望的事物。在发现之后,通常会发生积极的态度(向时间和定价),并且规格完成。这也使我们能够设定有利于客户和我们的开发团队的里程碑 - 并击中它们。

对于内部项目和有趣的附带项目,我通常会创建一个流程图和功能列表,然后开始将其组合在一起。在这些情况下,我发现比功能规格表更重要的是实际的UI。我将在纸上进行线框,然后进行简单的UI构建(HTML/CSS)。这可以帮助我思考用户体验,我比自己项目中的特定功能更重视。以后我总是可以回去拼凑在一起。

取决于您的设计文档的含义。

我花了1/3到1/2的时间写下我写的软件的设计,在笔记本中,勾勒出东西,弄清楚算法,关系,故事等。

我不在前面做这件事。

我没有主要的签名和密封文件。我过去曾经做过,而且我从未完成任何工作,因为我一直在等待有人签约。与我一起设计的概念相比,这是我与之相关的概念的官僚机构的问题,但我仍然更喜欢我现在拥有的流畅/敏捷方法。

许可以下: CC-BY-SA归因
scroll top