【工作感悟】完整项目的第一个里程碑感想

原创 2007年10月14日 18:17:00
三个月的试用期结束了,说实话,对于转正方面的事,一点感觉都没有,闯哥和生哥他们没事还谈论一下转正的事,而我根本没仔细考虑过,也许真的没什么关系吧,除了可能加点工资,然后把医疗保险等各种各样的卡发下来,也就不会有什么特别的了吧。麻烦!

经过2个月的努力,又一次得到了同事的肯定,感觉自己像火影里的鸣人,异常期盼着同伴的认可,所以在 cf  和 anxinboyin 给我以鼓励和肯定的时候我都非常的激动。

        黄金周过去了,我们的项目也进入了第二个里程碑,在短暂的调整之后,又要开始紧张的“战斗”了。说实话,这一阶段学到了很多东西,我记性超级烂,所以一定要记下来。

<需求>
        如果要评出大学期间最讨厌的专业课,那我一定会毫不犹豫的说是“软件工程”,原因很简单,跟政治一样的东西,作为一个工科的专业,我想谁也不会愿意去背那些不痛不痒的理论知识。然而,进入公司后,原来以为最不重要的东西,现在发现是最重要的。如果一个项目,没有软件工程的管理,将会是何等的混乱!其产品的可靠性,也就可想而知。
        软件开发的第一个流程就是需求分析,上大学那时候觉得需求、设计、编码、测试这几项中最简单的就是他,客户说什么,我们做什么就行了呗。现在想想,当时的想法幼稚的可笑!经过了这次“实战”,才明白为什么需求分析要占到整个项目15%的工作量,我们平时与机器打交道,写出的程序对,机器就会给我们正确的显示;错,机器就会给我们Error、Warning或者崩掉。但是需求是要和人打交道的,别人想要的东西,我们不可能马上完全的理解,如果觉得这样就可以了,我们理解的差不多了,然后就去设计,可能会发现我们设计完了,开始写代码的时候,有些需求我们没考虑,而这些被要求的功能,可能颠覆我们之前的设计!QCD中的Q和D都不容易保障!如果不仔细分析需求,那么很可能错过一些隐藏的需求,造成后期的风险。
        再者,需求分析是要指导设计的,不能完全体现功能需求的设计,即使他再有弹性,再漂亮,也不是好的设计,因此需求分析的“粒度”就需要十分的明确,不能在需求文档中写那些含糊其辞的东西,要尽量简洁,也要绝对详细,用一句同事们经常说的话,随便来过来一个人,看你的文档,就知道你要做什么!这就是需求分析的“粒度”的标准。

<设计>
       由于我们工具的特殊性,所以在第一个里程碑结束后,我们的设计和最终成果物的Demo已经出来了,先说设计!
       设计是一个反复推敲的过程,而设计的优劣,最直观的体现就是他是否能够在变化面前,能够从容的应对!因此我们在设计的同时要考虑实现现在需求里的东西,也要考虑以后可能加入到需求里的东西,这个尺寸需要拿捏的比较恰当,只考虑实现当前需求,会造成我们的设计在变化面前,像飞在天上的风筝一样脆弱;过分考虑以后的需求,又会造成我们的设计大而全,没有重点,又过于复杂。这时候就需要设计模式,需要OO的帮助,更需要经验。最近在看两本书《深入浅出设计模式》和《深入浅出OOAD》,获益匪浅,也把一些东西付诸实践,比如我们的设计就用到了单件模式,而实现单件模式的方法就是通过一个代理模式的思想做到的,这样提高了效率,规范了动作,两者兼得!我和 anxinboyin 作出这样漂亮的东西后,着实兴奋了一天!
       不得不提到的是在设计阶段 anxinboyin 的一个理念就是规范动作,让拥有相似数据段的类型拥有一致的数据结构,这样在处理时可以将耦合程度降至仅对这段数据,而不是整个对象,(呵呵,这句好像不太容易说清楚,打个比方来说,一个对象需要某种服务,而使用这种服务,需要向提供服务的类型传入数据,而这些服务在一定程度上像模板方法模式一样是一组纵向的方法,因此把数据块的各段规范一下,在解析时,就可达到模板方法一样的效果)
       在设计阶段另一个工作重点就是编写设计文档,这时就要利用UML和流程图来表达自己的思想,文档要规范,不然就会给以后的维护带来困难。因此在写文档时必须注意命名方式的统一,绘制UML图和流程图的风格的统一。还有就是多用图来表达自己的想法,因为40页以上的设计文档,字看多了,谁都会头疼。

<编码>
       代码要从三个角度来讲:
       1.最简单的就是编码风格的统一,这时需要依赖编码规范,要让项目中多个人写的代码,就像一个人写的代码一样“整齐”。变量的命名,函数的命名方式要让人能够“顾名思义”。代码的逻辑要简单,不太容易理解的地方一定要加注释。
       2.效率,效率问题往往和代码的复杂程度有一定关系,高效率的代码往往不容易理解。这就需要折中,有两个小技巧可以借鉴,用do while(false)来避免多个return;在多情况判断的时候将可能性大的放在前面。
       3.最不容易做到的放在最后,他也是一种style,这个style并不像编码规范那样肤浅,但是却非常重要,有些书可以借鉴《Exception C++ Style》《Effictive C++》等,利用书中提到的原则进行编码,可以让我们的代码更加健壮!(在写这条的时候,我担心这种感悟是不是有点大了,但是仔细想想,由于自己看过的C++方面的书很多,水平不高但也不是初级,加之同伴 anxinboyin 水平比较高,我们在编写Demo的过程中已经大量的用到了上面提到的两本书中的原则,因此这条也不算太“大”,呵呵)

