迄今为止，我们了解了不少软件工程的方法论。
瀑布模型
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型有以下优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
大泥球
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.
大泥球发生的主要原因可以归结为：
一次性代码
碎片式增长
为了让软件不出问题
Copy/paste导致问题转移（有问题的代码被复制到很多地方，不断蔓延）
尽管涌现出各种鼓励、促进良好结构代码的开发方法，软件技艺运动也在不断成长，但是“大泥球”仍然是最常见的软件设计，即使人们已经从过去恶劣的设计中学到了东西，但在新的开发过程中，大泥球仍未消失。
银弹
银弹，被引申为解决问题的有效办法。IBM大型机之父福瑞德·布鲁克斯在1986年的论文《没有银弹》中表达了他的观点：软件工程中不存在银弹——没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。这篇经典论文的核心论述通常被解释为复杂的软件工程问题无法靠简单的答案来解决。
布鲁克斯认为，软件开发的困难主要分为两类：
本质性困难：软件本身在概念（conceptual）建构上存先天的困难；亦即如何从抽象性问题，发展出具体概念上的解决方案。
附属性困难 ：将概念上的构思施行于电脑上，所遭遇到的困难。
附属性困难解决：开发工具的完善，如高级语言的出现，分时技术以及统一的开发环境等；
本质性困难解决：原因：复杂性（complexity）、隐匿性(invisibility)、配合性(conformity)、易变性(changeability)
目前解决方法的探索：高级语言、面向对象编程、人工智能……
敏捷
敏捷软件开发从被提出之后就收到了广泛的关注，其从传统开发中剥离开自成一体，逐渐占据软件工程学界的半壁江山，与传统软件开发分庭抗礼。在长期的软件工程发展中逐步形成敏捷型和传统型软件工程相辅相成，并渐渐被软件开发团体认可并运用于实际中。
敏捷型软件开发不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人，及突出了人作为软件开发的核心，在软件开发中起到的价值。它采用的是迭代式开发敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷型软件开发方法有很多，目前较为被认可和接受的是SCRUM编程和XP编程，及极限编程。在软件开发过程中，将项目切分成几个子项目，以最核心的功能为起点进行软件开发，每当一个阶段的软件开发结束，就交付一个阶段的可用开发成果，并且在保留可更改的能力的情况下对于代码进行优化，总结和经验分析。
总结
作为有理想的软件工匠，我们一直身体力行，提升专业软件开发的标准，并帮助他人学习此工艺。通过这些工作，我们建立了如下价值观：不仅要让软件工作，更要 精益求精；不仅要响应变化，更要 稳步增加价值；不仅要有个体与交互，更要 形成专业人员的社区；不仅要与客户合作，更要 建立卓有成效的伙伴关系。也就是说，左项固然值得追求，右项同样不可或缺。
提升我们所提供软件的价值：划小开发周期以及提升反馈效率。
要建立一个学习能力和适应能力都很好的组织。