8号团队-团队任务5:项目总结会

团队信息

团队序号：8号
开发软件名称：教师个人题库管理系统
会议整理人：

• 姓名：王和旋
• 学号：2017*****7239
• 职务：项目经理&软件工程师

项目地址

码云仓库地址：href="https://gitee.com/HeroWe/teacher
软件源码地址：https://github.com/2272062968/TeacherQuestions

会议记录

会议信息

时间：2019年6月25日8:30
地点：图书馆3楼中厅
成员：王和旋，田阳，马阔，董宇林，谷云鹤
参与情况：全员参加
照片：

会议开始前，首先明确怎么开好一个Postmortem会议:

1. 保持会议轻松愉快的氛围，可以考虑换一个开会的环境，如有饮料、零食、音乐相伴就更好了。
2. 当[大官]的最好不要出现，让大家畅所欲言。(即使出现，也要夹着尾巴，不要为自己以前的行为辩护，当个好听众。)
3. 坚持对事不对人的原创，强调一-如果再有一次机会， 会如何改进?而不是挖历史旧账。
4. 照顾到模板提及的各个领域，可以深人团队最感兴趣的部分。
5. 让所有人都有充分发言的机会。
6. 有人记录发言要点，最后列出所有改进意见。
7. 最后大家可以投票，如果我只有三票，投给哪些改进意见?
8. 大官们保证要采取行动，执行票数最高的一些改进意见。

对设想与目标的回顾

• 我们的软件要解决教师对自己的题库进行管理的问题。
• 定义的不是很明确，有些地方只有大概的描述，具体计划没有很清晰，导致后来开发的时候在登陆问题是否保留纠结了很久。
• 我们对典型的用户与场景有清晰的描述，比如教师在授课过程中经常需要出题目，还需要经常更新题目，这个过程需要花费较多时间，我们要开发一款软件方便试题管理，以及自动生成试题试卷的功能。
• 我们有充足的时间做计划（一周）
• 团队在计划阶段对于不同意见的解决方案是：从实用性角度考虑，投票，以及向用户了解需求几个方面解决

对计划的回顾

• 我们原计划的工作没有都做完（课件管理和忘记密码的邮箱验证）。课件管理功能在开发和用户沟通的过程中认为实用性不大，而且也不是核心功能，所以删掉了。邮箱验证功能我们后来了解到需要在服务器配置SMTP(发送邮件协议)，对操作还不熟悉以及能力的问题没有完成。
• 登陆和密码框的水印样式现在看来没有必要，因为这个样式和后来的修改不一致，后来我们发现可以在下面放文字空间再覆盖，然后后台简单判断一下显示隐藏就可以了，删掉了这个样式
• 并没有每一项任务都有清楚的定义和衡量交付件。如：试题录入界面Ui及代码设计，属性和尺寸最开始没有清晰定义
• 项目的整个项目基本按照计划进行，但是中间加了一项登陆注册功能和共享试题的问题
• 计划中留下了缓冲区，作用很大，比如给共享试题问题的解决留下了开发时间
• 将来的计划修改是每次计划尽量留下缓冲区，加班问题随情况而定
• 用户量，用户对重要功能的接受程度和预想一致，删除了一些无用功能，增加了登陆管理共享试题的功能，离目标更近了。
• 经验教训：做计划一定要把问题尽量考虑周全，否则后期加功能很麻烦。
• 如果历史重来一般，我们会更多的和用户沟通以及多参考其他优秀的设计

对资源的回顾

• 我们有足够的资源完成各项任务
• 各项任务所需时间由各项任务领取人做计划，服务器资源由队长提供，精度不是很准确，因为大家对自己的计划估计时间普遍要长
• 测试时间足够，因为测试前一天的软件，并且有两人测试，人力资源稍有稀缺，因为软件开发量比较大，硬件资源暂时足够，但还是存在卡顿，因为我们做的的个小型软件使用的阿里云学生服务器。对于那些美工，设计，文案资源，难度估计和工作基本没有差别
• 有感到某个人的工作让其他人做更有效率，因为任务分配时对大家的能力了解还不够
• 我们学到了合理对每个人分配合适的任务资源和时间效率是极高的
• 如果历史重来一遍，我们不会先急着开发，而是先了解好大家的能力，合理，会更高效

对变更管理的回顾

• 每个相关的员工都及时知道了变更消息
• 由于我们变更的是UI设计师，对于决定“推迟”和”必须实现“的功能，我们采用了先让UI设计师了解工作，软件工程师先开发核心功能，最后再添加UI的方案
• 项目的出口条件定义清晰度一般，好多都是按照个人思路设计
• 对于可能的变更可以’制定应急计划，因为大家每日的工作都会提交的码云管理平台
• 员工可以有效的处理意料之外的请求，遇到一项紧急任务或bug，正常计划的任务会周天或者加班完成
• 经验教训：合理熟练的使用工作管理平台或者做好每日工作记录，当变更到来时才能迅速应变
• 如果历史重来一遍，我们依然会更详细的使用码云平台进行每日的工作管理

