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

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

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
我们在这个课程的目标是	以团队协作方式完成一款可运行、可迭代、可展示的游戏项目，完整经历需求、设计、开发、测试、发布与复盘流程
这个作业在哪个具体方面帮助我们实现目标	通过事后分析复盘 Alpha 阶段的计划、实现、测试、发布和协作问题，为 Beta 阶段制定改进方案

一、会议基本信息

本次总结会是 Alpha 阶段的 Postmortem 会议。我们参考了邹欣老师《现代软件工程讲义 11 项目管理 - 事后诸葛亮会议》中的模板，围绕“如果历史重来一遍，我们会在哪些地方做得更好”进行讨论。

项目	内容
会议时间	2026 年 5 月 21 日 20:00 - 21:20
会议地点	线上会议 + 群文档同步记录
会议主题	Alpha 阶段复盘与 Beta 阶段改进
参会成员	庞济慷、张恒鑫、李元星、陈文卓、肖钦予、周文康、张泰尔
记录整理	张泰尔

Alpha 阶段我们完成了 T11 测试报告、T12 发布说明、T13 项目展示，也通过团队博客记录了 Scrum Meeting 1-4、CI/CD 实践、功能规格说明书等过程材料。团队主页：https://www.cnblogs.com/CodePorters

二、Alpha 阶段总体结论

Alpha 阶段的结果可以概括为：核心战斗原型初步成立，但还不是完整游戏。

我们实现了 Unity 2D 横版动作 RPG 的基础战斗框架：主角可以移动、跳跃、下落、冲刺、贴墙、墙跳、三段普攻、跳劈、反击和治疗；骷髅敌人可以待机、巡逻、发现玩家、追击、攻击、被反击眩晕和死亡；属性系统已经支持物理伤害、暴击、护甲、闪避和火/冰/雷元素状态。我们也发布了 Windows Alpha Demo，并围绕 Win11、i7 移动端 CPU、16GB 内存环境完成了基础测试。

不足也很明确：UI 还停留在血条、技能树节点和 tooltip 原型；音频尚未完整接入；战斗流程没有形成完整关卡，当前 SampleScene 更像功能测试场。换句话说，Alpha 阶段证明了“动作、敌人、数值能跑起来”，但还没有证明“一个新玩家不需要解释也能顺畅玩下去”。

三、设想和目标

1. 我们的软件要解决什么问题？

我们希望做一款 2D 横版动作 RPG，让玩家在短关卡中体验动作操作和 RPG 成长的结合。项目目标用户是喜欢横版动作、愿意尝试战斗节奏和属性搭配的玩家。

这个目标在功能规格中大体明确，但 Alpha 阶段对“完整战斗流程”的定义还不够细。我们比较清楚要做三段普攻、跳劈、反击、元素状态和技能树，但没有足够早地把这些功能排成一个新手可理解的 5 分钟体验流程。

如果重来一遍，我们会先写一条完整体验脚本：玩家从哪里开始、看到什么提示、遇到第一个敌人时学会什么、什么时候引入反击、什么时候引入元素、最后如何判定胜利。然后再把功能放进这个流程里。

2. 我们达到目标了吗？

部分达到。

原计划目标	Alpha 完成情况	评价
主角基础动作	已完成 idle、move、jump、fall、dash、wall slide、wall jump	达成
基础攻击	已完成三段普攻、跳劈、攻击惯性和伤害判定	达成
敌人战斗	已完成骷髅敌人基础 AI、追击、攻击、眩晕、死亡	达成
属性和元素	已完成物理、暴击、护甲、闪避、火/冰/雷状态	基本达成
UI	完成血条、技能树节点、tooltip 原型	部分达成
音频	完成需求整理和素材选型，未完整接入	未达成
完整关卡流程	只有 SampleScene 功能测试场	未达成
发布与测试	已发布 Alpha Demo，完成测试报告	达成

Alpha 交付时间上基本按课程节点完成。原计划中的“完整战斗流程”和“音频接入”没有完成，主要原因是我们低估了 Unity 场景配置、动画状态机、碰撞层和预制体引用的联调成本。

3. 软件工程质量是否提高？

相比项目初期，软件工程质量有提高，但提高还不均衡。

提高的地方：