<同行评审>
       第一次听说这个词是一篇介绍 Boost 库的文章里,当时翻译的好像是什么“同僚复审”,整的好像很高深的样子,到底是什么意思我到现在也不确定,但是在开发过程中,我们使用的“同行评审”,确实是提高我们产品质量的好的手段。
       俗话说“三个臭皮匠,顶个诸葛亮”,把我们做出来的成果,不论是文档还是代码,拿出来让其他同事看看,检查以下,这样就可能把其中的一些隐含问题找到,“一个”人考虑的方面可能不会很全,“一个”人的经验也不会比大家的经验总和高,所以这种review绝对会提高我们产品的质量。

<原因分析~缺陷预防>
       在评审中发现的问题,可能并不仅仅是这一个人的问题,别人也可能会犯同样的问题,所以我们需要“原因分析”,这并不是在批评某一个人犯了多么“低级”/“严重”的错误,而是告诉大家,这样的错误是如何产生的,以及如何做能够避免这样的错误,这就是“缺陷预防”。有的时候可能找不到本质问题,但是只要把问题“留档”,总会有一天把问题的本质揪出来!

<CMM>
       当初我不理解为什么要规定CMM的5个等级,现在终于明白了,其实我们做过的同行评审,原因分析和缺陷预防都是从CMM中得来的。我们老大说过,要把自己提升到全局的高度去看问题,才会有进步。管理为什么重要,我想亲身经理一下都会有体会。

        期待phase2的进步!

在项目中设立里程碑有哪些好处

在项目中设立里程碑有哪些好处 帮助同步工作成果   使项目团队外的人员也能看到项目进展情况和质量情况   可在项目进行中纠正偏差   着重于评审项目目标和交付成果   增...
  • wangchinaking
  • wangchinaking
  • 2006年03月07日 17:29
  • 1607

Git学习7:Git中的里程碑

认识里程碑里程碑就是Git中的tag,tag是与某个具体的提交(commit)关联的,使用里程碑的好处在于可以直观的看到版本的演变历史,而不是简单生硬的commit id。里程碑的命令是git tag...
  • u011116672
  • u011116672
  • 2016年04月28日 20:27
  • 2941

项目里程碑

项目需求 用户功能:用户可以注册、登录、退出系统 发布博客:用户可以创建、修改、查看、删除自己的文章 评论功能:任何人都可以对博客进行评论 管理员功能:管理员拥有比普通用户更高的权限,可以管理所有用户...
  • wen_special
  • wen_special
  • 2017年12月11日 11:03
  • 73

【项目管理】项目实战笔记之五:里程碑管理

一、背景 由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。 如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说: 以Windows 7为例,包含七八千万条...
  • liangjingbo
  • liangjingbo
  • 2012年04月27日 23:31
  • 2686

2016总结,真正新的里程碑和新起点

有感而发,2016年过的真心太快,一般来讲往年都会在自己的CSDN博客上面更新一下年终总结和新年展望。近段时间公司的事情确实太多了,导致自己的博客和公众号几乎都不更新了,对大家说一声:抱歉!( 201...
  • jiangqq781931404
  • jiangqq781931404
  • 2017年01月01日 08:52
  • 5965

产品研发流程的四个里程碑

《启示录》书中提到通过设立产品陪审团来监督产品研发流程,制定关键决策。一款产品的研发包括四个里程碑: (一)评审产品战略和产品路线图,启动评估产品机会的工作,即选择值得投入精力的产品,请产品经理...
  • orangelizq
  • orangelizq
  • 2016年05月23日 09:47
  • 2015

如何建立项目里程碑

建立项目里程碑   偶尔跟一些业内人士交流,发觉部分人士对『里程碑』的作用与如何建立里程方面有很大的意见差异,难怪一些技术人员对工作分解架构(WBS)感觉困扰。   当我们在路上行走的时候,会在沿...
  • tastelife
  • tastelife
  • 2010年11月11日 18:54
  • 374

控制好项目进程中的里程碑

案例   公司新成立,管理部负责按照CMM2级关键过程域制定了软件开发的规范,在推进规范执行的过程中,希望先选一个项目组作为试点。小王刚从系统分析员的 岗位上被任命为项目经理,负责一个物流货运系统...
  • tastelife
  • tastelife
  • 2010年11月11日 19:10
  • 754

软件项目量化管理(CMMI高成熟度)实践经验谈——之项目管理过程监督与控制篇

项目监督与控制(PMC)是CMMI 2级中项目管理过程内容,使用的比较普遍,但能成为一套管理体系的还是比较难的,本文记录实践过程中主要内容和样式,供相互交流、学习使用。...
  • xiaoyw
  • xiaoyw
  • 2015年03月16日 21:49
  • 1893

软件项目管理(CMMI成熟度)实践——之上线里程碑报告

本文实际项目为例,通过分析工作量、人力资源、风险与问题跟踪,总结出项目采购成本增加的原因,并总结经验教训。...
  • xiaoyw
  • xiaoyw
  • 2015年11月19日 21:12
  • 4739
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:【工作感悟】完整项目的第一个里程碑感想
举报原因:
原因补充:

(最多只允许输入30个字)