[T.14] 团队项目：Alpha 阶段项目总结

这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	[T.14] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是	体验完整软件开发流程，交付一款真正解决科研阅读痛点的软件产品
这个作业在哪个具体方面帮助我实现目标	完成 Alpha 阶段项目总结

一、设想和目标

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

我们的软件 Scider 是一个智能学术论文管理辅助平台，面向科研人员与学生，提供论文检索、AI解析、知识图谱可视化与个人文库管理等功能

Alpha阶段开始时，我们明确了要解决的核心问题：科研工作者在面对大量论文时难以高效提取关键信息

设计了研一新生张同学的文献调研场景的典型用户故事（详见T.12 Alpha 发布说明）来指导功能设计，使需求定义始终保持在较清晰的水平

2. 我们达到目标了么？

Alpha阶段原计划交付的功能包括用户认证、PDF上传与AI解析、文库管理、知识图谱、论文检索（方向推荐、关键词检索与上下游检索），最终这五大功能模块均成功上线

在交付时间上，因为错估了测试与bug修复的工作量，最终交付时间比预期晚了两天

关于用户量的目标，由于Alpha版本刚刚发布上线，目前还未到大规模推广阶段，用户数量与原计划的量化指标存在一定差距，尚未完全达到预期

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

目前Alpha版本刚刚发布，尚未收集到足够多的用户反馈数据来与预想进行对比...

我们在发布页面上配置了用户反馈问卷，计划在Beta阶段初期收集反馈并据此调整功能优先级。不过，在开发过程中，团队成员自身作为目标用户持续使用产品，发现了一些设计上的不足（如解析进度展示不够直观、检索过滤条件不够丰富等），并进行了优化

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

应该在开发的同时同步推进测试工作，并预留出总体测试与修复的开发时间

beta阶段的宣发提前推进，并尝试更多渠道

二、计划

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

在项目启动时，团队花了两天左右的时间集中进行需求讨论和任务规划排期

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

在飞书视频会议上进行充分讨论，确保每位团队成员都有机会表达自己的观点

当意见出现分歧时，由PM汇总各方观点，团队共同投票表决，按照少数服从多数的原则做出决策

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

原计划的工作都已完成

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

在开发过程中，前端团队花了不少时间在UI细节的美化上（如动画效果、配色微调等），但这些工作在Alpha阶段的功能验证阶段并不是必需的。事后看来，这些时间本可以用来加强单元测试和边界条件的处理，或者优化更有价值的功能模块。

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

任务在飞书项目管理中都有明确的描述；但部分任务对交付标准的定义比较模糊，缺乏可衡量的具体指标

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

项目基本按照计划推进，但出现了一些意外：

• PDF上传后需要经过Celery异步任务队列处理大模型调用，整个异步链路（上传→排队→解析→回调更新状态）的开发和调试时间比预估多了近一倍
• 部署环境差异导致了一些在本地开发环境未出现的问题，服务器环境配置花费了额外的排查时间

团队对异步任务队列和容器化部署的技术经验有限，在计划阶段对这些技术难点的评估过于乐观

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

我们在每个主要模块的排期中预留了1-2天的缓冲时间。这些缓冲时间确实发挥了作用，特别是在AI解析模块调试和部署问题排查时，缓冲区吸收了部分延期的压力，避免了项目整体的严重延期。但从最终结果来看，缓冲时间仍然略显不足，未来应预留更加充裕的缓冲时间。

8. 将来的计划会做什么修改？

• 在每个模块的预估开发时间上再增加20%-30%的缓冲，以应对未知风险
• 将大型任务拆分为更小的子任务（每个子任务不超过2天），便于更准确地跟踪进度
• 在排期中明确标出各模块的联调时间窗口，避免集中到发布前再进行集成测试

三、资源

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

在人力资源方面，六人团队的分工覆盖了前端、后端、测试、部署等多个领域，技能分布比较均衡，基本能够完成Alpha阶段的各项开发任务。但在某些专业领域（如大模型调优等），团队的经验相对不足，需要通过技术调研和学习来弥补。、

