[T.18] 团队项目：Beta 阶段项目总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.18] 团队项目：Beta 阶段项目总结
我在这个课程的目标是	学习软件工程的基础知识，和团队成员们实践各种软件工程的方法与流程，开发一个让我们值得骄傲的项目
这个作业在哪个具体方面帮助我实现目标	Beta 阶段项目总结

一、设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）
Beta 阶段核心功能全部完成上线，成功按照原计划交付，虽未大规模推广但已满足课程要求的用户指标。

和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
相较 Alpha，团队对项目进行了自动化测试，引入 CI/CD、单测覆盖率提升到 90%以上，通过 GitHub Actions 统计数据证明了代码规范与流程的显著进步。

用户量、用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
内测反馈显示用户能顺畅使用知识库上传与流水线编排，满意度与预测基本一致，我们确实离目标更近了。

有什么经验教训？如果历史重来一遍，我们会做什么改进？
假如重来一遍，我们会更早对外发布并进行宣传，同时在计划阶段详细设计好前后端接口并细化模块责任，避免后期出现局部人手紧缺与任务重叠。

二、计划

是否有充足的时间来做计划？
团队在 Alpha 答辩后一周即启动 Beta 规划，整体节奏较为从容。

团队在计划阶段是如何解决同事们对于计划的不同意见的？
大家会在例会中针对不同意见进行讨论，如果无法达成一致的化最后由PM来决定。

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

有没有发现你做了一些事后看来没必要或没多大价值的事？
现在来看我们做的所有事情都是有价值的。

是否每一项任务都有清楚定义和衡量的交付件？
所有任务在飞书表格和文档中有明确的可验证的验收标准，部分 UI 的设计没有明确的要求，由前端同学进行自由发挥。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
整体进度按计划照常进行。一个意外是运行的前后端对接比预想的困难（主要是最开始接口没有设计好），还有一个突发情况是Beta答辩前一天服务器炸了，因为预算不足导致我们租的服务器性能不是很好，而我们的项目对服务器又有一定的要求。

在计划中有没有留下缓冲区，缓冲区有作用么？
留了一周进行缓冲，主要是进行充分测试还有补充文档。

将来的计划会做什么修改？
条件允许的话想租个更好的服务器。

我们学到了什么？如果历史重来一遍，我们会做什么改进？
前后端的人员分配要相对均衡，像我们最开始只分配了一个人去前端，导致进度有些落后。PM 要对高风险任务动态调整分工。

三、资源

我们有足够的资源来完成各项任务么？
人力配置合理，服务器资源有限制。

各项任务所需的时间和其他资源是如何估计的，精度如何？
PM 对资源进行了一个大概的评估，并不是很细致。

测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源是否低估难度？
硬件资源不充足，测试时间有点紧张，文案工作量被低估了，还好影响不大。

你有没有感到你做的事情可以让别人来做（更有效率）？
开发的过程大多是并行的，交给别人反而会降低效率。

有什么经验教训？如果历史重来一遍，我们会做什么改进？
希望增加预算，租个好服务器。

四、变更管理

每个相关的员工都及时知道了变更的消息？
飞书提醒还有github向主分支提pr的时候所有人都会收到邮件提醒。

我们采用了什么办法决定“推迟”和“必须实现”的功能？
核心功能和杀手级功能是必须实现的，其他一些无关紧要的功能如果实现难度很大就会推迟。

项目的出口条件有清晰的定义么？
Beta 出口标准为前端流水线运行正常，权限管理模块正常、B端和C端有充分的用户反馈。

员工是否能够有效地处理意料之外的工作请求？
功能在设计初期基本就是确定的了，大家基本没有什么意料之外的工作请求，因为前端进度有点慢让几个同学去帮助前端，大家也都有效处理了。

五、设计 / 实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
学期初开始设计的，由范兴堃与吴佳峻完成，时间选得恰到好处，各方沟通顺畅。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有的，涉及到相关功能的同学直接到线下进行结对编程。

团队是否运用单元测试、TDD、UML等工具？这些工具有效么？
用了，有效。

什么功能产生的 Bug 最多，为什么？
前后端流水线运行过程对接bug最多。各个成员对接口设计的理解有偏差，导致并不符合该接口设计的原本意思。

代码复审是如何进行的，是否严格执行了代码规范？
所有主分支 PR 需要进行 Review，严格执行了代码规范。

六、测试 / 发布

团队是否有一个测试计划？
有。

是否进行了正式的验收测试？
是，PM 与邀请的用户在真实环境完成验收测试。

团队是否有测试工具来帮助测试？
是，测试全面引入自动化工具协助执行：后端使用 Apifox 管理接口用例与压力测试，前端引入 Playwright 进行 UI 自动化，整体性能由 JMeter 执行压测

团队是如何测量并跟踪软件的效能？压力测试呢？
我们通过 Grafana 监控关键接口的 QPS 与响应时延，并使用 Apifox 与 JMeter 对检索与 LLM 调用接口进行压力测试。

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

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

团队的每个角色是如何确定的，是不是人尽其才？
基于专长与兴趣分配任务，整体实现人尽其才。

团队成员之间有互相帮助么？
当然！！遇到困难时会采用“结对编程”的方式扫清障碍，互助氛围良好。

当出现项目管理、合作方面的问题时，团队成员如何解决问题？
会召开线下例会。比如说github版本出了问题，我们会在一起分析每个人写了哪些内容并进行版本回退和修改，最终解决问题

八、总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
已跨入三级“已定义”边缘，流程固化但度量体系仍需加强。

你觉得团队目前处于萌芽 / 磨合 / 规范 / 创造阶段的哪一个阶段？
正由磨合迈向规范。

你觉得目前最需要改进的一个方面是什么？
CI/CD 仍待纵深整合，需要把性能测试与指标监控前移到开发阶段。

对照敏捷开发的原则，你觉得你们小组做得最好的是哪几个原则？请列出具体的事例。
我们在短迭代频繁交付、欢迎需求变化以及面对面沟通上表现突出：每次进行多次例会，进行详细的进度汇报和任务划分，所有关键决策都通过线下例会迅速敲定。

正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
并及时更新文档，方便组员及时理解其他模块的作用。将管理、开发、测试更好的融入到各模块的开发过程中。

九、全组讨论照片