真正的软件工程师（中国与印度）_软件工程

大多数象我这样对软件有浓厚爱好的人，毕业后义无反顾地走进了企业，开始了程序员的生涯。那时，我们迷恋“大全”、“秘籍”一类的书籍，心中只有代码。当我看到一行行枯燥的代码变成了能够打电话的设备，变成了屏幕上漂亮的表格，变成了动听的音乐，成就感油然而生。我觉得自己也是一个出色的程序员了。

    在用户的机房中苦熬三昼夜解决软件的bug，也成了一种可以炫耀的资历。五年前的某一天，我把曾经让我兴奋自豪的大量代码和少得可怜的文档移交之后，来到了华为。这里有更多的年轻人，我如鱼得水，可以充分发挥自己的想象力。

　　依然是代码，依然是匆匆地在纸上记下稍纵即逝的灵感（我们把它称作文档），依然是无休止地和bug作斗争。当有一天，一个新来的同事拿着署着我的大名的文档，小心翼翼地来问我时，我发现自己好象有点不熟悉它了。我心里有点沮丧，再看看代码，发现文档上记录的一些灵感已面目全非。我当时不知道那位新来的同事感受如何，但我从那时起，好象意识到什么。现在来看，那时的很多事情都是事倍功半。

  　去年年底，公司派我到印度从事项目开发，学习印度的软件开发治理方法。一种久违的冲动在心底升起。印度，我已去过两次，虽说是走马观花，但是，印象还是比较深刻。我在访问过程中和印度的工程师交流过，他们言谈中透着自信。他们给我讲解正在做的软件的测试环境，给我看他们写的单元测试文档。当我看到一个软件模块的单元测试用例有三百多页时，我觉得心里很是沉重。

　　当我第三次踏上这片土地时，我又见到了熟悉的人们，明亮的眼睛，暖和的笑脸，随意的穿着，风驰电掣的摩托，还有大学校园中穿着拖鞋，手抱书本的年轻人。

　　我也见到了我的项目经理，一个个子较高，瘦瘦的年轻人，据说刚从美国回来，已工作了五、六年。我听了心里很兴奋，这回要一招一式地学两手。

　　需求分析的时间是一个月，项目经理和我们（实际上代表客户）讨论了proposal中的内容，确定每一项都是需要的。然后他把模块大致划分了一下，开始进入计划中的学习阶段。每个人在学习阶段要写出功能描述的胶片，给其他人讲解，不知不觉中，项目组的所有人对项目有了整体的了解。

　　他还安排了一些培训，如他们公司的软件开发模型、项目组中各角色的定义，以后及时的培训不断，只要项目组中有需求，他总是把qa或相关的人请来，培训很专业。需求分析完成后提交了一份四十多页的文档，当我看到这份英文文档中我写的部分整整洁齐地列在其中时，我的感觉很复杂，有些喜悦，但更多的是苦涩，我以前怎么就从来没有这样做过需求分析呢。在我写文档的过程中，qa给我们培训过srs的写作模板，后来我还是不放心，让他们一个有经验的工程师写了一段，我们再琢磨着照着写。这份srs虽然是多个人合写，但风格一致，内容详实。更为可贵的是，一直到最后，这份需求分析的内容都没有改过，以至于我们没有机会走一下他们的需求更改流程。

　　需求分析是项目的第一阶段，第二阶段的开发时间要根据需求分析的结果来确定。当对方的首席技术官（相当于我们业务部的总体组长）来和我们讨论计划时，他们已列出了对每个模块的代码行数的猜测，可能存在的风险。根据他们公司的生产率－－300行/人月，他得出了项目第二阶段需要多少周。我们当时就提出了异议：1）公司对该项目需求很急；2）每月300行是否太少；3）我们还有下载的源代码参考。他解释说，300行/人月是使得项目能达到他们质量标准的经验数据，考虑到有源代码参考，生产率最多不能超过350行/人月。当他问我们公司的生产率时，我脑袋里转了三个圈，没敢多说，大概六、七百行吧。他沉默了一会儿，然后坚定地说，我们这个计划是建立在确保质量的基础上的，我想你们到印度来开发软件，首先看中的应该是我们印度公司的质量保证。我知道你们不缺乏软件开发人员，你们为什么不选择下载的软件呢。几句话说到了我的痛处，现在国内的弟兄们还在为使用下载软件移植的产品四处奔波呢！

　　随后的开发活动有条不紊，我们老老实实地跟着做。系统测试计划、用例，概要设计，集成测试计划、用例，具体设计，单元测试计划、用例，编码，单元测试，集成测试，系统测试。一个完整的v模型开发过程，其中每个过程都有review。当我们对一些设计的方法不太明白时，项目经理给我们发来了相关的资料，我不知道他当时是怎么想的，一些基本的分析、设计方法是十年，甚至二十年前的软件工程书中就讲到的，印度每个计算机专业的人员都是必修这些内容的。而我们除了对一些具体协议的代码很熟之外，对这些常用的方法似乎一无所知。我感到一些羞愧，进城直奔书店，把他给我开列的书找了出来，晚上躺在床上，仔细研读，我仿佛忽然又碰到了能给我指点迷津的良师益友。现在印度所已形成了强烈的学习风气。我回来后也推销了700多本书，这些书教我们如何用工程化的方法开发软件，是成为一个软件工程师必读的资料。

　　我们的项目经理的计划控制能力很强，当有什么影响到项目计划的事情发生时，如人员辞职、实验室搬家、某一模块猜测不准（该模块是我们猜测的），他总是采取必要的措施，减少延期，调整计划。刚开始，我们对他们天天上午11点，下午4点下楼喝咖啡还有点意见，后来也跟着喝去了，原来，喝咖啡时的交流非常丰富，从项目治理到设计方法，从技术发展到风土人情，无所不包，对我们互相之间的理解，对团队的气氛很有帮助。我们项目的qa也在适当的时候出现在我们的面前，我们对她的工作只有一些感性熟悉。她每次参加会议时，手里时常拿着一个check list，项目经理预备相应的资料，回答一些问题，她打着勾，或写着项目经理的解释。她给我们做培训时也很耐心，体现出很好的职业素养，我至今还在怀念她给我们的帮助。

　　我从事软件开发已有九个年头了，可我现在仍然不能说自己是个合格的软件工程师，更不用谈什么合格的治理者。我看到一份报道说，瑞士洛桑一权威机构把中国的科技综合竞争力从原来的第十三位调到二十多位，原因是他们调整了一些评估标准，其中有一条是中国合格工程师的可获得性非常低。想着弟兄们熬红的双眼，四处奔波升级的疲惫身影，我有一个强烈的愿望：快把我们自己升级成合格的工程师吧!