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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.19] 团队项目：Beta 阶段项目总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习软件工程理论，在完成高质量的软件开发项目中深入学习软件工程经验
这个作业在哪个具体方面帮助我实现目标	总结Beta阶段经验，持续改进团队协作与工程实践

---

设想和目标

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

我们的软件《第四轴（Sephiroth）》是一款强调"理解规则即掌控世界"的科幻推理 RPG。我们的目标非常清晰——通过"数值守恒 + 标签系统 + 四维时空叙事"三大核心机制，为硬核解谜玩家提供独特的逻辑推理体验。

典型用户和场景在功能规格说明书中已有清晰的描述：

• 硬核科幻与时空叙事爱好者：追求逻辑严谨的剧情反转与设定自洽
• 规则驱动型解谜玩家：钻研机制边界，尝试各种"逃课"打法
• 剧情导向型独立游戏玩家：追求沉浸式情感体验与叙事记忆点

这三类用户画像在整个开发过程中始终指导着我们的功能设计和测试重点。

2. 我们达到目标了么？

目标	完成情况
原计划功能（Beta 阶段计划）	全部完成
— 时间机制（因果链接）	✅ 完成，可演示"改变过去影响现在"的因果链
— 第三章开发	✅ 完成"恶意"推理章节，含 5 个结局
— 新手引导系统	✅ 完成，10 分钟内核心机制理解率达 90%+
— 小地图系统	✅ 完成，支持实时导航
— 物品获取与使用反馈	✅ 完成，含拾取动画、特效、音效
交付时间	✅ 按计划于第三周末完成全流程交付
用户数量	Alpha 阶段在 Itch.io 发布首日即获得 43 次 Views 和 32 次 Downloads，Beta 阶段预期保持或超越该数据

3. 和上一个阶段相比，团队软件工程的质量提高了么？

明显提高。具体体现在：

维度	Alpha 阶段	Beta 阶段	提高幅度
单元测试覆盖率	约 40%	约 65%	+25%
Bug 修复率	P0 修复率 100%，但修复周期较长	P0/P1 修复率 100%，修复周期缩短 40%	显著提升
代码规范执行	初期较松散，后期逐步规范	全阶段严格执行代码规范与 Code Review	规范化
文档质量	文档齐全但部分滞后	文档先行，API 文档同步更新	时效性提升
自动化测试	有但覆盖不全	新增机制的自动化测试全覆盖	覆盖更全面

具体衡量方式：

• CI 构建通过率从 Alpha 阶段的约 85% 提升至 Beta 阶段的 95%+
• 阻断性 Bug 数量从 Alpha 阶段的 5 个降至 Beta 阶段的 3 个
• Beta 阶段全流程回归测试仅需 Alpha 阶段 60% 的时间

4. 用户量、用户对重要功能的接受程度和我们事先的预想一致么？

基本一致。Alpha 阶段发布后，用户对标签系统和数值守恒机制的反馈非常积极，认为"利用真理透镜透视世界本源的设定非常新颖且惊艳"。用户反馈的痛点（缺少引导、没有小地图、物品无反馈）正好与我们的 Beta 阶段计划吻合，验证了我们的优先级判断是正确的。

我们离目标更近了——Beta 阶段的三章完整游戏已能完整呈现"规则驱动叙事"的核心体验。

经验教训：如果历史重来一遍，我们会做什么改进？

• Alpha 阶段结束时就应该立即启动引导系统的开发，而不是等 Beta 阶段才开始。因为 Alpha 发布后获取的用户反馈中，引导缺失是最核心的流失原因，早一版解决就能早一版回收验证数据。
• 时间机制的引入应该更早进行设计评审。该机制与标签系统、数值守恒系统有复杂的交互关系，如果在 Alpha 阶段末期就开始接口设计，Beta 阶段的集成联调会更顺畅。

---

计划

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

有。Beta 阶段团队吸取了 Alpha 阶段"过于乐观"的教训，在制定计划时更加务实。我们在 T.8 (Beta 阶段任务分配) 中花了足够的时间进行任务拆解、工时估计和依赖分析，并预留了测试缓冲区。

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

