我从来没有写过功能规范,我更喜欢跳进代码并设计出去的东西.到目前为止,它的工作正常,但对于最近的个人项目,我正在写出一些描述产品所有功能的规范,以及如何"工作"而不详细说明它将如何实现,我就是发现它很有价值.
您有什么想法,您是否编写规格或者您是否只是开始编码和计划,哪种做法更好?
如果您从家里开车到最近的杂货店,您可能不需要地图.但...
如果你开车到另一个州以前从未去过的地方,你可能会这样做.
如果你随意驾驶以获得驾驶的乐趣,那么你可能不需要地图.但...
如果你想以最有效的方式到达某个地方(最小化距离,最小化时间,沿途进行三次特定停留等),你可能会这样做.
如果您自己开车并且可以随心所欲地停留,只要您看到有趣的事情或重新考虑您的目的地或路线,您可能不需要地图.但...
如果你是作为车队的一部分驾驶,并且所有人都需要一起做饭和过夜住宿,并且需要一起到达,你可能会这样做.
如果你认为我不是在谈论编程,你可能不需要功能规范,故事卡,叙述,CRC等等.但是......
如果你认为我是,你可能想要至少考虑上述之一.
;-)
对于那些"跳入代码"和"设计他们去"的人,我会说包括功能规范在内的任何内容都比你当前的方法更好.如果你花时间思考并在开始之前设计它,可以节省大量的时间和精力.
需求有助于定义您需要做什么.
设计有助于定义您计划制作的内容.
用户文档定义了您所做的事情.
您会发现大多数地方都会对这三个文档有一些变化.功能规范可以集中到设计文档中.
如果你不相信,我建议阅读快速发展.如果你花更多的时间来计划和设计,你真的可以更快地完成工作.
大型软件项目的"直接代码"跳跃几乎肯定会导致失败(因为immediatley开始构建砖块来构建桥梁).
在这些家伙37点的信号会说,最好是写在纸上的短文档比写一个复杂的规范.我想说,这可能适用于快速模拟新网站(设计和想法可能比刚性模式更好),但在其他现实生活中并不总是可以接受.
只需考虑客户签署的规范文档可能具有的(合法,甚至)重要性.
根据您的项目情景,士气可能是:灵活,并根据您的需要计划功能或技术规格.