关键字
前言
笔者认为“实践软件工程”（Practical Software Engineering）将成为未来40年软件工程发展的大趋势。
实践（Practical）一词的含义具有双重含义。
一方面实践指日后的软件工程焦点将从知识的完备性、体系性、权威性转向有效性、适用性。
另一方面它还指日后软件工程的实践者而非发明者将拥有更多的话语权乃至主导权，案例分享将取代培训课程成为主流的知识获取途径。
由于“未来40年”的周期长度甚至超过了国内的软件业的历史，更超过互联网兴盛期的历史，因此要做这么长期的预测，很多分析依据不能受限于当前的所谓“实际情况”。
软件工程的新焦点
有效性
有效性指将出现由具体的度量数据或具有统计意义的定性数据支撑软件工程发展的倾向。
历来的瀑布模型、CMMI乃至敏捷开发等方法，其传播往往是由权威机构（或潜在的权威机构）来发动的，并非由一些明确的改进案例来自发产生的。
在CMMI的推广过程中，实际上有很多SEI的度量数据支持其实际效果，但作为传播动力而言，其起到的作用很小。企业采纳CMMI多数是基于其权威性直接做出的选择；SEI亦疏于对其实际效果的度量和监控。当然SEI有理由这样做：因为它实际上是美国国防部DOD的下属机构，其关键词可以理解为“美国+军工”，因此并不对“改进全球软件研发”负有责任。
敏捷开发尽管来自于实践，但其实际效果却缺少“实践性”的度量，多数时候人们都“听说”敏捷开发很好，“鼓舞了士气，提升了生产率，提高了质量”，但对具体的数值，基本上一无所知。上次在中国敏捷大会上，一个基本共识是“敏捷开发传入中国接近10年，但现在还没有一个企业声称自己能被拿出来作为案例。”
有效性的定义
“我们用得很好”这种含糊的说词不能被作为有效性的定义，更为合理的有效性定义应当包括：
1. 在使用某方法后，团队或组织的绩效得到改善。
2. 在组织内部统计后发现，使用某方法的团队具备更好的绩效。
3. 在行业内部统计后发现，使用某方法的组织具备更好的绩效。
有效性应该被从多个方面度量，平衡计分卡可以认为是一个很好的提示，它指出应该被度量的方面包括：
1. 内部过程层面的提升（内部）
即我们常说的生产率的提升，进度、质量、成本等方面的提升。
内部过程是传统软件工程所关注的焦点之一，软件工程的度量长期以此为主。这在早期一些技术关键行业中是至关重要的，比如航空航天，军工，银行等。
但若只关注内部提升是狭隘的，典型的就是若一家普通企业不像上述企业一样可以聚焦于技术度量，而不得不应对压力日渐增长的财务、市场、客户、竞争对手环境，那么只关注研发过程，会大大削弱研发过程在公司中的地位，进而削弱研发人员在公司中的地位。
2. 学习与提高（内部）
指团队的扩张性、人员稳定性、能力提升速度等团队因素。
无论一个过程本身是好是坏，但若无法提供队员的学习与成长空间，进而形成团队的扩张，那么迟早也会出现问题。从这一点上说，无论是各司其职老死不相往来的分工+流程式的重型流程，还是四五个人自己挑选任务+自己说了算+互不干扰的极端敏捷主义流程，都会伤害团队的学习与成长。
这也是本人力主推广松结对编程和139团队的原因之一。2001年我所在的团队至今还是我亲自经历的扩张速度最快、队员水平提高最多的团队，松结对编程的概念就是源于在这个团队的经历。
3. 财务方面的提升（外部）
尽管看起来软件工程无法直接产生财务收入，但若一种软件工程缺少与公司收入增加的因果关系，在高层能获得支持的概率很小。
实际上很多软件工程都宣称可以通过更好地把握客户需求、减少质量成本、缩短工期……等方法来缩减成本和增加收入，但很少看到相关的数据。
多数软件从业者都逃避对公司至关重要的财务收入责任，又抱怨技术人员在公司的地位不高，陷入恶性循环。在业界平均收入最高的Google，有一个被内部技术人员引以为豪的重要指标，就是其服务器的运营成本只有业界的50%，而这些运营成本是Google这类公司最大的开销之一。这里的程序员和支持人员没有抱怨销售和市场人员，而是用自己卓越的技术来证明自己对公司的收入贡献，进而赢得了自己想要的收入。
4. 客户（外部）
客户的满意度代表了直接从外部观察到的某种软件方法的结果。
无论一种方法被团队或组织认为好与不好，若客户认为不好，则可以整体认为不好。
比如，无论一种测试方法内部认为多么有效，若客户认为产品的质量并未提高，那么这种测试方法就值得怀疑。怀疑的结果未必是推翻它，而是要思考为何事与愿违以及如何改进。
有效性的度量
而且度量结果应该满足：
1. 这些结果应该具备大致可度量、可比较的量化指标，因此可以用于时间前后或团队、组织之间的比较。
团队与组织间的可比较性要求使用某些业界普遍适用的方法，而不是企业自创的。
比如基于功能点的产生的生产率和质量度量就具备可比较性，而基于代码行、故事点、用例点、页面数等进行的就难以度量。
2. 尽管受到多种其他因素的影响，但统计学上而言这种方法与更好的绩效整体呈现正相关性。
财务方面的提升可以说受到非软件工程方面的影响很大，但若所有采用某种方法的企业其财务都走了下坡路，那么无论两者谁为因果，都应当进行必要的分析。
比如有一种传言是“组织越倾向于使用全职的Scrum Master，则企业的效益越可能走下坡路”。虽然这种微观实践和宏观结果之间的关系很弱，但它实际上是“摩天大楼定律”的软件业版本，即若企业有多余的钱做多余的事情时，企业就要开始走下坡路了。
适用性
适用性的定义
早在早期学习CMM（CMMI的前身）的时候，书上就宣称“在日本，有一家只有3个人的企业也通过了CMM的2级认证”，以论证CMMI适合小团队。而在学习敏捷开发的时候，也常常看到“用敏捷开发管理500人大型团队”的案例。这些案例，其实就像沙特动物园饲养了一头北极熊一样缺少说服力。这里要否定的不是沙特动物园有北极熊这件事情，而是在沙漠生态中引入北极熊的问题。
有说服力的适用性定义应当包括：
1. 对某个行业或某类公司而言，这种方法的价值主张与其非常符合。
比如在美国军工企业实施CMMI，其适用性就很好。在中国互联网行业实施CMMI，则适用性就堪忧，因为很难用美国国防部的标准来要求一个互联网企业，两者的价值观有根本的不同。
2. 有数据或共识表明，在具备某个特征（比如大型团队）的多数尝试者中，这种方法被证明利大于弊。
这一条是针对“跟随者”而说的，日后他们会在看到积极的数据后才做决定，而非像现在一样盲从很久才发现走错了路。
3. 在只有少数尝试者成功的情况中，其跨越门槛的方法具备一定的共性，或至少是可学习的。
这一条是针对“勇于尝试者”而说的。
很多研发方法在“国内不适用”，原因是文化和管理的差异。不过反过来，国内企业常常把文化和管理差异当作与生俱来的先决条件，从来没有想过它其实是可以被改变的。
就像有人常常说“我们的甲方一直就是很强势的，预算从来都不能改动，而需求则总是增加。”其实，我们现在就有办法尝试改变这一假设，在40年后更可以。但若总是把它当作一个雷打不动的事实，总是不假思索地问“那你说有什么办法”而不是主动思考哪怕1分钟，这个现状就很难改变。
适用性的度量
适用性度量大致有两个途径。
1. 行业数据的分析
功能点分析是现在唯一拥有确切、大量行业数据的软件工程方法，ISBSG、IFPUG、SPR、NESMA等都具有大量的有实际使用价值且被广泛使用的历史数据，项目数量可能接近五万个，度量项则大约达到500～1000万个。
其他的曾经出现过的热门的软件工程或相关方法，比如面向对象、UML、CMMI、敏捷开发……尽管实际采用或尝试的企业数量远远超过功能点分析，但可提供分析的数据则正好相反。
未来软件工程方法的发明者和推动者，应该有义务采集或发起对行业数据的采集，以验证自己的价值主张是否实现，以及在哪些环境中能更好地实现。若不能或不敢提供相应的数据报告，则很大程度上表明了可能信心不足。
Version One一年一度的敏捷调查是用于评估“敏捷开发有效性及适用性”一个很好的尝试，但这种尝试其实本来应该是敏捷联盟的义务，而非由一家软件公司发起。
2. 行业案例的广泛分享
案例分享与行业数据相比，这更像是一种定性的分析。
基于当前互联网现状及未来数十年潜在的发展，案例分享的声音将逐渐超过权威机构发布信息的声音。这很类似新闻发布机制的变化：最初是官方报纸，之后变成民间门户网站，而最后变成微博等多元的信息传播机制。换言之，未来北极熊的生存情况，将可能不再由动物园发布，而是北极熊本人发布。
实际上，现在在网络上已经有很多支持或反对某种软件工程方法的声音，只是还不成熟。多数停留在道听途说或浅尝则止之后的感受，较少有坚持尝试和思考后的声音。
日后随着实践活动的深入，倾听案例分享将成为人们获取知识的主要途径。而且在尝试中发现的新的实践，将成为未来软件工程方法的新源头。与以往大师或大型企业的方法相比，这些新实践的方法可能不完善且存在问题，但其适用性有保证，学习的门槛也会相对较低。
当很多实践者在分享相似过程和结果的案例的时候，极有可能表明他们采用了相同的思考方法，一种新的软件工程方法就诞生了。
实践案例分享的新趋势
案例分享由来已久，“实践软件工程”中的案例分享与以往常常发生的案例分享有何区别？
实践软件工程注重案例的收益而非过程
用《我们推行敏捷开发的过程分享》来命名一个当前的案例足以赚取眼球，但在未来则不行。由于各种软件工程方法逐一走下神坛，人们逐渐冷静下来，回到自己追逐软件工程的起点：我们为什么要推广敏捷开发？
转变的结果是，下面这几个案例的名字，将出现在未来40年的搜索引擎缓存中：《我们是怎样使用1/4业界代码量编写相同功能的》《我们是怎样让24个月的项目按期完成的》《我们是怎样把成本控制在计划的5%的》《我们是怎样将延期项目个数控制在10%的》
新的案例都宣扬了一个可度量的或至少很容易达成共识的有效性收益，并以一个实际的案例而非“可能有效”的方法来支撑。
案例中实现收益的方法或许是一个有名字的过程比如“敏捷开发”，也可能什么都不是，但人们追求收益的动力将大于过程。
曾经有一群实践者要写一本“敏捷开发案例集”，一个重要问题就是“什么是敏捷开发，哪些案例可以收集进来？哪些则不行？”笔者的主张最后被采纳，包括：
1. 必须是一个真实的案例
2. 必须是一个有收益的案例
3. 大致与敏捷开发沾边即可，不沾边其实也可
因为若我们执着于是否敏捷而放弃某些有益的案例，那么我们应该修改书的名字。
实践软件工程注重单点收益而非完整过程
由于软件开发的多元化和快速变化，将导致很难完整实施某种方法。
比如现在很多微型公司正在为苹果和Google开发手机应用，甚至很多大受欢迎的软件产品都是业余时间开发的；未来每10年可能都会出现与之前截然不同的开发方法。这将导致软件工程的发展远远跟不上软件开发本身的发展。
开发者与其等待一种为自己量身定制的完整过程，不如基于自己的需要单点突破。这时候就更会接受具备与自己相同价值观的案例，而不是一种号称神奇而实际上鲜有人试验成功的复杂方法。与后者相比，前者有实际收益的先例，而且实现的困难也被证明不是不可逾越的。
当然有案例和一定能模仿还有距离，最后一节将做总结性介绍。
未来案例的呈现方式
前段时间与麦思博（MSUP）的刘总讨论Top100 Summit 软件开发案例征集活动，下面是我当时的建议（略有扩充）。这些建议在一定程度上是本文的总结，也补充了几个没有谈到的地方。
1. 案例名称或主题必须具备1条鲜明的收益，而不是泛泛而谈
比如《我们是怎样使用1/4业界代码量编写相同功能的》就是一个好名称，而《我们是怎样提升软件开发过程的》则相反。
另外如果有多条收益，与其泛泛罗列，不如把一条讲透。
2. 案例必须基于可度量的指标
比如不能说“实现了敏捷开发后，我们的研发进度大大加快了”，因为这可能只是短迭代造成中间产品速度；但可以说“实现了敏捷开发后，我们的交付周期从10个月每个版本缩短到3个月”。同样前面代码量的案例也不能说“我们编写了大量可复用的函数和类库”，而必须提供有共识的度量结果，比如“我们使用1/4的业界代码量编写了相同的功能”。
3. 案例必须说明获得收益的具体方法
比如不能说“敏捷开发激励了员工积极性，产生了更高的质量”，而要说“实施了……制度后，用户反映的缺陷率降低了50%”。
4. 案例必须说明曾经试验过的其他方法及未来的考虑
我力荐《硝烟中的Scrum与XP》一书的原因就在于此。作者显然没有浅尝则止就草率写出了这本书，而是在真正实践和思考后，把中途走过的弯路、没走过的岔路都加以描述，还对未来前面的路做了预测。
如果世界上和中国有大量的这种深度的实践者，实践者掌握话语权的时代就不远了。
另：若您有符合以上4点的案例愿意分享，欢迎与我联系，我会协助推广：[email protected]
另：之后的几篇文章，可能涉及的内容包括：
1. 有效性的基本度量项讨论
包括那些相对不太容易度量的内容比如“团队稳定性”“财务收入”等。
2. 关于UP（统一过程）和UM（统一模型）的扩展讨论。
U指某些工程实践互相支撑，完成一个即可支撑另外一个而无需从头再写（比如UML中的各种图之间的关系）。但以往的UP如RUP只涉及软件技术工程，而对团队、绩效管理、商业运行较少讨论；UML更是只提及纯技术范畴。正如前述，这些都限制了技术人员在公司中的地位永远是“干活的”。对UP/UM的扩展讨论中，将会提到如何集成地管理团队（结构，层次，绩效，扩张，学习……）、研发流程（需求收集、需求管理、需求与技术的映射、需求与代码的映射……）、财务与客户（用户群建模、用户建模、产品线、产品、版本……，这些讨论更多地是商业层面的，而非技术层面的）。有些内容比较晚才会出现。
讨论的结果，旨在建立一种能打通平衡计分卡中四项的管理思路。当前这四项一般分别是四个部门的四种角色管理的（财务=大老板，客户=市场/销售，内部流程=研发人员+质量部，学习与成长=部门经理+人力资源），而相互之间缺少相似的或贯通的思路，因此导致矛盾很多。
本人倒没有完全想清楚一种模型，而且也认为这种“想清楚且普遍适用的”模型应该不存在，但会提供一些过去6个月思考的结果给大家。
一些常见问题比如“为何面向对象由来已久，但我们公司的软件复用一塌糊涂？”这类问题，因为它不完全是一个研发问题，还是一个部门管理问题，不是一个技术突破所能解决的。这也正是UP的价值。
不过完整的UP实施难度很大，所以我们会从AUP（Agile UP）入手，理解一个公司最基本的管理过程应该包含哪些内容。
3. 预测依据
预测结果永远是不准的，预测前提常常比预测结果更重要，无论对预测者还是旁观者而言。因为观察预测前提是否发生，就能对预测结果是否发生及如何发生进行修订。
本来本文中会包含预测依据，但是限于篇幅没有写太多。