问题标签 [waterfall]

您能否给出一种可以减轻瀑布模型缺点的方法？

在过去一年左右的时间里，我的团队从 1 人迅速增长到 5 人，并且非常有兴趣将我们的开发风格从 Waterfall 转变为像 Scrum 这样更具迭代性的方法。我们在一所大学工作，专门为不断变化的需求的内部客户开发 CRUD Web 应用程序。

所以，我的问题是……我们如何最好地实施 Scrum 技术？

补充问题：是建议退出瀑布“冷火鸡”以促进过渡还是您觉得渐进的方法更有效？换句话说，挑选一些 Scrum 技术现在就实施，然后再进一步添加其他技术？

我在敏捷环境中工作，并且由于当前敏捷场景的失败（他们认为），事情已经发展到客户认为他们更喜欢瀑布的状态。让他们这样想的原因是在冲刺的最后阶段发生的大量设计级别更改，我们（开发人员）无法在他们指定的时间内完成。

像往常一样，我们都互相指责。从我们的角度来看，最后所说的更改太多，设计/代码更改太多。而从客户的角度来看，他们抱怨我们（开发人员）没有完全理解需求，并提出了“不是”他们在需求中想要的解决方案。（就像他们让我们画一只老虎，我们画了一只猫）。

所以，客户（不是我们）觉得敏捷过程是不正确的，他们想切换到瀑布模式，恕我直言，这将是灾难性的。简单的原因是他们在敏捷模式中的满意度本身还不够，那么在瀑布开发的设计阶段花费了这么多时间之后，他们将如何容忍输出呢？

请提出您的建议。

微软项目和瀑布

使用 Microsoft Project 是否会迫使您进入瀑布模型？谁能指出成功使用（d）MS Project 作为支持工具的成功迭代（例如敏捷）项目的示例？

显然，应用这两种方法对团队、客户、投资回报率等的影响是巨大的，并且是许多书籍和无休止的讨论和会议的主题。

但是当我想得更多时，我很难找到两者之间的任何差异，这些差异最终不会映射到一个单一的根差异，即发布频率。

瀑布花时间在设计上，然后是编写代码，然后是测试，最后是发布。但是敏捷执行完全相同的一组步骤——只是每个步骤都更小。

敏捷方法的一个关键部分是从每个版本中学习并使用它来让更大的设计出现，而不是在一开始就试图预测它。

但瀑布也这样做。只是瀑布团队不是每 3 或 4 周学习一次，而是每 6 或 9 个月才学习一次。但瀑布设计仍然出现。也就是说，瀑布式第 2 版将反映第 1 版中学到的内容。所以这个过程没有什么不同，只是它以不同的速度执行。

敏捷专注于密切的客户协作。但瀑布也这样做。只是由于瀑布的迭代时间较长，因此更需要以合同形式列出的需求列表，以使每个人在很长一段时间内都保持在同一页面上。但同样，这只是频率的产物。交付频率越高，对合同的需求就越低。

是否还有其他我遗漏的原始差异 - 或者它真的只是频率？

我们需要堆叠瀑布图（我们正在使用 highcharts.com）。 http://fiddle.jshell.net/8JP8T/提供了创建瀑布图的选项，但我们需要创建堆栈。以前有人做过吗？谢谢 ！！

我对 SDLC 和软件过程这两个术语有些混淆。关于这些（或多或少相似）术语，有几个问题。

1. SDLC 和软件过程有什么区别？（我了解 SDLC 不仅仅是瀑布）。
2. 我们可以用统一流程映射 SDLC 吗？
3. 关于活动-传统瀑布模型中的分析，我们是否在统一流程中进行分析（任何统一流程-敏捷或理性）？

首先，我不考虑那个。

我想知道如何在 iPhone 上对一些沙丘上的瀑布进行简单的模拟。

事实证明，有几个人解决了移动水的问题，GameDev 已经多次接近这个想法。然而，所有这些解决方案似乎都是计算密集型的（这是有道理的，因为水是一种流体，而流体力学很复杂）。我对捷径很感兴趣，因为模拟是否准确并不重要，只是它看起来准确。

有人问如何在 DirectX 上使用 (Navier-) Stokes 进行模拟，使用 1500 个粒子。他说他的结果是参差不齐的。当然，在 iPhone 上，这将是这种事情的 OpenGL ES 实现。

另一个好心人试过用Chipmunk的物理引擎，但是听上去像是用战车杀蚊子，还是带来了很多很多粒子的问题。所以我现在想知道使用类似于 这种压力管理技术的技术是否合理，以便管理流体的宏观状态，并使用粒子管理边缘，以最小化总计算。

如果你有好的想法，请提出要测试的东西。

编辑 08/06/2015：我在Thimbleweed Park博客中发现了 Joseph Huckaby用 HTML5 完成的一项非常古老的技术的一个很好的例子。它只是与环境相关的，因为它只与外观有关，而不是与物理有关，但为什么不粗略地模拟流体，并用调色板循环效果覆盖“液体区域”呢？当然，由于该技术更多地依赖于艺术元素，它移动了艺术家领域的难度。然而，渲染代码在混合时有点密集。

我有一系列光谱数据，我想在瀑布式图中绘制。瀑布本身没什么用，因为细线在每个光谱中有太多的差异，那不是很有用

因此，我想尝试功能区功能，这在docs 中看起来很有希望。

但结果完全不同，也没用！

编辑：

我现在创建了一个手动瀑布图，它接近我想要的：

尽管如此，我仍然对原始问题的解决方案感兴趣。

编辑2：

这是一个使用瀑布、功能区和我的自定义代码的相同数据的示例。只有我的代码可用于可视化数据。我仍然想知道如何使丝带和瀑布看起来像一个体面的情节......

此代码现在用于创建一些数据

这是使用功能区的结果

这里有瀑布

为了比较使用我自己编写的代码的绘图，它类似于瀑布，但没有深度轴。然而，它是唯一一个看起来不错并显示数据曲线的模型，以便可以看到每条曲线之间的变化。

我已经阅读了很多关于敏捷和瀑布的信息，但我想不出今天有人应该做瀑布的任何理由。我特别关心测试过程。我是否错过了什么，是否有一些我忽略的明显优势？