软件工程专业毕业，从事软件开发工作将近十年了，近来我重看一些软件工程书籍，回顾着这些年的软件开发经历，越发有一种冲动：结合这些年软件开发的经历，倾述当前软件过程管理中的行业现状。当然我所说的并不一定就是正确的，权当作是一种经验总结。
回顾十多年前，软件开发工作还是由英雄人物似的程序员主导，一个牛X的程序员就可以完成一个软件项目。但软件发展到今天，一个软件或一个系统动辄都是几十万行上百万行代码，软件越来越复杂，项目周期要求越来越短，一个人单打独斗完成一个项目是越来越不可能了。而我从事的行业————车载娱乐系统（未来或叫车身电子），又是一个比较特殊的行业，这并不是传统的IT企业：它需要传统应用软件的友好的交互性，又需要有汽车行业的严格和安全性;它需要在一个固定的开发周期内达到一个很高的软件质量；它不是一个纯粹的软件开发，必须依托于特殊的硬件（即嵌入式开发），依托工厂生产。因此近些年，车载行业越发意识软件工程的重要性：即如何通过软件工程的理念，保障软件开发过程能像其他生产过程一样，保质保量按期完成。
第一准则：没有“银弹”
十年前的大学课堂里，第一次接触到软件工程的概念。当然当时因为缺乏实践经验，并不能完全理解里面的概念理论。但是直觉非常强的我，在第一次接触到软件工程的理论后，感觉在软件过程中有两个过程是非常重要的：需求与测试。在往后的工作中，也越发证明我当时直觉的准确性，但是行业现状决定了，我所在过的企业几乎没有企业认识到这两个过程的重要性（当然现在除外）。
我们学校的课程里，非常与时俱进地开设了当时非常流行的工具与方法：UML工具、CMMI过程改进等。谈到CMMI这门课程时，不禁让我回想到这门课程的课本厚厚得犹如牛津英汉大词典，老师在课堂上讲到CMMI时两眼放光，仿佛CMMI是一个神器似的方法，说多少著名企业多么推崇它。当时在课外时间里，我已经在看《人月神话》，这本书可以说是我软件工程思想的启蒙书籍，我个人非常推崇，因为它道出了软件工程学中一个非常重要且在未来很长一段时间都将成立的 第一准则：软件工程中，不存在解决软件危机的“银弹”。
老师在课堂上还讲述着：目前中国的IT企业正争相进行CMMI认证，目前为止中国企业没没有几家能够过CMMI3的认证，能过CMMI4的更是凤毛麟角。我在课堂下听着嗤之以鼻，深为中国的劣根性感到悲哀：中国国人的功利性导致国人不管这种方法是否适合自己就一拥而上。我当时的想法是：不管任何过程方法，适合自己的团队自身的企业才是最重要的。说白了CMMI也只是评判一个企业软件开发能力的标准，但并不是唯一标准，并不需要奉若皋圭：因为“软件工程中不存在银弹”。 CMMI真正的核心只有一个：持续的过程改进。
当时在新华书店里，我还看到了当时最流行的软件开发过程方法：XP极限编程。我当时在书店并没有细看，只是浏览了目录和翻看选看了一些感兴趣的内容。并不是我认为XP极限编程的观点不对（毕竟这本书籍影响了一代人），只是我对软件工程中的所有方法论都抱着一视同仁的态度：软件工程不存在适用于任何情况的通用过程方法。当时感觉CMMI和XP就像中国武侠小说里的两个极端：一个是堂堂皇之的名门正派的玄门功法，讲究循循渐进；一个是剑走偏锋的“魔道”武功，另辟蹊径闯出一条血路。简而言之就是“气宗”和“剑宗”的区别：CMMI适合大型企业的软件开发机制的完善，讲究机制的完善和文档的完整，非常消耗人力物力，但走在正确的道路上，不是技术出身的管理层也可以进行监管；XP适合小型的开发团队，讲究效率与沟通，以快速的应变来解决软件开发中的问题。在小型的开发团队里推行CMMI的管理方法，虽然不能说这样做一定不会成功，但这会使这个小团队陷于文档的“沼泽”中，开发人员一定会问：我们花这么多人力物力，但收效甚微，这样做值得吗？同样，在大型开发组织中广泛推广XP也不能解决大部分问题，虽然XP中的很多方法和思想到现在仍然很有用：例如“测试先行”、“简单设计”、“捉队编程”、“编码规范”、“代码重构”、“迭代开发”和“每周工作40小时”等。但XP的核心“用沟通替代文档”在大型的开发组织里是不适用的，因为这里涉及到 软件工程学中另一个重要准则：“沟通成本：1+1<2”。
我是一个深受中国传统文化影响的人：当年那个学期里，除了在课堂里接受软件工程的课本学习，我在课外时间里还花大量的时间研究“易经”。我骤然发现“易经”的思想在软件工程中是非常切合的，因此在CMMI这门课程的的课设我写了一个脑洞大开的论文：CMMI的易经模型。当时我只是感觉CMMI太过庞大，用易经的思想来简化CMMI模型，说不定可以适合小型开发团队。现在回想起来，当时的想法放在现在仍然很具有创造和前瞻性，但非常可惜，当时只保存了电子文档，但论文的电子文档发给老师后就消失在我的历史长河中了，虽然当时有在台湾某知名博客“XX小筑”和微软的博客MSN发布过，但这两个网站正如我的论文一样消失在历史的长河中。
回顾十多年前，软件开发工作还是由英雄人物似的程序员主导，一个牛X的程序员就可以完成一个软件项目。但软件发展到今天，一个软件或一个系统动辄都是几十万行上百万行代码，软件越来越复杂，项目周期要求越来越短，一个人单打独斗完成一个项目是越来越不可能了。而我从事的行业————车载娱乐系统（未来或叫车身电子），又是一个比较特殊的行业，这并不是传统的IT企业：它需要传统应用软件的友好的交互性，又需要有汽车行业的严格和安全性;它需要在一个固定的开发周期内达到一个很高的软件质量；它不是一个纯粹的软件开发，必须依托于特殊的硬件（即嵌入式开发），依托工厂生产。因此近些年，车载行业越发意识软件工程的重要性：即如何通过软件工程的理念，保障软件开发过程能像其他生产过程一样，保质保量按期完成。
第一准则：没有“银弹”
十年前的大学课堂里，第一次接触到软件工程的概念。当然当时因为缺乏实践经验，并不能完全理解里面的概念理论。但是直觉非常强的我，在第一次接触到软件工程的理论后，感觉在软件过程中有两个过程是非常重要的：需求与测试。在往后的工作中，也越发证明我当时直觉的准确性，但是行业现状决定了，我所在过的企业几乎没有企业认识到这两个过程的重要性（当然现在除外）。
我们学校的课程里，非常与时俱进地开设了当时非常流行的工具与方法：UML工具、CMMI过程改进等。谈到CMMI这门课程时，不禁让我回想到这门课程的课本厚厚得犹如牛津英汉大词典，老师在课堂上讲到CMMI时两眼放光，仿佛CMMI是一个神器似的方法，说多少著名企业多么推崇它。当时在课外时间里，我已经在看《人月神话》，这本书可以说是我软件工程思想的启蒙书籍，我个人非常推崇，因为它道出了软件工程学中一个非常重要且在未来很长一段时间都将成立的 第一准则：软件工程中，不存在解决软件危机的“银弹”。
老师在课堂上还讲述着：目前中国的IT企业正争相进行CMMI认证，目前为止中国企业没没有几家能够过CMMI3的认证，能过CMMI4的更是凤毛麟角。我在课堂下听着嗤之以鼻，深为中国的劣根性感到悲哀：中国国人的功利性导致国人不管这种方法是否适合自己就一拥而上。我当时的想法是：不管任何过程方法，适合自己的团队自身的企业才是最重要的。说白了CMMI也只是评判一个企业软件开发能力的标准，但并不是唯一标准，并不需要奉若皋圭：因为“软件工程中不存在银弹”。 CMMI真正的核心只有一个：持续的过程改进。
当时在新华书店里，我还看到了当时最流行的软件开发过程方法：XP极限编程。我当时在书店并没有细看，只是浏览了目录和翻看选看了一些感兴趣的内容。并不是我认为XP极限编程的观点不对（毕竟这本书籍影响了一代人），只是我对软件工程中的所有方法论都抱着一视同仁的态度：软件工程不存在适用于任何情况的通用过程方法。当时感觉CMMI和XP就像中国武侠小说里的两个极端：一个是堂堂皇之的名门正派的玄门功法，讲究循循渐进；一个是剑走偏锋的“魔道”武功，另辟蹊径闯出一条血路。简而言之就是“气宗”和“剑宗”的区别：CMMI适合大型企业的软件开发机制的完善，讲究机制的完善和文档的完整，非常消耗人力物力，但走在正确的道路上，不是技术出身的管理层也可以进行监管；XP适合小型的开发团队，讲究效率与沟通，以快速的应变来解决软件开发中的问题。在小型的开发团队里推行CMMI的管理方法，虽然不能说这样做一定不会成功，但这会使这个小团队陷于文档的“沼泽”中，开发人员一定会问：我们花这么多人力物力，但收效甚微，这样做值得吗？同样，在大型开发组织中广泛推广XP也不能解决大部分问题，虽然XP中的很多方法和思想到现在仍然很有用：例如“测试先行”、“简单设计”、“捉队编程”、“编码规范”、“代码重构”、“迭代开发”和“每周工作40小时”等。但XP的核心“用沟通替代文档”在大型的开发组织里是不适用的，因为这里涉及到 软件工程学中另一个重要准则：“沟通成本：1+1<2”。
我是一个深受中国传统文化影响的人：当年那个学期里，除了在课堂里接受软件工程的课本学习，我在课外时间里还花大量的时间研究“易经”。我骤然发现“易经”的思想在软件工程中是非常切合的，因此在CMMI这门课程的的课设我写了一个脑洞大开的论文：CMMI的易经模型。当时我只是感觉CMMI太过庞大，用易经的思想来简化CMMI模型，说不定可以适合小型开发团队。现在回想起来，当时的想法放在现在仍然很具有创造和前瞻性，但非常可惜，当时只保存了电子文档，但论文的电子文档发给老师后就消失在我的历史长河中了，虽然当时有在台湾某知名博客“XX小筑”和微软的博客MSN发布过，但这两个网站正如我的论文一样消失在历史的长河中。
软件工程中的第一准则：“没有银弹”。那么该怎么办呢？“易经”中的核心思想“不易之易”：把易经解释为一种描述自然规律的通用模型，通过确立不变的元素组成，来推演千变万化的事物发展规律。总而以一言之，就是李小龙那句著名的话：以无道为有道，以无法为有法。
————写于2016年8月19日