在开发开始之前，最低限度的设计/范围文档应该是什么？
我是一个初级开发人员，在项目的编程方面独立工作。
我得到了一个png文件与5-6页的设计，大多数时候在具体的细节。由此，我被要求开发维护网站所需的后端系统，通常是一个包含产品、标签和类别的编目系统，并将前端与设计相匹配。
我发现自己陷入困境，因为当我基于对网站流量的假设做出决定时，由于缺乏概述细节，我得到了纠正，并被要求重写代码以满足实际需要。
这一过程在整个项目中多次发生，经常发生在相同的细节上，直到它最终完成为止，整个项目的窗口都被打破了。
我知道项目的范围会变小，我可以理解我需要对此进行计划，但我觉得在这种情况下，我没有收到足够的大纲来有效地规划项目，导致代码中断和思维紧张。
在开始开发之前，我所收到的最小设计/范围文档应该是什么？
回答 3
Software Engineering用户
发布于 2012-09-18 06:41:59
当我根据假设做决定的时候，...，我得到了纠正
那就不要做那么多的假设--事先澄清，问吧！如果你要问的人没有时间，准备一张问题清单。每当出现新的问题时，要经常重复，也许每天都是如此！
这个过程在整个项目...中发生了多次，整个项目的窗口都是坏的。
当您多次改进代码时，它显然会变得更好，而不是更糟。如果您的代码变得更糟，这几乎每次都表明您试图一次又一次地向现有的方法和类添加新的需求，而不对代码进行任何重构，直到它们变得太大或太复杂。您可以通过更早开始重构来避免这种情况。您添加的每一个新需求都应该是在此过程中重构您的代码的机会，这样就可以更容易地添加新的需求。如果您需要更多的帮助，您将在此站点上找到大量关于重构的信息。
在开始开发之前，我所收到的最小的设计/范围文档应该是什么？
你在这里的误解是--“别人为我写下所有信息，然后我开始编码”。当你提出问题清单时，把答案写下来，并将它们添加到规范或设计文档中。然后执行你确信的事情，直到出现新的问题。对于编写设计/作用域文档的人来说，几乎不可能预见到所有的问题，所以不要指望他会这样做。最好把它看作是一个渐进的过程。当你没有问题了，并且写下了你得到的所有答案，那么你的设计/范围文档就完成了。
Software Engineering用户
发布于 2012-09-18 04:46:37
我认为，根本的问题是沟通，而不是文件。
此外，通过有效的沟通，向您的组织中的产品所有者/BA(或PM，如果没有业务分析人员)澄清客户和业务需求，将使您的生活更加轻松，并能极大地帮助您以较少戏剧性的更改集提供良好的结果。
您可能也知道，敏捷软件开发是针对上述目标的，您可以从这个参考文献中找到更多的信息。
Software Engineering用户
发布于 2012-09-19 07:50:15
我发现没有一个答案。没有黄金法则。
每个客户端和proejct都需要不同级别的规范。
不过，有一件事对所有人都很重要--沟通。尽你最大的能力，让客户了解你在做什么和为什么。一定要讨论网站的每个方面，并取消它的每一个细节。
我建议你做以下几点：-最终目标是什么。-这个网站是做什么的-谁使用它-这个网站是如何帮助商业的
目的在思考编码之前回答这些问题。在你清楚地理解了你的客户想要/需要什么之后，忘掉它，专注于实现。
我有客户给我做了一个简短的5分钟的演讲，这个系统需要2个月的时间才能展示出来。我的规范写在10页上，需要2天的开发时间。
重要的是要记住，我们为客户的bussines服务--我们为他们创造了一些东西，我们需要知道这是什么
https://softwareengineering.stackexchange.com/questions/165223
复制相似问题
腾讯云开发者
