一. 项目的预期计划 / 项目的现实进展

详见Alpha冲刺博客第一篇

二. 完成项目过程中的体会

详见Alpha冲刺博客第十二篇

三. 团队成员的分工及在Alpha阶段的工作量比例

成员	职务	博客	Alpha完成任务内容	比例（100）
031502610 胡武成	PM/BackEnd	winforbest	APP接口、分工监督管理、博文撰写	14
031502630 吴松青	BackEnd	Kaloneme	WEB接口	12
031502411 胡冰	Android	H_BING	Android部分内容	15
031502512 黄世辉	Android	hsh1234	Android部分内容	13
031502626 孙浩楷	Web	Little-White	WEB部分内容	13
031502518 练斐弘	Web	Mr.who	WEB部分内容	13
031502412 黄若岚	UI	perhap_s	WEB端UI	10
031502243 张旗	UI	NevesLalala	Android端UI	10

四. 关于Postmortem的回答

4.1 设想和目标

• 4.1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

  • 我们的软件要解决的问题如下：
    • 提醒学生完成作业，为学生在手机上提供资料分类管理（依据课堂分类），同步教师上传的课件，减少收集资料的时间
    • 为教师批改作业提供新的方式（在线作业图片编辑批改），解决学生与老师之间作业交流的延时性（课上>交作业，下节课等老师发放作业后才能知道自己作业哪里有错误），为教师统计学生平时完成情况提供便利性
  • 项目初期已经有了较为清晰的定义以及典型用户和典型场景的描述，随着项目推进，项目的定义更加清晰明了，对典型用户以及典型场景有更进一步的理解拓展。

• 4.1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

  目前基本已经达到Alpha所明确的功能要求，除却优秀作业展示、作业图片在线编辑等少数功能（其中作业图片在线编辑功能极为重要，但是暂时没有找到解决方案），其余功能基本实现。 由于此项目限于时间因素登录注册等等功能暂且没有去完成，以及项目与课堂有关较为复杂，故原计划中没有确定用户数量，待到Beta阶段完成上述功能，将邀请老师来使用测试.

• 4.1.3 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

  暂时无法回答

• 4.1.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

  经验教训：PM要明确功能需求，明确各部分分工需要完成的内容，要考虑到后期推进问题，及时监督开发/美工人员，避免返工现象发生
  改进：受限于Alpha各人员时间安排因素，没有更好的改进方式。

4.2 计划

• 4.2.1 是否有充足的时间来做计划?

  计划都是在Alpha阶段前做好，在冲刺阶段根据实际情况进行调控，故时间还是比较充足的

• 4.2.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？

  在QQ群/会议上进行讨论，根据成员对某一细节意见的表述，然后判断此项意见对这一细节的是否有效可行，可行性是否比其他意见更强。选择最优的意见。

• 4.2.3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

  初期Alpha确定的工作，完成绝大多数。但是，由于时间因素以及技术层次问题，图片在线编辑暂且没有找合适的解决方案。

• 4.2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?

  根据组员反馈，暂无。

• 4.2.5 是否每一项任务都有清楚定义和衡量的交付件?

  每项任务都保证开发人员清楚自己该完成什么，完成到什么样的程度，有问题都会在群里提出来，比如觉得哪个功能这么实现不合理，哪个功能是不必要的。

• 4.2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

  大体上按照计划进行，但出现在线图片编辑器无法引入vue.js框架中的意外情况，导致这项功能在Alpha阶段无法实现，这主要是因为，项目初期已经找到相关的图片在线编辑插件，而且之前也有做过插件引入，故觉得是可以引入到vue.js中，从而导致了后来出现的意外。

• 4.2.7 在计划中有没有留下缓冲区，缓冲区有作用么?

  由于页面及功能内容比较多，大体上还是按照计划一步步进行，没有多余的时间留出为缓冲区。
  缓冲区用一定用处，但是还是主要要看计划内容的安排。

• 4.2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

  目前计划暂时不作修改，平缓进行。

• 4.2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  开发过程需要用到的内容要提前去尝试做一遍.比如插件引入.

4.3 资源

