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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.18] 团队项目：Beta 阶段项目总结
我在这个课程的目标是	掌握软件工程的核心技能，提升开发效率与项目质量
这个作业在哪个具体方面帮助我实现目标	总结Beta阶段的任务

设想和目标

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

我们对软件解决的问题进行了清楚的定义，即解决用户组建队伍时面临的效率低，精准性差等问题。

软件的典型用户为有组队需求的大学生，典型场景为大学生进行课程大作业组队，想要高效、精准地匹配到具有相似课程需求，学习风格和技术领域的同学；或者大学生想要在生活娱乐领域寻找到与自己兴趣相似的同学。

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

我们基本都达成了原定的目标。

功能方面，我们完全实现了beta阶段开始时设计的功能，即实现用户之间的私聊和群聊功能，从而优化组队流程。

交付时间方面，我们按照原计划时间成功交付。

用户数量方面，我们未达到原计划。

3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

软件工程质量整体有明显提升，尤其在代码规范性、测试自动化、团队协作方面进步显著：

• 代码质量和规范性方面，我们使用静态代码分析工具确保代码符合规范，且实施了严格的Code Review流程

• 测试自动化方面，我们加强了单元测试和集成测试的编写，提升了关键模块的覆盖率，并初步引入了自动化测试

• 团队协作方面，我们优化了每日例会的流程，缩短了需求交付时间和任务阻塞时间。

4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

用户量未达到我们的预期，原因在于我们软件的宣传力度不足。

用户对重要功能的接受程度和我们的预期基本一致，通过用户反馈，我们了解到聊天功能很好地优化了组队流程，受到广泛好评。

总的来说，我们离目标越来越近。

经验教训：

• 市场推广启动太晚，范围过小：软件的推广时间较晚导致早期用户增长乏力，同时软件仅在校内进行推广，吸引的用户数目有限。

改进：

• 在开发阶段就尝试低成本推广，同时在校外的社交平台（如小红书，B站）对软件进行宣传

计划

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

是的，我们在alpha阶段初步确定了beta阶段的目标，并在alpha阶段结束后立即确定了beta阶段的计划

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

在团队会议出现不同意见时，我们会让不同意见的持有者给出他们的持有该观点的原因，然后所有组员进行协商并得出最终结论。如果还是存在分歧，最终会由组长确定最终结果。

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

均全部完成。

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

没有。吸取了alpha阶段的教训后，我们在添加功能时，会在组内进行研讨，充分分析这项功能的必要性，以避免在没多大价值的事情上浪费时间。

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

是的，我们在每次例会中，都会明确下一轮开发每个人的任务和任务的要求。

例如，针对开发任务，我们要求交付时必须满足功能全部实现+符合代码规范+通过单元测试+测试覆盖率满足要求；针对技术调研任务，我们要求对比至少3种方案+给出推荐理由

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

项目过程中，对聊天部分的难度和工作量的估计出现偏差

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

我们留下了缓冲区。每个开发周期中预留了1-2天作为调试和紧急修复的时间，以应对可能出现的突发技术问题或需求变更。同时，针对非核心功能，我们将其放在开发计划后段，仅在主功能完成并有余力时才实施。

事实证明，缓冲区在整个项目过程中起到了重要作用：

• 时间缓冲让我们在面对突发事件时不至于打乱整个开发节奏，也保障了功能的稳定性和质量；

• 功能缓冲帮助我们聚焦于核心目标，避免“功能膨胀”导致的延期；

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

• 更科学地分配和管理缓冲区：将缓冲区从模糊概念变为明确的时间块，每个阶段预留10–15%时间作应急处理，并纳入项目甘特图。

• 优化阶段验收机制：优化大任务的拆分策略，设立里程碑检查点，阶段性评估功能完成度与用户反馈。

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

在beta阶段的开发过程，我们学到了以下内容：

