Alpha阶段综合报告

视频压缩APP - Alpha阶段综合报告

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

---

一、 Alpha 阶段项目复审

复审人: 伊尔番 (PM)

1. 团队排名与点评

说明：以下排名与点评是基于对各团队博客、代码仓库、产品演示和用户反馈的综合评估。

最终名次 (无并列)	小组的名字和链接	优点分析	缺点、Bug 报告（不少于140字）	自我反思与启发
1	student-management-system开发团队	系统完整性高，工程实践规范。 成功构建了一个覆盖学生、教师、管理员三方的全功能管理系统，核心流程完整。Bug修复流程完善，高优先级Bug清零，展现了强大的质量控制能力。测试矩阵覆盖广泛，部署文档详尽，工程化程度很高。	项目在性能和移动端体验上存在明显短板。高并发场景下响应缓慢的问题被延迟修复，这在高频使用时会是致命伤。此外，“智能选课推荐”这一核心亮点功能的缺失，使其在解决用户痛点方面略显不足。数据备份依赖手动触发，缺乏异地容灾机制，系统可靠性面临挑战。	他们的测试矩阵和多环境部署文档做得非常出色，这是我们团队的短板。下一阶段，我们必须建立类似的规范化测试和部署流程，以提升产品的兼容性和可靠性。
2	开芯超人	核心功能扎实，安全意识强。 网盘的核心功能如分片上传、多格式预览、回收站等都已实现，完成度高。特别是在分享功能上，通过“提取码+有效期”的设计，展现了出色的安全意识。其单元测试和集成测试覆盖率较高，保证了核心模块的稳定性。	性能与高阶功能缺失是主要问题。 大文件断点续传功能的缺失，极大影响了核心场景的用户体验。文件搜索性能差，在高频使用下会成为瓶颈。此外，未考虑版本控制，对于有团队协作需求的用户来说是一大遗憾。项目对分布式部署的欠缺考虑也限制了其未来的扩展性。	“提取码+有效期”的安全设计给了我们很大启发。我们的视频分享目前是公开链接，未来可以借鉴这种方式，增加如密码保护、阅后即焚等功能，以满足不同用户的隐私需求。
3	0x07	商业闭环思维，技术栈现代。 项目最大的亮点在于其清晰的商业模式，成功打通了个人、高校、企业三端用户的完整回收流程。技术上，采用了HTTPS+JWT鉴权，安全机制值得肯定。测试覆盖面广，Bug分类清晰，高优先级Bug修复率100%，展现了优秀的工程能力。	健壮性与用户体验细节不足。 项目对异常场景考虑不周，如弱网环境下图片上传无重试机制。高并发下的订单拥堵风险未得到处理。此外，“回收进度实时推送”这一高频核心需求的缺失，影响了产品的核心竞争力。对于企业用户的发票合规性也未做校验，存在合规风险。	他们对多角色、全流程商业闭环的思考深度值得我们借鉴。我们的视频压缩APP目前还只是一个工具，这启发我们未来可以思考如何将其扩展为一个包含视频创作者、消费者等角色的服务平台。
4	书海拾贝队	精准切入校园场景，核心流程闭环。 项目精准地抓住了二手书交易这一校园痛点，并实现了从查询、发布到订单评价的完整闭环。代码仓库管理规范，文档齐全，严重Bug已清零，保证了Alpha版本的可用性。场景测试做得比较完整。	产品在“交易效率”和“安全性”上存在明显短板。 缺乏即时通讯功能，依赖邮箱联系，极大降低了议价和交易效率。订单状态无实时通知。更重要的是，采用面交模式虽然符合校园场景，但完全没有支付安全校验和商品真伪验证机制，这对交易平台来说是重大风险。	他们的项目很好地诠释了MVP（最小可行产品）思想，先用一个最简单的模式（面交）跑通核心流程。我们之前在“替换”功能上投入过多，或许也应该学习这种方式，先做最核心的，再逐步迭代。
5	超能女人	技术驱动，AI应用落地。 项目成功地将爬虫与AI问答技术结合，解决了校园信息分散的痛点，技术上有一定亮点。算法相关的测试用例覆盖全面，保证了核心功能的准确性。GitHub仓库和部署文档都非常规范。	工程实践与用户体验有待提升。 项目存在一些明显的短板，例如未考虑爬虫的“反爬”策略，这可能导致核心数据源中断。API Key由用户自行管理，存在安全隐患。在体验上，搜索结果排序未优化、异步加载缺少loading动画，影响了使用的流畅性。	该团队对AI技术的应用落地能力很强。我们也可以思考是否能在视频压缩中引入AI，例如智能识别视频内容、自动生成标签或摘要，从而提升我们产品的功能深度和技术壁垒。
6	海豹突击队	产品完成度高，设计贴合用户。 项目功能完整，覆盖了商品发布、搜索、订单、互动等二手交易全流程。UI设计适配移动端，符合校园用户的使用习惯。缺陷管理流程清晰（使用JIRA），值得学习。	平台“软实力”不足，缺乏管理与风控机制。 项目未考虑商品违规检测和交易纠纷仲裁机制，这对于一个交易平台来说是致命的。没有这些机制，平台将难以管理，用户权益也无法保障。此外，“智能推荐”这一提升用户粘性的功能也未实现。	他们使用JIRA进行缺陷管理，比我们单纯在聊天工具里沟通Bug要规范得多。这是我们项目管理上可以立刻引入并改进的地方，建立一个正式的缺陷跟踪流程。
8	真好，又活了一星七	多角色流程闭环，适配移动端。 项目成功实现了用户、配送员、管理员三方角色的核心流程闭环，响应式布局也保证了在移动端的可用性。场景测试覆盖了高频场景，部署文档详细，保证了项目可落地。	产品实用性受限，核心功能缺失。 “无在线支付”和“未按地理位置派单”这两个问题，使得项目更像一个“演示原型”而非可用的Alpha版本。此外，缺乏高并发订单处理和异常仲裁机制，也让其难以应对真实世界的挑战。	他们的项目提醒我们，在做MVP时需要警惕“模拟功能”。虽然模拟支付能让流程跑通，但它无法真正验证商业模式或解决用户痛点。我们应该尽量使用真实的、哪怕是简化的技术方案。
9	花好月圆	基础功能扎实，流程完整。 项目实现了图书馆管理的核心功能，如图书借还、读者管理等，流程清晰。团队解决了密码加密等安全问题，并提供了公开访问地址供大家试用，这一点值得称赞。	性能与效率问题突出。 大量数据加载时出现卡顿，这会严重影响管理员的使用体验。缺少批量操作功能（如批量入库、批量借阅），也意味着其在处理真实业务时效率低下。此外，数据备份容灾机制的缺失，是系统的一大隐患。	性能问题是产品的生命线。他们在大量数据加载上的卡顿问题警示我们，在未来的迭代中，必须关注我们视频压缩、特别是批量压缩时的性能表现，避免因处理大量文件而导致应用卡死。
10	睡了吗	AI应用有亮点，部署灵活。 项目的核心亮点在于将知识图谱与智能问答结合，并提供了Gradio部署方式，让用户能快速体验。团队成员分工明确，文档齐全，体现了良好的协作能力。	核心体验存在瓶颈，健壮性不足。 知识图谱节点过多时的卡顿问题，以及长答案无分页，都严重影响了核心功能的使用体验。对API限流的依赖（且无友好提示）也可能导致服务频繁中断。此外，未对推荐的资源链接做有效性检测，可能给用户带来困扰。	他们采用Gradio进行快速部署和演示，是一个非常聪明的做法。对于一些以算法或模型为核心的项目，这种方式可以让我们快速收集用户反馈，而无需等待前端应用的完整开发。
11	VisionPulse 智动团队	AI性能优化出色，有实际应用价值。 项目基于TensorRT进行推理加速，在AI视频检测的核心性能上表现优异。提供了公开访问地址，方便用户直接体验，这是自信的表现。核心功能流程完整。	工程化与文档严重不足，用户体验欠佳。 “无公开仓库”和“文档不够详细”是巨大的减分项，这让外部人员难以评估其软件工程质量。缺少用户注册、模型首次加载时间过长、不兼容低版本浏览器等问题，都表明其在产品化方面考虑不足。	他们的项目在核心算法性能上做得很好，但在“软件工程”这个维度上失分严重。这完美诠释了“软件 = 程序 + 软件工程”的公式。程序质量再高，如果工程质量差，最终的产品质量依然不高。
12	MANBA	游戏完成度高，娱乐性强。 作为一个游戏项目，它在功能丰富度（多战机、商店、排行榜）和数据持久化方面做得很好，保证了核心的可玩性。项目运行稳定，兼容性较好。	核心玩法缺失，扩展性不足。 “联机对战”这一游戏最核心的社交和竞技功能的缺失，使其可玩性大打折扣。窗口大小固定，严重影响了不同分辨率用户的体验。此外，未考虑防作弊和道具平衡性调整，也显示出团队在游戏深度设计上的不足。	即使是学生项目，也需要考虑“反作弊”。这提醒我们，任何有用户生成内容或排行榜的系统，都必须从第一天起就考虑如何防止恶意利用，以保证系统的公平和数据可信。
13	简码双星	基础功能实现，完成度尚可。 项目实现了笔记共享的核心功能，如上传下载和分类，支持多格式文件，注册登录流程也已打通，保证了最基本的用户流程。	产品过于初级，核心功能缺失严重。 仅支持本地部署、无批量操作、无权限管控、无全文搜索，这使得该产品在实用性上大打折扣，更像一个课程设计而非可用的Alpha版本。源代码管理也比较混乱，不利于协作。	看到这个项目，我们更坚定了当初“果断砍掉替换功能”的决策是正确的。与其做一个功能大而全但每个功能都半生不熟的产品，不如集中精力把一两个核心功能做精做透。
14	码	桌面端部署，技术栈有特点。 采用桌面端技术栈实现了一个局域网内的点餐系统，核心流程跑通。数据库连接稳定，在特定场景下（如无网络的小餐馆）有其价值。	应用场景严重受限，实用价值低。 “仅支持局域网访问”和“无在线支付”这两点，使其几乎无法满足现代餐饮业的运营需求。无数据备份机制和远程管理能力，也让其难以成为一个可靠的商用系统。文档和测试记录的缺失也反映了工程实践的不足。	这个项目让我们反思，在立项时，对目标场景和用户需求的调研至关重要。如果最初的技术选型或功能定义脱离了真实的市场需求，那么即使后续开发再努力，产品的价值也会非常有限。

