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

这个作业属于哪个课程	计科23级34班
这个作业要求在哪里	团队作业6——复审与事后分析
这个作业的目标	完成Alpha阶段项目复审和事后诸葛亮分析

Alpha阶段项目复审

小组的名字和链接	优点	缺点	最终名次
0x07	1. 实现个人/高校/企业多角色全流程闭环，功能覆盖完整；2. 测试覆盖单元/接口/系统测试，用例丰富（89条）；3. Bug分类清晰（48个），高优先级Bug修复率100%；4. 支持HTTPS+JWT鉴权，安全机制完善；5. 部署文档详细，可直接落地	具体bug：弱网环境图片上传无重试机制（延迟修复）；老旧Android机型身份切换动画掉帧（延迟修复）；地图偏远地区地址解析不精准。 项目目标：核心“多场景下单+智能计价”100%达成，仅“消息推送”未实现。 风险应对：未考虑高并发下订单拥堵，无排队机制；企业发票合规性未做第三方校验。 用户痛点：解决废品回收低效痛点，未覆盖“回收进度实时推送”高频需求。 需求取舍：舍弃“现金支付”（企业订单设计为月结），逻辑合理但未提前告知用户。 源码管理：Git分支规范，提交记录完整，但缺少自动化测试脚本。 如果我领导：添加弱网重试与订单排队机制，对接微信模板消息，补充发票合规校验，引入自动化测试。	1
student-management-system开发团队	1. 覆盖学生/教师/管理员全角色功能（选课/成绩/图书/权限），流程闭环；2. 修复16个关键Bug，高优先级Bug清零；3. 测试矩阵覆盖多系统/浏览器/分辨率，兼容性强；4. 部署文档详细，支持多环境部署；5. 权限管控严格（JWT）	具体bug：高并发响应缓慢（延迟修复）；移动端体验不佳；图书借阅记录仅支持近3个月查询。 项目目标：“学生全流程管理”核心达成，“智能选课推荐”未实现。 风险应对：数据备份需手动触发，无异地容灾；未做压力测试验证高并发场景。 用户痛点：解决教务管理低效痛点，未覆盖“跨学期成绩对比”“个性化课表推荐”需求。 需求取舍：舍弃“智能推荐”，保留基础管理功能，但未调研学生实际需求。 源码管理：Gitee仓库规范，文档齐全，但缺少代码评审记录。 如果我领导：优化高并发处理，开发移动端适配，添加异地容灾备份，实现跨学期成绩对比与智能推荐。	2
开芯超人	1. 功能完整（文件上传/分享/预览/回收站），支持分片上传与多格式预览；2. 单元+集成测试覆盖率高，核心用例全通过；3. Bug修复率80%，高优先级Bug全修复；4. 支持多系统部署，兼容性强；5. 分享功能安全（提取码+有效期）	具体bug：大文件断点续传未实现（延迟修复）；文件搜索性能差（延迟修复）；IE浏览器不兼容（不修复）。 项目目标：“文件管理+分享”核心达成，“全文搜索优化”未实现。 风险应对：未考虑分布式部署，高并发场景受限；无文件版本控制。 用户痛点：解决文件存储共享痛点，未覆盖“团队协作编辑”“大文件断点续传”高频需求。 需求取舍：舍弃“版本控制”，但未评估团队用户需求。 源码管理：分支策略清晰，提交规范，但缺少自动化测试集成。 如果我领导：开发断点续传，引入Elasticsearch优化搜索，支持分布式部署，添加团队协作编辑功能。	3
书海拾贝队	1. 功能闭环（ISBN查询/发布/订单/评价），核心流程无阻塞；2. 修复11个关键Bug，严重Bug清零；3. 测试覆盖多浏览器/设备，场景测试完整；4. 文档齐全（API+用户手册）；5. 代码仓库规范，提交记录清晰	具体bug：移动端适配不完善（延迟修复）；订单状态无实时通知（延迟修复）；无即时通讯功能（需邮箱联系）。 项目目标：“二手书交易”核心达成，“实时通讯”未实现。 风险应对：未做支付安全校验（面交模式）；无商品真伪验证机制。 用户痛点：解决教材购买成本高痛点，未覆盖“商品真伪鉴别”“实时沟通议价”需求。 需求取舍：舍弃“在线支付”，采用面交模式，符合校园场景但灵活性不足。 源码管理：GitHub仓库规范，分支清晰，但缺少性能测试报告。 如果我领导：优化移动端适配，添加WebSocket实时通知，开发即时通讯功能，补充商品真伪验证机制。	4
海豹突击队	1. 功能完整（商品发布/搜索/订单/互动），支持多条件筛选与评论盖楼；2. 测试通过率98.9%，核心功能无阻塞；3. Bug分类明确，修复率75%；4. 适配移动端，符合校园用户使用习惯；5. 部署文档详细	具体bug：低版本浏览器适配未做（延迟修复）；订单状态标签颜色不统一（轻微）；关键词为空时默认展示全部商品（已调整）。 项目目标：“二手交易闭环”核心达成，“智能推荐商品”未实现。 风险应对：未考虑商品违规检测；无交易纠纷仲裁机制。 用户痛点：解决闲置物品流转痛点，未覆盖“智能推荐”“纠纷处理”需求。 需求取舍：舍弃“违规检测”，但未制定平台管理规则。 源码管理：Git提交规范，缺陷管理用JIRA，但缺少自动化测试用例。 如果我领导：添加商品违规关键词检测，开发智能推荐功能，建立纠纷仲裁机制，补充自动化测试脚本。	5
超能女人	1. 核心功能（爬虫聚合+AI问答+栏目分类）完整，适配多用户角色；2. 算法测试用例全覆盖（数据清洗/关键词提取）；3. Bug修复率85.7%，高优先级全修复；4. GitHub仓库规范，部署文档详细；5. 支持本地部署，灵活度高	具体bug：搜索结果排序未优化（延迟修复）；异步加载缺少loading动画（延迟修复）；大模型偶发幻觉（无法修复）。 项目目标：“信息聚合+智能查询”核心达成，“消息推送”未实现。 风险应对：未考虑爬虫源站反爬机制；API key管理由用户自行处理，安全性不足。 用户痛点：解决校园信息分散痛点，未覆盖“关键词精准筛选”“个性化订阅”需求。 需求取舍：舍弃“消息推送”，但未评估用户通知需求。 源码管理：提交记录完整，文档齐全，但缺少高并发测试。 如果我领导：优化搜索排序逻辑，添加加载动画，完善爬虫反爬策略，开发个性化订阅功能。	6
真好，又活了一星七	1. 实现用户/配送员/管理员多角色闭环，核心流程（下单-接单-配送）通畅；2. 修复6个关键Bug，功能逻辑无阻塞；3. 场景测试覆盖全角色高频场景；4. 部署文档详细，支持本地+云端部署；5. 响应式布局适配移动端	具体bug：无在线支付（模拟支付）；配送员未按地理位置派单；数据可视化仅静态展示。 项目目标：“外卖配送闭环”核心达成，“在线支付+实时数据”未实现。 风险应对：未考虑高并发订单拥堵；无订单异常仲裁机制。 用户痛点：解决校园外卖配送低效痛点，未覆盖“在线支付”“实时配送轨迹”需求。 需求取舍：舍弃“在线支付”，采用模拟支付，实用性受限。 源码管理：Gitee仓库规范，提交记录清晰，但缺少性能优化方案。 如果我领导：接入在线支付接口，开发地理位置派单，实现实时数据刷新，添加订单异常仲裁机制。	7
花好月圆	1. 核心功能（图书借还/读者管理/统计分析）完整，流程闭环；2. 修复5个关键Bug，安全问题（密码加密）已解决；3. 测试矩阵覆盖多浏览器/分辨率；4. 提供公开访问地址，可直接试用；5. 代码仓库规范	具体bug：大量数据加载卡顿（延迟修复）；缺少批量操作功能（延迟修复）；操作日志仅保存30天。 项目目标：“图书馆管理”核心达成，“批量操作+日志扩容”未实现。 风险应对：未考虑数据备份容灾；无读者信用评级机制。 用户痛点：解决图书管理低效痛点，未覆盖“批量借阅/归还”“信用评级”需求。 需求取舍：舍弃“批量操作”，但未调研管理员实际工作效率需求。 源码管理：GitHub仓库规范，文档齐全，但缺少自动化测试报告。 如果我领导：优化数据加载策略，开发批量操作功能，增加数据异地备份，建立读者信用评级机制。	8
睡了吗	1. 核心功能（智能问答+知识图谱+资源推荐）完整，Gradio部署可直接试用；2. 修复6个关键Bug，核心流程无阻塞；3. 团队分工明确（8人），文档齐全；4. 支持本地+在线部署，灵活度高；5. 资源推荐精准度高	具体bug：知识图谱节点过多卡顿（延迟修复）；长答案无分页显示（延迟修复）；API调用限流（无法修复）。 项目目标：“知识查询+资源推荐”核心达成，“会话上下文管理”未完善。 风险应对：未解决API限流导致的用户体验下降；无资源链接有效性检测。 用户痛点：解决知识点查询痛点，未覆盖“复杂问题分段展示”“链接有效性校验”需求。 需求取舍：舍弃“多人协作”，但未调研学习场景协作需求。 源码管理：GitHub仓库规范，部署文档详细，但缺少性能优化记录。 如果我领导：优化图谱渲染逻辑，实现长答案分页，添加API限流提示，开发链接有效性检测工具。	9
VisionPulse 智动团队	1. 核心功能（模型上传+推理+告警筛选）完整，支持多格式视频流；2. 修复8个关键Bug，核心性能指标达标；3. 提供公开访问地址，可直接试用；4. 基于Tensorrt推理加速，性能较好	具体bug：无用户注册功能（延迟修复）；模型首次加载时间过长（延迟修复）；低版本Chrome按钮无响应（不修复）。 项目目标：“AI视频检测”核心达成，“Linux部署+用户注册”未实现。 风险应对：未考虑低配置GPU兼容；无模型推理容错机制。 用户痛点：解决视频检测需求，未覆盖“用户自助注册”“低配置适配”需求。 需求取舍：舍弃“多模型对比”，但未调研算法工程师需求。 源码管理：无公开仓库，部署依赖高配置环境，文档不够详细。 如果我领导：开发Linux版本，实现用户注册功能，增加低配置GPU兼容，添加多模型对比功能。	10
MANBA	1. 功能丰富（多战机+商店+排行榜+自定义按键）；2. 修复7个关键Bug，运行稳定；3. 支持多系统部署，兼容性较好；4. 数据持久化完善（进度+排行榜）	具体bug：窗口大小固定，无法调整；输入法冲突（游戏时禁用中文输入法）；Linux系统可能需要额外安装字体。 项目目标：“游戏娱乐”核心达成，“联机对战”未实现。 风险应对：未考虑防作弊机制；无道具平衡调整方案。 用户痛点：解决单机游戏娱乐痛点，未覆盖“联机对战”“窗口适配”需求。 需求取舍：舍弃“联机对战”，但未调研玩家社交需求。 源码管理：GitHub仓库存在，资源文件齐全，但缺少性能优化文档。 如果我领导：开发窗口大小适配，添加联机对战功能，建立防作弊机制，优化道具平衡。	11
RockStar Code Studio	1. 核心功能（批量压缩+分享+保存）完整，适配多安卓版本；2. 修复2个关键Bug，核心流程无阻塞；3. 场景测试覆盖目标用户需求；4. 无严重Crash问题	具体bug：“替换原视频”功能因权限问题已移除；低配手机压缩速度较慢；无自定义压缩参数功能。 项目目标：“视频压缩+分享”核心达成，“自定义参数+进度保存”未实现。 风险应对：未考虑视频格式兼容性（仅支持常见格式）；无压缩失败重试机制。 用户痛点：解决视频分享大小限制痛点，未覆盖“自定义分辨率/帧率”“压缩进度保存”需求。 需求取舍：舍弃“替换功能”，但未提供替代方案（如手动删除原视频提示）。 源码管理：无公开仓库，仅提供构建包，文档不够详细。 如果我领导：开发自定义压缩参数，优化低配手机性能，添加压缩失败重试，提供原视频删除引导。	12
码	1. 核心功能（点餐+菜单管理+桌位管理）完整，无阻塞性Bug；2. 支持多系统桌面端部署；3. 数据库连接稳定，数据操作无异常	具体bug：仅支持局域网访问，实用性受限；无在线支付功能（设计限制）；偶现数据库连接失败（无法重现）。 项目目标：“餐厅运营管理”核心达成，“广域网访问+在线支付”未实现。 风险应对：未考虑广域网部署需求；无数据备份机制。 用户痛点：解决餐厅本地管理低效痛点，未覆盖“远程管理”“在线支付”需求。 需求取舍：舍弃“广域网访问”，但未评估小型餐厅远程管理需求。 源码管理：无公开仓库，文档简略，缺少测试矩阵详细记录。 如果我领导：开发广域网访问支持，接入在线支付接口，添加自动数据备份，优化数据库连接稳定性。	13
简码双星	1. 核心功能（笔记上传/下载/分类）完整，无阻塞性Bug；2. 支持多格式上传（PDF/图片）；3. 用户注册登录流程正常	具体bug：仅支持本地部署，无法广域网访问；无批量上传/搜索功能；偶现页面闪退（无法重现）。 项目目标：“笔记共享”基础达成，“批量操作+广域网”未实现。 风险应对：未考虑多用户并发访问；无笔记权限管控（所有用户可见）。 用户痛点：解决笔记共享痛点，未覆盖“批量管理”“权限控制”“远程访问”需求。 需求取舍：舍弃“批量操作”，但未调研学生批量整理笔记需求。 源码管理：GitHub仓库存在，但分支策略缺失，提交记录简略。 如果我领导：开发广域网部署支持，添加批量上传/搜索功能，实现笔记权限管控，优化页面稳定性。	14

