团队作业6——复审与事后分析

这个作业属于哪个课程 计科23级12班
这个作业要求在哪里 团队作业6——复审与事后分析
这个作业的目标 Alpha阶段项目复审与事后诸葛亮分析
小组的名字和链接 优点 缺点，bug报告 最终名次
校园二手书交易平台
https://github.com/WiseL00k/Campus-Book-Trade		 程序质量：完全达成校园二手书便捷交易核心目标，实现供需发布、筛选、实名认证等核心功能，覆盖用户80%核心痛点；2. 软件工程质量：代码按Django标准分层，部署文档完整，新机器可快速构建；3. 需求取舍合理，优先保障C2C交易核心流程。 功能Bug：发布信息有效期仅支持固定选项无自定义时长，详情页浏览量统计仅定义字段未实现自增逻辑，无交易纠纷处理入口；软件工程缺陷：无每日构建配置，未集成CI/CD，核心业务逻辑无单元测试覆盖，数据库连接信息硬编码未用环境变量；安全性问题：手机号、微信号等敏感信息明文展示无脱敏，登录仅基础认证无二次验证或密码复杂度校验。整体来看，虽核心流程完整，但在细节功能、工程规范和安全性上仍有较多待优化点。 1
图书馆管理系统
https://github.com/ywks1/library-system		 程序质量：功能覆盖用户借阅、管理员图书管理、系统统计全流程，多角色权限设计合理，核心借还、超期计费逻辑正确；2. 软件工程质量：部署文档详细，数据库表设计规范且提供sql脚本，代码分层明确；3. 实用性强，支持Excel导出、借阅统计可视化。 功能Bug：用户留言模块无审核机制易出现违规内容，图书查询仅支持模糊匹配无组合筛选，超期费用计算逻辑无文档说明存在错误风险；软件工程缺陷：未使用Maven/Gradle管理依赖，需手动配置jar包，无版本控制规范，核心业务逻辑注释不足可读性差；性能与安全：无分页优化导致大量数据加载缓慢，管理员密码硬编码且无修改同步机制，登录无验证码易受暴力破解。该系统核心功能可用，但工程化和安全性短板明显。 2
在线考试系统
https://github.com/wodu-dreamy/online-exam-system		 程序质量：核心功能完整，支持在线考试、题库管理、自动批改，多角色权限划分清晰，前后端分离架构符合技术趋势；2. 软件工程质量：部署流程完整，技术栈选型合理（SpringBoot+MyBatis+Redis），源码提交记录完整；3. 集成Redis提升了系统性能，支持课程管理和帖子评论增强互动性。 功能Bug：无切屏检测、试题乱序等防作弊机制，学生可篡改客户端时间修改考试时长，试题仅支持SQL脚本导入无Excel批量导入功能；软件工程缺陷：无单元测试和集成测试，核心自动判分模块无测试覆盖，配置文件中数据库密码明文存储，无持续集成配置；稳定性不足：Redis仅单节点部署无集群，无考试数据备份策略，系统崩溃易丢失数据。该系统解决了线下考试低效问题，但防作弊和数据安全是核心短板。 3
大学生健康管理系统
https://github.com/baiyehhj/college-student-health-management-system		 程序质量：功能贴合校园场景，覆盖饮食/运动/作息记录、体检分析、心理测评、校医院挂号全流程，技术栈主流扩展性强；2. 软件工程质量：代码按backend/frontend/database分层，源码管理规范；3. 对接校医院资源，实用性和落地性较高。 功能Bug：健康预警规则未明确，无数据趋势分析功能，心理健康测评仅展示分数无专业建议；软件工程缺陷：无部署文档，新机器构建困难，无数据库脚本需手动建表，无日志记录难以排查问题；安全性问题：健康敏感数据未加密存储，接口无鉴权易泄露，无数据访问权限控制可查看他人信息。系统核心记录功能实现，但预警、隐私保护和工程规范需重点优化。 4
云盘系统
https://github.com/DPXCYun/YunPan		 程序质量：核心功能完整，支持文件上传/下载/分享、文件夹创建、回收站，多语言和扫码分享提升用户体验；2. 软件工程质量：提供数据库脚本和pom.xml，依赖管理清晰，前端页面设计简洁操作顺畅；3. 技术栈选型合理（SpringBoot+Vue+MySQL）。 功能Bug：文件上传无大小限制易导致服务器存储溢出，分享链接无过期机制永久有效，无断点续传导致大文件上传易失败，无文件搜索功能；软件工程缺陷：无部署文档，核心文件上传模块无单元测试，缺少异常处理逻辑（上传失败无提示）；性能与安全：无文件分片上传，大文件占用带宽，无病毒扫描易上传恶意文件，回收站无自动清理机制。系统解决了文件存储分散问题，但大文件处理和安全分享需完善。 5
笔记系统
https://github.com/iikachan/noteforces/releases/tag/v0.1.0-alpha		 程序质量：功能较完整，支持密码修改、笔记分享、管理员管理、暗黑模式，交互设计友好；2. 软件工程质量：源码管理规范，分支清晰，通过PR提交功能且有Changelog，已发布Alpha版本有版本控制意识；3. 修复了数据库自动建表、路由重定向等关键Bug，迭代规范。 功能Bug：笔记编辑无自动保存机制，意外关闭会丢失内容，无分类和标签功能导致大量笔记管理困难，分享功能无权限控制（仅公开/私有）；软件工程缺陷：无用户手册和部署文档，新用户上手难，Alpha版本稳定性不足，笔记搜索无索引优化性能差；兼容性问题：路由模式修改可能影响部分浏览器兼容，未适配移动端体验差。系统基础功能可用，但用户体验和工程文档需完善。 6
博客园前端
https://github.com/changlu812/TanhT-front.git		 程序质量：核心展示功能完整，支持文章分类、发布状态筛选和搜索，技术栈较新（Vite+Vue）构建速度快；2. 软件工程质量：源码管理规范，package.json依赖配置清晰，配置GitHub Pages可快速部署上线；3. 提交记录完整，有明确的功能迭代痕迹。 功能Bug：无文章评论和点赞功能，互动性严重不足，无用户权限控制（任意用户可编辑文章），文章编辑仅支持纯文本无富文本；软件工程缺陷：仅前端项目无后端代码，无法独立运行，数据依赖模拟db.json，无单元测试和集成测试；扩展性问题：未设计API接口规范，后续对接后端难度大，无国际化支持仅适配中文。系统前端展示功能完善，但无后端支撑和互动功能是核心问题。 7
编程工具（KFCoder）
https://gitee.com/zhiyu-xinxuan/kfcoder		 软件工程质量：代码分为backend和frontend分层清晰，有明确的开发任务规划（数据统计、打卡、登录页面）；2. 有提交记录和Issues管理，具备基础的项目管理意识；3. 源码仓库结构完整，无明显的目录混乱问题。 功能Bug：核心功能定位模糊，仅从任务推测为打卡+数据统计工具，无演示地址和测试账号，无法验证功能可用性；软件工程缺陷：无项目简介、技术栈说明、部署文档，新机器无法构建，未声明开源许可证存在法律风险，代码注释不足可读性差，无测试代码；项目管理：无燃尽图、里程碑计划，Issues分类混乱（9个Issues未区分Bug/需求）。该项目仅完成基础页面开发，核心功能和工程规范均严重缺失。 8
外卖系统后端
https://github.com/sywaaaa/Sky-take-out/tree/main/后端初始工程/sky-take-out		 软件工程质量：技术栈明确（Java 100%），符合外卖系统后端技术选型趋势；2. 源码仓库有明确的后端工程目录结构，无明显的目录混乱；3. 有基础的Git提交记录，具备初步的版本控制意识。 功能Bug：无任何功能说明文档，核心订单管理、支付对接、配送调度功能是否实现未知，无演示或测试方式验证功能；软件工程缺陷：无README详细说明，无部署文档、数据库脚本、接口文档，新机器无法构建，无提交记录语义说明，无法判断功能迭代情况，无测试代码；项目管理：无需求清单、无进度规划，仅搭建基础工程框架无实际业务逻辑。该项目仅完成工程搭建，无任何可验证的核心功能。 9
论坛项目
https://github.com/jiandanmingzi/jiandanmingzi/tree/main/3123004657/forum		 软件工程质量：采用前后端分离架构（back+front/forum_vue），符合主流开发模式；2. 有提交记录且标注“修bug”，具备基础的迭代意识；3. 源码目录划分清晰，区分后端和前端代码。 功能Bug：无任何功能说明文档，核心发帖、回帖、用户管理功能是否实现未知，无演示地址和测试账号；软件工程缺陷：无README详细说明，无部署文档、技术栈说明、数据库脚本，新机器无法构建，代码注释不足后端逻辑难以理解，无版本控制未发布任何版本；项目管理：无需求清单、无进度规划，无法判断需求取舍和风险应对。该项目仅搭建前后端框架，无实际可运行的核心功能。 10
知识分享平台
https://github.com/yosennn/KnowHub		 软件工程质量：配置了ISSUE_TEMPLATE，具备基础的问题管理规范；2. 有README文件和初始提交记录，具备基础的项目初始化意识；3. 源码仓库结构完整，无明显的文件混乱问题。 功能Bug：无任何实际业务代码，仅配置了ISSUE_TEMPLATE和README，核心内容发布、搜索、分享功能未实现，无法验证任何功能；软件工程缺陷：无技术栈说明、部署文档、数据库设计，项目无法运行，无提交记录（仅Initial commit），无任何迭代进度；项目管理：无需求清单、无风险应对方案、无进度规划，仅创建仓库无实质开发。该项目仅完成仓库初始化，无任何可落地的功能和代码。 11
体育场馆预约系统
https://github.com/skymoon-13/Sports_Venue_Reservation_System		 无明显可落地的优点；2. 仅创建了GitHub仓库，具备基础的项目初始化动作；3. 仓库命名清晰，可明确项目定位。 功能Bug：无任何代码实现，仅仓库名称表明为体育场馆预约系统，核心场地查询、时段预约、冲突检测功能均未开发；软件工程缺陷：无代码、无文档、无技术栈说明、无数据库设计，项目完全无法运行，无任何提交记录和开发痕迹；项目管理：无需求清单、无风险应对、无进度规划，未开展任何实质性开发工作。该项目仅创建仓库，无任何开发和功能实现，不符合软件工程基本要求。

