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

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

项目	内容
这个作业属于哪个课程	作业 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[T.17] 团队项目：Beta 阶段发布说明 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	通过学习软件工程理论与敏捷开发实践，熟悉产品从立项到交付的全流程，提升团队协作与工程开发经验。
这个作业在哪个具体方面帮助我实现目标	事后分析总结，总结团队在开发过程中遇到困难时克服的经验以及收获的成长经历，为后续的实际软件开发工作总结经验。

团队分工：

成员	角色/职责
庞济慷	PM，程序
陈文卓	程序
张泰尔	动作设计
李元星	UI设计
周文康	属性系统
张恒鑫	音频模块
肖钦予	技能设计

---

一、设想和目标

1. 我们的软件要解决什么问题？
要解决的是传统动作 RPG 游戏中“前期战斗策略单调、后期装备同质化、流派构建缺乏深度”的问题。

典型用户是追求操作上限的“硬核动作游戏玩家”和热衷养成的“RPG 收集型玩家”。他希望在一个游戏中完成：

• 体验 0.1 秒的极限弹反机制与流畅的连招；
• 通过丰富的技能树搭配多形态法术（如追踪、瞬移、时间回溯）；
• 刷取带有随机词缀属性的装备，进行深度的 Build 构建；

这个目标在 Alpha 版本之后已经非常清晰。Beta 阶段的重点是补齐 Alpha 暴露出的痛点：重构战斗判定解决手感问题、实装复杂的技能演变、完善装备词缀库以及打通稳定的后端云存档功能。

2. 我们达到目标了吗？
总体上达到了 Beta 阶段目标。
本次 Beta 版本不仅重构了底层战斗逻辑，还修复了此前收到的 72 个 Bug。核心功能已经完成并通过了严格的场景与性能测试。

功能目标完成情况：

目标	完成情况
极限弹反机制	已完成，支持 0.1 秒完美招架及硬直处决
法术流派系统	已完成，引入追踪、瞬移与时间回溯技能升级
数据驱动装备库	已完成，实现随机 Modifier 词缀与属性加成
视听与 UI 优化	已完成，修复死亡 UI 死锁，引入多场景自适应

3. 软件工程质量是否提高？
相比 Alpha 阶段，软件工程质量有明显提升。
可量化事实：

• 集中测试阶段共发现并修复 72 个 Bug。
• Crash 与 Severe 级别严重 Bug 修复率达 100%。
• 同屏高压场景下（20 怪 + Boss + 满特效）稳定 60FPS。
• P0/P1 级自动化与手工测试用例执行通过率 100%。

质量提升点：
需求管理通过明确的 Issue Tracker 驱动；状态机锁彻底解决了方法循环调用；物理层级的严谨划分杜绝了判定的相互干扰。
不足之处： 音频并发播放时暂未实装同帧剔除机制，部分复杂的连招组合依然依赖手工测试。

4. 用户量和用户接受程度
从展示阶段及内部反馈看，玩家对于 0.1 秒极限弹反和技能树深度给出了极高的评价，它们切实满足了硬核玩家的“秀操作”心理和刷子玩家的“变强”心理。

---

二、计划

1. 是否有充足时间做计划？
有。Beta 开始时团队制定了详细的规划，技能节点树拓展、底层状态机重构和最终测试回归的时间。
问题在于对部分“底层战斗框架重构”的时间估计偏乐观，比如解决技能特效碰撞与弹反判定的冲突耗费了比预期更多的时间。

2. 如何解决计划阶段的不同意见？
主要通过例会和需求讨论对齐。PM 根据玩家核心痛点定下优先级。
冲突最多的是“再多加几个关卡/怪物”还是“深挖现有战斗机制深度”。最终团队选择“把核心战斗链路做扎实”，专心实装弹反、技能演化和随机词缀，不盲目铺量。

3. 原计划工作是否都做完？
核心计划已经完成。未完全充分的是针对断网环境的离线模式兼容过渡，以及前端部分音效调度的极致优化。

4. 有没有事后看来价值不大的工作？
部分早期针对低级怪物行为树（AI）的死磕价值不大。当玩家后期解锁了“多重施法”和“瞬移碎片”等降维打击能力后，低级怪物的微操 AI 根本没有表现空间，这部分精力应更多转移给机制型 Boss 设计。

