屋顶上的木帷幕

今天看到思归的《细节、细节》，同感。因为大道理谁都会讲，但真正做好就是另外一回事情了——真正做好事情的要诀，都是一些很细节的东西，除非有闲人特地去总结，否则就只留在每个人自己的经验中。做人的道理如此，做事的道理如此，编出好程序的道理如此，做好项目的道理也如此。

就说软件过程这方面，经过二三十年的发展，软件过程理论都长得越来越像了：CMM、RUP、XP、TSP、PSP，还有微软自己的一套软件过程方法，都有很大的相似。这说明人们普遍对软件过程的认识和理解都趋于一致，看法都趋于成熟，已经非常接近很多规律性的东西。

但另一方面，光有这些过程理论，是做不好软件的，一做就走样，肯定走样。走样不走样的区别就在于细节！例如和Daily Build有关的就有一些很少被着重提及但非常重要的细节：

1）登记Bug时，一定要指明Bug是在哪个Build里面发现的；
2）做Daily Build，如果是Web Application，要把Build号加到首页页面上去，如果是WinForm，要把Build号加到About对话框上；
3）每个Build做内部发布的时候（比如build 4605），除了要创建并拷贝到\\release_svr\builds\4605下，还要拷贝一份到\\release_svr\builds\latest下。

类似的例子还有很多，一个项目组的流程和开发管理水平高低就都体现在这种细节中——而这也就是国内SQA现在所存在的问题。

很多企业都有SQA部门（Software Quality Assurance）和SPI部门（Software Process Improvement），这些部门并不作具体的测试工作，而是把自己定位在监督和帮助项目组改进软件开发过程上。从理论上来说，他们的工作的确很重要，因为好的流程能够带来好的质量。但从实际成效来说，他们找问题和提出改进意见的角度大都来自于一些常见的著名软件过程理论，往往还停留在说些“要有测试”、“要有配置管理”、“要有专门的客户文案”、“要有风险管理”等的话的层次。这样的流程改进过于粗放，实施中忽略了很多细节问题，效果大打折扣，还使得那些项目组对流程改进的有效性产生怀疑：“我已经按照你建议的流程做了，为什么还没有效果？你的流程到底有用么？”

打印 | 张贴于 2004-03-01 10:07:00 | Tag:Software Engineering