通过例会讨论和 PM 协调解决。在任务分配时，个别成员对自己的角色有不同想法（如卫丁恺在 Alpha 阶段负责测试，Beta 阶段调整为 UI/测试双角色），团队通过协商达成了共识。所有的分歧都在 Scrum 例会中公开讨论，由 PM 蒋渝做最终协调。

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

全部完成。Beta 阶段计划的 9 大任务模块（Alpha 痛点修复、小地图系统、时间核心玩法、时间交互 UI、第三章设计、场景配置、剧情扩充、测试与打磨、项目宣发与管理）全部按时交付。

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

有一个值得反思的点：在第三章设计中，我们最初计划了非常复杂的多分支对话树（每个 NPC 有超过 10 种对话状态），但在实际开发中发现，玩家更关注的是核心推理路径的流畅性，而非对话分支的丰富度。如果在对话系统上做减法，将更多精力放在谜题打磨上，效果可能更好。

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

是的。Beta 阶段每一项任务在分配时都明确了交付物（如"TimeManager 脚本"、"第三章 Scene 文件"、"测试报告单"），并绑定了质量验收标准。这是从 Alpha 阶段学到的经验。

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

大体按照计划进行。但有一个意外：第三章的时间机制与标签系统的集成比预期复杂。原因是两个系统各自独立开发时没有充分考虑到交互状态的共享（如"快进的"标签需要同时影响时间轴和标签显示系统），导致联调阶段花费了比计划多约 30% 的时间。

这个风险没有完全估计到，因为两个系统分别由不同成员（彭吕衡负责时间机制，张子昱负责标签系统）独立开发，接口定义虽然做了，但实际的边界情况比预期的复杂。

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

有。我们在第三周预留了约 20% 的缓冲区用于集成测试和 Bug 修复。这个缓冲区非常关键——上述时间机制与标签系统的联调问题正是在缓冲区中解决的。如果没有缓冲区，项目可能会面临延期风险。

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

• 增加接口联调的时间占比：对于涉及多系统交互的功能，在计划中增加"集成联调"的独立时间块，而不是把所有联调放在测试阶段。
• 更细致的任务分解：将超过 16 小时的大任务进一步拆分为 8 小时内可完成的子任务，提高跟踪精度。

---

资源

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

是的。团队成员 6 人在 Beta 阶段各司其职，人力资源充足。开发工具方面，Unity、GitHub、CI 工具链运转正常。

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

以功能点为基础进行估计，参考了 Alpha 阶段的历史数据。精度相比 Alpha 阶段有明显提升——实际工时与估计工时的偏差从 Alpha 阶段的平均 ±40% 缩小到 Beta 阶段的 ±20%。

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

测试资源充足。吴鑫祺负责测试，卫丁恺配合 UI 相关工作，测试覆盖了全部功能矩阵。

美工设计/文案的难度估计合理。黄韬乐的美术产出按计划完成，包括第三章场景绘制、UI 视觉优化、引导系统美术资源等。文案方面，蒋渝的第三章剧本和推理设计得到了团队的一致认可。

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

在部分非核心任务上（如文档排版、截图整理等），确实可以由多人分担来提高效率。Beta 阶段相比 Alpha 阶段已经有了明显改善——更多成员参与了文档编写和测试工作，而不是集中在少数人身上。

经验教训：如果历史重来一遍，我们会做什么改进？

• 在 Alpha 阶段就为每个成员指定"备份角色"，当核心开发任务出现瓶颈时可以灵活调配。
• 美工和开发的接口文件格式应更早确定，避免后期返工。

---

变更管理

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

是的。所有变更通过每日站会和微信群及时同步。遇到大的变更（如第三章的谜题设计调整），会召开临时会议讨论后再执行。

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

采用 MoSCoW 优先级法：

• Must have：引导系统、小地图、物品反馈、第三章核心玩法
• Should have：时间机制的 UI 美化、额外剧情分支
• Could have：可选剧情扩写、更多装饰性交互对象
• Won't have：跨平台支持、多人模式（确定为 Beta 范围外）

3. 项目的出口条件（Exit Criteria）有清晰的定义么？