• 4.3.1 我们有足够的资源来完成各项任务么?

  学习资源：网上随地都是，不懂的问题也可以去问问学长或者其他大佬
  服务器资源：采用了腾讯云1G/1核/2M的服务器，性能上已然足够
  简而言之，资源完全足够。

• 4.3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?

  各项任务所需时间根据个人能力以及项目难度（实现是否困难，资料是否难找..）去估计，精度有所欠缺，大体上花费的时间要比估计的时间多上一至两个小时。

• 4.3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

  人力和软件/硬件资源已经足够，但是，测试时间有些不足，许多问题都是到最后两天才发现并进行修改的。
  对于不需要编程的资源（美工设计/文案）没有低估其难度，Alpha过程中，多次修改UI，美工也对部分页面进行重构/切图

• 4.3.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

  计划提前进行，避免出现项目提交前一两天才能进行综合测试而出现问题来不及解决的情况。

4.4 变更管理

• 4.4.1 每个相关的员工都及时知道了变更的消息?

  Alpha基本是QQ群通知，都能及时知道项目内容变更消息，Beta阶段希望尝试使用github进行项目变更通知

• 4.4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?

  主要功能优先，辅助功能推后

• 4.4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

  能用，而且不出现明显的Bug

• 4.4.4 对于可能的变更是否能制定应急计划?

  可以，例如在线图片编辑插件引入失败，我们团队将原先定下的在线编辑图片的功能，改成点击放大图片进行查看，满足作业查看批改。

• 4.4.5 员工是否能够有效地处理意料之外的工作请求？

  目前没有出现这个问题。

• 4.4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  尽量在项目开展前期就做好工作准备，减少开发过程中大规模变更事件

4.5 设计/实现

• 4.5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

  功能需求确定后，会议讨论完成后，由两个美工（审美好，且有ps经验）进行设计。

• 4.5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

  由于功能划分很明确，且前端与美工也进行了会议交流讨论各个页面内容，故没有出现模棱两可的情况

• 4.5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

  开发时间比较紧张，目前还没有进行单元测试。前期使用ProcessOn网站进行状态图、活动图等等UML绘制，采用黑盒测试。

• 4.5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

  文件上传部分产生的bug比较多，主要还是VUE 跨域问题，目前暂未发布

• 4.5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

  Code Review 根据是否注释，注释是否规范，变量名是否规范，代码结构是否合理，是否过分冗余等等因素去要求组员对其编写的代码进行修改。就团队而言，没有很严格地执行代码规范。

4.6 测试/发布

• 4.6.1 团队是否有一个测试计划？为什么没有？

  根据场景进行模拟，以初定的页面交互效果作为测试评判

• 4.6.2 是否进行了正式的验收测试？

  在课堂展示前，对Alpha前确定的场景进行了模拟

• 4.6.3 团队是否有测试工具来帮助测试？

  前端主要还是采用黑盒测试，后端利用Postman进行了相关测试。

• 4.6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

  经验不足，这部分内容将放入Beta阶段进行尝试。

4.7 团队的角色，管理，合作

• 4.7.1 团队的每个角色是如何确定的，是不是人尽其才？

  根据每个人的意向及其熟悉的内容，我们团队，比较凑巧，两个Android，两个WEB，两个后端，两个美工。可以算是人尽其才了

• 4.7.2 团队成员之间有互相帮助么？

  在遇到一些技术问题上，会进行讨论，成员之间也会根据对方的问题，给出相应的解决方法

• 4.7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

  每天站立式会议时候讨论解决

4.8 总结:

• 4.8.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

  可重复级.

• 4.8.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

  规范。经历Alpha阶段的磨合，所有成员都对自己的职责有了更多的了解，直接的配合度增加。

• 4.8.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

  更清楚一个团队如何去开发一个完整的项目

• 4.8.4 你觉得目前最需要改进的一个方面是什么?

  代码规范

• 4.8.5 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

  主张简单、快速反馈。在开发过程中，我们团队初期设想的开发内容比较多，随着项目的进行以及时间的不足，我们砍掉了不少功能，也优化了有些功能的实现方式，比如，砍掉了教师的app端，将在线编辑图片替换成图片放大展示等等，以求快速简单地开发出能体现我们内容的项目。