对设计/实现的回顾

• 设计工作在每次软件开发任务之前，由项目经理为主干带大家讨论。时间，人选合适
• 设计工作有碰到过模棱两可的情况，如一个界面的具体设计方案，解决方案是让UI设计师或软工先做一个简单模型，再改进
• 团队用到了单元测试来测试每个页面的具体功能。没有进行测试驱动的开发。UML工具用到了墨刀和Axure，我们用到的这些工具感觉是很有效的。
• 对数据库数据的操作以及数据展示产生的BUG最多，因为对数据库不熟悉，数据的权限问题管理的不好。在发布之后发现了有些不共享的试题其他人也能看到。当时在设计／开发时没想到是因为开发时测试后没出问题
• 代码复审是按照功能的逻辑性顺序审核的，基本都严格执行了代码规范
• 我们学到了前期的设计对软件开发的顺利进行是很重要的，如果历史重来一遍我们会花更多的精力去设计，这样才能快速的完成作品

对测试/发布的回顾

• 团队有每日的测试计划，具体在码云仓库有记录
• 做过验收测试，我们找了许多人来内测我们的软件
• 帮助团队测试的工具主要有visual studio的断点功能来逐步分析
• 团队测量和跟踪软件的效能也主要是借助visual studio的内存展示图和断点功能。从软件实际运行结果来看，这些测试工作是有用的，例如在切换选项时会卡顿一会，因为需要请求数据库，测试出问题后改成了当数据有修改时才请求数据，提高了软件的效率。
• 发布过程中发现的意外问题有：
  • 如果用户电脑没安装office或者doc文件的默认操作软件不是office，生成试卷功能会闪退，已经找到问题并让我们开发的软件给出提示信息
  • 不同电脑分辨率显示软件大小有问题，已经做出的可修改窗口大小和自动适应屏幕的改进
• 我们学到了软件发布前的测试时很重要的，如果历史重来一遍，我们会先找更多的测试用户体验我们的软件

对团队的角色、管理、合作、的回顾

• 团队角色是根据每人的擅长点确定的，算是人尽其才

• 团队之间成员遇到问题都会互相帮助

• 当出现项目管理，合作方面问题时，团队的解决方案是让当事人首先冷静下来，看看是不是自身的原因，如何不是的话再找他好好谈谈，如果是的话要及时改正

• 每个成员都明确公开地表示对别人帮助的感谢：

  • 王和旋：我感谢田阳对我的帮助，因为测试工作仅靠软件工程师完成很可能会有bug产生，而测试工程师每天都会有计划的测试软件可能出现的问题，并将要修改的许多问题在码云的issues上指派给我，锻炼的我的编码能力，提高了软件开发的效率
  • 田阳：我感谢王和旋对我的帮助，因为每次测试软件的时候遇到问题都会细心的帮我解答，在每次提交代码的时候都会督促我测试，并且会提醒我上次出现的bug，然后多测试几次遇到问题及时像他报告，在队长的带动下，使我的学习气氛比以前高了很多。
  • 马阔：我感谢王和旋对我的帮助，因为本次制作的软件有很大一部分对于我是很难解决的，而他的水平刚好解决了这份尴尬，并且教会我很多不会的后台代码，并且在不会的时候会耐心教我如何解决这个问题，使我的编码能力得到了很大的提高。
  • 董玉林：我感谢田阳对我的帮助，因为测试工作有的时候会有些疏忽，犹豫我个人不太注重于细节，导致有时候会错过一下bug，会影响团队进程，还有就是感谢我们这个team hero 我们一起度过了这个学期 谢谢
  • 谷云鹤：我感谢王和旋对我的帮助，我在ui设计的图片上有很多的问题，他都会细心帮我，也会督促我提交图片文件，在队长的帮助下我在ui设计方面有了更多的进步

• 每个成员的软件工程水平都有很大的提升，王和旋学会了服务器的配置和数据库的开发，提高了wpf的编码能力；田阳和董玉林学会了软件测试的能力，从软件的功能和单元测试等；马阔提高了c#，wpf的软件开发能力，学会了很多软件样式设计的操作和后台逻辑的思路；谷云鹤提升了软件的UI设计水平，结合参考了许多优秀软件的设计，对自己的设计提升了很多。

• 我们觉得团队目前处于CMMI的管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。

• 我们觉得我们的团队目前处于磨合阶段。

• 我们团队这个阶段的里程碑比上一次有秩序了很多，已经能熟练的掌握码云，GitHub平台的合作开发。

• 对比之前我们团队软件开发采用的主治医生模式，我们应该更注重每个人的能力贡献

贡献分配

王和旋：7
田阳：3
马阔：2
董玉林：2
谷云鹤：1