• 从零散脚本逐渐整理为 Player、Enemy、General、UI、SkillSystem 等目录。
• 玩家和敌人行为使用状态机拆分，避免所有逻辑堆在一个脚本里。
• 使用 IDamageable、ICounterable 接口抽象受击和反击对象。
• 使用 ScriptableObject 管理技能数据和默认属性。
• 有了测试报告、发布说明、项目展示博客等过程文档。

不足的地方：

• 自动化测试不足，核心伤害结算还主要靠手工测试。
• Code Review 不够严格，部分代码和注释存在编码、命名、拼写问题。
• CI/CD 实践有记录，但还没有形成稳定的 Unity 构建流水线。
• 用户数据和反馈收集比较粗糙，主要依赖内部试玩。

4. 用户量和反馈是否符合预期？

Alpha 阶段没有做公开推广，主要是内部试玩和课堂展示。我们统计了两轮内部试玩，共 18 名同学体验，其中 13 人完成至少 5 分钟试玩，8 人完成“移动、接敌、普攻、受击、击败敌人”的基础流程，5 人尝试了反击或元素状态。

反馈和预期基本一致：玩家认可动作手感和元素系统潜力，但集中指出反击提示不明显、UI 信息不足、音频缺失、关卡目标不清楚。这些问题都不意外，但暴露得比我们预想更集中，说明 Beta 阶段不能继续只堆功能，必须优先做流程和反馈。

四、计划

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

时间有，但计划质量一般。我们在 Alpha 初期完成了模块分工，也通过 Scrum Meeting 1-4 记录进度，但计划更多是“模块列表”，不是“可验收的体验列表”。

例如，“UI 实现”这个任务在分工中存在，但具体到 Alpha 阶段到底要完成属性面板、技能树、血条、存档中的哪些部分，一开始没有拆到足够细。因此后期 UI 只能先做到血条和技能树节点原型。

2. 如何解决计划分歧？

主要通过群讨论和会议同步。分歧集中在“先做更多技能和特效，还是先做完整流程”上。Alpha 阶段我们实际选择了先把战斗核心做起来，这个选择保证了展示时有东西可演示，但也导致流程包装不足。

Beta 阶段我们会把“必须实现”和“可以推迟”的标准写清楚：凡是影响 5 到 8 分钟完整体验的内容优先，单纯增加数量但不改善体验的内容后置。

3. 原计划工作是否都做完？

没有全部做完。完成较好的部分是战斗、动作、敌人、属性、特效和发布；未完成较多的是音频、完整 UI、存档和关卡目标。

主要原因：

• 对 Unity 动画、碰撞、预制体和场景联调工作量估计偏低。
• 模块之间接口确定较晚，UI、音频需要依赖战斗事件，但战斗事件本身在后期才稳定。
• 测试和修复占用了最后几天大量时间。

4. 有没有做了事后看来价值不大的事？

有。我们花了一些时间讨论技能表现和后续装备系统，但这些内容并没有进入 Alpha 版本。现在看，Alpha 阶段更应该把时间用于三件事：新手流程、反击提示、音频反馈。

5. 每项任务是否有清楚交付件？

部分有，部分没有。

战斗模块交付件较清楚：能移动、能攻击、能受击、能击败敌人。测试模块也比较清楚：测试用例、Bug 列表、测试报告。UI、音频和关卡设计的交付件不够清楚，导致后期容易变成“做了设计，但没有合入可运行版本”。

6. 计划中是否留了缓冲？

留得不够。我们原以为 Alpha 后期主要用于整理博客和发布，实际大量时间被用于场景配置、Bug 修复和版本稳定。Beta 阶段需要至少预留 20% 时间作为冻结和回归测试缓冲。

五、资源

1. 资源是否足够？

人力上基本足够，但每个人的 Unity 熟悉程度不同，导致实际产出速度差异较大。资源上，像素素材、动画帧、Tilemap、VFX 足以支撑 Alpha 原型；不足的是音效资源整理和 UI 设计资源。

2. 时间估计精度如何？

偏乐观。代码逻辑本身的估计还可以，但 Unity 项目常见的“脚本写完不等于场景能跑”的问题被低估了。动画事件、LayerMask、碰撞体、Prefab 引用、Inspector 参数都可能让一个功能多花半天到一天。

3. 测试资源是否足够？