在时间资源方面，由于课程时间安排较为紧张，大家需要在学业和其他课程之间平衡时间，实际投入项目的有效时间比预期要少。、

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

我们主要采用类比估计法——即参考类似的软件工程项目来估算各模块的开发时间。同时结合团队成员的个人经验进行微调。对于常规的CRUD类功能，估算的精度相对较高（误差在20%以内）；但对于AI解析、知识图谱等创新性功能，估算精度较低（实际用时约为预估的1.5-2倍）

3. 测试的时间、人力和软件/硬件资源是否足够？

测试资源是一个明显的短板。Alpha阶段前期几乎没有安排专门的测试时间和人力，测试工作主要由PM兼任，且集中在发布前几天才开始实施。

人力上勉强够用，但时间上严重不足，导致Alpha版本可能存在未被发现的bug；未来需要更早地规划测试工作。

四、变更管理

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

我们通过飞书项目管理和微信群双通道来传递变更消息。每次需求变更或技术方案调整，PM都会在飞书上更新任务卡片，并在飞书视频会议上和微信群中进行同步通知，确保每位成员都能及时了解最新的变更信息

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

对于功能的优先级决策，我们主要依据两个标准：

• 一个功能是否属于用户完成核心任务（上传论文→获取解析→管理文库）的必经路径
• 一个功能如果缺失，是否会阻塞其他功能模块的正常运行

3. 项目的出口条件（什么叫“做好了”）有清晰的定义么？

“做好了”的定义在部分任务上是清晰的（如“用户可以成功注册并登录”），但在部分任务上不够明确（如“知识图谱可视化交互良好”）；后者缺乏具体的验收标准（如“支持至少100个节点的流畅渲染”、“拖拽响应时间不超过200ms”等）

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

在Alpha阶段，我们没有正式制定过应急计划。当出现突发问题时（如部署环境配置错误导致服务不可用），团队采取的是即时响应、临时协调的方式来解决，过程相对混乱；Beta阶段我们应该预先识别关键风险并制定应急方案

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

团队整体应对突发问题的能力尚可。例如，在Alpha版本发布前夕，AI解析服务出现了偶发的超时问题，后端同学及时介入排查并修复了问题。但由于缺乏规范的应急流程，处理这些问题时的沟通成本偏高，有时候问题被解决了但其他成员并不清楚具体原因

后续也许可以建立“突发问题处理记录”机制，记录问题描述、解决方案和影响范围，避免类似问题重复出现

五、设计/实现

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

系统设计工作（包括数据库ER图设计、API接口设计、前端架构设计）在项目启动阶段由各方向的负责人主导完成。后端由吴长骏负责数据库设计和认证体系架构，前端由华家璇负责整体架构搭建。从最终的执行效果来看，设计工作和负责人安排是合理的，早期确立的架构在后续开发过程中没有发生大的改动，为开发工作提供了稳定的基础。

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

在API接口设计阶段，前端和后端在数据格式上出现过一些分歧（如知识图谱数据的返回结构、分页参数的命名方式等）。

团队通过召集前后端相关同学进行集中讨论来解决此类问题，形成统一的接口规范并记录在Apifox上供全体成员查阅。

3. 团队是否运用单元测试、测试驱动的开发、UML或其他工具来帮助设计和实现？这些工具的效果怎样？

在Alpha阶段，团队主要使用了以下工具来辅助设计：

• Apifox：用于API接口的文档管理和测试，前后端基于统一的接口文档进行开发，减少了沟通成本
• 飞书-项目管理：用于任务的分配、排期和进度跟踪
• GitHub PR机制：用于代码审查，确保代码质量

在测试方面：

• 部分后端模块（如检索接口、PDF文本提取）编写了单元测试，但对测试覆盖率没有设定具体目标。随着功能迭代和代码量增加，维护单元测试的成本也在上升，部分测试用例已出现与最新代码不一致的情况
• 团队没有采用测试驱动的开发方法，单元测试大多是代码编写完成后补充的

4. 什么功能产生的bug最多，为什么？在发布之后发现了什么重要的bug？为什么在设计时没有想到？