5. 是否每项任务都有清楚交付件？
比 Alpha 好很多。有明确的《功能规格说明书》、《测试报告》以及包含测试用例、Bug 分布、测试矩阵的具体归档，不再是“口头验收”。

6. 项目是否按计划进行？
整体按计划进行，但后期联调波动较大。比如“DeathBoss 技能结算时的乘区数据溢出”和“玩家自身技能触发弹反误判”，都是在多个子系统融合测试时才集中爆发的。

7. 缓冲区是否有作用？
极其关键。Beta 发布前预留的黑盒验收与压测缓冲区，成功拦截了会导致内存溢出的恶性 Bug，如果没有缓冲区，这将会变成一场灾难。

8. 如果重来，计划会怎么改？

• 更早在底层统一规划 LayerMask，不把碰撞过滤留到写业务逻辑时才发现不对劲；
• 提前压测 Audio 模块的并发承受力；

---

三、资源

1. 资源是否足够？
总体足够，但分布存在波峰。在梳理底层判定与属性乘区时，动作设计（张泰尔）、程序（陈文卓）和属性系统（周文康）的配合密度极高；而发布前 UI 适配（李元星）和音效对接（张恒鑫）的压力也高度集中。

2. 时间估计精度如何？
UI 界面和基础 CRUD 逻辑耗时估计较准；但在涉及高频交互事件和技能多态演化（肖钦予）时的耗时偏低。因为动作游戏里的难点往往不是“写出这个技能”，而是“处理技能被打断、穿插、并发时的无数种异常态”。

3. 测试资源是否足够？
基于真实用户画像设计的场景手工测试很充分，但自动化代码覆盖率不足。当前对核心系统稳定性的保障还有很大一部分依赖人工肉眼观察。

4. 哪些事可以更高效分配？
部分数值平衡性测试可以通过配置“自动打怪 GM 脚本”来挂机收集统计数据，而不是让人工一遍遍刷 DeathBoss 来测算乘区是否溢出。

---

四、变更管理

1. 变更消息是否及时同步？
主要通过 Issue Tracker 和 PR 代码审核同步。比如修改了 Player_Health 的死亡状态锁或更正了伤害加算/乘算公式，都会在对应的 Issue 中及时告知相关开发者。

2. 如何决定推迟和必须实现？
判断标准：

• 是否直接引起游戏 Crash 或严重影响核心闭环？
• 是否影响 Beta 版本的硬性出口条件？
  因此，死亡死锁、数值离谱溢出、后端同步失败被列为必须修复；而多重飞剑带来的同帧音频爆音属于表现瑕疵，作为 Known Issue 推迟修复。

3. 出口条件是否清晰？
非常清晰。包含：核心机制用例 100% 达标；Zero Critical Bugs（清零所有严重以上缺陷）；20个怪+Boss同屏稳定 60FPS；云存档同步率 > 99%。

---

五、设计与实现

1. 设计工作何时由谁完成？
PM（庞济慷）主导需求与跨端设计；各模块由负责人攻坚：张泰尔把控动作帧与弹反手感，陈文卓搞定核心状态机，周文康搭建词缀数据底座，肖钦予构建衍生技能树，张恒鑫和李元星负责视听与 UI 呈现。跨模块功能大家共同敲定接口。

2. 是否遇到模棱两可？
遇到了。典型如：“脱下加血装备时，角色属性应不应该实时掉血？”“弹反的 0.1 秒究竟判定在攻击帧还是受击帧？”
最后团队通过规范化生命周期函数和引入明确的 ICounterable 接口协议，将模糊的口头讨论变成了严谨的代码契约。

3. 是否使用单元测试、UML 或工具辅助？
使用了 Unity Profiler 分析内存与帧数，使用网络抓包和弱网模拟器测试后端。虽然没有画庞大的 UML，但我们严格依赖组件化设计和接口解耦。

4. 什么功能 Bug 最多？
多系统并发联动的 Bug 最多。
典型的比如：在冲刺（Dash 无敌状态）碰上 DeathBoss 技能导致的判定锁死；法术碎片追踪自身判定成“弹反对象”的乌龙。动作游戏里的并发状态管理永远是重灾区。

---

六、测试与发布

1. 是否有测试计划？
有。我们制定了详尽的《测试矩阵》，覆盖了 Windows/macOS、高低配硬件测试、手柄/键鼠输入容错。

2. 是否有测试工具？
依赖内部的黑盒手工用例、性能监测仪和后端压测工具。下一步还需要补齐更多自动化集成测试工具。

