项目总结

2011年的上半年，我们伴随着PAP度过。2011的上半年，我们的工作因为PAP而变得丰富多彩。从3月15号立项，到7月19号发布，整整历时4个月。还不包括1月份和2月份的前期准备，技术调研工作。
承蒙兄弟们看得起，第一次担任PM角色。从制定项目计划，到寻找资源，每一步迈得都是崭新的人生，每一步走得都是勇敢的第一步。
怀揣着性能自动化、减少人力，解放时间的美好理想，一群没有任何开发经验的我们开始启航。
项目前期，基本处于技术调研、设计阶段。这段时光，是轻松的，所有的工作是集中在一个人的身上。正是由于过度的集中，才导致项目中期和后期，我们还要回头去做项目初期的事。
项目中期，项目开始实施scrum敏捷管理模式，大家开始进入真正的编码阶段。每个人开始owner一个模块。这个时候，详细设计不够详细，E-R图没画好，原型图未开发完毕等等一系列问题开始慢慢暴露出来了。这里很大一部分是我的责任，我没有组织好前期的详细设计评审、E-R图评审和原型图开发。还记得第一次迭代的狼狈吗？代码跑不起来，demo实现不了，迭代一，其实每个人只完成了一个小功能。从3月份kick off 到5月份的第一次迭代，我们其实完成的工作量非常少。我给迭代1的总结是：
1.代码风格未统一。
一个统一的开发环境是必须的
2.demo没有页面支撑
每个开发同学要理解需求，自己开发原型图。通过画原型图来理解需求，明天真正要做的是什么东西
3.缺乏沟通
大家有很多问题，很多疑惑，但是缺乏沟通，我明白了每天的晨会是多么重要，哪怕只是聊天10分钟。
4.任务完成量少
敏捷的核心是什么？是以人为本，相信团队。充分相信每个人会成为自己模块的owner，计划好自己模块每个迭代的开发任务。
迭代2的demo效果非常好，大家明显比迭代1效率高很多，基本完成迭代开始前申请的任务。敏捷模式慢慢开始成形。但是随着自己owner自己的模块，
迭代2暴露一个很严重的问题，有同学开始主动砍需求，修改需求。出发久了，我们越要思考我们为什么要出发？我们出发的目的的什么？
从我的角度来说，迭代2最大的问题就是我没有很好的review 需求和大家的问题。使有的需求在没经过讨论就改变了。
迭代2结束后，我发现项目整体进度慢了许多。这里也是我的责任，我没有很好的评估前端开发的工作量。对项目整体工作量的评估不足，导致了迭代3开始开发工作量的加大。
迭代3我们暴露一个很大的问题，就是代码的规范问题。由于我们缺乏架构师的统一规划，每个同学的注释、编码风格不统一，导致各模块衔接时出现了很多问题。
从PM角色，我总结了几点，只是自己的一些体会和心得，希望以后我们可以少走弯路。
1.PD确认整体需求，需求经过项目组评审后，整体需求不轻易更改。
2.需求转化为原型图，这部分工作由每个模块的负责人来做，让每个负责人真正理解需求，明白要做的东西，而不是简单照着别人画的原型图和需求文档进行开发，否则成不了模块的owner。
3.架构师整理项目的框架、E-R图、编码，注释的规范。统一风格。
4.敏捷开发，确认项目的总体工作量，确认每个迭代需要完成的工作量。
5.每天晨会，加强沟通，暴露问题。会后做好跟进工作。
6.每个迭代后 ，review 项目进度和问题。降低风险。

这不算正式的项目总结报告，只是一些小心得，非常高兴和兄弟们并肩作战半年，期间经历的风雨，只有我们体会到。
经历过这一次洗礼，我相信我们更加成熟、更加稳健！