2010年下年终总结--项目管理篇

     岁末将至，大三上也落下了帷幕，大半个学期都在被各种项目和各种比赛折腾，一直没有静下心来思考下自己的方向，得失，经验，自己的生活有些失控，很多时候都只能被动的应付，被各种不得不做的事情侵扰，这几天用几条线把生活理一下，把一些失败的地方也记下来，以此为鉴，这些失败的经验也是这一学期最宝贵的地方，是它们让我能走的更远，也希望这些经验能给看这篇文章的人带来或多或少的帮助。

 

　 项目管理篇

      这学期比较大的一个项目是考试系统，前后一共参与了13人（12编码，1美工），刚统计了下代码（SourceCounter），Cs代码已经突破了10w行，除去窗体自动生成的和一些工具类，估计也有7 8w了，现在这个项目已经进入后期测试，希望能有良好表现。将这期间的一些感触贴出来，希望这些经验能给小组以后负责项目的同学一些帮助，同时要注意的是这里面的感触只代表我目前的想法，这里面必然有许多还不成熟，或许到不了下星期我就觉得有些看法浅薄了，但它们都是基于现实经验的思考，而不是自己无病呻吟，即使有的错了，我觉得这些无论对经历者还是读者都是很宝贵的。

     下面的分类没有什么逻辑，仅仅是针对想到的主题，对这里面的观点欢迎大家拍砖讨论。

　1.这个项目最初的开发模式是 先开发教师端再开发学生端，这么做的考虑主要有 同时多路并进人手怕分不开，进度不好监控，但现在想如果 同时开发应该是比较理想的，因为

　　无论技术上还是管理上，理想的开发应该是 原型，测试，完善 这样一个迭代的模式，而且迭代时间应该尽量的短，这样技术上可以及时纠正偏差，管理上可以给大家个盼头，激励团队。而教师端先行，不见学生端，而教师端又这么庞大让大家总觉得这个项目似乎遥遥无期，没有一个准确的盼头，在教师端耽搁时间有点长。而且教师端和学生端没有很早的互相反馈，教师端有的功能上的偏差没有及时纠正，现在进入测试阶段，才对项目的走向有信息。一言以蔽之，开发原型，再迭代开发较之线性的瀑布型开发模式有巨大优势，再确定开发进度时要以此为戒。

      迭代开发和瀑布式开发的一个看起来矛盾的地方是 迭代开发要对项目一直做更改，而有的同学的代码是越改越烂，总想避免迭代。其实这些是逃不掉的，而且越往后修改的成本越大。此外，如果项目的架构是真正ORM，完全基于对象，那么我们之前很多大项目越修改问题越多的事情就可以避免，我们很多项目的架构都是用面向对象的语言和技术写做面向过程的代码，具体架构上的会单独讨论。

　2.项目的最初需要做的事情有：

      1)确保团队其他成员了解需求，了解要解决的问题，了解数据库结构等。尤其团队成员没有完全参加需求定制的时候，最重要的还是理解这一块要做成什么样子，具体是为了解决什么问题，客户最在意哪些，哪些是需求危险地模块。

　   2)制定项目开发中的技术标准，如 时间日期的格式，对中间协议的规定，对文件结构的规定，这些要尽早定，而且方便起见，最好直接放在托管代码里。

      3)非常重要的一点（至少对我来说，我总想求大求全）是确保系统中哪些东西做，哪些东西不做，哪些东西什么时候做，第一阶段都是要出一个原型，在后面一级一级的完善。更严谨的来说，这一块在需求阶段就要确定，只是现在我们流程还走不了那么规范。。。

　3.团队激励：