iBlog Community 项目事后诸葛亮分析报告

会议基本信息

  • 会议时间：2025年12月10日 14:00-16:30
  • 会议地点：团队会议室（线上+线下结合）
  • 主持人：高圣凯
  • 记录人：蒋国栋
  • 会议形式：按照《构建之法》第15章“事后诸葛亮会议”的规范流程进行

一、项目回顾与成果总结

1.1 项目目标达成情况

目标维度 计划目标 实际达成 状态 说明
功能范围 实现用户、文章、评论、社交、后台5大模块 全部实现，超出计划（增加了数据统计功能） ✅ 超额完成 Beta版本规划的功能提前完成
时间进度 15周完成Alpha版本 14周完成，提前1周 ✅ 提前完成 敏捷冲刺效率高
质量标准 测试覆盖率>80%，无P0级Bug 覆盖率85%，修复所有P0/P1 Bug ✅ 达标 质量内建策略有效
技术目标 前后端分离，容器化部署 完全实现，CI/CD流水线自动化 ✅ 达成 技术栈选择合理

1.2 关键成果数据

  • 代码规模：后端2.3万行，前端1.8万行
  • 测试用例：单元测试127个，API测试68个，集成测试场景12个
  • Bug处理：发现14个，修复12个，修复率85.7%
  • 文档产出：技术文档8份，用户文档3份，API文档完整
  • 部署效率：一键部署时间从2小时缩短到15分钟