---

二、 事后诸葛亮分析报告

会议时间: [会议日期]
参会人员: 刘瑞康、伊尔番、刘泽昊

1. 计划与实际

计划中的任务	实际完成情况	计划外的任务	实际完成情况
1. 修复权限异常	已完成	1. 保存视频到相册	已完成
2. 界面汉化	已完成	2. 修复“替换”闪退	转为移除功能
3. 加入批量处理功能	已完成	3. 优化分享兼容性	已完成

分析: 我们成功完成了所有计划内的核心任务。但冲刺过程中出现了两个重要的计划外“插曲”：一个是用户反馈驱动的积极改进（保存与分享优化）；另一个则是棘手的技术难题（“替换”闪退）。这说明我们的计划虽然合理，但仍需为应对突发状况留出缓冲。

2. 做的好的方面 (What went well)

1. 团队沟通高效: 每日站会起到了很好的同步作用。当“替换”功能的技术壁垒被发现时，开发能迅速将问题升级，PM能快速决策，团队在一天之内就调整了方向，没有造成任何内耗。
2. 目标聚焦，核心价值交付清晰: 团队始终围绕“压缩”和“分享”两大核心价值。在面对不稳定的“替换”功能时，能够果断舍弃，确保了核心体验的稳定和高质量。
3. 技术驱动决策: 在决定是否移除“替换”功能时，开发团队提供了充足且严谨的测试报告和技术分析，使得 PM 的决策有据可依，整个过程非常专业和理性。

