对于那些在大型设计前/瀑布群体中工作的人:在您的设计阶段跳过了多少批判性思维和设计?在设计阶段结束时,您的功能和技术规格如何完整和详细?

在我看来,在设计阶段结束时需要提供的细节水平上有很大的解释空间,当设计阶段急忙时,我会感到烦恼就像我们在装配线上淘汰小部件一样,进展。另一方面,一个完整的设计阶段,可以使构建阶段像组装线一样运行,实际上包括与之的实现阶段 - “构建”中所有的内容都是将内容键入编辑器。当然,这也意味着您的设计阶段是巨大的。

我意识到这是瀑布模型的缺点, ,但是,如果有人可以提供一些建设性的建议:一个人在哪里绘制界限?对设计和建造阶段的期望应该是什么?在构建阶段不应该/不应该容忍什么样的设计缺点或错误?

有帮助吗?

解决方案

我是快速原型,快速增量和快速迭代的忠实拥护者。进化而不是“智能设计”。您正在编写软件来解决人们和人们的问题,往往会随着时间的流逝,甚至短时间的时间来改变他们的主意和需求。

获得要求,鸟眼的视图和编码前尽可能地“签名”是很不错的选择,但是没有什么意义是教条的,所有的都是液体。准备好进行编辑,修改和丢弃代码。有趣的是,无论如何,您永远都不会到达完整点...大多数代码在人们关心它时似乎都在改变,然后一旦没有人在乎,它就会被删除。

现在可以肯定的是,这将不适用于飞机控制系统,核反应堆控制等的第一个工作,但我的猜测不是您的情况。

其他提示

在设计阶段总会有一些错过的东西。人们是不完美的,即使拥有完美的管理,可以允许大量的设计阶段时间而没有推动实施的压力,也会错过一些事情。

同样,在设计中,您输入回报率降低的点。例如,如果设计用户界面并在规格中编写该界面,则可以迅速达到规格包含布局,格式化和表单的所有逻辑的点。在这种情况下,它与实施几乎相同,也许只有凌乱的代码胶是不同的。

您确实需要查询将设计推得太远的价值:当设计变成编写代码时,因为这是传达您意图的最清晰的方法,是时候询问是否足够了。

因此,实施将开始发现遗忘或错过的东西,以及其他似乎很容易但事实并非如此的实施细节。 (也许您认为您可能会从某些库或操作系统获得的服务并不像预期的那样……您需要进行一些挖掘或编写大量新代码作为工作,或补丁。)

瀑布是一个可爱的简单模型,非常适合向管理层解释。它也与现实中发生的迭代和混合高水平 /低水平思维相距甚远。


关于这一点的评论更有趣,可以在一本旧书中找到:埃德·莫登(Ed Yourdon)的《美国程序员的衰落和衰落》。

我知道这不是一个完美的答案,但是编程和设计方法也不是完美的。最好的方法是将它们视为完成工作的有用系统。规则在那里可以帮助您,并在妨碍您时被打破。规则的违反应该是聪明地完成的,这不仅是因为有人从第1天开始剪裁代码。

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