软件危机

软件工程师的困惑：软件具有太多的不确定性，软件工程师每天日复一日的工作，大多数面对的都是自己目前不知道答案的问题。我们依赖着过去的经验，朝着大致的方向，努力地解决一个又一个问题。但历史的经验并不解决未来的问题，反面太多成功的经验可能会让我们陷入经验主义。我们也会经常责怪前人犯下的错误，需要我们去应对。我们讨厌需求的变更，它让我们曾经的付出付诸东流。变更是软件开发中不可避免的，所以我们在任何的阶段都要去适应变。即使软件发布了，也不可能一劳永逸，它像一个生命体还得继续维护。

从软件项目管理角度的困惑，软件存在所谓的软件危机：软件的开发进度难以预测；软件的开发成本难以控制；软件的功能难以满足用户；软件的产品质量无法保证；软件产品难以维护…..

正如《人月神话》中描述的一样：

正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷入越深，最后无法逃脱灭顶的灾难。

软件工程学试图通过建立并使用良好的工程原则，以经济的成本方式，在目标的运行环境上，获得可靠并高效的运行软件。从早期的CMM，到传统的敏捷方法（Scrum/极限编程），到现在DevOps研发模式，以及各大厂产品线级工程实施。都在不同的阶段不同的场景一定程度地缓解了软件危机。

软件工程

软件工程学，就需要研究软件进行的一般规律，通过应用方式、方法，并持续进行改良研究。那又我们又如何理解软件工程？软件工程应该是也符合一般的工程性原则，包含规范化的过程，强调工具化和文档化。为了遵循实用性的原则，经常需要做多方面的权衡。

软件不像其它的项目工程，有些它自身独特的困难。软件是抽象的、不可见的、人思维逻辑的产物，容易变化也很容易变得很复杂。软件产品本身是去解决其它领域的问题，并可以应用于几乎所有领域，而领域差异性和多样性很强。

因此，不同的领域软件玩法可以差别极大，没有一套放之四海而皆准的打法。比如嵌入式系统与互联网的电商系统它们的技术体系与应用场景差异性很高。虽然软件工程的一般原则和思想像哲学一样可以高度概括都适用，但具体的实施方法和技术层面存在很大的差异。

工程文化

既然没有放之四海而皆准的打法，但还是有些实用的工程文化。

有效运转：让软件开发这事可以有效地运转起来。在适当的地方选择性的应用相关理论，方法和工具，即使没有可用的理论与方法，也会有试图发现问题的解决方案。在组织和经济约束如商用策略，成本，时间约束等条件下工作，并且必须考虑在这些约束之下寻求解决方案，没有约束是不可能也不现实的。

权衡决策：不要做一个完美的软件产品，追求实用而非完美，在进度与预算范围内追求品质，不同的方案中做权衡取舍决策，正如敏捷中所提倡的做刚刚好的系统。

精益敏捷：根据具体情况选择合适的方法，一般采用系统化、有组织的方法以实现高质量的软件开发。更加灵活、支持快速变化的开发方法在某些情况下是适用的，例如小规模的Web系统或移动应用。充分考虑软件的特点，就像需要市场经济与计划经济相结合，采用去中心的决策机制，分层授权，精益与敏捷相结合原则。

善于复用：利用已有的软件知识开发新的软件。通过复用封装专家知识，多次复用的软件经过检验，质量更可靠，复用软件成本可知，不确认性更低一些。复用能减少软件开发的和确认的时间，复用也使得实现更加的标准和统一。

加强协作：促进软件研发、运营与客户之间的沟通、协作，通过快速反馈提升软件的用户体验和研发效率。注重彼此之间的沟通，持续交付可靠且满足预期的软件产品与服务，降低不必要的返工和成本。