Alpha版本中，AI解析模块产生的bug最多。主要原因是该模块涉及多个服务的协作（PDF上传服务、Celery任务队列、大模型调用服务），任何一环出现问题都会导致整体功能异常。

常见的bug包括：异步任务回调超时、大模型返回格式不符合预期、MD5去重判断在并发场景下的边界问题。

发布后发现的一个重要bug是：部分PDF文件上传后解析进度一直显示为“处理中”，实际上后台任务已经失败了，但前端未能及时获取失败状态并进行展示。这个问题在设计和测试阶段都没有被充分覆盖，原因是对异步任务的异常处理路径考虑不够全面。

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

代码复审通过GitHub PR机制进行。每个功能分支在合并到dev主分支之前，必须创建Pull Request并由至少一位其他团队成员进行代码审查。审查主要关注代码逻辑的正确性、代码风格的规范性以及潜在的安全问题。从Alpha阶段的执行情况来看，PR机制的落实总体是严格的，有效保障了主干代码的质量；但在开发后期，部分较小的修改没有严格遵循PR流程，直接提交到了dev分支。

六、测试/发布

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

Alpha阶段没有形成书面的、系统性的测试计划。测试工作主要依赖于开发者自测和PM在发布前的集中测试。

缺失测试计划的原因在于：团队将有限的开发时间优先用于功能实现，对测试的重视程度不足。如团队在Alpha阶段总结的教训——测试工作应该尽早开始规划实施，不要堆在发布前才紧急修复一堆bug。

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

没有进行正式的验收测试。Alpha版本的验收主要依赖团队成员对核心功能路径的走查，验证了用户可以完成“注册→登录→上传论文→查看解析结果→管理文库”的完整流程。但对于边界情况、异常情况、性能和安全性等方面的验收测试覆盖面不足。

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

团队主要使用了Apifox进行API接口测试，对后端接口的正确性进行了验证。但对于前端测试、端到端测试、性能测试等方面，目前还没有引入专门的测试工具。

4. 团队是如何测量并跟踪软件的效能的？

目前团队主要通过主观感受和偶尔的手动检查来评估软件效能，尚未建立系统性的效能跟踪机制。例如，我们对AI解析的耗时有关注，但没有持续记录和跟踪解析耗时的变化趋势。Beta阶段应引入更系统的效能监控方案，对关键接口的响应时间、解析成功率等指标进行持续跟踪。

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

发布过程中遇到的主要意外问题：

• 服务器环境依赖缺失：部署到云服务器后发现缺少部分Python依赖包，导致后端服务启动失败，临时补充安装后解决
• 前端静态资源路径问题：前端打包后的资源路径与nginx配置不匹配，导致页面加载异常，需要临时调整nginx配置
• AI解析服务高负载下的稳定性问题：发布后有多人同时上传PDF测试，解析服务的并发处理能力受到考验，出现了部分任务排队时间过长的情况

七、团队的角色、管理、合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

团队的角色分配主要基于成员的技术背景和兴趣：

• 肖清心担任PM兼前端开发与测试，统筹项目管理和前端实现；
• 华家璇负责前端架构与运维部署；
• 吴长骏、廉晟、周嘉祺、覃宇航按各自擅长领域分别负责后端不同模块。

从整体来看，角色分配比较合理，实现了人尽其才。每个人在自己负责的领域都有一定的经验积累，能够独立推进工作。但也存在角色职责重叠的情况（如PM同时兼顾测试），这在资源有限的情况下是一种折中方案。

2. 团队成员之间有互相帮助么？

团队成员之间的协作比较积极。当某位成员遇到技术难题时，其他成员会主动提供帮助。例如，后端同学在AI解析模块遇到大模型调用的问题时，对LLM比较熟悉的同学及时给予了技术支持。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

项目管理方面的问题主要通过每2日一次的scrum meeting来发现和解决，会议中每个成员汇报工作进展和遇到的阻碍，由PM协调资源或调整计划。合作方面的问题（如接口联调时的意见分歧）则通过即时沟通（飞书或微信）来快速协调解决。