事后诸葛亮分析

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件主要解决老师之间分享课件时版本混乱、统计成绩又费时间又容易错、学生对课程的反馈难传到老师手里这些教学里的实际问题，还能给不同角色分权限、给课程按热度排序。问题定义得很清楚，我们找了10位老师和20位学生聊过，还做了场景问卷，明确了老师、学生、管理员三类主要用户，也详细描述了“老师对比课件不同版本”“学生快速给课程评分”“管理员分配权限”这些常用场景，还对比了使用前后的变化，能看出需求是真实的。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户量达到了么?)?

大部分核心目标都达成了，Alpha版本已经实现了课件上传查看、版本管理、学生星级评分+短评、多维度成绩统计导出、不同角色权限控制这些最关键的功能，一个没落下；也按原计划时间完成了Alpha版本发布；但因为还没正式推广，原本计划初期覆盖1所中学的用户量没完全达到，中期推广到3所学校的目标也还没推进。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

虽然没正式上线，实际用户量没达标，但小范围找了5位老师和20位学生试用，大家对核心功能的接受度和我们想的一样：老师觉得课件版本对比、成绩导出特别实用，备课时间能省30%；学生觉得评分流程很方便，不用填复杂表单。我们肯定离目标更近了，核心功能都跑通了，为后续推广打好了基础。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

