软件开发方法论

瀑布模型（Waterfall Model）
该方法论按照线性顺序，分阶段进行开发，每个阶段的结果都必须完成后才能进入下一个阶段。

喷泉模型（Fountain Model）
该方法论是瀑布模型的一种变体，加入了迭代的思想，让软件开发成为一个不断迭代的过程。

敏捷开发（Agile Development）
该方法论强调快速响应变化、以人为本、小步快跑等理念，通过多次迭代、快速原型实现来快速交付符合客户需求的软件。

DevOps
该方法论将开发和运维结合起来，旨在加速软件开发、部署和维护的过程。

软件工程（Software Engineering）
该方法论强调对软件开发进行规范化、标准化、工程化管理，旨在提高软件开发的效率和质量。

DDD（领域驱动设计，Domain Driven Design）
该方法论关注软件系统的业务模型和业务逻辑的设计，强调将业务问题和软件实现结合起来，从而更好地满足用户需求。

TDD（测试驱动开发，Test-Driven Development）
该方法论强调在编写代码之前先编写测试用例，从而更好地确保代码的正确性和可靠性。

为什么软件方法论会令人觉得糟糕？

在围绕软件开发实践和方法论的宗教战争中，
有很多教条。相门方法在管理软件开发风险方面是有效的，还是仅仅在风险管理歌舞伎方面是有效的？TDD真的能生产出更高质量的软件吗？结对编程是代码审查的优秀替代品，还是只是提高咨询费率的一种方式？我要说的是，虽然缺乏科学证据来决定这些说法，但有两个一般原则可以帮助我们选择良好的实践，同时提高我们提供的软件的价值：缩短周期时间和增加反馈。
Michael Feathers提出以下觀察：
我认为，最终，我们只需要接受开发人员技能是一个比语言选择或方法上的细微差别更重要的变量1。坦率地说，我想我们都知道这一点，但我们似乎陷入了一种错觉，即它们是调整的主要旋钮。也许这是根深蒂固的观点的延伸，即从经济角度来看，如果人们可以互换，那将是理想的。
问题是，我们如何获得熟练的开发人员？由于IT中个人生产力的概念从未得到令人满意的定义，因此这是一个特别难以解决的问题。代码行数 - 仍然是一种流行的措施 - 遭受了毁灭性的缺陷，即一行代码是一种负债，而不是人们通常认为的资产。衡量工作小时数会鼓励英雄行为 - 但经验表明，"英雄"通常是那些通过早期承担不可接受的风险而导致项目延迟的人，长时间工作使人们愚蠢并导致软件质量差。对于IT专业人员来说，仍然没有一套普遍接受的专业标准或特许制度，招聘优秀的人才在很大程度上是一门艺术，而不是一门科学。
心理学家至少已经解决了为什么获得和衡量IT技能如此困难的问题。正如丹尼尔·卡尼曼（Daniel Kahneman）在《快速和缓慢思考》（Thinking Fast and Slow）一书中所说，"获得一项技能有两个基本条件：一个足够规律、可以预测的环境;一个可以预测的环境。[和]通过长期练习学习这些规律的机会。
但传统的软件项目与常规的、可预测的环境相反。衡量项目成功与否的唯一良好标准 - 最终结果是否在其生命周期内创造了预期的价值？- 与导致成功或失败的关键决策相距甚远，以至于原始团队中的任何人都很少在场以获得反馈。几乎不可能确定哪些决策导致了成功或失败（在人工智能中，这被称为信用分配问题）。
这些因素使得IT专业人员很难获得导致成功的产品和服务的技能。相反，开发人员获得的技能使他们能够最有效地实现激励他们的目标 - 通常宣布他们的工作尽快"开发完成"，而不管功能是否集成和生产就绪 - 并且类似的问题也出现在其他功能领域。
软件项目是复杂的系统而不是常规环境这一事实导致了另一个问题 - 收集关于哪些技术，实践和方法实际有效的数据极其困难，并且几乎不可能在收集的上下文之外推广这些数据。
在他的优秀著作《软件工程的妖精》（The Leprechauns of Software Engineering Laurent Bossavit）中，对软件开发民间传说进行了毁灭性的攻击，例如"更改成本"（或"缺陷成本"）"曲线"，声称开发人员生产力的差异是一个数量级，确定性锥体的概念，以及软件开发中方法论知识的许多其他基石。他表明，这些理论——以及许多其他理论——依赖于非常小的数据集，这些数据要么是从计算机科学学生的非正式实验中收集的，要么是不可能得到有效控制的项目。构成这些说法基础的研究的组织在方法论上往往不健全，数据分析不善，而且最令人震惊的是，研究结果的普遍性远远超出了其适用范围2。
因此，不可能认真对待任何关于敏捷开发实践是否比瀑布式开发实践更好的一般主张，反之亦然。"思想领袖"的直觉也是一个糟糕的指南。正如卡尼曼所说，"人们对直觉的信心并不是他们有效性的可靠指南......在评估专家直觉时，你应该始终考虑是否有足够的机会学习线索，即使在常规环境中也是如此。正如 Ben Butler-Cole 在他的姊妹篇"为什么软件开发方法论摇滚"中指出的那样，引入新方法的行为本身就可以产生该方法采用者想要带来的一些结果。
你可能会认为，在决定如何管理团队时，这让我们处于一个不可能的位置。但是，考虑一下为什么软件开发不是一个常规的环境，以及为什么运行实验，获得技能以及衡量哪些实践和决策导致成功以及哪些导致失败是如此困难。所有这些情况下的根本原因 - 环境不规则的原因 - 是进行更改和理解更改结果之间的反馈循环太长。这里的"变化"一词应该非常笼统地理解为需求的变化，方法的变化，开发实践的变化，业务计划的改变，或者代码或配置的改变。
缩短周期时间有很多好处 - 这是我们将精益思维应用于软件开发时出现的最重要的原则之一。短周期时间对于创造伟大的产品当然是必不可少的：正如Bret Victor在他令人兴奋的视频"原则发明"中所说的那样，"如此多的创造是发现，如果你看不到你在做什么，你就无法发现任何东西。
但对我来说，这是关键：我们几乎不可能实践持续改进，学习如何作为团队或个人变得更好，并获得能够成功创造伟大产品和服务的技能 - 除非我们专注于尽可能短地获得反馈循环，以便我们能够实际检测相关性， 并辨别因果关系。
事实上，从想法到反馈的周期时间短的好处非常重要，它们应该成为您商业模式最重要的标准之一。如果您必须决定是将产品创建为用户安装的软件包还是软件即服务，那么这种考虑应该会将您推向软件即服务的方向（我在这里根据经验发言）。如果您正在构建一个涉及硬件的系统，请弄清楚如何尽快获得原型，以及如何将硬件和软件模块化，以便您可以快速独立地更新它们。3D打印可能会在这一领域产生巨大影响，因为它允许将软件开发实践应用于硬件系统的演变。如果你想实现足够短的周期时间，在跨职能团队中工作或多或少是一个要求。
软件方法论——甚至是"雇佣一群很棒的人，让他们自我组织"的方法——很糟糕，因为它们经常导致货物崇拜行为：我们正在做单口相声，我们有一个优先的积压工作，我们甚至为了善良而练习持续集成 - 为什么我们制作的东西仍然很糟糕和迟到？因为你忘记了最重要的事情：建立一个尽可能快地学习和适应的组织。