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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.18] 团队项目：Beta 阶段项目总结
我在这个课程的目标是	进一步加强协作完成项目能力，最终开发出功能完善的软件
这个作业在哪个具体方面帮助我实现目标	beta阶段开发完成后总结

一、设想和目标

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

   在alpha阶段的基础上继续完善精准推荐，提供校内问答对接服务。

   目标问题在开发之初就已定义完毕，并对典型用户和场景做出了描述。

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

   达到了，并且在原计划前就已交付，最终用户数量在30个左右，基本符合预期

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

   提高了，尤其在代码规范和项目管理上，可以由协作等工具使用的频率和效率上衡量。

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

   一致，用户普遍反映能接受重要功能并能较为流畅地使用。

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

   会在开发前就做好更细致的分工，总得来说beta阶段在细化功能模块的分工上还是有不平衡，责任的划定还需要在计划前就确定好。

二、 计划

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

   是。beta前一周基于alpha的答辩有针对性的提出方案。

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

   在例会中讨论决定。

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

   完成，除了有一些多余的工作为了防止出现alpha未完成的情况，在例会中讨论后一致决定舍弃了。

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

   有，集中在多余的论坛和评价上，后面大家认为没必要而放弃了。

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

   有。

   后端提供全面的 API 接口文档（通过 APIfox 联调），并配套编写了测试用例。

   这些交付物覆盖对话、广场、算法、敏感词等新功能模块，方便前后端协调与验收。

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

   第一个就是还有出现分工不均的情况，加上迭代版本前端后端本身的工作量相差就比较大，会拖慢进度。

   第二个就是如上所说的多余工作，导致一些开发时间被浪费了。

   未充分估计这些模块的调试与联调成本，计划上没有做好应对各种情况的措施。

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

   开发周期内设置了2天的缓冲区，有作用，给后面的测试留了更多的时间。

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

   将工作拆分为更具体的子任务（如 API 编写、前端组件联调、写真测试等），并由执行者评估开发时长，减少预估偏差，最后在排期前让团队成员对关键技术耗费进行评估，并在计划中留出应对风险的时间。

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

   关键功能、模糊接口应由前后端及时对齐，清晰确认需求后再执行，其中由 PM、组长督促任务落地，必要时快速调整分工与进度。

三、资源

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

   有。

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

   beta阶段由PM和各部门组长也就是有开发经验的人来评估，精度比较好

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

   足够，由于本软件文案、美术设计不多，因此不会有过高难度。

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

   beta阶段主要在后端，可能一些对话相关的内容交给开发过的人会更有效率，但是考虑到每个人的工作量还是分开来分配给不同组员。

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

   需要再增加对工具的熟悉程度，事实上很多工具都只使用了其功能的很小一部分。

四、变更管理

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

   借助微信群、例会、issue、APIfox 协同流程及时通知所有变更。核心模块变更会同步更新文档，确保开发、设计、测试一线同步。

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

   使用功能优先级评分表和技术评估机制，评估标准包括用户价值、技术复杂度、上线风险，功能通过高优先级判断；技术难度大或价值次要的，在团队共识下可移至 Beta 后期甚至抛弃。

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

   出口条件涵盖功能完备性、性能指标、安全扫描、兼容性验证等，Beta 阶段已明确衡量标准并按 OKR 管理工具追踪执行。

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

   是，Beta 阶段引入应急机制：

   • 遇人员缺席，自动从候补开发池中调配成员。
   • 碰到技术阻塞，及时启动专家辅导+快速原型机制，控制质量与进度。

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

   是，在例会上就能具体说明下一步的工作

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

   提前设定变更评审机制，设定变更窗口，确保文档、资源同频更新。

五、设计/实现

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

   计方案在beta初期由PM+设计人员根据用户故事产出，随后每周一与前后端同步评审。实践证明时间节点恰当，协作顺畅。

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

   有。提供 2–3 个可选设计方案，开发/产品组集体评估优劣并迅速选型，显著缩短决策时间。

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

   beta阶段继续使用单元测试与APIfox接口对接覆盖关键路径，同时引入部分前端自动化测试。

   UML保持用于模块边界管理和接口设计，效果持续提升。

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

   依旧是两个核心功能上

   推荐模块：推送时间久，原因在于embedding调整难度较大，对算法模型未提前mock充分。

   WebSocket：多端高并发下曾出现断连或重连失败，后续引入心跳机制和断线重连策略，大幅提升稳定性。

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

   由PM和测试人员进行审核，另外beta阶段执行严格代码审查流程，所有主要模块均需在例会中由至少两位成员复审；

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

   架构的前瞻性，还有beta阶段可提前准备mock服务、支持能够联调的示例数据，提升联调效率

