创新课程管理系统-第一次迭代开发心得

 第一次做项目,第一次用javaee开发web工程项目,很多东西不会,摸着石头过河,也学到了很多东西。
  第一次迭代开发,小组总体做出来的东西不多,与计划相比少了不少。完成的大致有两个半模块,其一是登录注册,其二是报警信息展示,其三是工单处理,还在技术上研究了动态数据在图表上的动态展示的实现(基于单个数据项的展示)。总体来说,很多后台工作没实现,前端做的页面倒是蛮多,交互功能也有,前端的工作进度是先于后台的;后台开发的滞后性,以致于功能模块的集成进度受到了阻碍。
接下来就说一说我们组项目(创新课程管理系统)第一次迭代的心得。
设想和目标
 1. 我们的Web项目的目的是实现一个创新课程管理系统,开发出一个基础版本,供下一个项目组接手并投入实际使用。
2. 第一次迭代开发目标完成。
计划
1. 有很长一部分时间都在做计划、原型。  
2. 在整个第一次迭代的过程中,我们小组先是学习guns框架,guns框架学习成本很高。再一点是在人员分配上,感觉还是较混乱的,如果哪一模块遇到问题长时间没有解决的话,整个组的节奏会受到影响(不过也没办法,大家都是从零开始,guns框架的学习成本也确实较高)。
4. 项目的整个过程都按照计划进行,项目中途服务器、网页的功能出现一些问题。
5. 在计划中没有留下缓冲区,导致开发后半段十分紧张。迭代开发验收的前两天,边老师突然在群里发了一份儿验收要求,仔细一看,我们组当时做的没有几条是符合要求的。于是我们赶紧加班加点按照老师      的要求各种改代码,找bug。这也给我们一个教训,不要正好卡在ddl完成项目,一定要留出充足的时间去应对各种突发情况。幸运的是,最终验收结果还算较为满意。
6. 将来的计划将留出充足的时间检测bug,尽量将进度往前赶。
资源
1. 我们有足够的资源来完成各项任务。
2. 各项任务所需的时间和其他资源是通过其大致专业难度,听取老师意见决定的。
3. 对于那些不需要编程的资源 (美工设计/文案)没有低估难度。
变更管理
1. 因为我们小组每周都会开一次项目例会,汇报自己本周进度,所以每个相关的员工都可以及时知道了变更的消息。
2. 我们采用了举手表决,少数服从那个多数的方法,决定“推迟”和“必须实现”的功能。
3. 对于可能的变更没能制定应急计划,这点需要改进。
4. 组员能够有效地处理意料之外的工作请求。
设计/实现
1. 因为之前大部分时间一直都在写各种各样的文档,所以我们的项目起步比较晚,真正意义上编写代码的时间只有不到两个礼拜。而且,我们当初把项目实现想得过于理想,导致后来时间有些不够用。
2. 设计工作碰到模棱两可的情况,团队举手表决。
3. 团队运用UML来帮助设计和实现。工具有效。 比较项目开始的 UML 文档和现在的状态,发现有些逻辑在实际实现中发生了改变。需要要更新 UML 文档。
4.前端页面注册登录功能产生的Bug最多,因为在这个模块中需要反复测试各种错误提示。
5. 代码复审(Code Review)是小组间互相审查的,较为严格地执行了代码规范。
团队的角色,管理,合作
1. 团队的每个角色是通过表明自己所擅长或感兴趣的方面来确定的,大致做到了人尽其才。
2. 每次遇到问题时,团队成员之间能够做到互相帮助。 
3. 当出现项目管理、合作方面的问题时,团队成员通过讨论开会达成一致。
4.但是有一点不是很适应,因为我们组并没有全员参与开发,其实老师有一些强制性的要求对我们组不是很公平,不过也好在我们组内5个人都比较有凝聚力,我相信大家迎难而上我们一定可以按期按量地完成任务。
 
总结: 
第一次迭代开发学到了很多,主要是研究技术上的实现,没有多少时间帮助后台人员进行开发。但是,作为PM,在此我不得不说,后台的开发真的是太慢了!大家要抓紧时间,多多把任务放在心上。真心希望每个人都是开发中,“鸡与猪”故事里的猪。
posted @ 2018-12-09 18:33 黄柏欣 阅读(...) 评论(...) 编辑 收藏