• 计划的灵活性与稳定性同样重要。一个好的计划不仅要细致，还要留有调整的空间。我们在本次项目中通过设置时间和功能的缓冲区，提升了团队对突发问题的应对能力。

• 明确交付标准可以显著提高协作效率。我们在每次例会中约定交付标准，减少了模糊任务导致的返工和误解，也提升了代码质量和测试覆盖率。

如果重来一次，我们会做出如下改进：

• 对技术难点进行更早期的原型验证：对于被低估难度的聊天模块，如果能在计划初期安排一次技术小规模原型验证，可能会更早发现问题，调整时间分配。

资源

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

我们有充足的资源来完成各项任务。

• 人力资源：我们根据每位组员的专长进行分配，采用3前端+2后端+1管理端的分工，确保每个人的能力能得到充分发挥。同时在任务重叠或成员临时有事的情况下，其他成员能够及时顶上

• 时间资源：我们在Alpha阶段就制定了Beta阶段的目标，并第一时间完成了合理的排期。同时我们在每个开发周期中都安排了1~2天的缓冲时间，确保紧急问题能被及时处理，保证了任务的交付节奏。

• 硬件资源：在课程组的资金支持下，我们租了一个性能合适的服务器

• 技术资源：我们使用的框架、工具链和部署方式都在团队掌握范围内，技术栈成熟，出错率较低。

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

前端

前端部分，我们基于页面复杂度，页面数量，组件复用度进行评估。

• 页面复杂度：我们将页面分为静态展示类页面（如首页、介绍页）与交互性强的功能页面（如组队页、聊天页），不同复杂度的页面拥有不同的估计时间。

• 组件复用度：如果部分组件可复用（如按钮、弹窗），对应页面的开发时间会适当缩短。

这种估计策略对于普通页面的估计准确率很高，对于高交互页面则存在部分偏差。

后端

后端部分，我们基于接口数量与业务复杂度估算，并综合考虑了单元测试与调试时间。

• 业务复杂度：无状态接口的估计时间较短，涉及事务、权限或状态维护等核心功能的接口拥有较长的估计时间。

这种估计策略对于无状态接口具有很高的准确率，但对于复杂接口，由于学习成本不好预测，这种策略的准确度一般。

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

beta阶段的开发流程较为顺利，因此测试的各项资源是足够的。

而对于不需要编程的资源，由于聊天功能对美工设计和文案的依赖程度较低，我们并未嘀咕难度。

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

在开发小程序聊天界面的时候会遇到这种情况

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

我们学到的内容包括：

• 合理资源预估是高效开发的基础：我们通过任务复杂度拆解来评估工作量，这种方法帮助我们在大多数任务中实现了较高的进度准确性，也避免了开发资源的浪费。
• 任务估算不能只依赖技术视角：比如前端的高交互页面或后端复杂接口，经常会因为预料之外的细节处理或逻辑漏洞导致开发时间延长。这让我们意识到：估算时不能只看表面工时，还应考虑调试、沟通、测试等隐性成本。

如果历史重来一遍，我们会对复杂任务进行双人预估 + 协同开发：对于估算偏差较大的任务，比如高交互前端页面或核心后端接口，可以两人共同评估、开发，这样不仅能互补技能，也能在一定程度上缓解单点风险。

变更管理

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

是的，当开发或测试流程中出现变更时，我们会立即在微信群中进行通知，并详细描述变更内容

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

在项目开发过程中，面对功能多、时间紧的情况，我们采用了功能优先级评估机制，来决定哪些功能“必须实现”，哪些功能可以“推迟”或“有余力再做”。

我们首先将所有功能按照重要程度划分为核心功能，非核心但重要功能，辅助功能三类，并评估每项功能对项目目标是否有核心作用，如果答案是“是”，则优先开发；否则，视开发资源与时间情况决定是否实现。

特别的，即便某些功能很有价值，但如果在当前周期内开发难度大或依赖条件尚未成熟，我们也会做出“推迟”的决策

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

