我的项目管理经历

                                我的项目管理经历
    项目管理经历记录了按照项目为单位的相关管理上的问题，包括管理思想、管理方法、
管理实践等相关的内容。（为了保密原因其中的名称均是化名，但并不影响真实性）

1. 新网络管理系统项目（2005/7——2007/4）
    该项目是在xxxxx公司从事的MSTP系列通讯网络的管理系统，用于管理公司自行研发生
产的MSTP设备和运营网络。在该项目的开发周期内同时也有一些公司其他的项目的网络管理
系统的开发工作（如：RPR等），所以此处以MSTP网管系统的开发作为一个项目的代表。
    MSTP项目是我所管理的第一个软件开发项目，主要工作包括团队的建设、项目管理和软
件开发的具体工作。同时也是第一次引入了敏捷软件开发——极限编程方法，在引入该开发方
法时并没有全面的按照XP方法的内容进行开发，而是采用了根据当时情况的需要而认为较为
符合团队实际情况的实践内容，主要是结对编程、代码公有制、单元测试、版本管理、持续
交付这几个方面的方法。由于我所接手的开发小组原来并没有形成明显的团队观念，所以在
整个开发过程中为了能够培养和组建一支高绩效的团队采用了我所认为的实践和方法，主要
是生日庆祝制度、项目阶段奖励制度、员工等级晋级制度、每周开发会议制度、荣誉责任制
度、轮值领队制度、为人师表制度、阶段性过程改进制度、共产主义制度、共荣共辱制度、
远景规划等相关的方法和体制。对于具体的软件开发活动则采用以身作则为人师表的方式给
每一个项目成员提供榜样和参考，对于需要在团队中采取的任何措施必须自己先身体力行，
我们遵循这样的格言：
                   “己所不欲，勿施于人。唯己所欲，勿施于人。”
                   
    我们在项目的过程中采用了如下的阶段工作安排：
    *项目初期阶段
       a. 首先确定了团队名称、团队宣言、团队目标和参考的开发方法体系，然后确立了
          项目的章程与远景目标;
       b. 接下来就是所要开发的软件的总体架构的设计和讨论工作，确保每一个团队成员
          都能够参与和理解所开发的软件架构，以围绕着架构进行工作（一个非常有效的
          工作方式）;
       c. 在确保每一个人都明确了开发的软件总体图景之后，需要就开发所采用的环境、
          工具和技术进行了必要的探索、准备和培训工作，并使得每一个开发人员都能够
          对开发的环境有一定的熟悉程度（不可能在开始前做到非常的精通，要不断地摸
          索和学习），其中包括了开发IDE环境、操作系统、第三方工具和库、项目工程
          目录结构规则等等一系列的开发约束;
       注：项目的需求建立在每一个开发人员都在以前的项目开发活动中了解了项目的真
           实需求，并且网管软件与被管系统之间的接口也已经事先定义完成。
    *项目进行阶段：
       d. 确定了开发活动中风险最大的部分，然后对其该部分的子结构模型进行了抽象设
          计，并就每一个人充分的了解该部分的模型结构；
       e. 根据模型结构的划分，将任务划分成为几个关键的组成模块，采用结对认购任务
          和开发人员自行估算的方法进行开发任务的下发方法；
       f. 在本次迭代开发过程中，由于有些开发人员没有全面深入的理解所开发的模块的
          结构导致了我必须和他们重新编写该部分的代码，但是还是在3个月的时间内完
          成了工作并进行了第一次成果演示；
       g. 后续的开发活动则按照每一个开发人员对软件不同部分的熟悉程度进行人物的安
          排，没有再采用自行认领的制度，但是在全部的开发过程中均极为严格的要求每
          一个模块在编写时必须同步编写单元测试代码；
       h. 模块的持续集成工作，我们在完成模块的开发后马上进行模块之间的集成工作，
          虽然没有采用严格的接口设计和约束，但是我们通过无阻碍的沟通和交流以及荣
          誉责任制度，保证了在所有的模块进行集成时从未遇到任何集成问题；
       i. 对集成了的模块进行了单独的集成测试的编写工作，采用代码编写者与测试者共
          同编写集成测试代码的方式保证了测试过程的顺利进行，同时亦保证模块会被更
          多的人理解和学习；
       j. 在开发过程中我们不断地修正工程目录结构、不断的从遇到的问题和陷阱中提炼
          出开发规范，并在下一个阶段积极的实施，做到持续的改进过程；
    *项目发布阶段：
       k. 在发布阶段我们最遗憾的是没有采用项目自动化的方法保证每天都能够进行项目
          的自动编译和测试工作，但是我们通过共荣共辱制度使得每一个人在项目的发布
          阶段不断的保证项目的健康状况，把项目当作自己的责任看待；
       l. 后来进行了几次release后发现确有必要编写一个发布脚本来完成该工作，遂通
          过最为简单的bash脚本完成了上述的工作（虽然很粗燥）；
       m. 在完成软件第一次完整发布后，我们组织团队成员进行了一次天柱山之旅，大家
          兴趣高昂，第一次看到了volcano团队的真正形成；
    *项目维护阶段：
       n. 根据我公司现场调试人员的反馈进行了必要的修正和再发布工作；
       o. 此时RPR项目被下达给了我们团队，根据通讯网络管理系统的相似性，我们第一
          次萌生了重用MSTP基础代码模块的想法；
       p. 由于MSTP网管代码并不是为了可重用的框架编写的，所以在开发RPR项目的过程中，
          我们对MSTP网管的基础架构代码进行了较大的重构，由于我们开发配有单元测试和集
          成测试，所以该重构过程变得非常的顺利和平滑，很快完成了该工作；
       q. 在公共基础上进行RPR项目的开发工作，我们仅仅只花费了50天的时间就完成了
          代码的设计、编写和全部的测试工作，是我们从未有过的历史；
       r. 我们在开发RPR项目的过程中，引入了MSTP项目的开发模式和全部的开发实践及
          规范，又一次的证明了上述开发策略的有效性，同时我们形成了一个真正团结一致的
          开发团队；
   
    最遗憾的是我没有能够得到公司领导的大力支持，由于公司领导采用了他自己的一套管理和开发
方法（瀑布模型），他的方法在我看来不太适合小规模的团队，由于无法达成一致的认识，为了能够
不在错误（我认为的）的开发方法上浪费时间，我选择了离开，告别了我的团队。现在他们回到了从
前，团队也不复存在。经过了这样的开发经历，我深刻的认识到了任何工作都不是单纯性质的工作，
软件开发也不仅仅需要面临和解决软件开发活动中的问题，还有与所在企业文化息息相关的内容，所
以选择开展工作的形式和方法需要充分的考虑到企业的认知和氛围，如果不能完成你的愿望，最好选
择离开。我认为在某些时候、经过了种种努力：
                                         “离开才是最好的选择。”