事后诸葛亮分析

项目名称：在线考试系统 (Online Exam System)
会议时间：2025年12月17日
参会人员：邢子昂、庄成杰、张翔

一、 会议背景与照片

在 Alpha 版本发布后，我们小组于 Deadline 前召开了“事后诸葛亮”会议。大家围坐在一起，不再讨论具体代码，而是对过去 7 天的冲刺进行了一次灵魂拷问：我们做对了什么？我们做错了什么？如果有下次，我们会怎么做？

👇 会议现场照片
image

二、 设想和目标 (Goals)

1. 我们的软件要解决什么问题？是否定义得很清楚？
我们的目标是开发一个轻量级的“在线考试系统”，解决传统考试中组卷繁琐、判分耗时的问题。

  • 事后分析：目标定义比较清晰，但在具体功能边界上前期有些模糊。例如“主观题是否支持自动判分”这个问题，直到开发中期才决定砍掉，这导致前期数据库设计时多余了一些字段。

2. 我们达到目标了吗？
基本达到了 Alpha 阶段的目标。核心功能（题库管理、组卷、在线考试、自动判分）均已上线并可运行。

3. 只有 100% 的满意度才是成功吗？
不是。对于 Alpha 版本，我们的满意度大概在 80%。剩下的 20% 来自于移动端 UI 的适配不完美，以及部分异常情况下的错误提示不够友好。但作为一个可用的 MVP（最小可行性产品），它是成功的。

三、 计划 (Plan)

1. 是否有充足的时间来做计划？
时间非常紧迫。我们只有 7 天的冲刺时间。

  • 反思：我们在 Day 1 花了太多时间纠结“选什么前端框架”，导致后端 API 接口定义的文档出得太晚，前端在 Day 2 和 Day 3 经常需要等后端接口，造成了时间的浪费。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们采用了“每日站会”制度。

  • 例子：在数据库命名上，有人习惯用下划线，有人习惯驼峰。最终我们在站会上决定严格遵循 application.properties 中的配置，以配置文件为准，解决了分歧。

四、 资源 (Resources)

1. 我们有足够的资源吗？

  • 人力：3人小组，1前端+2后端，分工相对合理，但在测试阶段显得人力不足。
  • 技术：我们使用了现成的 Spring Boot + Vue 框架，这极大地节省了基础架构搭建的时间，是一个正确的资源复用决策。

2. 某项任务是否因为缺乏资源而受阻？
是的。服务器资源。
我们在本地调试（Localhost）一切正常，但在模拟部署时，因为没有公网服务器，只能在局域网内测试，导致无法验证真实网络延迟下的倒计时同步问题。

五、 变更管理 (Change Management)

1. 每个相关的员工都及时知道了变更的消息吗？
大部分时候是及时的，通过微信群和站会沟通。

  • 教训：有一次后端修改了 Question 实体的字段名（把 questionTitle 改成了 content），忘记在群里单独说，导致前端页面绑定的数据突然不显示了，排查了半个小时才发现。以后接口变更必须发文档！

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们使用了 MoSCoW 法则（Must have, Should have, Could have, Won't have）。

  • Must have：登录、答题、判分（必须实现，全力以赴）。
  • Won't have：主观题人工阅卷、复杂的权限管理（果断推迟到 Beta 版本）。

六、 设计/实现 (Design/Implementation)

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人吗？
设计主要在 Day 1 由邢子昂（数据库）和张翔（接口）完成。

  • 反思：时间略晚。应该在冲刺前就确定好数据库 ER 图。因为数据库一改，Mapper XML、Entity、Service 全要改，成本太高。

2. 代码复审（Code Review）是如何进行的？
我们采用了“结对编程”的变种。遇到复杂逻辑（如自动判分算法），张翔写完后，邢子昂会坐在旁边一行行看，确保逻辑无误后再提交。这种方式虽然慢，但有效减少了 Bug。

七、 测试/发布 (Test/Release)

1. 测试用例是何时编写的？
是在开发完成后才补写的。这是我们流程中最大的问题。

  • 后果：很多 Bug（如多选题判分错误）是到了 Day 6 集成测试时才发现的。如果是测试驱动开发（TDD），应该更早发现。

2. 值得再次提及的 Bug？

  • Redis 依赖问题：我们一直以为 Session 是存在内存里的，结果上线发现配置了 Redis，导致不启动 Redis 服务就无法登录。这告诉我们：不要想当然，要看配置文件！
  • 数据库名称不一致：文档写 online-exam-system，配置写 online-course，导致连接失败。教训：配置大于文档。

八、 团队成员在 Alpha 阶段的角色和具体贡献

为了量化贡献，我们将总分设定为 150分（3人 x 50分），根据实际工作量和难度进行分配。

姓名 角色 (Role) 团队贡献分 负责板块与可验证的贡献 (Verifiable Contribution)
邢子昂 PM / 后端开发 50 1. 数据库设计：设计了 User, Question, Subject 等核心表结构。
2. 用户模块：完成了登录、注册、JWT 认证接口。
3. 题库API：实现了题目 Excel 批量导入功能（难点）。
4. 项目统筹：主持每日站会，编写燃尽图。
庄成杰 前端开发 / UI 50 1. 页面搭建：使用 Vue+ElementPlus 搭建了前后台所有页面。
2. 考试交互：实现了倒计时组件、答题卡状态联动（难点）。
3. 适配优化：修复了移动端浏览器下的样式错位问题。
4. 接口联调：负责与后端进行全链路数据对接。
张翔 后端开发 / 测试 50 1. 核心业务：实现了最复杂的自动判分算法（支持多选漏选给分）。
2. 试卷管理：实现了随机组卷逻辑。
3. 缺陷修复：修复了 10+ 个逻辑 Bug，配置了 Redis 环境。
4. 文档编写：撰写了测试报告和部分发布说明。

九、 总结 (Conclusion)

“事后诸葛亮”不仅是为了补救，更是为了下一次的出发。
通过 Alpha 阶段的磨合，我们从最初的“环境配置都报错”到最后能“完整跑通考试流程”，团队凝聚力大大提升。

下一阶段（Beta）的改进计划：

  1. 代码规范：严格执行接口文档先行。
  2. 测试前置：每写一个 Service 方法，必须配套一个 JUnit 测试用例。
  3. 用户体验：重点优化移动端体验，增加错题本功能。

Alpha 阶段，任务完成！大家辛苦了！

posted @ 2025-12-24 21:49  jslisten  阅读(0)  评论(0)    收藏  举报