Predictive vs Reactive软件设计

Question

我知道，对我来说，我首先开始遵循项目管理的瀑布方法，并且我采用了软件设计的预测方法。在这里我的意思是我们有大量的文档包，UML，数据库模式，数据字典，工作流，活动图等。

从事软件工作已超过10年，我发现从反应式方法进行软件设计更为现实。我经常遵循scrum方法进行项目管理，并且生成的文档很少。我们的工作流程规范很少（尽管它们仍然有用）。这是一种更加动态的软件创建方法。当然随着时间的推移经常进行重构，因为随着时间的推移我们发现我们预先计划好的新功能会大大改变一切。

我们的最大区别在于，第一种方法需要更长时间，似乎在软件构建领域更频繁地失败，并且几乎不那么灵活。第二种方法提供了更大的灵活性，使我们更快地意识到故障（因此我们可以更快地纠正），并在每次迭代结束时提供某种形式的功能。

从经验中了解双方，我仍然发现许多人喜欢瀑布式方法而不是敏捷的软件开发方法。我不明白。

问题：为什么有人会使用瀑布而不是某种形式的敏捷与所有支持敏捷的研究？使用瀑布而不是敏捷有什么强有力的论据？

Answer 1

我认为人们仍然经常坚持瀑布的部分原因是它给人一种控制的幻觉。在瀑布中，你可以做足够的前期工作来整理一个漂亮的时间表，很好地解决你能想到的每一个意外事件，然后为业务方面的任何人提出详细的路线图，询问功能X何时会出现可用。

问题在于你几乎永远不会遵循该计划，并且你几乎总是迟到/丢弃功能。然而，从前期开始，它看起来非常可控和易于管理。

我是一个敏捷的大粉丝，但我一直在努力的是销售和营销人员经常要求的长距离路线图/预测。我认为瀑布的确定性幻觉对经理和商界人士来说非常令人欣慰。

Answer 2

当我开始编程时（使用COBOL不少），瀑布是“新”方法。今天，我告诉你我使用了一种瀑布式敏捷方法。对于较大的系统，我发现瀑布式启动效果最佳。不创建大型文档（这是浪费时间IMO），而是采取一些步骤，如创建UI原型和/或用例来解决手头的业务问题。一旦我们感到舒服，我们就会解决问题，并且我们有了充分的理解，我们将进入敏捷开发模式。

要回答你的问题，我认为瀑布的主要原因是许多人不喜欢改变。改变并从瀑布走向敏捷是一件很可怕的事情。

Answer 3

我的老板告诉我。

我怀疑很多人别无选择，老老板也不会学习新技巧。

Answer 4

没有偏见，但几乎任何研究都是不科学的。

你说（强调是我的）

  

问题：为什么有人会使用瀑布而不是某种形式的敏捷所有支持敏捷的研究？使用瀑布而不是敏捷有什么强有力的论据？

但不要链接到任何研究。

这是已知非常难以实际测试的事情之一。你不能让两个相同的团队同时在同一个项目上工作，因为没有两个相同的团队。您不能让同一个团队使用两种不同的方法连续两次完成相同的任务，而第一次传递不会污染第二个。我从来没有听说过任何人设计一个可以令人信服地争论任何软件开发方法的实验（甚至统计）研究。如果你有链接，我有兴趣看到一个。

缺乏真实证据，归结为个人偏好。巧克力比香草有什么强烈的论据？

Answer 5

我将扮演魔鬼的拥护者，并指出敏捷是有缺陷的几乎与瀑布方法一样多。我不是喜欢瀑布方法的人之一，但我也不喜欢敏捷。

我对敏捷的体验并不是很积极。公平地说，我在企业环境中使用它，这使得口头上的服务变得“敏捷”，同时仍然希望我们的经理能够提前制定长期里程碑和可交付成果。

然而，我发现敏捷（特别是scrum）方法常常掩盖了设计中的主要问题。虽然瀑布为管理者提供了控制的幻觉，但敏捷似乎也为开发团队做了同样的事情。我已经看到团队提出任何不在当前sprint / iteraton中的问题是不受欢迎的，期望它会及时处理。它只需要忽略一些主要的设计决策，以便项目在未来适应不断变化，而当前的迭代进展顺利，项目看起来正在进行中。

你可以说团队因不理解敏捷的精神而有过错，但我希望看到更好的方法论，其中包含了敏捷的最佳部分。

Answer 6

（至少）XP的一个前提是变化很便宜。瀑布模型建立在改变的原则之上，任何改变都是昂贵的。瀑布模型中的假设是，一旦编写了软件，更改它比预先花费时间来对问题进行“完全”理解更为昂贵。