有。在 T.8 (Beta 阶段任务分配) 中明确定义了 DoD（完成定义）：

1. 时间机制玩法代码闭环并能正常演示
2. 第三章地图跑通，各交互对象可正常响应
3. Alpha 遗留问题修复（引导、反馈、小地图）
4. 集成测试通过
5. 宣发物料按时交付

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

对于关键路径上的变更（如某个核心开发人员请假），我们有简单的应急计划——由 ARCH（张子昱）作为技术兜底，必要时可临时接管关键模块的开发。

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

可以。所有外部工作请求（如其他组的协作需求、课程反馈等）统一由 PM 蒋渝接收和协调，开发人员专注于自己的核心任务，不会被频繁打断。

---

设计/实现

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

• 系统架构设计：由 ARCH 张子昱在项目初期完成，时间合理。
• 第三章策划与剧情设计：由 PM/策划 蒋渝在 Beta 阶段第一周完成，为后续开发提供明确方向。
• 美术设计：由美术总监 黄韬乐在全阶段持续产出，与开发并行推进。
• 时间机制设计：由 GAME 彭吕衡主导设计，ARCH 张子昱配合接口定义。

总体而言，设计工作由最合适的人在合适的时间完成。

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

有。最典型的例子是"时间机制中标签状态的跨时间轴同步规则"——当一个标签在过去被修改时，现在的对应对象应该怎么变化？这个规则最初有多套方案。

解决方式：彭吕衡和张子昱联合进行了两轮技术方案评审，最终采用"双向状态映射 + 冲突检测"的方案：每个 TimelineObject 维护过去和现在的两份状态快照，修改时自动检测冲突并选择"时间上最近的一次修改"作为最终状态。

3. 团队是否运用单元测试（unit test）、测试驱动的开发（TDD）、UML 或其他工具来帮助设计和实现？这些工具有效么？

工具/方法	使用情况	有效性
单元测试	对标签系统、数值守恒系统、存档系统进行了单元测试	✅ 有效，在测试阶段发现了多个回归 Bug
UML 图	在架构设计阶段绘制了类图和时序图	✅ 有效，帮助团队对齐了接口设计
CI/CD	GitHub Actions 自动构建与测试	✅ 有效，每次合入前自动验证编译和测试
Code Review	所有 PR 必须经过至少 1 人 Review	✅ 有效，早期发现了很多潜在问题

UML 文档与现状的差异：Beta 阶段新增了时间机制相关的类和接口，最初的 UML 文档未包含这部分。项目结束后需要更新 UML 文档以反映实际状态。

4. 什么功能产生的 Bug 最多，为什么？

时间机制产生的 Bug 最多（约占总 Bug 数的 35%）。原因：

1. 这是 Beta 阶段全新引入的机制，缺乏 Alpha 阶段的积累和验证。
2. 时间机制与标签系统、数值守恒系统、存档系统都有交互，集成复杂度高。
3. 时间轴切换涉及大量状态的保存、恢复和同步，边界情况多。

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

Beta 阶段严格执行了 Code Review 制度。所有代码在合入主分支前必须：

1. 通过 CI 构建和自动化测试
2. 至少经过 1 名团队成员的 Review
3. 确认符合 C# 编码规范

相比 Alpha 阶段后期"Review 流于形式"的问题，Beta 阶段的 Code Review 更加认真。卫丁恺和吴鑫祺在 Review 中多次发现了潜在的逻辑错误和性能问题。

经验教训：如果历史重来一遍，我们会做什么改进？

• 时间机制的接口定义应该更早完成，并在实现前进行一次全团队的架构评审。
• Code Review 的检查清单可以更加结构化（如增加"是否处理了边界条件"、"是否添加了必要注释"等检查项）。

---

测试/发布

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

有。测试计划在 Beta 阶段初期由卫丁恺制定，覆盖了：

• 单元测试计划（各核心模块）
• 集成测试计划（跨系统联调）
• 场景测试计划（用户使用场景）
• 回归测试计划（Alpha 功能的回归验证）
• 验收测试计划（出口条件验证）

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