经验教训是核心功能做好后，得早点找小范围用户试用，收集真实反馈，别等后期再集中改；另外要提前规划上线的全流程，包括服务器配置、怎么推广这些。如果重来，我们会在开发中期就对接试点学校，功能一完成就启动小规模试用，同时完善上线需要的服务器配置、用户使用说明这些东西。

计划

1. 是否有充足的时间来做计划?

有充足的时间做计划，我们结合乐观、最可能、悲观三种情况估算任务时间，还制定了每周的详细安排，明确了每个阶段要做什么、谁来做、要交出什么成果，还用工具做了可视化的进度表，让计划一目了然。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

计划阶段大家意见很统一，少数细节有分歧（比如该支持多少种课件格式），我们就看用户需求迫切程度和实现难度，结合之前的调研结果商量，最后达成一致，没影响计划推进。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

核心功能都做完了，但一些次要功能（比如课件换主题、操作引导动画）没按计划落地；另外，中期推广相关的工作（比如对接试点学校、优化用户手册）也没推进完。主要是期末的时候，好几门课的大作业和考试凑到一起，团队时间被拆得很散，没精力做这些非核心的事。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

暂时没发现，所有做的工作都是围绕“核心功能落地”“让用户用着舒服”“保证功能稳定”来的，比如课件版本对比、成绩多格式导出这些，试用时都验证了确实有用，没有白费功夫的事。