我们设定的出口条件包括以下几个方面：

• 功能通过标准：所有核心功能模块（微信登录、北航邮箱验证、组队、消息、个人中心、课程、博雅）均能正常使用。

• 测试通过标准：单元测试覆盖率符合目标（前端≥70%，后端≥80%），关键路径覆盖率高于90%。

• 性能与稳定性通过标准：压力测试通过，系统在高并发下稳定运行，无崩溃或严重性能瓶颈。

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

是的，我们在项目计划阶段就意识到，需求变更、技术难点、进度偏差等都是开发过程中不可避免的风险。因此，我们提前制定了应急计划来应对可能的变化，以确保项目整体节奏不被打乱。

在每轮开发迭代中，我们预留了1–2天作为应急缓冲期，用于应对因需求修改或Bug修复而产生的额外工作。具体来说，在项目发布前，我们发现聊天记录显示存在bug，于是我们组织了紧急修复，用不到一天的时间修复了这部分bug。

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

团队中成员的技术栈存在重合部分，因此能够在面对突发任务或变更请求时，灵活调整、协同应对，有效处理意料之外的工作请求，保障整体项目进度与质量。

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

我们学到的经验包括：

• 缓冲期与应急机制的必要性：在实际开发过程中，聊天模块的Bug修复、临时文档准备等任务充分证明了预留缓冲时间的价值。合理设置缓冲区，是项目成功的关键保障。

• 功能优先级管理的重要性：通过功能分级，我们成功避免了功能膨胀，保证了核心目标如期实现。这让我们意识到，对功能进行合理取舍十分重要。

如果历史重来一遍，我们会更早进行风险评估。聊天模块在实现时比预期复杂，如果能更早识别关键技术难点并进行任务拆分，能进一步减少开发与bug修复成本。

设计/实现

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

成员方面，我们是组员给出自己的提案，由大家进行审评，最终一起得出设计的总框架。

时间方面，我们会在开发阶段开始时首先给出设计的基本框架，并随着开发进程推进对设计工作进行讨论、修改、完善。

我们认为成员和时间都是合适的，合理的设计策略为我们开发的顺利进行奠定了基础。

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

是的，在设计过程中我们确实遇到过几次需求描述模糊或交互逻辑不清晰的情况。例如聊天记录的搜索部分，前端给出了跳转到新页面与采用悬浮窗口两种设计，又如前后端在部分接口的返回值上存在分歧。

针对有分歧的设计项，我们组织了组内评审会议，持不同观点的同学陈述理由，其他组员评审并提出意见。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们主要使用了单元测试和UML，没有使用TDD。

单元测试方面，我们前后端都编写了单元测试，这一工具确保了模块功能在多次迭代中保持正确，有效减少了bug。

UML方面，我们为聊天功能的执行逻辑绘制了交互时序图，为这一模块的开发提供了便利。

项目开始的UML文档并未发生变化。

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

在整个开发周期中，聊天模块是bug最多的功能，问题主要集中在以下几个方面：

• 消息发送问题：用户切出小程序再重新进入后，WebSocket断开导致消息发送失败。

• 聊天记录丢失或重复：历史聊天记录在某些情况下未正确加载，或出现重复渲染。

• 未读消息数目异常：用户进入某个聊天后，这个聊天内新发送的消息仍会被记录为未读消息。

原因在于，这一模块涉及到了WebSocket长连接、消息队列处理、多服务联动，比其他功能的复杂度高很多。

在发布后，我们没有发现重要的bug，这归功于我们严格的开发与测试规范。

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

我们使用github的PR机制进行代码复审。具体来说，每位开发者完成一个功能或模块后，需提交PR，负责人进行代码审核后才能合并至dev分支。

我们每个成员都严格执行了约定的代码规范。

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

我们学到了提前明确设计细节的重要性：聊天模块中的部分问题，追根溯源其实是由于设计阶段未能充分考虑“WebSocket 断连重连机制”、“未读消息更新逻辑”等细节场景。我们认识到，功能越复杂，前期越需要花时间在细化设计、覆盖边界场景上。

