如何进行软件过程改进

比尔盖茨在70年代就意识到了软件的重要性。相比硬件，软件是无限制的，软件提供的服务也是无限制的，软件可以创造任何东西，所以软件将主宰未来的应用。事实也证明了这一点，软件在生活中占据了越来越重要的地位，软件的应用范围也在不断扩大，软件不再是可有可无的点缀，软件的质量也开始受到人们前所未有的重视，因为我们已经离不开软件了。软件组织开始感受到来自客户对软件功能的要求和对质量的压力。因此改进软件生产过程，提高软件生产率和软件质量变得比以前任何时候都重要。

目前在软件过程领域也存在不同的流派和方法，传统的计划驱动方法仍然是占据主流的开发方法，瀑布模型，迭代模型，ISO9000，RUP，CMM层出不穷，你方唱罢我登场，一个个好不热闹；最近几年兴起的敏捷方法也逐步引起大家的重视和研究。轮番出场的各种方法让人感觉象雾里看花。到底应该选择哪种软件过程好呢？怎样才能建立适合自己的软件过程呢？

无论那种方法，我认为都要坚持如下的一些基本原则：只有这样才能找到适合自己的方法。

 

以人为本

程序员在软件生产中是第一位的。这是敏捷方法带给我们的最重要的思想。程序员是软件过程参与的主体，他们对于如何实施软件过程最有发言权，因此无论任何软件开发过程改进都应该以程序员为本。软件开发过程改进的成败也在于是否坚持以程序员为本。

软件过程改进的根本目的是为了提高软件生产的效率，提高软件的质量。因此实施软件过程改善不仅仅是管理者单方面的需要，更是程序员自身的需要。管理者不应该独自决定如何进行软件过程改进，然后强行把它推给程序员执行。

软件过程改进必须要全员参与，首先让大家明白过程改进是为了提高自己的工作效率，提高软件质量。另外要让程序员参与到过程改进的规范制定中去，让管理者和程序员能够达成一致的思想和行动。在规范制定过程中，要始终坚持一种思想：软件过程改进是为程序员服务的，不是单纯为了管理者服务的；因此在制定过程的时候，要尽量考虑程序员的需求，要尽可能减轻程序员的额外负担，而不是简单为了管理者方便检查，监督而制定很多繁文冗节的规定，程序员不胜其烦，自然想方设法蒙混过关，或者百般推托，达不到改进的目的；让程序员参与其中并虚心听取他们的意见，这样制定出来的改进措施一定是敏捷的，既能真正提高工作效率，又不会带来过多的工作量，程序员何乐而不为呢？

以人为本的另一个体现是注重员工培训。国内很多软件组织的通病之一就是不重视员工培训，他们天然认为程序员都是天才，不学就会，能够无师自通，从战争中学习战争，所以他们从来不考虑培训。但是所有的开发流程，制度，无论多么完美，最终都是要人去实施的，因此员工的素质是一切软件过程，软件开发成败的关键，如果员工不能得到很好的培训，他们就不能很好的理解这些软件过程，制度在软件质量和工作效率提高方面的作用，从而不能很好地发挥软件过程的效果。即使有了完美的软件过程，软件的设计和开发依然不是随便什么人就可以设计出来的，具有有高超软件设计能力的程序员是生产高质量软件的根本条件，而培训是提高程序员设计能力的一个快捷途径。

 

培训的重要性对于敏捷方法尤其重要，敏捷方法号称敏捷，但是它对于程序员，组织的能力和组织文化的要求都很高，从国内的大多数组织来说，他们根本不具备实施敏捷方法的条件，因为他们既没有训练有素的程序员，也没有成熟，开发的团队开发文化。如果不能通过培训提高程序员的能力，建立适合敏捷方法的组织文化，即使实施敏捷方法也不可能得到良好的效果，这就是众多组织实施敏捷方法失败的原因。驾驭敏捷方法的关键就在于高素质的程序员。

 

没有银弹

 

不要期望存在完美的软件过程模型可以解决所有问题，软件质量就可以大幅度提高。软件开发从来不存在银弹。明白了这一点，要坚持活学活用，。