5. 是否每一项任务都有清楚定义和衡量的交付件?

是的，每项任务都有明确的完成标准：开发的功能要能正常运行（比如后端接口要能通过测试工具验证）、前端页面要和设计图一致；测试要交出完整的测试用例和报告；文档要规范清晰，不管是Markdown还是Excel格式，都能让人一眼看明白。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

项目前期和中期都按计划走，后期有点乱。意外情况是期末好多门课的大作业和考试挤在两周内，团队能投入项目的时间大幅减少；另外，开发深入后发现，课件存储路径、跨域请求这些细节需要额外花时间优化，比一开始估计的要麻烦。当时没料到好几门课的作业和考试会撞期，主要是没提前梳理期末的学业安排，对时间冲突预判不足。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

留了缓冲区，大概占总工期的20%，本来是用来处理突发bug和优化功能的。前期确实派上用场了，比如解决课件版本对比的算法细节、优化前端交互，都是在缓冲期内完成的；但面对期末学业冲突这种突发情况，缓冲区就不够用了，没能覆盖次要功能和推广工作的滞后。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

以后会把缓冲区提高到总工期的30%，还会分“处理bug的缓冲区”和“应对突发情况的缓冲区”；项目启动前，会先梳理大家的学业和其他任务，提前避开时间冲突；另外，会明确区分核心功能和次要功能，要是时间紧张，就先保证核心功能做好，次要功能可以放到后面版本。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到计划要充分考虑外部风险，比如期末学业冲突，缓冲区要留得更灵活，功能优先级要分清楚。如果重来，我们会在项目启动前就梳理期末的学业安排，把核心开发周期提前，避开期末高峰；还会采用“做一点、测一点”的模式，每完成一个功能就赶紧测试，提前发现问题，避免后期集中修改。

