事后诸葛亮会议

1. 设想和目标
   目标清晰度：系统目标明确（实现图书数字化管理、自助借还、智能推荐），但初期对“智慧”的定义模糊（如智能推荐算法的具体指标未量化）。

用户场景：典型用户（学生、图书管理员）描述清晰，但忽略了管理员年龄差异对UI易用性的影响。

计划时间：需求分析阶段时间充足，但市场竞品调研不足，导致部分功能重复开发。

目标达成：核心功能完成度达95%，但用户对“智能推荐准确率”的满意度低于预期（仅60% vs 预期80%）。

改进方向：

提前定义可量化的“智慧”指标（如推荐准确率≥85%）；

增加多年龄层用户调研。

2. 计划
   任务完成度：90%计划任务完成。未完成部分为“数据可视化大屏”（因技术选型延迟）。

低价值任务：过度设计读者社交功能（用户反馈需求极低）。

交付件标准：任务均有明确交付物，但部分接口文档验收标准模糊。

计划执行：前期严格按计划，后期因需求变更频繁偏移。

缓冲区设置：预留10%时间缓冲，但被用于修复紧急Bug而非应对变更。

改进方向：

砍掉低优先级功能；

明确文档验收标准；

缓冲区增加至15%。

3. 资源
   资源充足性：测试资源不足（仅1人负责全系统测试），硬件资源充足。

估算精度：开发时间估算偏差±20%，但UI设计时间低估50%（因未考虑多次返工）。

资源分配：组长刘晋宇兼任开发与协调，效率低下；部分前端任务未交给更专业的成员马瑞鑫。

改进方向：

引入三点估算法（乐观/悲观/最可能）；

外包复杂UI设计；

明确分工避免兼任。

4. 变更管理
   变更通知：需求变更通过企业微信群同步，但部分成员遗漏关键信息。

优先级决策：采用“MoSCoW法则”（Must/Should/Could/Won't），但“Could”类需求常被误判为“Must”。

出口条件：发布标准明确（测试覆盖率≥80%，无严重Bug），但未定义性能指标（如并发支持）。

应急能力：成员能快速处理Bug，但面对需求变更缺乏预判。

改进方向：

变更需经全员确认回执；

增加性能验收标准；

建立变更影响评估表。

5. 设计/实现
   设计阶段：架构由成员刘天宇在需求分析后设计，时机合理但缺乏团队评审。

模糊问题：RFID标签识别率争议，最终通过原型测试解决。

工具应用：

采用单元测试（覆盖率70%）；

未用TDD，导致部分模块返工率高。

Bug分布：

图书推荐模块Bug占比40%（因算法逻辑未覆盖边缘场景）；

发布后发现借阅超期计费错误（需求理解偏差）。

代码复审：执行严格，但未检查算法健壮性。

改进方向：

关键设计需团队评审；

核心模块采用TDD；

增加边界测试用例。

6. 测试/发布
   测试计划：有测试计划，但性能测试仅覆盖单机环境。

验收测试：客户参与验收，但反馈周期过长（5天）。

测试工具：使用Jmeter进行压力测试，未引入自动化UI测试工具。

效能跟踪：监控了系统响应时间，未跟踪推荐算法准确率。

发布问题：上线首日因并发访问崩溃（未模拟真实场景压力测试）。

改进方向：

增加分布式压力测试；

搭建自动化UI测试；

定义关键效能指标看板。

7. 团队状态
   CMMI等级：规范级（Level 3）

有稳定流程，但量化管理不足。

团队阶段：从磨合期转向规范期

成员协作顺畅，但创新主动性不足。

里程碑改进：

代码规范性提升（ESLint引入）；

每日站会效率提高。

最需改进：需求变更响应机制（当前被动接收，应增加预判分析）。

核心经验总结
若能重来，团队将聚焦三点：

需求锚定：通过用户故事地图明确核心功能边界，拒绝镀金需求。

质量左移：关键模块采用TDD，开发阶段嵌入性能测试。

变更防御：建立“影响-成本”评估模型，预留应急资源池。