3. 做的需要改进的方面 (What could be improved)

1. 前期风险评估不足: 在冲刺计划阶段，我们低估了“替换”功能在现代安卓系统上的实现难度。我们将其视为一个普通的 CRUD 操作，而没有预见到分区存储带来的权限复杂性。
2. 对系统 API 的依赖过于乐观: 我们最初认为 RecoverableSecurityException 能够优雅地解决 Android 10 的删除问题，但在实际测试中才发现其行为并不稳定。对不熟悉的系统 API，应抱有更谨慎的态度。

4. 下一步计划 (What will we do differently next time)

1. 引入“技术预研 (Spike)”故事: 对于任何涉及与外部系统（如文件系统、第三方SDK、硬件API等）进行深度交互的功能，在正式排入开发计划前，必须先安排一个限时（如 4-8 小时）的 Spike 任务，由一名开发人员专门验证其技术可行性，并产出简要报告。只有在可行性得到确认后，才能进入正式开发。
2. 建立团队知识库: 我们应该把这次解决权限问题、文件读写和分享兼容性的经验，以及关于分区存储的“坑”，都记录到团队的共享知识库（如Confluence、Notion）中，避免未来有人重复踩坑。

5. 团队成员角色与贡献分

名字	角色	团队贡献分	可验证的贡献
刘瑞康	主程 (Lead Dev)	95	- 负责权限、批量处理、文件删除等核心功能的架构设计与实现。 - 主导了“替换”功能闪退的技术攻关，并为最终决策提供了关键技术依据。 - 编写了 requestStoragePermission, deleteOriginalVideos 等高复杂度代码。
伊尔番	PM (Product Manager)	94	- 负责需求分析、制定冲刺计划和优先级。 - 在“替换”功能出现风险时，果断决策，并与用户沟通，成功管理了需求变更。 - 持续跟进用户反馈，提出了“优化分享”等关键改进点。
刘泽昊	程序 (Developer)	93	- 负责全部的 UI 汉化工作，包括 XML 布局和 strings.xml 文件的维护。 - 实现了批量处理时的 UI 交互逻辑，如进度条更新、结果对话框等。 - 协助主程进行了多版本的 Bug 复现和回归测试。