发信人: bungee_jumping(bungee_jumping)
整理人: leeyg(2001-06-05 20:41:43), 站内信件
|
从程序员升级到工程师
作者: dasdfasdfd (192.168.0.12)
日期: 05-31-01 14:42
从程序员升级到工程师
大多数象我这样对软件有浓厚兴趣的人，毕业后义无反顾地走进了企业，开始了程序
> > 员的生涯。那时，我们迷恋“大全”、“秘籍”一类的书籍，心中只有代码。当我看到
> > 一行行枯燥的代码变成了能够打电话的设备，变成了屏幕上漂亮的表格，变成了动听的
> > 音乐，成就感油然而生。我觉得自己也是一个出色的程序员了。
> >
> > 在用户的机房中苦熬三昼夜解决软件的bug，也成了一种可以夸耀的资历。五年前
> > 的某一天，我把曾经让我兴奋自豪的大量代码和少得可怜的文档移交之后，来到了华
> > 为。这里有更多的年轻人，我如鱼得水，可以充分发挥自己的想象力。
> >
> > 依然是代码，依然是匆匆地在纸上记下稍纵即逝的灵感（我们把它称作文档），依
> > 然是无休止地和bug作斗争。当有一天，一个新来的同事拿着署着我的大名的文档，小
> > 心翼翼地来问我时，我发现自己好象有点不认识它了。我心里有点沮丧，再看看代码，
> > 发现文档上记录的一些灵感已面目全非。我当时不知道那位新来的同事感受如何，但我
> > 从那时起，好象意识到什么。现在来看，那时的很多事情都是事倍功半。
> >
> > 去年年底，公司派我到印度从事项目开发，学习印度的软件开发管理方法。一种久
> > 违的冲动在心底升起。印度，我已去过两次，虽说是走马观花，但是，印象还是比较深
> > 刻。我在访问过程中和印度的工程师交流过，他们言谈中透着自信。他们给我讲解正在
> > 做的软件的测试环境，给我看他们写的单元测试文档。当我看到一个软件模块的单元测
> > 试用例有三百多页时，我觉得心里很是沉重。
> >
> > 当我第三次踏上这片土地时，我又见到了熟悉的人们，明亮的眼睛，温和的笑容，
> > 随意的穿着，风驰电掣的摩托，还有大学校园中穿着拖鞋，手抱书本的年轻人。
> >
> > 我也见到了我的项目经理，一个个子较高，瘦瘦的年轻人，据说刚从美国回来，已
> > 工作了五、六年。我听了心里很高兴，这回要一招一式地学两手。
> >
> > 需求分析的时间是一个月，项目经理和我们（实际上代表客户）讨论了proposal中
> > 的内容，确定每一项都是需要的。然后他把模块大致划分了一下，开始进入计划中的学
> > 习阶段。每个人在学习阶段要写出功能描述的胶片，给其他人讲解，不知不觉中，项目
> > 组的所有人对项目有了整体的了解。
> >
> > 他还安排了一些培训，如他们公司的软件开发模型、项目组中各角色的定义，以后
> > 及时的培训不断，只要项目组中有需求，他总是把qa或相关的人请来，培训很专业。需
> > 求分析完成后提交了一份四十多页的文档，当我看到这份英文文档中我写的部分整整齐
> > 齐地列在其中时，我的感觉很复杂，有些喜悦，但更多的是苦涩，我以前怎么就从来没
> > 有这样做过需求分析呢。在我写文档的过程中，qa给我们培训过srs的写作模板，后来
> > 我还是不放心，让他们一个有经验的工程师写了一段，我们再琢磨着照着写。这份srs
> > 虽然是多个人合写，但风格一致，内容详实。更为可贵的是，一直到最后，这份需求分
> > 析的内容都没有改过，以至于我们没有机会走一下他们的需求更改流程。
> >
> > 需求分析是项目的第一阶段，第二阶段的开发时间要根据需求分析的结果来确定。
> > 当对方的首席技术官（相当于我们业务部的总体组长）来和我们讨论计划时，他们已列
> > 出了对每个模块的代码行数的预测，可能存在的风险。根据他们公司的生产率－－300
> > 行/人月，他得出了项目第二阶段需要多少周。我们当时就提出了异议：1）公司对该项
> > 目需求很急；2）每月300行是否太少；3）我们还有下载的源代码参考。他解释说，300
> > 行/人月是使得项目能达到他们质量标准的经验数据，考虑到有源代码参考，生产率最
> > 多不能超过350行/人月。当他问我们公司的生产率时，我脑袋里转了三个圈，没敢多
> > 说，大概六、七百行吧。他沉默了一会儿，然后坚定地说，我们这个计划是建立在确保
> > 质量的基础上的，我想你们到印度来开发软件，首先看中的应该是我们印度公司的质量
> > 保证。我知道你们不缺乏软件开发人员，你们为什么不选择下载的软件呢。几句话说到
> > 了我的痛处，现在国内的弟兄们还在为使用下载软件移植的产品四处奔波呢！
> >
> > 随后的开发活动有条不紊，我们老老实实地跟着做。系统测试计划、用例，概要设
> > 计，集成测试计划、用例，详细设计，单元测试计划、用例，编码，单元测试，集成测
> > 试，系统测试。一个完整的v模型开发过程，其中每个过程都有review。当我们对一些
> > 设计的方法不太明白时，项目经理给我们发来了相关的资料，我不知道他当时是怎么想
> > 的，一些基本的分析、设计方法是十年，甚至二十年前的软件工程书中就讲到的，印度
> > 每个计算机专业的人员都是必修这些内容的。而我们除了对一些具体协议的代码很熟之
> > 外，对这些常用的方法似乎一无所知。我感到一些羞愧，进城直奔书店，把他给我开列
> > 的书找了出来，晚上躺在床上，仔细研读，我仿佛突然又遇到了能给我指点迷津的良师
> > 益友。现在印度所已形成了强烈的学习风气。我回来后也推销了700多本书，这些书教
> > 我们如何用工程化的方法开发软件，是成为一个软件工程师必读的资料。
> >
> > 我们的项目经理的计划控制能力很强，当有什么影响到项目计划的事情发生时，如
> > 人员辞职、实验室搬家、某一模块预测不准（该模块是我们预测的），他总是采取必要
> > 的措施，减少延期，调整计划。刚开始，我们对他们每天上午11点，下午4点下楼喝咖
> > 啡还有点意见，后来也跟着喝去了，原来，喝咖啡时的交流非常丰富，从项目管理到设
> > 计方法，从技术发展到风土人情，无所不包，对我们互相之间的理解，对团队的气氛很
> > 有帮助。我们项目的qa也在适当的时候出现在我们的面前，我们对她的工作只有一些感
> > 性认识。她每次参加会议时，手里时常拿着一个check list，项目经理准备相应的资
> > 料，回答一些问题，她打着勾，或写着项目经理的解释。她给我们做培训时也很耐心，
> > 体现出很好的职业素养，我至今还在怀念她给我们的帮助。
> >
> > 我从事软件开发已有九个年头了，可我现在仍然不能说自己是个合格的软件工程
> > 师，更不用谈什么合格的管理者。我看到一份报道说，瑞士洛桑一权威机构把中国的科
> > 技综合竞争力从原来的第十三位调到二十多位，原因是他们调整了一些评估标准，其中
> > 有一条是中国合格工程师的可获得性非常低。想着弟兄们熬红的双眼，四处奔波升级的
> > 疲惫身影，我有一个强烈的愿望：快把我们自己升级成合格的工程师吧
----
In this world there are only two ways of getting on---either by one's own industry or by the imbecility of others.
|
|