二、团队成员贡献分析

名字 角色 团队贡献分 (0-10分) 可验证的贡献
高圣凯 项目管理、后端架构、数据库设计 9.5 1. 主持15次站会、4次评审会（会议纪要可查） 2. 完成数据库8张表设计（ER图、SQL脚本提交记录） 3. 制定项目WBS和燃尽图（Git仓库文档） 4. 设计RBAC权限系统（代码审查记录） 5. 编写架构设计和部署文档（docs/目录）
郭程朗 前端开发、UI设计、用户交互 9.0 1. 完成12个Vue页面组件（frontend/src/views/） 2. 设计并实现3套UI原型（Figma设计稿链接） 3. 集成Markdown编辑器、代码高亮（组件提交记录） 4. 解决跨浏览器兼容性问题（测试报告验证） 5. 编写用户使用手册（docs/user-manual.md）
方哲 后端开发、API实现、DevOps 9.2 1. 实现38个RESTful API接口（Controller类提交记录） 2. 搭建CI/CD流水线（.github/workflows/配置） 3. 完成Docker容器化部署（Dockerfile提交） 4. 集成Redis缓存、性能优化（性能测试报告） 5. 实现JWT认证和安全防护（安全扫描报告）
蒋国栋 测试、质量保障、文档 9.0 1. 编写195个测试用例（test/目录） 2. 执行端到端集成测试（测试报告文档） 3. 发现并跟踪14个Bug（GitHub Issues记录） 4. 制定测试计划和策略（docs/test-plan.md） 5. 编写API测试集合（Postman collection导出文件）

