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

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

一、设想和目标

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

   心运岛是一款面向18-25岁年轻群体的轻量级心灵慰藉工具，旨在为用户提供低门槛、个性化、易分享的无负担心灵陪伴，缓解日常焦虑与决策纠结。

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

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

   alpha阶段目标基本完全完成，但存在少量bug，如存在折线图未实时更新。

   交付时间延迟了2天。

   大部分部分用户为内测，数量暂时满足了alpha阶段需要。

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

   基本一致，用户能理解功能的用法与优势，但是存在加载太慢让用户使用感不佳的问题。因为用户主要为内测，会比预期的用户量少一些。

   更加接近了，beta阶段会继续改进。

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

   ui设计部分可以更清楚一点，让前端的推进更加顺利。

二、 计划

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

   是。

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

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

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

   基本完成。PWA添加到主屏幕功能因域名审核未完成而推迟到Beta阶段、ECharts折线图更新Bug暂时未解决。

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

   没有。

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

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

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

   大致按照计划进行。但有出现一点团队沟通协同问题，初期组员各自埋头开发，导致接口联调阶段频繁返工。还有域名审核周期比我们预估的要久很多，导致PWA添加到主屏幕功能未能实现。

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

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

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

   我们会吸取Alpha阶段的教训，在每周安排固定的联调日，会议上强制同步组员进度。我们的任务量预估将会更加保守，并预留更充足的调试和修复时间。

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

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

三、资源

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

   有。

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

   我们是让组员根据任务进行评估，精度总体较好，对于修复bug所需时间偏差较大。

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

   足够，但美工设计和文案方面我们低估了难度，卡片生成和高保真视觉稿反复修改多次。

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

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

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

   因为前端工作量较大，在人员分配上面可能会让更多人兼顾前端的工作。

四、变更管理

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

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

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

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

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

   有，见[T.11]博客。

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

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

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

   是。

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

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

五、设计/实现

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

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

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

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

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

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

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

   Bug主要集中在前后端接口对接处和前端UI交互问题，还有少量跨机型兼容性问题。

   团队前期API文档不够详细，接口字段反复调整引发联调问题。

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

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

   基本执行了代码规范。

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

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

六、测试/发布

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

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

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

   是。按照功能验收标准执行了手动测试，覆盖了所有核心用户路径。根据测试报告，测试矩阵覆盖了5种主流浏览器下注册/登录、查看运势、分享运势、记录心情日志、答案之书等9项核心功能，全部通过。

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

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

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

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

   通过k6进行压力测试，模拟80/100/200并发阶梯式加压。UserLogin在80并发时平均延时5.5秒、错误率5%，100并发时错误率升至48.33%；GetFortune和GetFortuneTrend在200并发下保持0%错误率；GetPlazaCards在200并发下平均延时7.6秒、错误率3.83%。

   压力测试帮助我们提前识别了登录接口和广场卡片查询的性能瓶颈。后续应该更早启动性能测试，并在测试环境模拟更多真实使用场景。

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

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

   • 域名审核时间太长，导致PWA添加到主屏幕功能暂不可用。

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

   我们的任务分工更多侧重于开发工时，低估了测试和修复所需时间，把所有测试工作压到最后一周，导致压力测试暴露问题后修复时间极其紧张。Beta阶段将在开发中期就启动首批压力测试，每周设置一次全量回归测试，提前发现性能瓶颈并预留修复窗口。

七、讨论

1. 对比敏捷的原则，你觉得你们小组做得最好的是什么？

   我们团队在Alpha阶段确定了MVP范围，优先实现了用户调研中的核心功能，情绪日记、AI运势和答案之书。我们每周迭代、持续交付可用版本，并邀请用户进行小范围Alpha版本测试，验证产品方向是否正确。

   团队每两天召开一次线下会议同步进度，讨论技术方案和解决阻塞问题。在Bug修复阶段，PM会组织小范围会议进行一对一沟通与跟进，有效提高了信息传递效率。

   尽管Alpha阶段最后一周存在加班，但开发总体上保持了稳定的节奏。通过任务文档化的方式，确保每位成员都能看到全局进度，进度管理相对清晰。

2. 什么是在下个阶段要改进的地方？越具体越好。

   我们Alpha阶段的任务分工更多侧重于开发工时，低估了测试和修复所需时间，把所有测试工作压到最后一周，导致压力测试暴露问题后修复时间极其紧张。Beta阶段将在开发中期就启动首批压力测试，每周设置一次全量回归测试，提前发现性能瓶颈并预留修复窗口。

   前期后端API文档不够详细，导致前后端接口对接时反复修改。在Beta阶段，前后端先共同制定API契约，文档确认无误后再分头开发。

   在bug修复阶段，我们的Bug记录分散，缺乏系统性汇总，主要采用点对点通知，大大增加了沟通成本。Beta阶段将建立每周Bug Review制度，由PM和测试负责人主管，对所有未解决的Bug进行分类、优先级排序、指定责任人和DDL，确保Bug不在最后一周集中爆发。