有一句非常有名的话：所有的模型都是不正确的，只有部分模型是正确的(All models are wrong, some models areright)。再完美的理论不可能完全符合实际，实践也不能完全照搬，套用理论，要坚持走中国特色的社会主义道路，全盘西化要不得。因此必须结合本组织，团队的实际开发状况，选择符合实际的改进方法和措施，不必一定拘泥于某种方法，不必一定完全照搬某种方法，ISO9000，CMM，XP等等都有很多优秀的，比如ISO9000的阶段评审，CMM的KPA实践，XP的小型发布，简单设计等等都是可以借鉴的方法和最佳实践。要坚持一切从实际出发，拿来主义，以我为主，唯我所用，不能唯方法而方法，作方法的奴隶。不管黑猫白猫，能抓到耗子就是好猫。只有坚持以我为主的思想，才能逐步改进现有的软件过程，最终找到真正建立适合自己的软件过程。

 

要改革不要革命

暴风骤雨的革命可能显得气势恢宏，颠覆性的方法更多是广告式的宣传。革命性的改变对于组织的影响是巨大的，是破坏性的，在某种情况下可能是致命的，如果不能取得好的效果，原有的过程势必也被破坏殆尽。因此，不是万不得已，不要轻易采用什么激进的，革命性的休克疗法，俄罗斯就是休克疗法的一个例子，效果大家想必都看得到。我们做软件的就不要重蹈覆辙了。

如果一个软件组织没有任何软件过程，它完全可以照搬任意一种它认为完美的软件过程方法，有总比没有好；但是，大多数软件组织已经形成了自己的软件开发过程，具有自己的特点和开发文化，其中有合理有效的部分，也有需要改进的部分。这时候如果全盘否定过去，强行推行一种新的软件过程，可能会导致大多数组织成员的不适应和反抗，还可能抛弃了自己原有的好的传统，效果可能适得其反。比较有效的策略是“和风细雨，润物无声，积小成多”的改革，改革对现有组织的影响小，在保持原有机制基本稳定并且继续发挥作用的基础上，根据自己的实际情况，分析自己存在的主要问题，确定自己的目标和改进方向，在此基础上进行软件过程的改进。这样不断的通过小步的改进，逐步积累成大改进，最后让软件组织达到一个质的提升，产品质量也会随之逐步提高。这个过程虽然可能漫长一点，但是比较稳妥，也比较有效。只有致持之以恒，持续不断的改进，软件过程改进才能真正见到实效。有的软件组织今天采用CMM，明天RUP，后天又是XP，就像是学习外语，今天是跟我学，明天是许国璋，后天是新概念，英语水平永远提不高。

 

管理层支持

建立成熟的软件过程是一个漫长的过程，不可能一蹴而就，有时候可能还需要组织结构的改变，因此需要方方面面的参与和支持。在软件过程的建立，改进初期，由于采取了新的措施，方法，大家可能会有一些不适应，在实际运行中还可能出现一些问题，此时的软件生产率其实是比较低的，比采用新方法之前还要低，这时候最需要组织各方面特别是管理层的理解和宽容，管理层应该鼓励创新的精神，容许改进过程中的失误，给予足够的时间去试验，而不是一如既往的压任务，赶进度；在任务和进度的压力下，大家只能勉力应付现有工作，根本无心也无力改进，最后只能导致改进失败，再次回到起点。

 

持续改进

软件过程是一个持续改进的过程，软件过程的改进不是孤立的实践，有时组织架构也要根据软件过程而作改变，因此软件过程的改进不是一朝一夕的工作，也不是一个人或者几个人的事情，它需要整个组织的支持，特别是高层管理者的支持和相关部门的配合，软件过程的改变还影响组织文化的建立和改变，它影响组织中的每一个人，它改变了组织的工作模式和流程。软件过程改进(SPI)的一个核心思想就是：不断改进，永不停止。软件工程的著名学者Barry Boehm曾经总结了软件开发的七个基本原则。其中最后一条，也是最重要的一条就是承认不断改进软件工程实践的必要性。CMM的最高级第五级被称为优化级。这些思想都强调了持续改进的重要性，只有不断改进，才能臻于完美。

没有最好的软件过程，只有更好的软件过程，只有适合自己的软件过程。软件过程改进没有终点。