没有银弹！

没有一个尺寸的裤子适合所有人穿，没有银弹，没有一个解决方案适合所有场景。本文概述了各种软件方法学。
为什么软件方法学都不同？
软件方法论主要是为了对付风险而生，因此方法学规定了特定的日常流程或一系列行动，因此他们还规定了管理软件项目风险的特定方法。

方法论是暴露隐藏风险......
我们引入了一种开发团队在构建软件时可能遵循的软件方法，它包括分析，编码和测试等步骤，而且，我们研究了每个操作的是如何管理软件交付过程中的风险。例如，开发人员无需知道他的编码是否会破坏“功能Y”，因为该编码功能的集成测试部分会在测试阶段主动暴露这种隐藏的风险，而不是让它浮出水面生产（它变得更加昂贵）。

这里介绍有一些不同的软件方法简单的介绍一下，并试图解释为什么它们是不同的。让我们从瀑布开始。

瀑布

“瀑布式开发模型起源于制造业和建筑业;高度结构化的物理环境意味着设计变更在开发过程中变得非常昂贵。” - 瀑布模型，维基百科

瀑布是一系列方法论，倡导对提供软件系统所涉及的过程采用线性逐步方法。瀑布式方法背后的基本思想是软件过程分为不同的阶段，通常包括：

• 需求捕获
• 规格
• 履行
• 验证
• 交付和运营
• 在每个阶段签字

错误的风险？
在建筑场景中，这很有意义。但是，软件项目与构建项目不同。应用于软件时，瀑布方法有两个主要批评：
“1.客户在看到可运行的软件之前可能不知道他们的需求到底是什么，因此如果他们改变需求，导致重新设计，重新开发和重新测试，并增加成本。”
“2.设计人员在设计新的软件产品或功能时可能不会意识到未来的困难。” - 瀑布模型，维基百科

因此，当瀑布应用于软件时，瀑布规定的可以减轻建筑行业返工和成本超支的解决方案却并不能解决（并且可能加剧）上面提到的两个问题。
无法管理这些风险导致在1970年代确定了“软件危机”：
软件危机是计算科学早期使用的一个术语，因为它难以在所需的时间内编写有用且高效的计算机程序......软件危机是由于计算机能力的迅速增加和问题的复杂性造成的。无法解决。“ - 软件危机，维基百科

敏捷
软件危机表明，在很多时候，前期需求 - 捕获，规范和固定价格出价几乎无法管理软件项目的成本和进度风险。因此，到了20世纪90年代，各种不同的软件工程师团体都在倡导“敏捷”技术。

在极限编程解释中，Kent Beck列出了他想要解决的风险以及他提出的解决这些风险的行动。这些风险与瀑布所解决的风险不同，不出所料，不同风险也会导致不同的行为。

针对不同风险的不同方法
以下是我们在其他一些流行方法中看到的一些高级别差异：

• 精益软件开发：瀑布借鉴了建筑行业的风险管理技术，而精益软件开发应用了上个世纪制造业丰田开发的精益制造原则。Lean认为制造业面临的最大风险来自浪费，浪费代表库存、过度生产、在制品、等待时间或生产缺陷，将此方法应用于软件意味着最大限度地减少在制品，频繁发布和持续改进。
• 项目管理知识体系（PMBoK）：这是传统项目管理实践的形式化。它规定了管理项目范围，进度，资源，通信，依赖关系，利益相关者等的最佳实践。虽然“风险”被视为一个单独的管理实体，但上述所有领域都是项目中的风险来源，我们将在后面看到。
• Scrum：是一种流行的敏捷方法。可以说，它比极限编程更“极端”，因为它促进了一组有限的，更可实现的敏捷实践，例如频繁发布，每日会议，产品所有者和回顾。这种简单性可以说更容易学习和适应并且可能有助于Scrum比XP更受欢迎。
• DevOps：许多软件系统在“开发中”和“生产中”之间的边界上挣扎。DevOps是对此的肯定，并且是关于更紧密地调整开发人员和生产系统之间的反馈循环。它支持诸如持续部署，自动发布和自动监控等活动。

效果
“所有方法都是基于恐惧。你试图设定习惯，以防止你的恐惧成为现实。” - 极限编程解释，Kent Beck

任何一种方法论都是承诺它将帮助您管理某些隐藏的风险。但这是以牺牲您对方法实践的努力为代价的。基于方法设计者关心的风险，方法论为我们提供了克服风险的途径。当我们使用该方法时，这意味着我们正在考虑如何采用我们的行为才能避免这些风险。

方法论失败​​​​​​​
当我们根据一种方法采取行动时，我们期望能如愿以偿，如果这没有实现，那么我们觉得这种方法失败了。它可能只是对我们正在运行的项目类型不合适。我们自己的风险目标可能不是该方法设计者所设想的那样。例如：

• 在发射太空飞船时，美国宇航局不遵循敏捷方法：没有两周发射一次，他们不可以迭代，因为失去火箭或卫星的风险太大，这不允许在生产中迭代。风险方向完全不同：您需要管理因需求变更风险而丢失硬件的风险。
• 同样，政府监管项目通常需要大型的前期的瀑布式设计：让政府机构的满意往往表明您需要有一个精心规划的实现监管的途径。通常，监管机构和其他利益相关方在实施之前需要对变更进行审核和批准。使用“迭代几个月”的方法无法做到这一点。
• 另一方面，Facebook曾经采用 “快速行动，打破它”的方法。当他们尝试降低在快速发展的社交网络领域中被竞争对手超越创新的风险时，这可能是最佳的。 现在他们已经对此进行了修改，以“在稳定的基础设施中快速行动”，这可能反映了他们最大的风险不再是竞争，而是糟糕的宣传。

选择方法论
采用一种方法作为一个完整的过程集合是有价值的：选择一种方法（或任何过程）可以减少个人必须做的思考量，但是它也会成为导致失败的原因。

把责任归咎于其他地方真好。但是，如果我们真正关心我们的项目，那么我们必须将方法选择与项目的风险概况相匹配。我们需要准确理解我们的方法可以帮助我们管理风险，以及它不会提供哪些风险保证; 哪里合适用，哪里不合适用。

“鉴于任何规则，无论科学上是”基本的“还是”必要的“，总有一种情况是，不仅要忽视这一规则，而且要采取相反的规则。” - 保罗费耶阿本德

现成的方法不太可能完全符合任何项目的风险。有时，我们需要将方法分解为其组件实践，并仅应用我们需要的实践。这需要对个体实践如何运作以及它们带来什么有更细致的理解。