是。在 Beta 阶段第三周周末，由 PM 蒋渝主持，全员参与的正式验收测试。测试按照预定义的"出口条件检查表"逐项验证，全部通过后方才确认发布。

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

有。我们使用了：

• Unity Test Framework：用于 C# 单元测试和集成测试
• GitHub Actions：自动化 CI 流水线，每次提交自动运行测试
• 手动测试脚本：对于无法自动化的 UI 交互和游戏体验测试

自动化测试改进计划：后续可以考虑引入可视化回归测试工具（如 Unity 的 RenderDoc），自动比对画面渲染的一致性，减少手动测试的工作量。

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？

由于是本地单机游戏，我们没有进行传统的压力测试。效能跟踪主要通过：

• Unity Profiler：在关键场景（第三章大厅、战斗场景）中记录帧率和内存占用
• 多配置测试：在高低配两台机器上分别测试，确保主流配置下帧率 >= 50fps
• 长时间运行测试：连续运行游戏 2 小时以上，检查内存泄漏和性能衰减

这些测试工作非常有用——我们通过 Profiler 发现了第三章壁炉粒子特效的性能问题，并增加了 LOD 控制来缓解。

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

意外：在构建发布包时，发现某些场景的 Asset Bundle 没有正确包含，导致解压后部分音效和 UI 图片缺失。

原因：部分新资源（第三章新加的 UI 素材）在 Unity 的 Build Settings 中没有正确添加到 Scenes 列表之外的必要资源列表中。

解决：使用 Unity 的 Addressable Assets 系统统一管理资源引用，重新构建后问题解决。

经验教训：如果重来一遍，我们会做什么改进？

• 在正式构建发布包之前，先进行一次"预发布"的干跑测试，确保所有资源都正确打包。
• 建立一个发布检查清单，逐项确认构建配置、资源引用、版本号等信息。

---

团队的角色，管理，合作

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

团队角色基于每个成员的技术背景和兴趣确定：

成员	角色	评价
蒋渝	PM / 策划	发挥出色，主导了全阶段的策划、协调和文档工作
黄韬乐	美术总监	贡献卓越，美术设计、UI 和宣发一手包办
彭吕衡	GAME / 后端	核心代码贡献最多，时间机制和标签系统的开发主力
张子昱	ARCH / 架构	在架构设计和复杂问题攻关上发挥了关键作用
卫丁恺	测试 / UI	Beta 阶段从测试转向测试+UI 双角色，适应良好
吴鑫祺	UI / 测试	Alpha 阶段负责 UI，Beta 阶段转向测试，测试工作完成度高

整体而言，人尽其才。Beta 阶段的角色微调（卫丁恺和吴鑫祺的角色互换）被证明是合理且有效的。

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

是的。在集成联调阶段，时间机制和标签系统的对接需要彭吕衡和张子昱的密切配合；在第三章场景配置中，黄韬乐和彭吕衡高效协同；测试阶段全员参与 Bug 验证和修复。团队氛围良好，互帮互助是常态。

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

• 技术问题：由 ARCH 张子昱或 GAME 彭吕衡牵头做技术方案评审，全员参与讨论决策。
• 进度问题：由 PM 蒋渝在每日站会上协调，必要时调整任务优先级。
• 人际问题：Beta 阶段未出现显著的人际冲突，所有分歧通过坦诚沟通解决。

4. 每个成员对团队的感谢

蒋渝：感谢黄韬乐在美术和宣发上的全力投入，第三章的推理氛围全靠你的地图设计和像素风格才得以完美呈现；感谢彭吕衡和张子昱在技术攻关上的日夜付出，没有你们就没有 Sephiroth 的核心机制。

黄韬乐：感谢彭吕衡在场景配置时的耐心配合，反复调试交互对象的位置和碰撞体，你的认真让第三章的每一处细节都有了灵魂。

彭吕衡：感谢张子昱在时间机制设计上的关键建议，如果没有你的架构视角，时间轴和标签系统的联调会多走很多弯路。

张子昱：感谢蒋渝的 PM 统筹，三次迭代的节奏把控得非常精准，让开发团队能专注于代码，不用操心排期和沟通。

