事后诸葛亮分析报告

事后诸葛亮分析报告

说明：本次为单人团队复盘（成员：何俊朗），不提供讨论照片。

一、总结提纲（参考《构建之法》15 章）

1. 选题与目标
   • 选题基于真实需求：实验室/自习室资源稀缺，预约冲突与报修流程不透明是高频痛点。
   • Alpha 目标明确为“核心流程可用 + 权限正确 + 可复现测试”，避免扩展功能分散精力。
   • 目标可验证：预约冲突校验、签到/违规、报修指派与状态流转全部有接口与脚本验证。
2. 用户与价值
   • 学生：快速预约、避免冲突、按时签到、提交报修并追踪进度。
   • 管理员：审批预约、处理违规、指派维修并可全量查看。
   • 维修人员：查看指派任务并推进状态，形成闭环沟通。
   • 核心价值：降低冲突成本、提升资源使用效率、提高报修处理透明度。
3. 需求分析
   • Must：登录、预约创建/冲突校验、报修提交/流转、权限控制。
   • Should：签到/违规、管理员豁免解锁、评论沟通。
   • Could：更细筛选、更丰富提示、前端优化与截图材料。
   • 需求边界：不做复杂审批规则、多端推送和大规模并发优化。
4. 架构设计
   • 前后端分离：React+Vite，Express+SQLite（better-sqlite3）。
   • 分层结构：路由、校验、服务逻辑、数据层清晰。
   • 设计重点：状态机与权限校验集中处理，减少逻辑分散。
5. 迭代计划
   • Day1-3：梳理缺口、补接口测试、完善前端交互。
   • Day4：验证违规与锁定链路，形成脚本与复现记录。
   • Day5：报修指派与状态流转补齐并固化规则。
   • Day6-7：文档完善与演示准备、形成 Alpha 报告。
6. 实施过程
   • 先保证后端规则完整（冲突校验、状态流转、权限），再优化前端提示。
   • 用脚本驱动关键流程，确保规则变化可被测试捕捉。
   • 发现逻辑漏洞后先修后测，避免缺陷扩散。
7. 质量策略
   • 输入校验：必填、日期格式、时间顺序、上传类型/大小。
   • 权限校验：学生、管理员、维修三角色按职责分配。
   • 状态机规则：禁止跳步、禁止越权、禁止不合规指派。
8. 测试覆盖
   • 自动化：npm test（核心接口）；day4:check（违规链路）；day5:check（报修流转）。
   • 手测：预约创建/冲突、签到/违规、报修指派/状态、角色越权提示。
   • 回归：修复后重跑脚本，确保不引入新回归。
9. 配置与部署
   • .env 支持端口、JWT、数据库路径与违规参数配置。
   • SQLite 文件可直接备份，适合课程演示和小规模应用。
   • 启动命令简单，便于新成员快速跑通。
10. 进度与风险

• 高风险：违规逻辑与签到时间窗、报修状态跳步、角色越权。
• 应对策略：把高风险流程转为脚本验证，避免仅靠手测。
• 进度控制：功能优先，延后非核心 UI 优化。

11. 缺陷管理

• 记录：发现 Bug → 归类 → 修复 → 回归验证。
• 归因：逻辑问题、权限问题、用例不一致等分类处理。
• 结果：所有发现的核心缺陷均修复并回归通过。

12. 文档交付

• README：启动、环境变量、已知问题与测试说明。
• SRS：角色、需求、状态流转、数据模型。
• dev-guide：测试策略、手测清单、发布说明。
• 每日 Scrum + Alpha 报告 + 复审文档。

13. 团队协作

• 单人团队采用“需求-开发-测试-文档”顺序工作流。
• 每天保留固定时间用于测试与文档，减少后期返工。
• 将问题清单显式化，避免遗漏关键修复点。

14. 复盘改进

• 截图与演示素材不足：缺少可视化证据链。
• 性能与兼容性测试薄弱：缺少压力/弱网场景验证。
• 需要把“可复现性”作为文档硬指标。

15. 下一阶段

• 增强前端错误提示与空态展示。
• 完成演示截图与流程说明，形成可直接展示材料。
• 增加边界条件与性能类测试，形成基线指标。

二、事后诸葛亮会议要点

• 成功点
  • 核心流程闭环：预约冲突校验、签到违规、报修指派与状态流转均可跑通。
  • 权限校验清晰：学生/管理员/维修角色边界明确，越权可被拦截。
  • 测试可复现：关键链路脚本化，回归成本低。
• 主要问题
  • 截图证据不足：缺少可直接展示的截图与演示材料。
  • 性能与兼容性验证不足：缺少多浏览器/弱网/大数据场景测试。
  • 文档一致性风险：规则调整后需同步更新测试与说明。
• 改进措施
  • 建立演示材料清单并完成截图补齐。
  • 增加性能与异常场景用例，形成简单基线指标。
  • 文档与测试联动更新，变更必须同步修正用例。

三、Alpha 阶段角色与贡献

名字	角色	团队贡献分	可验证的贡献
何俊朗	负责人/全栈	20	需求与SRS、后端API与权限、前端页面与交互、测试脚本与报告、文档与发布说明

说明：单人团队贡献分唯一且不重复。

四、关键决策与取舍

• 先保证核心流程可用，延后 UI 细节优化与高级筛选。
• 采用 SQLite 作为 Alpha 数据库，降低部署与演示成本。
• 用脚本验证高风险逻辑（违规与报修状态），提高可复现性。

五、风险清单与应对

• 风险：违规逻辑时间边界出错 → 应对：引入脚本+单测验证。
• 风险：权限越界 → 应对：统一鉴权与角色校验。
• 风险：文档滞后 → 应对：变更需同步更新测试与文档。
• 风险：缺少演示证据 → 应对：整理截图清单并按流程补齐。

六、可量化结果

• 核心自动化测试：npm test 通过。
• 违规链路脚本：day4:check 通过。
• 报修流程脚本：day5:check 通过。

七、下一步行动清单

1. 完成演示截图与文档插图。
2. 增加弱网/大数据场景测试并记录结果。
3. 完善前端错误提示与空态 UI。
4. 补充性能与回归测试基线。