资源

1. 我们有足够的资源来完成各项任务么？

• 人力资源：团队3个人，分别擅长后端开发、前端设计、测试和文档整理，刚好覆盖全流程，人手足够，但测试和开发的分工可以更细一点，避免有时候一边测试一边改bug，效率不高。
• 开发资源：常用的开发工具和框架都有成熟的教程，不用瞎摸索；只有课件版本对比的算法细节需要自己调试，没遇到找不到资料的情况。
• 设备资源：云服务器、本地电脑、笔记本都有，能满足开发、测试、部署的需求；测试时能覆盖不同浏览器和操作系统，设备不缺。
• 时间资源：项目前期和中期时间充足，到了期末，因为大作业和考试集中，时间就很紧张了，影响了次要功能和推广工作。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？

时间是结合乐观、最可能、悲观三种情况估算的，还参考了任务难度和大家的技术熟练度；资源是根据功能需求规划的，比如存储课件需要专门的工具，缓存数据需要对应的软件，提前都考虑到了。Alpha阶段的时间估计还挺准的，核心功能的耗时和实际差得不多；但有些技术细节，比如跨域配置、文件路径映射，没想到要花额外时间优化，超出了初始估计。

3. 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？

• 测试相关：留了2天专门测试，有1人负责测试，其他人后期也帮忙，时间和人力足够；设备能覆盖多浏览器、多系统，还有接口测试工具、单元测试工具，能满足测试需求。
• 美工和文案：前期找用户反馈优化了设计，后续没大改动，没低估难度；文案方面，功能说明、部署文档都写得很完整，没遗漏关键信息。

4. 你有没有感觉你做的事情可以让别人来做（更有效率）？

有，比如后端开发完接口后，可让测试人员提前测试，不用等前端对接时才发现问题；前端页面做好后，可让负责文档的人同步写操作说明，不用让开发人员又写代码又写文档，能提高整体效率。

有什么经验教训？如果历史重来一遍，我们会做什么改进？

经验教训是分工明确能提高效率，别让一个人同时做好几件事。如果重来，我们会制定更细的分工清单，明确“开发完→测试上→文档跟”的流程，让每个人专注做自己擅长的事；每天开短会同步进度，及时解决分工衔接时的问题，让流程更顺畅。

变更管理

1. 每个相关的员工都及时知道了变更的消息？

是的，大家更新代码后会在仓库里标注变更内容，合并前会通知相关人；接口文档改了会及时更新到仓库，还会在微信群说一声；测试时发现问题会马上告诉开发，变更消息不会延迟或遗漏。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？

主要看两个方面：一是用户需求急不急，二是实现难度大不大。核心功能（比如课件共享、成绩统计、权限管理）是必须实现的，直接解决用户的关键痛点；能提升体验但不是必需的功能（比如课件版本对比、快速评分），如果用户需求高就优先做；那些用户需求低又难实现的功能（比如换主题、引导动画），就推迟到后面版本。

3. 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？

有清晰的标准：