如果历史重来一遍，我们会为聊天模块安排更早的开发与测试，避免集中在后期赶进度。同时我们会细化设计，覆盖更多用户行为场景，以减少测试过程中的bug。

测试/发布

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

团队采用了较为简单的测试计划，即每个人在开发时测试自己负责的模块，确保无明显bug，然后团队再进行前后端联调与压力测试。

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

是的，在课堂展示前一周的周五我们进行了正式的验收测试。在验收过程中，我们针对软件小程序端和管理端的核心功能、界面交互以及性能表现进行了全面测试，确保展示不会出现问题。

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

前端部分，我们使用mock模拟后端接口，隔离前端逻辑进行测试，同时模拟用户操作流程，进行端到端功能验证。

后端部分，我们使用Junit进行单元测试，使用Postman对接口进行功能测试。

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

我们从后端接口性能、前端页面响应速度两方面来测量软件效能。

• 后端：使用Postman + Postman Monitor对常用接口（登录、聊天、组队、查询等）进行测试并记录平均响应时间。

• 前端：使用微信开发者工具监控页面初次加载时间、渲染耗时、资源请求时间等关键指标。

压力测试方面，我们使用Jmeter软件，通过模拟100个并发用户持续发送消息对我们的软件进行了压力测试，确保服务器能够在不影响使用体验的情况下及时地进行响应。

从软件实际运行的结果来看，压力测试帮助我们在部署前提前定位瓶颈，避免了发布后因高并发造成崩溃。

改进方面，目前压力测试仍主要为手动操作，未来应引入CI/CD 的性能测试流程，实现自动化回归检测，以持续保障系统在版本迭代过程中的稳定性和可靠性。

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

在发布过程中，我们在域名解析部分遇到了问题，导致在某些特定网络条件下无法访问到小程序。

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

我们学到的经验包括：

• 测试计划不应仅靠个人自行测试+临近发布的集中测试：尽管每位开发者都测试了自己的模块，但是很多模块间交互Bug直到后期联调才暴露，说明单靠个体测试难以全面保障系统质量。

• 验收测试非常关键：正式的验收测试帮助我们在课堂展示前一周发现了界面异常与接口延迟等问题，并及时修复，保证了最终的系统稳定运行，这让我们认识到发布前的系统级测试是不可跳过的一环。

如果历史重来一遍，我们会接入自动化测试流程，在CI/CD流程中引入自动化测试脚本。

团队的角色，管理，合作

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

在第一次团队会议时，我们每个人都介绍了自己擅长的技术栈，依据各自擅长的技术栈进行分工，做到人尽其才。

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

团队成员在开发过程中遇到问题时，会在微信群中进行询问，其他成员会积极给出建议或解决方案。遇到需要联合讨论的难题时，我们会召开线下会议，高效解决相关问题。

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

普通问题会在微信群中讨论解决，针对较难达成共识的问题，我们会开展一些额外的线上讨论或者小规模的线下会议。

4. 每个成员明确公开地表示对成员帮助的感谢

• 高子贺：感谢饶晨烜同学对项目的环境搭建、后端开发等方面的贡献，感谢安琦同学对于小程序功能、后端开发的贡献，感谢袁耀武同学、丁子航同学、张珺强同学对于小程序前端开发的贡献

• 饶晨烜：感谢袁耀武同学搭建前端帮我验证微信登录功能和聊天的可行性；感谢安琦同学在Spring和Django系统对接联调上的支持。

• 袁耀武：感谢饶晨烜同学对于后端项目的构建，前后端接口设计，联调的支持，感谢丁子航，张珺强同学的合作开发。

• 丁子航：感谢饶晨烜同学和安琦同学对于后端项目的构建，感谢袁耀武同学和张珺强同学的合作开发。