六、测试/发布

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

   有，beta阶段测试人员在完成算法后集中精力完成测试文档。

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

   有，由前后端组长和主测试在真实环境中测试对话流程、推荐展示、新增敏感过滤等核心功能。发现包括 WebSocket 健壮性和推荐重复等问题

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

   ​ 很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

   后端：通过APIfox实现大规模接口自动化测试。

   前端：利用Flutter自带的widget测试工具进行基础UI验证。

   压力测试集中在对话中，模拟50用户同时发送密集消息的情况，评估通过率。

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

   进行关键流程性能门槛设定，接口响应时间需在定义范围内，支持50‑100并发压力下正常运行。另外在压力测试时伴随收敛 WebSocket连结异常，同时加入心跳机制与重连策略，测试真实网络断开与重连行为。

   前端依然使用DevTools分析渲染帧率和卡顿现象。

   整体测试策略已体现多维度闭环验证。

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

   发现用户断连未及时清理导致连接飙增，直接导致消息队列卡死。

   后续发布后存在嵌入重复用户逻辑缺陷，已优化去重机制。

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

   可以增加反馈闭环与变更响应机制，完善定义用户活跃度、关键流程成功率、性能指标，现在的指标停留在浏览量等表面的数量统计上，还可以关注用户回答标签覆盖率等等更深层次的数量。

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

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

   beta阶段明确采用Scrum架构：由Scrum Master负责节奏把控与障碍清除，各个部门的“owner”聚焦需求优先级设定，内部开发负责模块实现与自测试

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

   有具备高度跨职能融合，开发、测试、设计共同参与需求拆解与联调，促进集体对系统全貌的理解 。

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

   使用项目管理工具跟踪问题，同时微信群中提出，对于比较大的问题线下讨论。

八、总结

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

   初步达到定量管理级Level 4，能根据驱动的质量与交付改进进一步提升稳定性与可预测性

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

   规范阶段，提出了明确开发流程，可以遵循共同规范。

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

   推广CI/CD全链路集成，增强开发与测试间的“Shift‑Left”协作策略，现在是相对割裂的。

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

   持续日沟通与双周Sprint Review：2-3 次例会汇报进度并快速调整；

   短平快决策机制：团队成员快速生成方案，组长PM敏捷切换实现路径。

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

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

   可以引入持续集成/持续部署（CI/CD），同时在分支上一致采用更加规范的PR请求。

   建立严格的代码审查制度，鼓励团队成员之间进行交叉审查，涵盖代码风格、逻辑正确性、性能优化等方面，确保审查的全面性和一致性。同时在开发提交分支前就自我审查代码规范，发现潜在的问题并促进知识共享

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

   当前项目采用标准的MVC架构，后续可以将系统拆分为多个独立模块（用户管理、问答管理、消息通知、广场等），每个模块负责单一功能，降低模块间的耦合度，提高系统的可维护性和可扩展性。

   每次例会前识别风险并建立风控列表，Sprint结束后开展总结并调整流程。

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

   可以引入成熟敏捷工具套件，采用多样化工具管理任务与Sprint，并结合github issue等实现 CI/CD 自动化构建、测试及部署

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

   置回顾（Retrospective）环节，面对挑战沉淀经验，微调流程与角色权限

   对未来统计“潜在风险”，提前识别并安排应对措施。

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

   在上面测试/发布最后一条已经说了，除此之外还可以引入行为埋点与漏斗分析，观察用户完成关键流程（如从提问到评价）过程中的掉失点。

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

   文档风格不同且时间节点参差不齐，应该建立文档审查机制与模板规范，确保API、架构、测试文档同步上线

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

   PM应该更加注重每个人的进度和状态，不单单只是在总体上有宏观把控，还应该细化到每个人，注重每个人在团队中的参与感和集体感，以及个人在团队中的表达和意见，确保大家都能从中获益，团队都能在每个人上获益。

   另外对于成员技术不同的问题，可以主动采集佬的学习经验分享出来，促进团队共同成长。

8. 对于软件工程的理论，规律有什么心得体会或不同意见？

   软件工程不仅是工具整合，更是“持续学习与业绩迭代”的机制。

   beta阶段引入的进一步迭代实践，是对“流程即产品”的自我进化，迭代本身就是一种沿着“量化管理—优化—创新”路径，迈向工程质量持续飞跃。