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

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	[T.19]Beta 阶段项目总结
我在这个课程的目标是	掌握软件工程的核心理论，协作完成软件项目开发
这个作业在哪个具体方面帮助我实现目标	进行Beta阶段的总结

一、设想和目标

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

   心运岛是一款面向18-25岁年轻群体的轻量级心灵慰藉工具，旨在为用户提供低门槛、个性化、易分享的无负担心灵陪伴，缓解日常焦虑与决策纠结。Beta阶段我们在Alpha基础上增加了个性化 AI、社交互动（运势PK、评论）、彩蛋机制、徽章系统等，让产品从能用走向有趣、有粘性。

   在[T.5]博客中，我们定义了三大典型用户类型，并分别描述了各自的使用习惯、需求和典型应用场景，包括日常解压型、决策纠结型、社交互动型和情绪复盘型四大场景。

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

   目标基本完全完成。

   交付时间延迟了1天。

   实际日活跃用户数约48人，未达到预期。

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

   基本一致，用户能理解功能的用法与优势，但是存在加载太慢让用户使用感不佳的问题。

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

   我们应该尽早开始推广，Beta阶段推广时间较短，效果有限。正式发布前应提前一个月布局社交媒体、建立用户社群。

二、 计划

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

   是。Beta阶段我们用了2天时间拆解任务、评估工时，相比Alpha阶段更加充分。

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

   我们是采用团队协商讨论+PM最终确定的方式，若在线下会议讨论出现不同意见时，通过投票或PM定夺决策，整体上意见差异不大。

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

   基本完成。苹果手机登录页密码框显示异常，仅视觉效果，不影响输入和登录功能。用户可忽略，或使用验证码登录。

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

   没有。

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

   有。每个任务都明确标注了ID、模块、任务名称、工时和负责人，制定了全面的api接口文档和测试用例。

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

   大致按照计划进行。

   之前没考虑到分享链接可能混用协议，运势PK分享链接根据用户访问生成，可能存在http和https两种协议。经常使用https登录的用户，点击http链接时token存储在http域下，导致401未授权。我们只测试了https环境，忽略了历史分享链接可能是http。

   前端限制图片大小2MB，后端限制1.4MB，服务器也默认限制请求体大小。用户上传1.5MB图片时，前端没提示，但后端返回413。

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

   有。我们在Beta阶段的初期计划中预留了约20%的缓冲时间用于Bug修复和整合测试，但实际实施中修复Bug耗时超出预期，缓冲时间仍显不足。

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

   我们会吸取教训将缓冲区提升至 25%，在每周安排固定的联调日，会议上强制同步组员进度。我们的任务量预估将会更加保守，预留更充足的调试和修复时间，并设置功能冻结截止日期，之后只允许修 Bug。

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

   我们的计划不会再一成不变，而是随会议上汇报的实际情况进行动态的调整。同时我们会注意加强沟通，不清楚的地方及时提出并改正。

三、资源

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

   有。

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

   我们是让组员根据任务进行评估，精度总体较好。

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

   足够。我们用一周时间做功能测试、压力测试、兼容性测试。

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

   基本没有，团队的分工较为明确。

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

   因为前端工作量较大，在人员分配上面让更多人兼顾前端的工作，原本负责后端开发的同学调整到前端，部分任务切换成本高。如果一开始让一个人专注前端、一个人专注后端会更高效。

四、变更管理

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

   是的，我们采用微信群或线下会议时沟通。

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

   我们是按照功能优先级划分的。核心功能，如运势看板、答案之书、情绪日记等必须实现，而增强功能，如彩蛋机制、PK功能、主题卡片可以适当推迟。

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

   有，见[T.16]博客。

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

   是。我们提前制定了应急方案，如当LLM API调用失败时，系统自动切换至预设安全文案库。

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

   是。

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

   我们会预留更多的时间处理突发情况，在项目验收前一周就开始确认发布中的问题。