• 安琦：感谢饶晨烜在Spring框架，微服务等方面对我提供的技术支持。

总结

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

团队处在定义级，即定义了软件管理的基本过程与文档化的标准，并将这些标准集成到了软件开发过程中去。

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

规范阶段。我们能顺利进行协作开发，有明确的流程和规则 。

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

我们团队分工更加明确，开发流程更加规范。

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

我们团队最需要改进的一个方面是系统化、自动化的测试流程。我们目前的测试依赖于人工操作、用Postman检查接口等，效率低，易遗漏。同时整个测试流程没有集成到CI/CD流程中，无法实现提交即测试、改动即反馈，增加了后期回归测试成本。

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 欢迎需求的变化：我们能针对需求变化及时调整软件的实现。

• 面对面交流：我们每两天召开一次线下会议。

• 频繁交付可运行的软件：我们部署了CI/CD流程，修复bug或新增内容后会第一时间同步到新版本。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

6.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

提高代码管理的质量：

• 提交粒度控制：建议每次提交只涉及单一或少个功能点，便于代码回滚、定位问题

• 规范化提交信息：使用约定式提交。

提高代码复审的质量：

• 明确审查项：制作一个固定的checklist，每次PR审查时按照该清单严格执行。

• 轮流指派Reviewer：定期轮换审查人员，鼓励团队成员之间进行交叉审查。

提高代码规范的质量：

• 明确统一的代码规范：制定统一的代码规范文档并定期讨论与修订。

7.整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

如何通过重构等方法提高质量：

• 实施分层设计：将模块拆分为控制层，业务逻辑层和数据访问层，明确每层的职责分工，使系统结构更加清晰。

• 定期重构核心模块：定期识别代码中的函数太长、重复代码、循环嵌套多、类职责混乱等问题，通过抽取公共工具类、拆分过大类/函数、使用设计模式替代大量if-else等策略提升代码可读性、可测试性和可维护性。

如何衡量质量的提高：

• 代码复杂度：使用工具（如SonarQube、CodeClimate）测量函数复杂度。

• 性能指标：观察重构后是否有平均响应时间下降、内存占用降低等表现。

8.其它软件工具的应用，应该如何提高？

• 测试工具：引入测试用例管理平台统一记录用例和结果。

• 依赖管理工具：配置lock文件控制依赖版本一致性，同时使用版本清单记录每次升级变更。

9.项目管理有哪些具体的提高？

• 风险管理：制定风险清单，提前准备好应急缓冲。

• 任务分配更清晰：使用飞书任务板，列出每人任务、开始时间、截止时间、完成状态。

• 会议机制优化：每轮迭代开始前快速明确目标、优先级；结束后总结复盘，提炼经验。

10.项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

• 建立自定义埋点系统：在关键功能中埋点（如点击“组队”按钮、打开聊天、成功发送消息），使用分析工具记录用户行为路径。

• 制作数据看板：利用微信后台 + 自定义数据接口制作周报，展示DAU/WAU、活跃路径、流失路径等。

• 用户行为与产品联动：每周通过数据报告复盘，找出用户最常用功能、点击率最低模块，用数据指导功能优化。

11.项目文档的质量如何提高？

• 文档标准化：设立统一的文档目录结构，制定编写规范和模板。

• 版本同步机制：每次迭代功能更新或接口变动，文档必须同步修改。

12.对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

我们要明确领导者和成员的身份，并对团队会议的流程要进一步优化，提高团队会议的效率。

13.对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

在本次软件开发实践中，我们切实体会到了软件工程理论的重要价值。团队成员普遍反映，虽然模块化设计、高内聚低耦合、敏捷开发等理论为我们提供了清晰的指导方向，但最大的收获在于学会了如何将这些原则灵活运用于实际项目开发。通过实践，我们深刻认识到：这些理论不是空洞的教条，而是帮助我们解决复杂工程问题、提升开发效率与产品质量的实用工具。

全组讨论照片