工作总结---部份内容涉及公司内部情况被我做了修改
这是到公司以来第一次认真的写个总结,技术总结不是片言只语就能写好,这需要一个系列的总结才能够完成,我就只谈谈其它方面的内容,前段时间公司通过了CMMI三级,我就想先从CMMI谈起,作为一个软件公司,取得CMMI无疑是软件开发专业化的表现,可是CMMI中有着严格的开发过程,这些开发过程的取舍我觉得应时适度,目前喊的比较多的还有敏捷开发,原型开发等等,究竟一个组织采用什么样的开发过程,这些也跟组织对行业的了解,对公司组织架构的形式密不可分。
软件开发人员,或者准确的说是需求分析人员与客户较多的分以下两种形式,一种是客户对行业了解高于需求分析人员,另一种是需求分析人员对行业了解高于客户 ,两种不同的形式采用的开发过程肯定也不一样,目前我们部门的实际情况应属于前一种情况,这种情况更适合采用敏捷化的开发形式,有句话说的好,交付可以使用的软件,胜过面面俱到的文档,在以客户需求为导向的过程当中,我们只能去理解客户的意图,并不断迭代,以达到客户的要求。回到物流部门以后,跟着方方在做报关报检中叠加保税和文件管理模块,目前我们的开发过程更像是不断迭代的过程,我比较喜欢这样,........(被删除部份),呵呵。这样的方式,更适合去完成一个客户、公司要求的时间紧的工作。
刚进公司的时候,在保税部门呆过一段时间,从我看到的来讲,保税部门所做的项目对行业了解还是比较透彻,当然了,可能每个地方稍有不同,但总体是都是大同小异的,......(被删除部份),因为一个组织,都是由一个成长期到成熟期的过程,对行业了解从不熟悉到精通的过程,我想说的是,在成长期适合采用敏捷化的开发过程,成成熟期就可以借鉴CMMI中的某些过程了,更形像点讲,敏捷开发适合打江山,而CMMI适合座江山,当然了,喜欢敏捷也不是说什么文档都不要,有些对于迭代过程当中的设计成果还是需要记录的,我比较喜欢之前在保税部门豆豆写的文档,写清楚了软件原型的业务逻辑,且不是为了追求文档完美而写。
我觉着我们部门对走向对行业知识成熟的过程当中,会是从一个项目到一个产品的过程,也所谓是打江山到座江山的过程,项目和追产品做法又不一样,产品更多去关注灵活性,可维护性,但这些需要前期做更多的设计,花更多的时间去做设计,就好比打一场仗之前要花80%的时间去做战役方案,最后只要花个20%的时间去打一下就可以了,所以,以后我们可能会面临一些开发过程专业化而摆在面前一些问题,如开发过程与测试过程如何协作的问题,在客户要求的时间内,对于还存在BUG的开发成果是不是要交付的问题。
时间紧,就先写这些,以后有机会再写,还有些想说的是开发过程,还跟公司技术架构、组织架构也有关系,许许多多的问题就好比一个人的器官,每个部份都是相互协作不可忽视的部份,只每个部份都能良好运作才可能做出完美的产品