　　这学期里老师不在，大家的士气激励我没有做到位，在大家存在厌倦心理的那段时间里 我是中止项目进度(这里面还有些客观因素)来让大家放松，后来发现这样成效是不大的，大家需要的是一个有明确，可行时间表的项目进度，而没有一个原型的系统在这方面表现乏力，我在对一些模块不满意时也没有做好开发同学的鼓励。

    4.开发日常制度：

       在项目之初，想每天固定时间例会，有观点觉得 每天都在一起没必要 而没有实施，后来认为这个制度是极有必要的，让大家了解下互相都在做什么，可以使团队互相了解，督促，也方便任务的安排和调度；类似的一些制度像小黑板上记录每个人的任务等也都是非常有效的，黑板上写下每个人的开发任务和开发时间，这样会让大家心里有底，也能催促开发进度，希望小组以后项目能坚持。

    5.项目组织者本身的素质和需要注意的：

       最重要的也是我最缺的是魄力，在很多时候没有坚持自己的看法，或者对一些问题有姑息，结果会产生新的，更大的问题。这个项目本来是要严格按面向对象思想来走，这样的好处是明显的，可以使代码更健壮，不会出现那种一改就死的问题，但没有做好这方面的宣传，大家对此认识不够，有的模块并没有严格按照这个分层来走，而这时我没有强制舍弃这部分代码，造成了DAL层失去了原本的作用，操纵的还是dataset而model有一半成员都没用，到最后反而成了累赘。

      组织者非常重要的是对宏观的把握，要能想到各个模块的入口和出口是什么，和其他模块连接时哪些地方可能是问题，流程这样走下去能不能走通，有没有漏掉哪些模块，这些的工作并不轻松，因此不要给自己身上安排太多代码开发的任务。在学生端里，我对考试的核心模块不放心而自己开发，使得没有足够精力来监督测试和寻找遗漏模块。这一次是有足够经验的开发同学不多，07,08级同学人数上不给力，到下一届时候会好得多。

　 而且我现在想有必要列出一个文档，这个文档纵向为各个模块，横向式状态，包括 开发中，开发完成，流程走通，测试成熟，用户体验良好几个阶段。

      分工时不仅要考虑开发的工作量大小，还要考虑维护的成本，如业务核心逻辑可能代码不多，不过需求更改最容易影响的就是这里，分配时要酌情考虑。另外，不要太过拘泥与给谁分配的代码量多，谁的少，这里的多少可能只是一个开发日的量，而且绝对的合理本身就是不可能的。

     6.系统架构本身

      这次架构我的构思是完全面向对象，后来发现这样走的很艰难，因为数据库并不健壮，经常要改，这样使代码生成工具派不上用场，因为分层多，各个模块的代码量很大，这个问题的根源可能和我们的整体开发观念有关，我们是 需求->数据库->架构来走的，但面向对象应该是 需求->抽象类->数据库，这样才是ORM，这个模式的实践只能由后面同学在其他项目里来尝试了。我认为这样的好处巨大的，可以一定程度上缓解需求更改带来的问题，现在我们已经认识到了这个问题，但我们集中注意力在文档上，我们努力做出最真实需求的文档，但这样难度依然很大，大家对文档里理解还可能不一样，文档细化粒度小了本身就是个很大的工作量，而且从文档来想系统是否健壮本身就是个很挑战性的工作，而如果能给系统建模，这个抽象的对需求的思考就会变得可考据些，希望后面的同学能在这个思路上实践下。

     另外架构时候系统分层数也应该考虑实际情况，太多太少都会是灾难，要以最少的层数来最大实现关键处的复用为目标，分层数一多，整体的代码量也就上去了，而且如果添加一块功能需要在4层 5层（额 我们有WebService...加上它的类库就得2层）的代码上都做修改，想想就是个头大的事。

    7.项目进度

　　项目进度的估计：项目进度的估计不能只凭自己主观臆想，现在想 进度估计的一种方法是把一个模块分解为大的功能点，每个功能点估算工作日。可以看到这里面的难度在于估算工作日，这里需要考虑代码量，参加同学的技术水平，这一块对其他模块的依赖，有无可能的技术难点，鉴于小组特殊情况，还要考虑同学有没有课，机房有没有课，如果一段时间未接触代码，还要有一定的上手时间。

       上面是针对分模块，还有一个是分层，在一个架构良好的，规模中型以上系统里，至少要有三-四层，底层的代码会被多处复用，这些也会给项目进度估算带来难度。一般来说，在不用采用代码生成工具时，一个模块在刚开始架构的时候时间是很长的，这一块代码量也最大，像项目之初的不短一段时间大家都在做底层的功能代码。

    8.测试

　  测试时候测试团队至少要有一个人专门负责组织测试，督促提交代码，收集整理bug文档，部署新测试，这些的工作量也很大。一个项目测试大概可以分为这几个阶段  功能完整的原型->流程测试->功能测试->模块间关系测试-.压力情况和异常处理测试->用户体验测试。如果人手够的话，用户体验的测试和订正可以和之前并发进行。另外测试bug的更改的修订要同时进行，以尽量短的时间进行迭代反馈，投入新的使用。

      在测试阶段尽量保证每天晚上都有测试，白天根据反馈问题进行订正。

　   在最后几天上线了BugTracker系统，发现这个在项目测试阶段非常有帮助，使大家的bug提交和跟踪反馈效率大大提升，现在甚至想象不出来以前没有bug跟踪系统使用Excel时候的测试是怎么过来的....