去年6月到今年1月我参与了XX公司（因为保密原因不能透露具体公司名称）的SIP Trunk项目，现在正在从事XX公司的一个Web语音二期网管项目的开发工作，该公司是国内最大的IToIP解决方案提供公司，参与了这个公司的两个项目的开发工作后我有些感想一直在心头，实在是不吐不快！尤其看到现在中国的软件业发展的越来越快，更多的人提出中国的路在何方之类的问题时，我总想为此做点什么，虽然我只是一只还没出道的IT小小鸟。
        当然，接受国际外包还是不接受之类的问题我是没有能力去讨论的，我能贡献的也仅仅是我对软件成型的一些想法，以及我看到的软件工程中的一些问题。还有我对中国发展自己的软件成型方法论的一些建议。
        我之前并不知道软件工程的具体内容，只是对软件成型有一定的了解，和大多数程序员一样，我认为软件工程只是一个提法，因为当软件规模大到一定程度后需要多人一起开发，这时就需要一个组织方法来开发这个软件，于是便出现软件工程这种东西，就是一个开发软件的方法论，没有什么实质性的东西。我们的目的是实现需求中的功能，而不是去实验各种开发方式。
        也许说到这里就有部分是项目经理的人要喷我了，请你们先不要慌，我的项目经理就坐在我右手边第二个位置呢（我这个项目是外包项目，甲方派经理来和我们这群开发人员在一起，所以我可以更清楚得了解到项目经理平时都在干什么）！
        在开始谈正事之前需要先说明几点。XX公司的软件项目大部分都是运用从IBM学习过来的软件工程方法——V模型开发。当下的两大软件工程方法分别是：结构化方法（structured approach）和面向对象方法（object-oriented approach）。我非常荣幸的接触了结构化方法中较为经典的用例“V模型开发”。
        我问过经理“贵公司为什么选择V模型，而不是RAD，或者瀑布模型？”经理其实也不太清楚具体的理由，只是说他们公司一直在使用这种方式进行开发，觉得效果不错就一直沿用至今。我之前并未接触过其他的软件模型，但对RAD，RUP，XP，瀑布等模型还是有所了解的。我始终认为开发模型并不是最重要的，最重要的应该是实现软件的功能，而无论你用何开发方式。实际许多软件成型的思想是相通的，例如迭代模型、增量模型和螺旋模型都可以归为“分阶段开发”的思想。
        极限编程（XP）也是最近才在我们团队火起来的，因为有部分队员从事的开发工作规模极小，只需要一个人或者两个人就能完成，而且可以和用户几乎0距离的沟通，所以他们天天嚷着“XP”为王。不过这种开发模式也只适合软件开发的小团队。而V模型这种完备的开发方式才适合企业级的软件开发，它更清楚地揭示了软件开发过程的特性及其本质。V模型是在IBM的快速应用开发(RAD，Rap Application Development)模型基础上演变而来，不过我更愿意相信它是由瀑布模型演变而来的。
        如果你仔细观察会发现这两个模型最大的区别就是V模型将开发和测试完全分开了，这点在我做项目是感受尤为明显，当我们的概要设计完成后，经理会督促我们着手写系统测试用例，一个20K规模的工程一般测试用例可以写到400~800个左右，然后经理会把我们的HLD和用例发回公司去确认，确认完成后我们才能开始下一个流程的工作，之间的时间大家就都在学习编程规范之类的知识。每一个流程我们都有输入文档和输出文档，而且我们的输出文档都会被发回公司去审查，通过了才能开始下一流程。聪明的程序员一定会发现这个V模型太适合做外包项目了，因为公司的人只需要确认外包公司传回来的文档就行了，测试人员可以留在公司干别的工作，而大部分开发工作都由我们这些廉价劳动力给做了。我们不甘啊！那有什么办法吗？有啊！找出新的开发模型，提出新的软件成型解决方案，开办一家新的IT方案解决公司，击垮曾经压迫你的公司。哈哈哈！！我有点愤青了，呵呵！
        不过说真的，这个V模型乍看上去是非常棒的一个开发模型，从概要设计到详细设计再到编码和最后的层层测试。似乎这就是软件开发的“圣经”。事实上当我亲身体验过这种开发流程后就会感受到它的冗余和漏洞。
        首先，这种开发模式限定死了程序员的创造力和创新意识。为什么要把这一条先说呢？因为我始终站在程序员这边说话，我知道他们有多苦，有多累，回报有多少。每个流程都有文档的输入和输出，这对项目经理和公司来说是件好事，因为他们可以随时监督项目的进度并及时发现漏洞，但站在程序员的角度来说这是一件费力又完全没有技术挑战的任务，对一个优秀而又有进取心的人程序员来说写这些文档只会磨灭他的项目热情，可能几天，甚至几个星期都在写一些重复性的文字，修改一遍又一遍，而且自己假如又有点新的想法本来可以优化整个框架的，结果被层层测评和文档约束，不得不作罢！（想当初我想改进XX公司的平台定时器处理方案时就被这些文档难住了）
        其次，这种开发模式浪费了大量的时间，不是像很多软件分析师所说的那样节省了时间，相反，是浪费了大量的时间。目前我做的这个项目规模在16K代码量左右，整个项目组包括项目经理在内有15人，统计我们的timesheet就会发现我们平均每周的人力在6~7左右，这意味着我们有超过1/3的人是全工作量（每天按8小时算）在实验室，然而看看他们的输出，SRS做了1个半月，HLD计划是1一个月完成，ST计划3周，LLD计划1个月，IT计划2周，Code计划2周，CT用1个半月。整个项目耗时半年左右。天啊！半年左右，15人开发，14K代码！我记得我的三个同学用一个月的时间开发了一款测试水污染源的程序，10K左右的代码，这完全没法比啊！那我们把时间都耗在哪了？写不必要的文档是一个，开会传达没有效率是一个，等待公司确认输出文档是一个。
        如何解决上述问题？也许我现在还没有能力提出一个新的模型取代它，那我就只能想办法解决了？关于程序员的创造力和创新意识的问题恕我在这里不能展开讨论，因为我有一套心得正在酝酿一篇文章，出炉后自然和大家分享。这里就只讨论节省开发时间的问题。这三个问题都很直接，也都很具体。
        首先我们需要节省撰写文档的时间。我的建议是复用统一文档，仅仅做过两个项目我就发现这两个完全不相干的项目居然有那么多的文档内容是相似的，包括文档的框架和具体细节，因为保密原由我无法将文档贴出来让大家看看有多么的相似。
        第二个问题是有效传达的方式。也许我们不需要再召开全组的培训会议和周日例会，仅仅告诉小组长有哪些内容是必须掌握的，然后有小组长自己选择时间召开组内的交流会，这样会节省很多准备会议室或连接netmeeting的时间。有无数的先驱发现过人与人面对面的交流比看着PPT交流要有效的多。至少我敢于提出异议而不用担心经理的脸色（我发现有时候是因为这个原因很多人不敢说出自己的想法），我们使用组内邮件或直接走过去和他讨论将会节省很多时间。
        最后那个问题或许我们可以搭建一个沟通的平台，让开发人员能够和测试人员更好的沟通，而不需要走经理这条线，这么做有两个风险，一个是导致测试人员更加忙碌，一个是架空了项目经理。但我们为什么不裁剪这个V模型呢？将LLD融入代码的编写中去，或者把系统测试用例和集成测试整合成一套，又或者改变提交的时间……
        能够改进的地方还有很多，我的想法也没有完全说出，不过这篇文章有点长了，所以以后再继续交流吧！也希望看到大家对软件工程的一些想法。