• 核心功能的测试都通过，发现的问题都修复好了；
• 学生、老师、课程管理员、超级管理员四类角色的权限分清楚，没人能越权操作；
• 本地和云端都能正常运行，登录、传课件、导出成绩这些关键流程没毛病；
• 部署文档写得详细，照着步骤能成功搭建环境；
• 常用的用户场景测试都没问题，能满足核心需求。

4. 对于可能的变更是否能指定应急计划？

可以。比如开发时发现课件存储路径不对，就回退到之前的稳定版本，重新梳理路径配置；测试时发现跨域请求被拦截，就先临时关闭跨域校验（只在测试环境），同时后端赶紧配置跨域，保证核心流程不卡住。

5. 员工是否能有效地处理意料之外的工作请求？

可以。比如Alpha阶段测试发现，云端部署后有些前端请求路径不对，需要统一配置，开发人员很快就调整了配置文件，换掉了硬编码的地址，没影响发布；还有课件封面上传后看不到，后端也快速修正了存储路径，配合服务器代理解决了问题。

我们学到了什么？如果历史重来一遍，我们会做什么改进？

我们学到变更管理要做到“消息传得快、决策有标准、有应急方案”，这样能少走弯路。如果重来，我们会专门建一个变更记录文档，写下变更内容、原因、负责人和影响，方便后期追溯；对于经常变的场景（比如接口调整），制定固定的处理流程，减少重复沟通的时间。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作主要在开发启动前完成，大家一起商量：后端负责整体架构设计，前端负责页面和交互原型，测试负责制定测试计划。设计时间很合适，在开发前就明确了方向；每个人都做自己擅长的事，分工很合理。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，比如讨论“要不要支持课件在线预览”时，有人觉得能提升体验，有人觉得要兼容很多格式，实现起来麻烦。我们先把这个功能记下来，再去问用户，如果超过60%的用户需要，就放到Beta版本，否则就推迟；最后因为用户更需要版本对比、成绩导出这些功能，就决定先不做在线预览，避免争议影响核心功能推进。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

没用到这些工具。我们觉得直接用接口测试工具测后端、人工测前端更高效，能同时发现前后端衔接的问题；系统架构不算复杂，口头商量加简单的流程图就能明确模块关系，没必要用复杂的设计工具。实际效果来看，这种方式能满足Alpha版本的需求，但因为没做单元测试，有些接口的细节问题（比如成绩计算的精度）没提前发现，得后期测试时修正。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

产生bug最多的是部署相关的功能，有2个：云端部署时跨域请求被拦截、前端请求路径不对；还有1个是课件封面上传后看不到。原因是开发时主要在本地测试，没提前在云端环境测试，没考虑到线上的网络和路径差异，对部署的细节考虑不足。

发布后没发现重要bug，测试时发现的问题都修复了。开发时没想到这些情况，是因为前期只关注功能能不能用，没重视本地和云端环境的区别，没做跨环境测试，导致部署后才暴露这些问题。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码主要是自己检查，核心模块（比如成绩计算、权限校验）会让其他成员帮忙看看。只约定了变量命名、写注释这些基础规范，没有详细的审查清单，没严格执行复杂的代码规范；主要是时间紧张，觉得先把核心功能做好更重要，代码规范可以后面再优化。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到设计时要充分考虑部署的细节，代码检查和测试工具能提前发现问题，减少后期修改的成本。如果重来，我们会在设计阶段就制定云端部署的方案，明确本地和云端的路径、网络配置差异；用单元测试覆盖核心接口，比如成绩计算、权限校验这些关键模块；制定详细的代码规范和审查清单，让两个人互相检查核心代码，保证代码质量。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

有完整的测试计划，明确了要测什么（单元测试、前后端衔接测试、全流程测试）、测多久、谁来测、用什么工具；还设计了56条测试用例，覆盖核心场景，确保没遗漏关键功能。

2. 是否进行了正式的验收测试？

没有做正式的验收测试。主要是时间紧张，Alpha版本测试完要赶紧发布，就用“走一遍核心流程+小范围用户试用”代替了，确保关键功能正常，但没制定正式的验收流程和用例。

3. 团队是否有测试工具来帮助测试？