三、做得好的方面（Keep）

3.1 项目管理方面

  1. 敏捷实践有效
    • 每日站会坚持15分钟，问题不过夜
    • 燃尽图真实反映进度，及时调整策略
    • 冲刺周期明确，目标感强
  2. 沟通机制顺畅
    • 使用腾讯文档实时协作，信息透明
    • 技术决策有记录，可追溯
    • 代码Review制度化，质量有保障
  3. 风险管理到位
    • 识别了技术难点并提前攻关
    • 每日任务都有缓冲时间
    • 关键决策集体讨论，避免个人偏差

3.2 技术实施方面

  1. 技术选型合理
    • Vue 3 + Spring Boot生态成熟，学习成本低
    • MyBatis-Plus大幅提升开发效率
    • Docker容器化保证环境一致性
  2. 架构设计清晰
    • 前后端分离，职责边界明确
    • 三层架构便于维护和扩展
    • 微服务友好，便于后续拆分
  3. 代码质量可控
    • 编码规范统一，风格一致
    • 单元测试覆盖核心业务逻辑
    • 代码Review发现并修复了多个潜在问题

3.3 团队协作方面

  1. 角色互补性强
    • 前后端能力均衡，无明显短板
    • 测试人员早期介入，质量左移
    • 成员之间互相学习，技能提升快
  2. 工作态度积极
    • 主动承担责任，不推诿
    • 遇到困难主动求助
    • 加班情况合理，无过度疲劳
  3. 知识共享充分
    • 每周技术分享会坚持进行
    • 文档及时更新，知识不流失
    • 代码注释清晰，便于理解

四、做得不好的方面（Problem）

4.1 计划与估算问题

  1. 任务估算偏差
    • 前期任务估算偏乐观，实际耗时多出30%
    • 对技术难点（如搜索功能）预估不足
    • 测试时间预留不足，后期压缩了测试范围
  2. 需求管理不严
    • 过程中增加了3个"小而美"的功能
    • 部分功能边界模糊，导致返工
    • 用户验收标准不够具体

4.2 技术实施问题

  1. 技术债务积累
    • 前端组件复用率不够高
    • 部分SQL查询未优化，性能有隐患
    • 错误处理机制不统一
  2. 文档维护滞后
    • API文档与实际接口有时不同步
    • 部署手册更新不及时
    • 部分设计决策未记录原因
  3. 测试覆盖不足
    • 前端自动化测试覆盖率低（仅78%）
    • 压力测试和安全性测试不够充分
    • 边界条件测试用例不完整

4.3 团队协作问题

  1. 沟通效率待提升
    • 部分技术讨论时间过长（>1小时）
    • 远程协作时，信息同步有延迟
    • 部分决策需要多次会议才能确定
  2. 技能不均衡
    • 前端开发压力集中在一人
    • DevOps知识集中在个别成员
    • 数据库优化经验不足
  3. 工具使用不充分
    • Leangoo看板更新不及时
    • 代码Review工具使用不熟练
    • 自动化测试工具集成度不够

五、改进建议（Try）

5.1 项目管理改进

  1. 估算方法优化
    • 采用三点估算法（乐观/悲观/最可能）
    • 建立历史数据参考库
    • 复杂任务分解到4小时以内
  2. 需求管理强化
    • 严格执行需求变更流程
    • 每个功能必须有明确的验收标准
    • 定期进行需求优先级重排
  3. 风险管理细化
    • 建立风险登记册，每周评估
    • 关键风险制定应急预案
    • 技术选型进行POC验证

5.2 技术实践改进

  1. 代码质量提升
    • 引入SonarQube进行静态代码分析
    • 制定代码坏味道检查清单
    • 建立技术债务偿还计划
  2. 测试体系完善
    • 前端引入Jest进行组件测试
    • 建立性能测试基线，定期回归
    • 实施安全扫描自动化
  3. 文档管理自动化
    • API文档与代码同步生成
    • 使用Git Hook确保文档更新
    • 建立文档评审机制