Alpha 阶段测试主要靠手工测试，测试同学负责 clone 检查各模块内容、记录问题、推动修复。测试资源对课堂展示足够，但对长期质量不够。T11 中我们记录了 15 个 Bug，修复 10 个，仍有 5 个留到后续版本。

4. 哪些事情可以更有效率地分配？

UI 和音频不应该等战斗逻辑基本完成后才开始接入。即使事件名暂时不稳定，也可以先定义最小事件协议，例如 OnPlayerHit、OnEnemyHit、OnCounterSuccess、OnHeal。这样 UI、音频可以并行做假数据验证，后期只替换数据源。

六、变更管理

1. 成员是否及时知道变更？

大多数时候知道，但记录不够系统。群聊可以快速同步小变更，但很容易被新消息淹没。比如某个攻击状态参数调整后，测试同学未必第一时间知道应该重新测哪部分。

Beta 阶段我们会把变更分成三类：

• 代码结构变更：必须写在 Issue 或 PR 描述中。
• 玩法数值变更：必须同步测试成员。
• 场景/预制体变更：必须附带测试步骤。

2. 如何决定推迟和必须实现？

Alpha 阶段主要靠临近展示时的实际风险判断。比如音频很好，但不接入也不阻塞战斗演示；反击提示不明显，但反击功能可运行；完整关卡目标缺失，但 SampleScene 可以展示核心系统。因此这些被推迟。

Beta 阶段会采用更明确的优先级：

• P0：没有它就不能完成完整体验。
• P1：影响体验质量，但有替代方式。
• P2：锦上添花，可放到 Beta 后。

3. 出口条件是否清晰？

到 T11 测试报告时才变清晰。Alpha 出口条件包括 SampleScene 可启动、主角基础动作可用、至少一种敌人可战斗、基础 UI 可显示、无阻塞 Bug、2 分钟 Demo 连续运行 5 次至少 4 次完整通过。

如果重来一遍，出口条件应该在 Alpha 冲刺第一天就写出来，而不是测试阶段才形成。

4. 是否有应急计划？

有一些临时应急，但不够体系化。比如展示时如果元素状态不稳定，可以只展示物理战斗；如果敌人卡在平台边缘，可以把玩家移动到开阔区域重新引导敌人。这些办法能保展示，但不是工程意义上的风险管理。

七、设计与实现

1. 设计由谁完成，时机是否合适？

战斗和动作设计主要由庞济慷、周文康推进；UI 由李元星设计原型；特效由陈文卓、肖钦予负责；音频由张恒鑫整理需求；测试由张泰尔负责。

动作和敌人状态机设计时机比较合适，较早建立了主框架。UI、音频和关卡流程设计偏晚，导致它们没有充分参与核心闭环。

2. 设计中有哪些模糊问题？

主要有三个：

• 反击到底是技能、动作，还是防御状态？最后实现为 ICounterable 接口和 CounterAttackState，但前期讨论较久。
• 元素状态要做到什么程度？Alpha 最终实现火持续伤害、冰减速、雷蓄积落雷，没有做完整数值 UI。
• 技能树 Alpha 要不要真正影响战斗？最终只做节点原型和 tooltip，没有做完整解锁逻辑。

3. 是否使用测试、UML 或工具帮助设计？

我们在功能规格和技术规格阶段做过设计说明，Alpha 实现中更多依赖 Unity 脚本结构和状态机代码。Unity Test Framework 已在项目依赖中，但自动化用例不足。CI/CD 有实践记录，但还没有变成稳定的 Unity 自动构建。

Beta 阶段应该补两类工具：

• EditMode 测试：覆盖伤害、暴击、元素抗性、闪避等纯逻辑。
• PlayMode 测试：覆盖玩家攻击敌人、敌人死亡、状态切换等场景流程。

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

Bug 最多的是战斗联动和状态切换。原因是它牵涉输入、动画、刚体、碰撞、敌人状态、伤害结算和 VFX。T11 记录的 Bug 中，连续普攻输入丢失、受击击退方向、冲刺撞墙、敌人卡平台、反击提示不足都属于这个范围。

根因不是单个脚本写错，而是跨模块协作复杂。Beta 阶段需要把战斗事件和状态切换规则文档化，让 UI、音频、测试都能围绕同一套事件工作。

5. Code Review 是否严格？