用到了一些测试工具：后端接口用接口测试工具测，核心逻辑用单元测试工具测，测试用例用表格管理；但没用到自动化测试工具，前端功能主要靠人工操作。这些工具挺有用的，能快速验证接口逻辑，覆盖核心测试场景，还方便追溯测试情况。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们没专门测试软件的并发能力和压力情况，只让几个人同时操作，简单验证了稳定性；主要是设备和人手有限，没法模拟很多人同时使用的场景。从实际效果来看，测试工作很有用，发现了跨域、路径异常、封面看不到等5个关键问题，都修复好了，保证了核心功能的稳定。

改进方向：① 用工具测试多用户同时使用的情况，看看系统能不能扛住；② 监测接口响应速度、课件上传速度这些指标，设定合格标准；③ 多测试不同环境、不同设备的兼容性，覆盖更多边缘情况。

5. 在发布的过程中发现了哪些意外问题？

发布时遇到了4个意外问题：① 云服务器内存不够，连续运行几天可能会宕机，得手动重启；② 跨域请求被拦截，后端没提前配置；③ 有些前端请求路径是硬编码的，云端部署后访问不到接口；④ 课件封面上传后存储路径不对，看不到图片。这些问题都通过调整配置、修改代码解决了，但耽误了一点发布进度。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

属于有基础管理流程的阶段，能按计划推进项目，有明确的分工、需求清单、测试计划和发布标准，资源准备也充分，每个人都知道自己要做什么；但还没有一套固定的、制度化的管理方法，比如代码规范、变更管理流程这些，还需要靠项目推进过程中临时约定。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

处于规范阶段。团队成员的分工和职责很明确，技术上互补，对项目目标、计划、流程都达成了一致；每天开短会同步进度，遇到问题能快速响应；通过Alpha阶段的合作，大家配合得越来越默契，没有互相推诿、意见不合的情况，能高效推进任务。

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

相比前期，主要有4点改进：① 分工更贴合每个人的特长，后端专注架构和接口，前端专注交互和设计，测试专注用例和文档，效率更高；② 执行力更强，核心功能都按计划落地，遇到bug能快速修复；③ 文档更完整，需求说明、测试计划、部署文档都很规范，方便后续追溯和维护；④ 变更管理更高效，信息同步及时，功能取舍有明确标准，不纠结。

你觉得目前最需要改进的一个方面是什么?

最需要改进的是设计的全面性。虽然核心设计完成了，但对部署环境、边缘场景（比如大文件上传、很多人同时使用）的设计考虑不足，导致发布时暴露了路径、跨域、内存等问题；后续要在设计阶段就考虑“功能怎么用+怎么部署+遇到异常怎么办+能不能扛住多人使用”，提前预判潜在问题，减少后期修改的成本。

改进

1. 通过Alpha阶段的相互了解，我们团队的成员之间更加了解，认识到彼此的特性，分配任务时也更贴合每个人特点了。比如林嘉俊擅长后端架构和算法，主要负责课件版本对比、成绩统计等核心接口开发；王梓涵对界面美感和交互敏感，主导前端页面和原型设计；廖鸿基严谨细致，负责测试用例设计、Bug排查和文档整理，分工精准提升了整体效率。

2. 团队的执行力更强了，虽然期末阶段时间紧张，但只要任务布置下来，成员都会挤时间完成。比如Alpha阶段测试发现跨域问题时，后端连夜修改配置；前端路径异常时，快速替换硬编码地址，确保了Alpha版本按计划发布。

团队目前最需要改进的地方

设计工作的全面性。后续项目中，要在设计阶段就考虑到功能逻辑、部署环境、异常场景、多人使用情况，制定详细的架构图、部署方案、异常处理流程；对于核心模块，用简单的图表明确模块关系和数据流转，避免因设计疏漏导致后期频繁修改。同时，邀请外部同学或老师对设计提建议，让设计更完善。

全组讨论的照片

Alpha阶段团队成员贡献表

名字	角色	团队贡献分	可验证的贡献
林嘉俊	后端开发（Dev）	95	完成课件版本对比、成绩统计核心接口开发，提交代码12次；修复课件存储路径映射Bug，核心接口测试通过率100%
王梓涵	前端开发（Dev）	88	完成前端页面原型设计，开发课件管理、成绩统计界面；优化交互3处，修复前端请求路径硬编码问题，适配多浏览器；上台汇报项目核心进展及Alpha版本成果
廖鸿基	测试&文档（Test）	86	设计56条测试用例，执行系统测试覆盖核心场景；发现并跟踪修复5个Bug；编写6次团队作业博客，完整记录项目进展、问题解决及复盘内容