精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>编程开发>>● 系统分析>>(轉貼)从程序员升级到工程师

主题:(轉貼)从程序员升级到工程师
发信人: 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.

[关闭][返回]