5.3 团队建设改进

  1. 技能交叉培训
    • 实施结对编程，知识共享
    • 每周技术分享主题化
    • 建立团队技能矩阵，识别短板
  2. 工具链优化
    • 统一IDE配置和代码模板
    • 优化CI/CD流水线，缩短反馈周期
    • 引入更好的协作工具（如Notion）
  3. 沟通效率提升
    • 技术讨论设置时间盒（30分钟）
    • 远程会议使用专业工具（摄像头必开）
    • 决策文档化，避免重复讨论

六、根本原因分析（Root Cause Analysis）

问题类别 表面现象 直接原因 根本原因 解决层次
估算偏差 任务超时30% 缺乏历史数据参考 经验不足，估算方法简单 过程层
技术债务 代码重复，性能隐患 时间压力，重功能轻质量 质量意识不够，缺乏代码标准 文化层
沟通低效 会议时间长，决策慢 讨论无主线，准备不足 缺乏会议管理和决策机制 制度层
测试不足 覆盖率低，Bug遗漏 测试时间被压缩 测试重要性认识不足，未左移 认知层

七、如果重来一次（If We Could Start Over）

7.1 我们会坚持的

  1. 敏捷开发模式：短周期迭代确实有效
  2. 每日站会：保持团队同步的关键
  3. 代码Review：提升质量的最佳实践
  4. 容器化部署：解决环境问题的根本方法
  5. 前后端分离架构：适合团队技术栈

7.2 我们会改变的

  1. 需求阶段：
    • 花更多时间做原型和用户故事映射
    • 建立更严格的变更控制流程
    • 让测试人员参与需求评审
  2. 设计阶段：
    • 进行关键技术选型的POC验证
    • 制定更详细的接口契约
    • 考虑更多的非功能性需求
  3. 开发阶段：
    • 实施更严格的TDD/BDD
    • 建立代码质量标准并自动化检查
    • 更早开始性能和安全测试
  4. 团队建设：
    • 建立团队工作协议（Team Working Agreement）
    • 定期进行retrospective会议
    • 建立知识管理体系和导师制度

八、经验教训与收获

8.1 最大的收获

  1. 技术层面：
    • 掌握了全栈开发的完整流程
    • 理解了微服务架构的设计要点
    • 学会了DevOps实践和工具链搭建
  2. 管理层面：
    • 体验了敏捷开发的全过程
    • 学会了项目风险识别和控制
    • 掌握了团队协作和沟通技巧
  3. 个人成长：
    • 提升了问题分析和解决能力
    • 学会了在压力下保持工作质量
    • 增强了团队合作和领导能力

8.2 最重要的教训

  1. 计划不如变化，但必须有计划
    • 详细的计划是调整的基础
    • 灵活性建立在纪律性之上
  2. 质量是设计出来的，不是测试出来的
    • 前期投入质量成本，后期节省修复成本
    • 自动化是保证质量的唯一途径
  3. 沟通是项目成功的第一要素
    • 清晰的沟通避免误解和返工
    • 透明的信息建立团队信任
  4. 团队比技术更重要
    • 好的团队可以克服技术困难
    • 技术可以学习，团队默契需要培养

九、未来行动计划

9.1 短期行动（Beta版本前）

  1. 偿还识别出的技术债务（2周）
  2. 完善自动化测试体系（1周）
  3. 优化CI/CD流水线（1周）
  4. 进行用户调研，收集反馈（持续）

9.2 中期行动（项目结束后）

  1. 整理项目资产，形成模板库
  2. 进行技术复盘，输出最佳实践
  3. 建立团队知识库，传承经验
  4. 规划个人技能提升路径

9.3 长期影响

  1. 对个人：建立完整的项目经验履历
  2. 对团队：形成可复用的协作模式
  3. 对组织：积累软件开发过程资产

十、致谢与结束语

感谢团队每一位成员的辛勤付出和专业精神。这次项目不仅交付了一个可用的软件产品，更重要的是我们共同经历了完整的软件开发生命周期，积累了宝贵的经验。

"软件工程不仅仅是写代码，更是关于人、过程和技术的艺术。"通过这次实践，我们对这句话有了更深的理解。

项目有终点，学习无止境。 让我们带着这次的经验教训，在未来的工作中做得更好！

会议结束时间：2025年12月10日 16:30
下次回顾会议：Beta版本发布后（预计2026年1月）
报告批准：全体团队成员签字确认 ✅

posted @ 2025-12-23 17:08  郭程朗  阅读(2)  评论(0)    收藏  举报