logo标签列表

预测性与响应式软件设计

agilescrumsoftware-designwaterfall
9
我知道我最开始使用的是瀑布式项目管理方法，同时采用了预测性软件设计方法。这意味着我们有大量的文档、UML、数据库模式、数据字典、工作流程、活动图等等。
在软件行业工作了十多年后，我发现从反应式角度来看待软件设计更加现实。我经常采用Scrum项目管理方法，很少生成大量文档。我们几乎没有工作流程规范（虽然它们仍然有用）。这是一种更具动态性的软件创建方法。当然，随着时间的推移，随着我们发现新功能，我们需要频繁地重构，因为如果我们事先计划好了，可能会对事情产生巨大的影响。
对我们来说，第一种方法需要更长的时间，在软件构建世界中似乎更容易失败，并且不够灵活。第二种方法提供了更多的灵活性，让我们更快地意识到失败（因此我们可以更快地进行纠正），并在每个迭代结束时提供某种形式的功能。
尽管有着丰富的经验，我仍然发现许多人喜欢瀑布式方法而不是敏捷方法来进行软件开发。我不明白其中的原因。
问题：在所有支持敏捷方法的研究中，为什么有人会使用瀑布式方法？使用瀑布式方法而不是敏捷方法的有力论据是什么？
2
世界上有很多人更倾向于“熟悉和舒适”而非“改变和进步”，我们的开发者群体中也充斥着这样的人（尤其是在管理层，有趣的是）。 - Hardryv
这个问题不在本站的范围之内，因此属于不适当的话题。请参阅我可以在这里问什么样的问题？和哪些类型的问题应该避免提问？。你可以尝试在其他 Stack Exchange 网站上提问，例如[pm.se]或[softwareengineering.se]。请务必阅读帮助中心的相关页面，了解您打算发布问题的任何网站的主题内容。 - Makyen
15个回答
6
当我开始编程（使用COBOL语言），瀑布模型是“新”方法。今天，我会告诉你我使用的是类似于瀑布模型的敏捷方法。对于较大的系统，我发现瀑布式的开局效果最好。不是创建庞大的文档（在我看来这是浪费时间），而是采取一些步骤，比如创建UI原型和/或用例，以便我们理解手头的业务问题。一旦我们确信已经确定了问题范围并且我们有了充分的理解，我们就进入敏捷开发模式。
然而，回答你的问题，我认为瀑布模型仍然存在的主要原因是许多人不喜欢改变。改变是可怕的，从瀑布模型转向敏捷模式是一个巨大的改变。
6

我认为人们仍然经常依附于瀑布模型的部分原因是它给人以控制的错觉。在瀑布模型中，你可以做足前期工作，制定一个漂亮的进度表，很好地应对你能想到的每种情况，并向任何询问“功能X何时可用”的业务方提供详细的未来路线图。

问题在于，你几乎永远无法完全按计划执行，并且你几乎总是会延误/删除一些功能。然而从前期规划来看，它看起来非常受控且可管理。

我是一个忠实的敏捷方法粉丝，但我始终困扰于销售和营销人员常常要求的长期路线图/预测。我认为，瀑布模型关于确定性的错觉非常让管理者和商业人士感到安慰。

3
“控制的幻觉” 真是太好了。 - dash-tom-bang
4

我的老板让我这么做。

我怀疑很多人没有选择，老板不愿学习新的技巧。