不够严格。Alpha 阶段更多是“能跑优先”，代码复审以组内口头检查和测试反馈为主。问题包括部分注释编码异常、命名拼写不统一、Inspector 参数依赖说明不足。

Beta 阶段至少做到：

• 合并前说明改动影响范围。
• 核心战斗脚本必须由另一名成员阅读。
• 新增状态类必须写清进入条件、退出条件和动画触发器。
• 修改预制体或场景时附带验证步骤。

八、测试与发布

1. 是否有测试计划？

有。T11 测试报告中整理了测试计划、测试矩阵、场景测试、测试用例和 Alpha 出口条件。测试重点包括主角控制、战斗系统、敌人系统、属性系统、元素系统、UI、场景与资源。

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

进行了简化版验收测试。标准是：Windows 11、i7 移动端 CPU、16GB 内存环境下，SampleScene 能启动，主角基础动作可用，骷髅敌人可战斗，血条和技能节点可显示，固定 2 分钟 Demo 连续运行 5 次至少 4 次完整通过。

3. 是否有测试工具？

目前主要是手工测试，辅以 Unity Editor Play Mode 调试。Unity Test Framework 已接入但测试用例不足。Beta 阶段需要把伤害计算、元素状态、敌人状态切换做成可重复的自动化测试。

4. 发布过程中有哪些意外？

发布过程暴露了两个问题：

• 发布包需要保持 RPG demo.exe、Data 目录、UnityPlayer.dll、MonoBleedingEdge 在同一文件夹内，说明安装说明必须写清楚。
• 课堂展示和 GitHub Pages 发布说明不等于正式产品发布，用户仍可能误以为这是完整游戏，所以发布说明中必须强调 Alpha Demo 的限制。

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

1. 角色确定是否合理？

基本合理。分工如下：

成员	Alpha 角色	复盘评价
庞济慷	战斗设计、主角动作实现	承担核心闭环，工作量最大，后续需要更早释放接口给 UI/音频
张恒鑫	音频/音效	完成需求和素材选型，但接入较晚，Beta 需提前并行
李元星	UI 实现	完成血条、技能树节点、tooltip 原型，Beta 需推进完整属性面板
陈文卓	Shader/特效	完成 URP 2D、受击、命中、暴击和元素效果方案
肖钦予	Shader/特效	协助资源整理、背景视差和场景氛围
周文康	动作技能设计	设计技能表和动作逻辑，协助调试攻击与反击
张泰尔	测试	完成测试报告、Bug 记录和展示稳定性检查

2. 成员之间是否互相帮助？

有。战斗模块完成后，特效和 UI 都围绕战斗事件补充；测试同学在后期帮助定位预制体、碰撞层和动画触发器问题；动作和技能设计也多次回到代码里调参数。

3. 感谢记录

成员	感谢
庞济慷	感谢张泰尔在最后阶段反复测试战斗流程，帮助发现状态切换和展示稳定性问题
张恒鑫	感谢庞济慷说明战斗事件触发点，让音频模块能明确后续接入位置
李元星	感谢陈文卓和肖钦予提供特效和美术资源，帮助 UI 原型更容易融入场景
陈文卓	感谢周文康提供技能表现需求，使特效调试有明确目标
肖钦予	感谢李元星同步 UI 需求，方便场景和界面风格保持一致
周文康	感谢庞济慷把动作设计落到可运行状态机中，让技能设计能被验证
张泰尔	感谢所有成员及时响应测试反馈，保证 Alpha Demo 能在展示前稳定运行

十、团队状态总结

1. CMM/CMMI 阶段判断

我们认为团队目前接近 CMMI 2 级“已管理级”的初期：有分工、有版本、有测试报告、有发布说明、有 Scrum 记录，但过程管理还不够稳定，很多规范依赖成员自觉，没有完全制度化。

2. 团队处于哪个阶段？

团队处于“磨合”向“规范”过渡的阶段。我们已经能把核心功能做出来并发布 Demo，但模块接口、Code Review、自动化测试、变更记录还不够规范。

3. 相比前一个里程碑有什么改进？

相比功能规格说明阶段，Alpha 阶段最大的改进是项目从文档进入了可运行状态。我们不再只是描述玩法，而是通过实际代码验证了主角动作、敌人 AI、属性系统、元素状态、基础 UI 和发布流程。