3. 如何跟踪性能？
记录极限压测下的帧时间与内存变化，通过 2小时以上的满负载挂机排查内存泄漏，最终确保稳定在 60 帧以上。

4. 发布中发现哪些意外？
意外通常发生在真实玩家复杂的操作手癖中。比如疯狂重置死亡、以及在极限帧率下触发的视听特效错位。这些也让我们更加认识到黑盒灰度测试的必要性。

---

七、团队角色、管理与合作

团队角色与成员的专业优势非常契合：

• 我们感谢 陈文卓 (程序)，他理清了乱麻般的底层状态机，解决了致死死锁难题；
• 我们感谢 张泰尔 (动作设计)，打磨出了拳拳到肉、刀刀见血的极爽 0.1 秒弹反体验；
• 我们感谢 李元星 (UI设计)，为庞大且复杂的词缀库和多分支天赋树做出了优雅且不凌乱的交互界面；
• 我们感谢 周文康 (属性系统)，搭建了稳固又极具拓展性的数据驱动装备库，让后期的 Build 百花齐放；
• 我们感谢 张恒鑫 (音频模块)，精细的音频对象池调度为激烈的打斗带来了充满震撼的视听反馈；
• 我们感谢 肖钦予 (技能设计)，时间回溯和法术追踪的天才设计，让游戏的策略上限获得了质的飞跃；
• 我们感谢 庞济慷 (PM/程序)，在统筹整个项目进度的同时，协调解决各项难题，打通了游戏闭环。

团队遇到进度冲突时，坚决以保证“核心体验”为最高准则。

---

八、总体评价

1. CMM/CMMI 档次判断
大约在 CMMI 2 级到 3 级之间：我们有了可靠的 Issue 跟踪、结构化的测试用例、明确的退出门槛和文档积累，但量化管理和自动化验证还需要进一步沉淀。

2. 团队阶段判断
团队已从 Alpha 的“能跑就行”步入“规范成熟阶段”。大家懂得了用状态锁、契约接口、性能指标和出口条件来约束开发，而不是走一步看一步。

3. 相比前一个里程碑的改进

• 战斗从单调的打带跑升级为了高风险高回报的弹反博弈；
• 技能与装备不再是数值叠加，而是流派层面的组合；
• 数据安全通过云端同步得到了彻底解决；
• 消灭了上一版本各种闪退的恶性体验。

4. 最需要改进的一方面
自动化测试。对于动作 RPG 而言，依靠人工去覆盖所有技能与环境排列组合是不现实的，后续亟需增加底层逻辑的自动化测试保障。

---

九、对照敏捷原则

做得较好的原则：

• 可工作的软件是首要度量：一切评估都以最终能否在 60 帧下流畅体验核心连段为准；
• 业务人员与开发者合作：动作、技能、程序模块的同事频繁对齐判定逻辑；
• 响应变化：针对 Alpha 测试反馈的战斗单一问题，果断投入重构动作与技能树系统。

做得还不够的原则：

• 节奏把控仍有优化空间，后期性能排雷压力较大；
• 持续集成的自动化验证还相对薄弱。

---

十、下一阶段改进计划

1. 底层重构：优化高频音频事件的同帧剔除算法（解决爆音）。
2. 测试强化：引入 Unity Test Framework 编写 PlayMode 自动化测试，验证各技能触发器的边界。
3. 性能深挖：针对技能乱战极度消耗渲染性能的问题，深入打磨对象池并优化 DrawCall。
4. 离线体验：实装完整的无网络单机游玩模式，优化重新联网时的无缝同步策略。
5. 体验打磨：丰富后续 Boss 的行为逻辑树，以匹配玩家不断成长的强大技能。

---

十一、结语

Beta 阶段不仅是游戏战斗表现的一次飞跃，更是我们团队软件工程素养的升华。功能和画面上的惊艳只是冰山一角，真正托起这座冰山的，是底层状态机的重构、LayerMask 的精细划分、防丢失的云端管线以及那一张张详实的测试矩阵表。

这段充满挑战的研发旅程让我们深刻体会到：优秀的动作反馈，绝非仅仅依靠设计的巧思，更离不开软件工程上的一丝不苟。因为踩过的这些坑， 从一个有着酷炫想法的 Demo，真正长成了一款硬核、稳定且极具深度的 2D 动作游戏。期待在未来更完善的版本中与大家相见！