我们迫切需要软件工程的核心理论
最大的挑战：我们在一个崇尚流行的行业中
似乎每过两、三年，我们对于软件开发方式的看法就会颠覆一次，这比时尚界的变化还要频繁。世界各地的大公司随意抛弃那些投入高额资金的流程和工具，而他们甚至都还没有尝试使用一下。他们抛弃了过往可供学习的经验，不经考虑就选中一些新东西从头来过，就因为他们相信那是焕然一新的东西。可实际上，没有发生多少变化。时尚界中，经常发生无事生非、小题大做的状况。对于像做衣服这样的小事，也许可以令人接受。可考虑到我们行业中不菲的投资，这就是浪费、昂贵而且荒唐之至的事情。充斥于耳畔的热门名词，在不断压迫我们忍耐力的极限。
最新的趋势是“要敏捷”（以Scrum为例）。“敏捷”运动一直告诉我们：在开发软件时，人处于首要地位。这没什么新鲜的，类似的话题每隔10年左右就会浮现一次。这在有关创造性解决问题的练习中早已人所共知。而有些天真的经理总想把相关观点固化下来，再使之商品化，拿去卖钱。如何以团队的方式工作，如何协作，如何记录工作文档，如何规划每天、每周和每月的工作，凡此种种，都很重要，我们也应该知道怎么去做。可当人们把焦点放在这些东西之上时，却把很多其他应该注意的东西抛在脑后，或是被那些新名词搞得头昏眼花，以为出现了什么全新的玩意儿，而没有注意底下其实是老古董。
这样做的后果就是：大量的人力物力被浪费。类似的真相被反复发掘，却被披上新的外衣。年轻人和缺乏经验的工作者们鼓吹新的趋势，跟随新的宗师，而渴望发现“新闻”的媒体们也起到了推波助澜之势。脱离实际开发工作已久的经理们发现自己身处绝望之境：抗拒最新的流行趋势，他们也给自己戴上“无法接触”的标牌。人们用试验项目证明新方法的优越之处，却没有看到：在小范围内，积极主动的开发人员可以搞定一切。由此，后浪把前浪拍死在了沙滩上，老法子被全盘抛弃，即使是没有问题的部分也随着无法生效的方法被一同丢出门外。等到人们发现即使是新方法自己，也是有些部分好使，有些无助于解决问题；一切都已经太迟了。
问题的根本原因，在于人们对于软件开发本质的极深误解。研究人员们为了解决这个问题，提供种种新理论，比如证明程序正确性的形式化理论，或是使用从未被学院以外的人们使用过的形式语言。业界也付出多年努力，试图为难以理解、不断膨胀的元模型建立标准。
只有亲身投入，我们才能深入了解和掌握软件工程，而不是去先学习什么理论，再实际操作。大学和技术研究所传授给我们特别的工作方式，诸如XP 或是Scrum。而当我们面对现实世界的真正挑战时，却毫无坚实的知识基础可以依托。因此我们就很容易摆向新的趋势，而不是保留、吸收学到的经验教训。在现实世界里的项目都会采纳某种特别的方法，我们必须在开始动手工作之前学习和掌握。每当改换工作时，我们也得在开始着手新的任务之前学习新的工作方式。这样做效率低下，我们无法汲取过去的经验，总是要从头来过。
我们应该停下来，不再跟风赶时髦，也不要妄想找到简单的答案，那样我们得到的永远是失望。可是到底该怎么做呢？至少过去十年来，我一直在思考这个问题，也因此而产生了具体的想法，以指导我们达成目标。
解决挑战：制定一套核心理论，说明软件工程的实质
在我看来，这套理论就摆在面前，我们要做的，就是把它拿起来。我们可以从所有的方法、过程、实践入手，并从中找到软件工程的“真理”。在我的公司中，人们正是这么做的，结果也被应用在全世界数百家公司之中。
解决方案包含以下几点：
1.找到内核——所有方法之母
所有的方法都有很多共同点。再怎么说，它们也是用来开发软件的，为了这个目的，总有一些事情我们必须要做。比如，我们总得写代码，总要测试（不管以何种方式），总要思考需求（无论是否有没有记录文档），总是要有一个待办事项列表（无论显式隐式），我们还总是要有一个计划，不管它是写在纸上或是仅存在于脑海之中。借用一个使用过度的比喻，我们希望找到软件开发的“DNA”。
我们希望发现软件开发的“本质”或“内核”，这个“内核”应该是无法再简化的。
通过研究包括XP和Scrum 在内的50多种方法，我们已经找出一个有20多种元素的核心，其中涵盖我们总要做的事情，或是总得产生的产品。表面看来，在这些被研究的方法之间，以及我们使用它们的方式之间，也许有着很大的差异。举例而言：功能特性或用例都可以用来捕获需求。可这许多方法总是有一个基础，我们将其放在我们的核心元素之中。
2.理解方法和过程的固有特点
有一个重要的发现：每种方法都是由实践构成的，无论这些实践是否被称为“实践”。举例来说，RUP包括很多集成的实践，而Scrum仅有一个实践。Scrum主要关注项目管理，因此，为了简单起见，我们将这个实践称作Scrum。RUP和Scrum都由很多重要的模式构成，比如Scrum的敏捷工作模式。然而，为了简单起见，我们改日再谈这些模式。
3.使用内核描述各个有趣的方法
有了内核之后，所有的方法就都可以使用统一的方式描述了，并可以作为核心的特例或是扩展。我们可以从所有广泛使用并得到验证的方法或过程中提取隐含的实践，包括架构、Scrum、组件、迭代等到。有些实践会有相互重叠的部分，比如RUP 和Scrum中的迭代。有些实践则可以互补，比如用例和Scrum。
核心将各方法之间的表面差异忽略不计，比如同样的东西可能在不同的方法中叫不同的名字。例如RUP中的迭代和Scrum中的sprint，实际上二者都是同样的东西。这样一来，我们就可以明确看出不同方法之间的实质性差异。
目前，使用核心可以定义出大约15个类似的差异。由于核心并不关心任何特定的差异，我们可以很快找出不同实践之间的本质区别，而不是仅限于表面。这会降低每种方法所持有的特定观点所造成的影响。而软件工程相关的教育也能变得更加符合实际，可以将注意力放在不变的理念之上，而不是去琢磨形成每种方法、过程或方法论的特定观点。我想学生们一定会喜欢这样的东西。
如果我们的技术研究所或是大学可以向学生们传授软件工程的基本元素和理念，然后在此基础之上给学生们培训一系列优秀实践，那就再好不过了。这里也是众多相关研究的空白之处。
记住库尔特·勒温的话：“没有什么比好的理论更可实践。”好的理论是易于学习和掌握的，而且能够增进你的知识，同时还不让你过于盲从。这才足够明智。
这对行业来说意义何在？
诸多大型公司都有自己内部的方法或过程，通常都来自于其他通行的理念，再加上一些公司特定业务领域的想法。这些过程经常被编写成厚厚的书本，或是放在网站之上，公司会投入很多资金来把这些过程记录在案。有时，人们会接受过程相关培训；有时，他们只是被人告知要去看相关的文档。
实际情况中，人们常常忽略过程。真正被用到的，是组织内部“口口相传”的一些传统。这可以被一条人们反复发现的“公理”所证实：人们不会阅读过程文档。间或出现一些新的观念（比如人们现在都想变敏捷），此时人们就会把旧过程看作过时的东西，相关的书也就被放在书架上，任由其堆满了灰尘。
在这些大公司中，可能有不止一种过程。大型系统集成商也许拥有10到20中不同的类似过程。大多数情况下，这些过程都很像，但是相似之处却隐藏在所有的表面差异之下。
更重要的是，一家公司可以采纳其他公司使用的实践，同时不必抛弃自己公司现有的、而且是适用的实践。如果你的公司接受实践的想法，即使面对着正在流行的、崭新的迷人理念，也不必抛弃目前实用的工作方式。实际上，你可以一步一步来，逐渐改进现有的工作实践。
你应该将现有的工作方式看作一系列实践，然后寻找你们的薄弱环节，去掉无法生效的工作实践，替之可以弥补弱点的实践，从而使得公司的工作过程变得更加圆满。
对于有多种工作方式的大型组织，你可以使用上面的方式来逐渐改进每种不同的工作方式，同时不必强迫每个人使用同样的方法或过程。
这种方法可以使得采纳新实践变得更容易，同时不必变更其他现有实践。如果你已经在多年前就引入了核心元素，并以之描述你所使用的实践，那么现在要想用Scrum替换现有的项目管理实践就很容易了，而且使用的其他实践也不会伤筋动骨。展望未来， Scrum 也许会被某个新实践所替代，届时要想替代 Scrum，也是很容易的。
结束语
一直以来，我们对于软件工程的理解都缺少一个终极理论。因此，我们总是在不断给旧理论换上略带不同的新衣服，掩盖了带来真正创新的机会；这让我们在抛弃旧方法不良之处的同时，更难以有效利用新方法的优秀之处。好的理论可以帮助我们为软件工程的教育带来实质性提升，也能让我们在面对到处涌现的新概念时不那么天真。最后，好的理论还能让我们更快地采纳新想法、实施新实践。
从核心看来，理论要依赖实践的检验。实践的概念有好有坏，而实践相关的理论已经出现50来年了，可这些实践的定义却很松散。我们需要更精确的实践理念。
1.我们在设计实践时，要从开发人员的角度出发，而不是从过去的过程角度，为过程工程师角度考虑
2.我们需要让实践彼此独立，这样才能互相组合，创造符合自己实际情况的工作方式和过程。
3.此外，由于人们不会阅读过程文档，因此实践必须是轻量级的。我们的实践要可以通过一系列卡片描述，仅仅关注于最本质的东西。
4.最后，我们需要能够执行的实践，而不仅仅是堆砌的文字描述。
这个理论真正的受益者，将会是整个行业，而且很多公司都已经证实它的可行性。我们可以更快地教育新人，让他们跟上队伍，提升我们开发产品的水平，有系统地对我们的产品展开重新工程过程（其力度要强于重构），并且不断改善我们的工作方式。
以更高的质量、更快的速度、更低的成本开发软件，这就是我们将会得到的结果。█