[T.14] 团队项目：Alpha 阶段项目总结
| 类目 | 详情内容 |
|---|---|
| 所属课程 | 2026年春季软件工程 |
| 作业要求 | [T.14] 团队项目：Alpha 阶段项目总结 |
| 课程目标 | 团队合作经过两轮迭代完成软件开发实践 |
| 作业价值 | alpha阶段总结与反思 |
团队成员
| 组员 | 角色 | Alpha 阶段主要贡献 |
|---|---|---|
| 袁子轩 | PM | 项目规划、WBS 拆分、接口联调、CI/CD 与部署 |
| 罗浩宇 | 后端 | 用户模块、鉴权、注册登录与 refresh token |
| 李昊霖 | 后端 | 知识问答框架、流式问答、多模型与笔记生成 |
| 李昊宸 | 后端/RAG | 知识向量库、分词/重排模型、RAG 服务 |
| 赵志勇 | 后端 | 题库往年题、模拟考试、自定义组卷、错题本 |
| 王赫 | 前端 | 首页、导航栏、用户模块、知识问答页面 |
| 刘诗怡 | 前端 | 论坛模块、题库模块、发帖与组卷页面 |
一、设想和目标
1. 我们的软件要解决什么问题？是否定义清楚？
目标定义较清楚：面向北航计算机学院本科生，在复习期提供“查知识点 → 做题 → 讨论 → 整理笔记”的学习闭环。典型用户和场景在《功能规格说明书》和 Alpha 展示博客中均有描述。
2. 是否达到目标？
| 维度 | 原计划 | Alpha 实际 | 说明 |
|---|---|---|---|
| 核心功能 | 登录、知识问答、题库、论坛 | 均已上线可演示 | 主路径打通 |
| 交付时间 | 5.5 前 | 5.5 完成 | 按时交付 |
| 杀手功能 | 课程感知 RAG + 笔记沉淀 | 已实现 | 问答绑定课程知识库，支持笔记生成与图谱 |
| 用户量 | 内测小范围 | 未系统统计 | 缺运营埋点，DAU/留存数据空缺 |
3. 软件工程的质量是否提高？
相对项目启动时，有明显提高：三仓 CI/CD 就绪、API 分层规范、RAG 独立服务化、32 个 alpha 子任务可追溯。但自动化测试覆盖率未形成统一口径，测试与埋点建设偏晚。
4. 用户接受度与预期是否一致？
内测反馈表明知识问答和题库浏览可用性较好；RAG 引用来源展示不够直观、错题复练链路不完整、论坛缺少管理后台、移动端体验不足——这些已写入 Beta 改进清单。
经验教训： 目标定义清楚，但“可量化验收”和“用户数据”应在 Alpha 就预留，而不是等到 Beta 再补。
二、计划
1. 是否有充足时间做计划？
有。4.21 启动时完成 WBS（32 子任务、158 人时），并建立 Alpha Milestone 与 Issue 跟踪。
2. 如何解决计划分歧？
PM 在飞书共享文档维护任务与 ddl，每日例会同步；争议功能（如多模型、图片输入）通过“先保证主路径、增强功能后置”收敛。
3. 原计划工作是否做完？
32 个子任务中，核心 29 项按时完成；3 项（部分移动端适配、运营数据看板、完整测试报告）延后至 Beta。
4. 有没有事后看来价值不大的事？
部分页面样式在功能未稳定前反复调整，消耗了联调时间；论坛“加入课程才能发帖”在 Alpha 后期被证明门槛过高，Beta 需重构。
5. 任务是否有清晰交付件？
大部分 alpha-xx 任务有 Issue 与验收条件；联调类任务（如“知识问答流式稳定”）交付标准曾不够量化。
6. 是否按计划进行？意外与风险？
整体按 4.21—5.5 推进。主要意外：RAG 流式阻塞、题库父子题数据联动、多模型参数耦合——均未在计划初期充分估计。
7. 缓冲区是否有用？
有用。5.1—5.5 的缓冲主要用于笔记图谱、流式修复和 Alpha 展示材料，避免了演示前集中爆雷。
经验教训： 计划要留缓冲，且增强功能应有明确的“可裁剪”标记，避免与核心链路争抢资源。
三、资源
1. 资源是否充足？
人力上 7 人分工明确，三仓并行开发可行。环境方面 MySQL、Redis、RAG、LLM API 的联调成本高于预期。
2. 时间与资源估计精度？
WBS 估时整体合理，但 RAG 调试、题库迁移、前后端联调普遍超出单任务 8h 上限。
3. 测试资源是否足够？
不足。Alpha 以手测和 CI 基础检查为主，缺少系统化的接口测试、压测和 E2E，测试计划文档不完整。
4. 是否有工作可以交给更合适的人？
有。例如 UI 统一规范、运营数据口径、测试用例设计，若更早引入专人或固定负责人，可减少后期返工。
经验教训： Beta 阶段应为测试和文档预留固定人力，而不是“开发完成后谁有空谁测”。
四、变更管理
1. 变更是否及时同步？
每日例会 + 飞书文档 + GitHub Issue/PR 评论，大部分变更可追踪。接口字段变更有时依赖口头同步，存在联调遗漏风险。
2. 如何决定“推迟”与“必须实现”？
原则：演示主路径优先。推迟项包括管理员后台、完整埋点、移动端深度适配；必须实现包括登录、问答、题库浏览、论坛基本互动。
3. 出口条件是否清晰？
Alpha 出口条件在 5.5 例会明确：五条 Demo 路径可跑通、三仓 CI 绿、release 可部署。部分模块（如 RAG 引用展示）标准仍偏模糊。
4. 是否有应急计划？
有 USE_REMOTE_RAG 灰度开关，RAG 异常时可回退；数据库迁移有 Alembic 版本管理。
5. 能否处理意外请求？
能，但偏被动。例如流式阻塞、时区问题多在联调阶段才暴露并修复。
经验教训： 接口变更应写入 PR 描述并 @ 相关模块负责人，减少“做了但对方不知道”的情况。
五、设计 / 实现
1. 设计何时、由谁完成？
架构设计在阶段初由全员参与（三仓分离、RAG 独立）；页面设计分散在各前端负责人，缺乏统一设计规范，导致后期样式不统一。
2. 模棱两可如何解决？
通过例会讨论 + PM 拍板，例如会话软删除、错题本与 mock exam 表关系等。
3. 是否使用单元测试、TDD、UML 等？
- 后端/RAG：CI 中跑
pytest，但用例数量有限； - 前端：
vue-tsc+ ESLint + 构建检查； - 未系统使用 TDD 或 UML，文档以 Markdown 为主。
4. Bug 最多的功能？
知识问答（流式、多模型、图片）和题库（父子题、错题本联动）。原因：链路长、外部依赖多、数据模型复杂。
5. Code Review 与规范？
PR 合并前需 review，统一 ApiResponse、分层结构和 [vibe] 提交前缀约定。后期存在“形式化 review”现象，深度不足。
经验教训： 核心链路（问答、题库）应在设计阶段画出序列图或接口契约，减少联调期才发现的集成问题。
六、测试 / 发布
1. 是否有测试计划？
有零散手测清单和 CI 自动检查，但缺少成文的 Alpha 测试计划与用例库。
2. 是否正式验收测试？
5.5 前进行了主路径手测和演示 checklist 验收，未做完整黑盒测试报告。
3. 测试工具？
GitHub Actions（pytest、前端 build）、本地手测。自动化覆盖不足，大量依赖人工点击。
4. 效能与压力测试？
Alpha 未系统开展。Beta 计划补充查询接口压测和登录瓶颈分析。
5. 发布中的意外？
RAG 服务端口、.env 配置、时区字段曾导致演示环境异常，已通过联调文档和 compose 脚本逐步规范。
经验教训： Beta 必须至少有一条自动化回归路径（如：登录 → 提问 → 题库 → 论坛），并纳入 CI 或定时任务。
七、团队的角色、管理、合作
1. 角色是否人尽其才？
整体合理：PM 管进度与部署，后端按模块分工，前端分论坛/题库与通用页面。RAG 与主后端边界清晰。
2. 成员是否互相帮助？
有。例如鉴权问题前后端一起排查，RAG 客户端异常由李昊霖与李昊宸协作，题库联调赵志勇与刘诗怡配对。
3. 合作问题如何解决？
每日例会暴露阻塞，PM 协调优先级；技术争议在例会上讨论或私下结对解决。
成员感谢（节选）：
- 我感谢 李昊宸 对 RAG 链路和知识库构建的帮助，因为在 Alpha 后期多次协助排查检索质量问题与流式协议。
- 我感谢 王赫 对知识问答前端联调的帮助，因为在多模型、图片输入与 SSE 展示上投入大量联调时间。
- 我感谢 赵志勇 对题库数据结构梳理的帮助，因为自定义组卷与错题本涉及多表迁移，保证了 Alpha 演示可用。
八、总结
| 维度 | 自评 |
|---|---|
| CMM/CMMI 档次 | 介于“已定义”与“已管理”之间：有流程、有 CI，但测试与度量未制度化 |
| 团队阶段 | 规范阶段：分工清晰，例会固定，文档与 Issue 可追溯 |
| 相对上一里程碑 | 从“能跑”到“可演示”：核心学习闭环上线，工程化基础建立 |
| 最需改进的一点 | 质量内建：测试、埋点、验收标准应与前开发并行，而非阶段末补 |
九、对照敏捷原则：我们做得最好的是什么？
结合 敏捷宣言 四条价值观与十二条原则，我们认为 Alpha 阶段做得最好的是以下方面：
1. 响应变化高于遵循计划（Responding to change）
事例： Alpha 中后期知识问答从“单模型非流式”扩展为多模型、图片输入、笔记生成时，团队没有僵化执行最初 WBS，而是通过每日例会重新排序：先保流式主链路，再逐步加增强功能。5.1 笔记图谱与流式修复占用缓冲期，仍保证 5.5 演示交付。
2. 可工作的软件高于详尽的文档（Working software）
事例： 阶段目标是“可演示的 release 环境”，而非堆文档。4.21—5.5 内完成登录、问答、题库、论坛四条主路径上线；三仓 CI/CD 与 release 分支部署使“每次合并都能验证、随时可演示”成为常态。
3. 个体和互动高于流程和工具（Individuals and interactions）
事例： 7 人全栈分工明确，但阻塞项依赖面对面/例会沟通快速解决：鉴权边界、RAG 超时、题库父子题等问题均在 1—2 个例会周期内跨模块对齐，而不是等待 lengthy 流程。
4. 技术卓越与良好设计（Technical excellence）
事例： 坚持三仓分离、RAG 独立服务、endpoint → service → schema 分层、ApiResponse 统一契约；USE_REMOTE_RAG 灰度开关体现对架构演进与回滚的设计考量。
5. 可持续节奏（Sustainable development）
事例： WBS 设 15% 管理缓冲，5.1—5.5 明确用于修复与材料，避免最后 48 小时通宵赶演示；每日例会控制在进度同步与风险暴露，而非长篇汇报。
十、Beta阶段要改进的地方
| 序号 | 改进项 | 具体做法 | 负责人 |
|---|---|---|---|
| 1 | 测试自动化 | 主后端补充 160+ 用例目标，RAG 60+ 用例；CI 拦截失败；至少一条“登录→问答→题库”集成路径 | 罗浩宇、袁子轩 |
| 2 | 可观测与埋点 | 用户行为经 Redis 缓冲写入汇总表；管理员统计视图展示 DAU、活跃用户、健康度 | 罗浩宇、李昊霖 |
| 3 | RAG 可解释性 | 引用溯源、题目推荐与问答闭环；优化数据库/OS 课程知识库 | 李昊宸 |
| 4 | 题库复盘闭环 | 错题本筛选、一键复练、模拟考试与 AI 题目推荐联动 | 赵志勇 |
| 5 | 论坛治理 | 简化发帖门槛（去“加入课程”限制）；管理员统计与基础治理能力 | 李昊霖、刘诗怡 |
| 6 | 体验统一 | 品牌统一为“启元知微”；深色主题覆盖统计视图与实用工具；移动端适配 | 王赫、刘诗怡 |
| 7 | 文档与例会 | 14 篇阶段例会博客；Beta 展示博客；Postmortem 行动项跟踪到 Issue | 袁子轩 |
| 8 | Code Review 深度 | PR 必须说明影响模块与测试方式；核心 service 变更需 second reviewer | 全员 |
若历史重来一遍，Alpha 阶段我们会：
- 在 4.25 前冻结接口契约并写清 OpenAPI/示例；
- 从 4.27 起每周固定 4h 用于自动化测试与手测用例，而非全部堆在 5.5 前；
- 移动端与运营数据在 WBS 中单列任务，不设“可选”；
- 增强功能（多模型、图片、笔记图谱）标注优先级 P1，与 P0 演示路径隔离排期。
十一、全组讨论截图
浙公网安备 33010602011771号