经验似乎表明很难完全理解问题，如果采取一些预防措施（例如单元测试），变更会变得便宜很多。因此，如果遇到某些敏捷前提不成立的问题，其他方法可能会再次变得可行。在瀑布和敏捷之间，至少有螺旋式开发，这是我们的实践。

Answer 7

你需要具有足够的预测性来交付货物。你需要足够积极地处理这些问题。

我曾经被困在六个月内完成一个估计需要一年的项目，而根据过去的经验经验需要两年。所以我花了三个月研究方法论。我们使用瀑布流程的适当部分按时（三个月）完成。

使方法工作的几点：   - 创建使用标准，在需要时更新它们。   - 构建库：做一次，做得好，修复它而不破坏现有代码。   - 做足够的文档。   - 版本控制你可以做的一切。   - 打破局面;方法应该是管理工作还是工作。   - 增加凝聚力，减少耦合，重复使用。   - 购买或构建您需要的工具。   - 跟踪您的问题和进展。

我参与的另一个项目是一个为期六个月的项目。在开始一年半之后我才参与其中。在他退休养老金计划的职业生涯中，发展领导者已被聘用为极端加价。在项目开始时，他问项目经理，“你想让我做得对吗还是被动反应？”你能猜出答案吗？我参与的那一周同样的功能是在周一，周三和周五实施的。猜猜周二和周四发生了什么？

敏捷的优势在于它足够及时地强调它。瀑布方法的优势在于它涵盖了您需要考虑的所有事情。我还没有完成一个已完成或应该完成所有步骤的项目。我曾参与许多项目，这些项目采取了应该在公司基础上完成的步骤。

Answer 8

标题说明了一切。 （实际上：主动与反应）。为什么选择反应方式并放弃控制，除非你不必？瀑布不是唯一的选择，您可以根据自己的喜好进行任何类型的开发过程。控制是关键。

这是一个频谱btw，一端的瀑布和另一端的完全反应，零文档方法。如果您在咨询行业中为强大的（通常是优柔寡断的）客户工作，则必须采用反应性方法。如果您开发了收缩包裹软件，您可以提前计划并管理知识。有些项目还需要大量的规范和规则，其中代码和修复方法不会削减它。对我来说，软件工程主要是关于知识管理和设计，编码是第二位。

P.S。没有敏捷和固定价格这样的东西。不是经典的方式，他们通常出售方法。见http://martinfowler.com/bliki/FixedPrice.html

Answer 9

如果您确切地知道从不苛刻的要求，如果您知道每个步骤需要多长时间，并且如果您知道所有资源在需要时可用，您可以做瀑布并且它将起作用。但是这些项目非常罕见，我想我永远不会参与其中。

Answer 10

在设计最终用户使用的系统时，敏捷通常很有效，因为要求可能不正确，并且过程的很大一部分是以可用版本的形式从用户那里获得反馈。

但是，在创建与其他软件接口的软件时，通常可以非常清楚地解决这些要求。在这种情况下，确保您拥有非常清晰和准确的规范通常会更高效，单元测试在此模型中，您还可以生成相当好的工作估算，并且使用敏捷模型会产生更多成本。

Answer 11

追溯行为

Answer 12

如果你有一个由十几个人组成的团队，在十年的时间里，将瀑布策略改进到适合他们的地步，你是谁进来说“你做的它错了......“？真的，如果它对他们有用，为什么要改变呢？是的，这仅仅是在解决问题，但我认为这可能是一个有效的观点。

Answer 13

在我的团队中，我们发现维护项目（这是我们所做的大部分工作）我们正在进行调整或更换，因为除了一些UI原型之外，并不总是需要用户输入。

在这种情况下，特别是考虑到涉及商业交易，宏观层面的瀑布式方法可以很好地适应。即便如此，我们仍然希望在实施层面采用增量/敏捷方法。

值得注意的是，我们的大多数客户都是喜欢他们文书工作的大型伐木组织，这为我们增添了更多的动力，至少对他们来说是传统的。

Answer 14

在瀑布流程中生成的文档允许大量的CYA。当项目脱离轨道时，您可以指责。很少有高管会说“哦，好吧，我猜这个项目离我们很远！好吧，至少我们早点发现，没有任何伤害没有犯规！”

此外，设计文档可以自动生成测试计划，这对QA非常有用。

Answer 15

在竞标合同时很常见，其中一个铁板条件是你遵循他们的“过程”，在检查时是瀑布。