工作总结---部份内容涉及公司内部情况被我做了修改

这是到公司以来第一次认真的写个总结，技术总结不是片言只语就能写好，这需要一个系列的总结才能够完成，我就只谈谈其它方面的内容，前段时间公司通过了CMMI三级，我就想先从CMMI谈起，作为一个软件公司，取得CMMI无疑是软件开发专业化的表现，可是CMMI中有着严格的开发过程，这些开发过程的取舍我觉得应时适度，目前喊的比较多的还有敏捷开发，原型开发等等，究竟一个组织采用什么样的开发过程，这些也跟组织对行业的了解，对公司组织架构的形式密不可分。

   软件开发人员，或者准确的说是需求分析人员与客户较多的分以下两种形式，一种是客户对行业了解高于需求分析人员，另一种是需求分析人员对行业了解高于客户 ,两种不同的形式采用的开发过程肯定也不一样，目前我们部门的实际情况应属于前一种情况，这种情况更适合采用敏捷化的开发形式，有句话说的好，交付可以使用的软件，胜过面面俱到的文档，在以客户需求为导向的过程当中，我们只能去理解客户的意图，并不断迭代，以达到客户的要求。回到物流部门以后，跟着方方在做报关报检中叠加保税和文件管理模块，目前我们的开发过程更像是不断迭代的过程，我比较喜欢这样，........(被删除部份)，呵呵。这样的方式，更适合去完成一个客户、公司要求的时间紧的工作。

刚进公司的时候，在保税部门呆过一段时间，从我看到的来讲，保税部门所做的项目对行业了解还是比较透彻，当然了，可能每个地方稍有不同，但总体是都是大同小异的，......(被删除部份)，因为一个组织，都是由一个成长期到成熟期的过程，对行业了解从不熟悉到精通的过程，我想说的是，在成长期适合采用敏捷化的开发过程，成成熟期就可以借鉴CMMI中的某些过程了，更形像点讲，敏捷开发适合打江山，而CMMI适合座江山，当然了，喜欢敏捷也不是说什么文档都不要，有些对于迭代过程当中的设计成果还是需要记录的，我比较喜欢之前在保税部门豆豆写的文档，写清楚了软件原型的业务逻辑，且不是为了追求文档完美而写。

我觉着我们部门对走向对行业知识成熟的过程当中，会是从一个项目到一个产品的过程，也所谓是打江山到座江山的过程，项目和追产品做法又不一样，产品更多去关注灵活性，可维护性，但这些需要前期做更多的设计，花更多的时间去做设计，就好比打一场仗之前要花80%的时间去做战役方案，最后只要花个20%的时间去打一下就可以了，所以，以后我们可能会面临一些开发过程专业化而摆在面前一些问题，如开发过程与测试过程如何协作的问题，在客户要求的时间内，对于还存在BUG的开发成果是不是要交付的问题。

时间紧，就先写这些，以后有机会再写，还有些想说的是开发过程，还跟公司技术架构、组织架构也有关系，许许多多的问题就好比一个人的器官，每个部份都是相互协作不可忽视的部份，只每个部份都能良好运作才可能做出完美的产品