五、设计/实现

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

   设计工作由PM和前端在项目开发初期共同完成，时间安排在制定任务分配计划前，符合项目启动的先后次序。

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

   有。PM汇总前后端人员各方意见，再通过团队讨论决定如何进行下一步开发。

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

   后端运用pytest单元测试，372 个用例，覆盖率 83%，前端使用Vue Test Utils初步尝试，压力测试工具k6帮助我们定位性能瓶颈。这些工具在提高代码健壮性和效率上非常有效。

   部分模块先写测试再写代码，效果很好。

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

   Bug主要集中在前后端接口对接处和前端UI交互问题，如前端限制图片大小2MB，后端限制1.4MB，服务器也默认限制请求体大小。用户上传1.5MB图片时，前端没提示，但后端返回413。还有少量跨机型兼容性问题。

   苹果手机登录页密码框显示异常，仅视觉效果，不影响输入和登录功能。用户可忽略，或使用验证码登录。

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

   通过GitHub PR进行代码审查，每次合并至少由一名非本人成员审阅通过。制定了统一的Git规范，如提交格式<type>(<scope>): <subject>。

   基本执行了代码规范。

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

   我们会更详细的完成架构设计部分，让后续的开发推进更轻松。将API文档等开发文档部分规范的更清晰，减少后续前后端沟通成本。

六、测试/发布

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

   有，见[T.6]博客，采用分层测试策略来设计本系统的测试，分为单元测试、集成测试和压力测试等。

   • 功能测试：覆盖 9 大模块（登录/注册、运势看板、答案之书、广场、我的、设置、PWA、响应式、安全），累计 70+ 测试点，采用手动方式逐个验证。
   • 压力测试：前端使用 autocannon 对静态资源加压，后端使用本地 Docker 环境模拟并发请求。
   • 单元测试：后端 pytest 框架，覆盖 372 个用例。
   • 兼容性测试：测试矩阵覆盖 3 种操作系统（macOS、Windows 11、Android）、7 种浏览器（Chrome、Safari、Firefox、Edge、百度浏览器、PWA），核心功能全部通过。

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

   是。

   • 后端单元测试：共 372 个用例，100% 通过，源码覆盖率达 83%，覆盖认证、运势、答案、广场、评论、徽章、日记等全部核心模块。
   • 前端功能测试：覆盖登录/注册、运势看板、答案之书、广场、我的、设置、PWA、响应式、安全等 9 大模块，累计 70+ 测试点，全部通过。
   • Bug 修复：Beta 阶段发现 9 个主要 Bug（勋章遮挡、广场换行、收藏刷新、生日选择器、头像 413、PK 401 等），全部修复并完成回归测试。
   • 后端压力测试：150 并发下成功率 100%，200 并发时成功率仍达 99.8%（仅 2 次读超时），性能稳定。
   • 前端压力测试：小文件（193KB JS）在 200 并发下吞吐量 129 req/s，传输速率 639 KB/s，响应延迟低；大文件（1.5MB 图片）受带宽限制传输较慢，但不影响核心功能。
   • 兼容性测试：覆盖 macOS / Windows 11 / Android 系统，Chrome / Safari / Firefox / Edge / 百度浏览器及 PWA 安装模式，所有核心功能均通过验证。

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

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

   是。后端使用pytest、autocannon；前端计划使用Vue Test Utils；压力测试使用k6；端到端测试使用Playwright；兼容性测试在Mac/Windows真实浏览器中手动验证。

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

   • 使用 autocannon 对前端静态资源进行并发测试，发现大文件在 200 并发下超时率高达 66%，带宽成为瓶颈。
   • 后端压力测试在本地 Docker 环境执行，模拟 50/100/150/200 并发，记录 RPS 和成功率。150 并发时 RPS 为 56.44，200 并发时成功率仍达 99.8%。
   • 通过 Prometheus 监控生产环境 CPU、内存、响应时间。

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

   部分IOS浏览器登录存在不兼容问题。

   前端大文件加载慢，未预料到图片体积对用户体验的影响

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

   在 UI 设计阶段就评估资源体积，对超过 500 KB 的图片自动压缩。

   在测试时使用真机云测试平台，确保所有主流环境都能正确运行。