标签：大致 应急 个数 web项目 出现 注册 方法 遇到 之间
第一次做项目，第一次用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，在此我不得不说，后台的开发真的是太慢了！大家要抓紧时间，多多把任务放在心上。真心希望每个人都是开发中，“鸡与猪”故事里的猪。
创新课程管理系统-第一次迭代开发心得
标签：大致 应急 个数 web项目 出现 注册 方法 遇到 之间
原文地址：https://www.cnblogs.com/hbxloveyuu/p/10092438.html