卫丁恺：感谢吴鑫祺在测试工作中的细致认真，你发现的那些边界条件 Bug 让我们的游戏质量提升了一个档次。

吴鑫祺：感谢卫丁恺在 UI 工作上提供的帮助，在我转向测试后你能快速接手 UI 工作，保证了项目不被阻塞。

---

总结

团队状态评估

评估维度	当前状态
CMM/CMMI 档次	已从 Alpha 阶段的 Level 1（初始级） 提升至 Level 2（可重复级）。关键过程（需求管理、项目计划、质量保证）已形成可复用的流程规范。
团队成熟度阶段	从 Alpha 阶段的 磨合期 进入 规范期。角色分工明确，协作流程顺畅，有共同的工作规范和文化。
相比前一个里程碑的改进	计划估算更准确（偏差从 ±40% 降至 ±20%）、测试体系更完善、Code Review 更规范、跨角色协作更高效。
最需要改进的一个方面	自动化测试覆盖率的进一步提升。目前单元测试覆盖率约 65%，集成测试仍以手动为主。如果能将自动化集成测试覆盖率提升至 80% 以上，可以大幅降低回归测试的人力成本。

对照敏捷开发原则的评价

敏捷原则	团队表现	具体事例
尽早交付有价值的软件	好	Alpha 阶段按时交付了核心机制闭环和新手体验；Beta 阶段按计划交付了时间机制和第三章。
欢迎需求变化	好	Beta 阶段中期根据测试反馈调整了第三章谜题难度曲线，快速迭代。
频繁交付可工作的软件	好	Alpha + Beta 共两次阶段性发布 + 3 次内部迭代。
业务人员与开发者一起工作	好	PM 蒋渝深入策划一线，同时参与开发讨论，不存在信息断档。
面对面沟通	好	每日站会 + 微信群实时同步，沟通效率高。
可工作的软件是进度的首要度量	好	每个冲刺结束都有可运行的 Demo。
可持续的开发速度	好	Alpha 阶段末期加班较严重；Beta 阶段有明显改善，但第三周仍有赶工。
持续关注技术卓越	好	引入了单元测试、Code Review、CI/CD，并在 Beta 阶段进一步强化。
简单性——最大化未完成工作的艺术	好	有时候会有过度设计的倾向（如第三章对话分支的过度丰富），需要提醒自己"够用就好"。
自组织团队	好	成员在各自领域有充分的自主权，PM 只做协调，不做微观管理。

下一阶段如何提高软件工程的质量？

1. 代码管理的质量：

   • 引入更细粒度的分支策略（如 feature branch + develop + main）
   • 提交信息规范化（采用 Conventional Commits 标准）
   • Code Review 增加结构化检查清单

2. 程序架构的改进：

   • 对时间机制和标签系统的耦合部分进行重构，抽象出更清晰的事件总线
   • 增加架构评审的频率，从每阶段一次改为每月一次

3. 软件工具的应用：

   • 引入 SonarQube 或 Unity 代码分析工具进行静态代码分析
   • 考虑引入可视化回归测试工具

4. 项目管理的改进：

   • 继续保持当前的 Scrum 实践
   • 在计划阶段增加"风险预演"环节

5. 用户数据跟踪：

   • 虽然单机游戏难以跟踪详细数据，但可以通过 Itch.io 的数据分析功能和 QQ 群的人工反馈来了解用户行为
   • 下一阶段可以考虑在游戏中埋入可选的匿名使用数据收集

6. 项目文档的质量：

   • 更新 UML 架构图以反映 Beta 阶段的变更
   • 将所有配置和策划文档统一版本管理

7. 人的领导和管理：

   • 继续保持扁平化的沟通方式和自组织的团队文化
   • 考虑引入轮流主持站会的制度，让每个成员都有机会锻炼领导力

---

后记：从 Alpha 到 Beta，Sephiroth 从一个"有核心机制的原型"成长为了一个"有完整三章内容和深度叙事的可玩制品"。这段旅程中我们踩过坑、加过班、经历过联调的痛苦，也享受过通关时的成就感。正如游戏中那句台词——"影子找到了他的主人"。Sephiroth 也终于找到了属于它自己的样子。