为什么需要软件过程改善（Software Process Improvement）？
为什么需要软件过程改善（Software Process Improvement）？
麦当劳餐厅的成功在于无论在哪个餐厅里提供的服务和食物都是“一致的和可预测的”。
据说麦当劳对购餐等待的时间，薯条烘烤的时间都有限定。套用CMMI的标准，达到定量控制的4级恐怕没有太大的问题。
汽车制造商每年都会有因为制造缺陷导致召回的汽车。在汽车召回的时候，细心的人会注意，厂商一定会说明两件事情：一件是召回的范围，即是哪年哪个工厂的哪个批次的汽车；另一件是缺陷会在什么情况下发生，导致什么问题。这从反面说明了，汽车制造过程同样是“一致的和可预测的”，因为连产品出现的缺陷都是可以预测的。
而普通的餐厅是无法使得同样的食品每次的口味都一样；同样，糟糕的汽车制造商无法提前预测哪台汽车有问题，只会疲于应付突发的售后品质问题。很多人都说，制造业的高品质就是由于可重复的，“一致的和可预测的”制造过程。而CMM实际上是戴明的全面质量管理（TQM）在软件开发领域的具体体现。那么，软件开发过程现在能做到“一致的和可预测的”吗？
低成熟度软件开发状况
开始工作之前，他充满了自信，心想：没问题，肯定能够搞定。但是，是否能够成功实际上取决于他本人，谁也无法保证真的没问题。
一个看似美妙的开始，并不总是意味着真的一帆风顺。工作的过程中，不知道从什么时候开始，似乎开始有一些小麻烦，似乎开始有一些没有预料到的事情出现了。但是，他仍然不担心。没关系，进度肯定是可以赶回来的；没关系，算法肯定是可以搞定的；没关系，bug肯定是可以修正完的。
这样的日子一天一天地进行着，延误越来越多，开发越来越混乱，bug越来越解决不完，而交付的日子却越来越近了。最后，他终于发现没办法了。为什么一开始这么美好而最后竟变成这样？为什么大家都很努力却做不好？到底是从什么时候开始变坏的？到底是哪里做错了？他发现，连失败的原因都找不到。
这样的故事，这样的“他”，在软件行业中每天都在上演，到底哪里出了问题？
登山和软件开发
前几年，北京的大学生登山队，怀着“无所畏惧的革命热情”和“人定胜天的必胜信念”，抛下一切，义无反顾地去攀登高山了，结果很不幸，成了无谓的牺牲者，给家人带来了无限的伤痛。
真正优秀的登山者恰恰是“有所畏惧的”，因而在登山之前是一定要做好一切可能的准备，并预测各种可能的困难和风险。只有这样，登山才有胜利的可能性。
这些“无所畏惧”的大学生登山者们，毕业后来到了软件开发行业，就变成了“无所畏惧”的“他”。
Boehm说，软件开发失败的最主要根源有二：不准确的估算和不确定的需求。
估算是开发的第一步。是否能够相对准确地估算开发的规模，人月数，日程等直接决定了能够制定可行的开发计划。而在这个过程中，“他”需要准确地抽取，精练和跟踪用户的需求；根据开发工作的内容建立良好的开发人员体制；计划开发日程并确定关键节点（Mile Stone），并获得大家共同认可；共同探讨分析开发可能面临的风险和难题。只有在此基础上，怀着敬畏的心情去开始开发，才能说“或许没有严重的问题吧”。
优秀的登山者在攀登的过程中，会随时检测和监控地形，高度，天气，温度，氧气浓度以及自身的身体状况等信息，并据此调整行动路线和行动计划。很多时候甚至距离山顶已经近在咫尺，也会因为突发的天气变化或者自身的身体状况的变化而调整。如果没有随时的检测和监控，登山要么失败，要么成为牺牲者。
软件开发也是这样，在进行开发的推进过程中，“他”也必须随时地把握整体的开发进度，跟踪需求的变更，判断开发产物的品质，汇总开发中的问题，准确地把握每个时刻的开发状况。在这样的基础上，判断当前的状况是良好的还是不足的，要么调整开发步调，要么调整计划目标。
正如同不是每次登山都会成功，不是每次开发都会成功。但是，优秀的登山者在被迫放弃或者延期的时候，会有准确的理由。
同样，真正优秀的“他”在面临无法按期完成开发，品质无法达到要求的时候，也应当能说出问题的原因所在，如何解决，以及经过调整，何时能够达成目标；而不是像热锅上的蚂蚁，毫无对策。
“他”的例子，也就是告诉我们：为了能使得软件开发获得成功，必须进行良好的估算和计划，持续有效的跟踪监控，准确地把握状况并在此基础上判定与目标的偏差，进而进行开发调整。
从“没有软件过程”，到建立起“基本的软件开发过程”，这就是软件过程改善的第一次飞跃。
软件开发过程的跟踪监控
长江是中国最长的江，从西至东，流经数省市，有6000多公里，是中国的母亲河。虽然是母亲河，但是也会给人们带来灾害。
长江的首害就是：洪水。
国家为了抵御长江中流的洪水，在长江的上游重庆修建了三峡大坝。
为什么不在中游武汉，而在上游重庆修筑大坝呢？理由很简单：随着江水的流动，从上游而下，洪水的水位越来越高，当洪峰到武汉的时候，已经非常大，就是修坝，无论如何都阻挡不住了。
软件开发就像水流一样，为了避免在开发的下游工程发生大的问题，就必须在开发的上游工程，在开发的早期阶段就进行开发的监控。比如通过定期的周例会来检查开发状况，发现开发问题，制定对策等。
开发到了后期工程，比如测试工程的时候，暴露出来大量的问题，想解决已经来不及了，即使来得及，也要付出数十倍的努力。
最近十年，长江最新爆发的灾害是：污染。
长江在源头的地方是非常清澈的，但是等到了入海口的上海，已经污染很严重了。
这样的结果，不是突然某个区域污染的，而是从上游开始，污染逐步严重起来的。那么，到底在那个地带是污染最严重的呢？
为了能够查明这个事实，长江流域各地进行了水文检测，通过定量化的水质指标来寻找水质的变化趋势，并向上回溯，从中找出最严重的污染源。
软件开发也是同样。开发结局是失败的，这不需要争论，但是到底问题最先出在哪个开发阶段，是从什么时候开始恶化的，如何变得不可收拾的？为什么不能尽早地发现和处理？
为了解决开发中的“水害”和“污染”，我们要通过定例会议和需求追踪等，来定期（Periodical）和不定期（Event Driven）监察开发过程，定量地精确分析生产物的品质，了解开发风险，定量地判定开发品质，尽早识别问题和解决问题，避免表面现象和假想这样的话，就可以防止开发走入误区，避免与目标产生大的偏差。
从定性管理到定量管理
在古代，人们在描述距离的时候，通常会用“不远”，“较远”，“很远”，“遥远”，“万仞”等表现。
可是，这样的说法是比较模糊的，不同人听了，不同场合听了，理解会不一样。
但是，自从定义了“米”的单位之后（1米等于通过巴黎子午线的400万分之一），人们用米或者千米（公里）来描述。南京到上海是300公里，南京到北京是1200公里。这样描述的话，不管是谁听了都很清楚到底是多远了。
100年前，著名的英国物理学家开尔文（Kelvin）说了如下的话：如果你能够测量你所说的对象，并且使用数字表示出来，这说明你知道了这个对象；但如果你无法测量，你无法使用数字来表示，这说明你的情报是贫乏和无法满意的。这可能是情报的开始，但是，在你的内心，它决不可能达到科学的层次。
这句话在CMMI界广为流传，被人们作为定量过程改善的意义的佐证。开尔文的话主要是针对自然科学而言的，如果无法用数据来描述自然现象，当然无从谈起自然规律了。在软件开发领域，固然不需要像自然科学那样精确，但是定量化的描述是非常重要的。
美国的戴明（Deming）在日本名气要比在美国还大。戴明战后来到日本，指导日本企业进行品质改善，促进了日本战后工业品的品质提升。戴明的基本观点就是基于数据进行全面和持续的品质改进。
戴明说：In God We Trust，All others Bring Data（除非你是上帝，否则任何人都必须以数据说话）。前半句“In God We Trust”早就印在了美国的钞票上，深入人心了；戴明巧妙地通过这样的句式说明了数据的重要性。
美国人在80年代被日本的工业品打得手足无措的时候，美国的NBC（有线电视网）挖掘出了戴明，并在采访中发出了“If Japan Can，Why Can't We?”的感叹。
软件开发也是一样，没有数字化的描述，准确把握开发状况是很困难的。
以测试工作为例。测试者汇报：测试工作很快就要结束了。测试者的意思是：计划的测试用例全部测试完了。但是，管理者理解为：计划的测试用例测试完了，并且bug也全部修正了，并且还进行了回归测试。
这就是由于没有用准确的数字来描述开发状况，结果导致理解的分歧。而这种分歧只会到下一个检查点才能发现。可是那个时候发现也来不及了。
从“没有软件过程”到凭主观感觉（Subjective Feeling）的“定性的软件过程”是软件过程改善的第一次飞跃。
从“定性的软件过程”上升到凭可观数据(Objective Data)的“定量的软件过程”，是第二次飞跃，而且是质的飞跃。
目前国内的大部分公司都处于第一飞跃结束，迷惘于如何开始第二次飞跃的阶段。
过程改善的现实和梦想
软件过程改善的路线图（Road Map）和梦想是什么呢？
首先，从“计划靠拍脑袋，实施靠拍胸脯，失败后拍大腿”式的开发，到按计划，有秩序，可控制地进行软件开发过程的展开，建立“一致的”过程。
可控制就是说：可跟踪，可回溯。可跟踪是指从项目计划之初开始，能够确保用户的所有需求，所有问题点在可跟踪的状态下，逐步展开，逐步推进。可回溯是指在开发的途中，对于发生的问题等，能够根据开发跟踪的信息，回溯到开发的上游，追查到问题发生的原因和起点。
实现了开发过程的可跟踪和可回溯，就基本上建立起初步的软件开发过程了。
其次，在此基础上，通过定量化的数据来进行控制，使得开发过程和开发产物能够通过数据可视化，准确化。
在此基础上，如果有长期稳定的数据积累，建立起品质模型和成本模型，那么我们就可以建立起“可预测的”过程了。
这样，在开发还没有开始就能大体准确地估算出开发所需要的成本和日程；在开发还没有结束，就能大体准确地估算出开发的品质。
最后，带着持续改善，追求卓越的理想，不断地反思，不断地创新，就可以不断地取得进步，建立起“持续改善的”过程。
全员参与，共同改善
汽车工业的成熟不仅在于汽车制造商的过程改进。
在汽车工业中，除了汽车制造商之外，还有汽车行业协会以及独立的汽车评价机构，定期地对不同汽车商的汽车的设计，功能，性能，品质，安全性（碰撞）等进行比较和分析，这些活动共同推动了整个工业的进步和发展。
中国的软件行业也开始了这样的尝试。在系统与过程改进分会和CSBSG的牵动下，通过长期的企业的软件开发的交流，寻找共性缺陷和最佳实践，定期地了解全行业的改善状况并进行不同企业的开发过程（品质，生产率，人员，技术，工具）的比对（Benchmarking），来促进整个软件行业的过程改进。
萧华德（Shewhart），朱兰（Juran）和戴明等无数前辈们在制造业和服务业上的品质改善经验的精华的浓缩就是下面的话。让我们一起记住它：
产品的品质很大程度上取决于开发和维护产品的过程的品质（The quality of a product is largely determined by the quality of the process that is used to develop and maintain it）。