4. 目前最需要改进的方面

最需要改进的是“以完整用户流程为中心组织开发”。Alpha 阶段我们按模块推进，导致每个模块都有一些成果，但组合起来还不够像完整体验。Beta 阶段应该先定义体验路线，再拆任务。

十一、对照敏捷开发原则

我们做得较好的敏捷原则：

1. 经常交付可工作的软件。
   Alpha 阶段我们不是只写文档，而是发布了 Windows Demo，并通过 T11、T12、T13 博客分别完成测试、发布、展示。

2. 业务人员和开发人员必须相互合作。
   在我们项目中，动作技能设计、战斗实现、特效、UI 和测试之间频繁对接。例如反击、跳劈、元素状态都需要策划、开发、特效和测试一起确认。

3. 可工作的软件是进度的首要度量标准。
   Scrum Meeting 中我们逐渐从“完成了哪些脚本”转向“SampleScene 能不能跑通”“Demo 能不能展示”。这让后期决策更现实。

4. 定期反思如何提高效率。
   通过 Scrum Meeting、T11 测试报告、T13 展示总结和本次 Postmortem，我们已经开始把问题归因到流程，而不是只归因到某个人或某个 Bug。

做得不够好的敏捷原则：

• 对变化的响应还不够体系化。变更经常通过群聊同步，没有统一记录。
• 持续集成不足。T10 做了 CI/CD 实践，但 Unity 项目的自动构建和测试还没有稳定运行。
• 简洁性不足。Alpha 阶段讨论过一些不进入当前版本的功能，分散了注意力。

十二、下一阶段如何提高软件工程质量

1. 代码管理质量

• 建立 PR 模板：说明改动范围、测试步骤、影响模块。
• 核心战斗脚本必须至少一人 Review。
• 命名和注释统一为 UTF-8，修复乱码注释。
• 修改场景或预制体时必须说明涉及的对象和 Inspector 参数。

2. 架构质量

• 把战斗事件抽象为统一事件接口，供 UI、音频、特效使用。
• 将属性系统的纯逻辑部分与 MonoBehaviour 解耦，方便自动化测试。
• 梳理玩家和敌人状态机文档，明确每个状态的进入条件、退出条件、动画触发器和可打断规则。

3. 工具应用

• 使用 Unity Test Framework 增加 EditMode 和 PlayMode 测试。
• 推进 GitHub Actions 或 Unity Cloud Build，至少做到构建检查。
• 使用 Issues 管理 Bug 和 Beta 任务，避免任务散落在群聊中。

4. 项目管理

• Beta 阶段第一天写清楚出口条件。
• 每个任务必须有交付件和验收方式。
• 每周至少一次同步风险清单。
• 冻结展示版本前至少预留 20% 时间做回归测试。

5. 用户数据跟踪

• 记录试玩人数、完成基础流程人数、完成关卡人数、失败点、平均游玩时长。
• 简单统计玩家是否使用反击、治疗、元素状态。
• 收集 3 到 5 条高质量文字反馈，而不是只问“好不好玩”。

6. 文档质量

• 更新功能规格说明书：补充 Beta 阶段完整关卡流程和 UI 需求。
• 更新技术规格说明书：补充事件系统、状态机、测试方案。
• 保持发布说明、测试报告和已知问题同步。

7. 人的管理

• PM 更早明确优先级，避免每个人都在做“看起来有用但不一定进版本”的事情。
• 模块负责人要主动暴露风险，不等到最后两天才说接不进去。
• 对测试反馈建立响应规则：P0 当天处理，P1 两天内给结论，P2 进入 backlog。

十三、Beta 阶段改进清单

如果只有三票，我们投给以下三项：

1. 完整战斗流程：设计并实现 5 到 8 分钟教学关卡，包含移动、战斗、反击、元素和阶段性挑战。
2. UI 和音频反馈：补齐属性面板、技能说明、伤害/状态提示、攻击/受击/反击/治疗音效。
3. 自动化测试和构建：为伤害结算、元素状态、敌人死亡、基础构建流程增加自动化检查。

这三项分别对应用户体验、反馈质量和工程质量。Beta 阶段如果能把它们做好，项目就能从“Alpha 功能原型”向“可独立试玩的关卡 Demo”推进一步。