6
找另一位老板！ - redsquare
1
+1 @redsquare - 我完全同意这一点，并倾向于四处走动，以确保我看到新技术、新设计、新方法...最重要的是新人。似乎企业人员在大约6个月到一年后就会变得陈旧。 - Andrew Siemer
3
不偏袒任何一方，但几乎任何研究都充其量都是不科学的。你说（重点在于我）：
问题：为什么有人会使用瀑布流而不是某种支持敏捷开发的方法？使用瀑布流胜过敏捷开发的强有力的论据是什么？
但没有链接到任何研究。
这是那些被认为极难实际测试的事情之一。你不能让两个完全相同的团队同时在同一个项目上工作，因为不存在两个完全相同的团队。您无法让同一团队使用两种不同的方法完成相同的任务两次，而不会使第一次操作影响第二次。我从未听说过有人设计出一项实验性（甚至统计）研究，可以令人信服地证明任何软件开发方法论。如果您有链接，我会很感兴趣。
除了真实的证据外，它归结为个人喜好。巧克力优于香草的强有力的论据是什么？
3
我将扮演魔鬼的角色并声明，敏捷方法和瀑布模型一样存在着许多缺陷。我不是那些喜欢瀑布模型的人，但我也不喜欢敏捷方法。
我的敏捷经验并不是很积极。公正地说，我在一个企业环境中使用它，该企业口头支持“敏捷”，同时仍然期望我们的经理提前制定长期里程碑和可交付成果。
然而，我发现敏捷（特别是Scrum）方法常常掩盖设计上的重大问题。虽然瀑布模型给了经理们控制的错觉，但敏捷似乎为开发团队提供了同样的错觉。我见过一些团队，任何不在当前Sprint/迭代中的问题都会受到反感，期望这些问题“及时”处理。只需要忽略几个重大的设计决策，项目就有可能在未来崩溃，而当前的迭代顺利进行，项目看起来进展顺利。
你可以争论团队没有理解敏捷精神的责任，但我希望看到更好的方法，将敏捷的最佳部分结合起来。
3
（至少）XP的前提之一是变化是廉价的。瀑布模型建立在任何变化都是昂贵的原则上。瀑布模型的假设是，一旦软件编写完成，改变它的成本比投入时间来“完全”理解问题更高。经验表明，很难完全理解问题，如果采取一些预防措施（例如单元测试），变化就会变得更加廉价。因此，如果你遇到某些敏捷前提不成立的问题，其他方法可能再次变得可行。在瀑布和敏捷之间，至少有螺旋式开发，这也是我们所实践的。
2
你需要有足够的预见性来交付产品。你需要足够的反应能力来处理问题。
我曾经卡在一个估计需要一年时间完成的项目上，只剩下六个月的时间。基于过去的经验，这个项目需要两年时间才能完成。所以我花了三个月的时间研究方法论。我们使用瀑布流程的适当部分，在规定时间内完成了项目。
使方法论奏效的几点是： - 创造并使用标准，需要时进行更新。 - 建立库：只需做一次，做好，修复时不会破坏现有代码。 - 只做足够的文档。 - 对所有可以进行版本控制的内容进行版本控制。 - 将事物分解；一个方法应该管理工作或执行工作。 - 增加凝聚力，降低耦合度，重用。 - 购买或构建所需的工具。 - 跟踪问题和进展。
我曾经参与的另一个项目是一个为期六个月的项目。我直到它开始一年半后才参与其中。开发负责人被以极高的价格雇用，因为他正在离开一份带有养老金计划的工作。在项目开始时，他问项目经理：“你想让我做得正确还是反应迅速？”你能猜到答案吗？在我参与的那一周，同一个功能在周一、周三和周五实现了。你能猜到周二和周四发生了什么吗？
敏捷的优势在于强调“足够的，及时的”。瀑布方法的优势在于它涵盖了你需要考虑的所有事情。我还没有参与过所有步骤都做到或应该做到所有步骤的项目。我参与过许多本应在公司层面完成的步骤的项目。
在处理问题时使用适合的方法。当你有期限要满足和客户要满意时，真的没有空间去坚持教条主义。+1 - hythlodayr
1
标题即内容（其实是主动 vs.被动）。为什么要选择被动的方式并放弃控制，除非你不得不这样做？瀑布模型不是唯一的选择，你可以有任何你喜欢的开发过程，并在需要时进行改进。控制是关键。
这是一个光谱，瀑布模型位于一端，完全被动、零文档方法位于另一端。如果你在为强大的（通常是优柔寡断的）客户提供咨询服务的行业工作，你必须采取被动的方法。如果你开发收缩包软件，你可以提前计划和管理知识。有些项目还需要大量的规格和规则，而编写和修复的方法就不够用了。对我来说，软件工程主要是关于知识管理和设计，编码排第二。
附：敏捷和固定价格之类的东西是不存在的。至少不是他们通常推销该方法的经典方式。参见http://martinfowler.com/bliki/FixedPrice.html。
0

如果您确切地知道永远不会改变的要求，如果您知道每个步骤需要多长时间，并且如果您知道所有资源在所需时间内都可用，那么您可以使用瀑布模型，它会起作用。但实际上，这种项目非常罕见，我认为我永远不会参与其中。

0

在设计供最终用户使用的系统时，敏捷方法通常很有效，因为需求可能是不正确的，而过程的大部分是通过可用版本从用户那里获得反馈。

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

我不确定我理解你的意思，Larry - 为什么在这种情况下使用敏捷方法会更昂贵？我与公司完成的大多数系统集成/接口工作都是采用敏捷模型，特别是因为我们在开始项目时对要集成的系统没有很好的先进了解。在主流开发中，我们在像这样的项目上使用敏捷方法之前就已经离开了标准瀑布模型。 - Chris Boran
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接