ddl战士———alpha阶段问题总结随笔

ddl战士 2025-11-09 19:14:00

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——事后诸葛亮
这个作业的目标	alpha阶段问题总结
其他参考文献	《构建之法》、Google Style Guides

一、设想和目标
1. 核心问题与反思
2. 经验教训与改进
二、计划
1. 核心问题与反思
2. 经验教训与改进
三、资源
1. 核心问题与反思
2. 经验教训与改进
四、变更管理
1. 核心问题与反思
2. 经验教训与改进
五、设计 / 实现
1. 核心问题与反思
2. 经验教训与改进
六、测试 / 发布
1. 核心问题与反思
2. 经验教训与改进
七、AI 技术员工作实例分析
1. 核心应用实例与贡献
2. 存在的问题与局限
3. 经验教训与改进方向
总结
1. 团队当前状态
2. 核心改进方向

一、设想和目标

1. 核心问题与反思

软件解决的问题定义：基本清晰，但聚焦不足
我们明确了 “打造 2D 洞穴主题动作游戏” 的核心目标，拆分了玩家、敌人、攻击等模块，但初期对 “典型用户与场景” 描述不够细致（如未明确 “新手玩家”“熟练玩家” 的操作习惯差异），导致部分功能适配失衡 —— 比如精英敌人攻击节奏初期未考虑新手玩家的反应时间，仅设置 0.2 秒攻击间隔差，玩家难以感知强度区别，后期才将普通敌人攻击间隔从 2 秒调整至 2.5 秒，精英敌人从 3 秒调整至 3.5 秒。此外，初期想覆盖的元素攻击（火 / 冰 / 雷 / 风）、技能类型（火球术 / DashStab / 连招）较多，分散了开发精力，导致雷元素连锁攻击范围打磨不够充分，初期仅 2 米，无法覆盖密集敌人场景。
计划时间：充足，但利用效率不均
冲刺前预留了 6 天时间，整体周期充足，但前 2 天团队存在 “摸索期”—— 陈志豪不熟悉 Unity 的 A * 路径规划插件，胡定赟对 UI 多分辨率适配逻辑不熟练，汪涛在 Git 分支管理上出现冲突，导致基础功能开发进度滞后，后期靠压缩优化时间追赶，部分 UI 细节（如背包 “99+” 文字间距）未能彻底完善。
不同意见解决：依赖默契，缺乏规范流程
团队遇到分歧（如攻击判定范围大小）时，主要通过每日站立会讨论 + 模块负责人拍板解决，虽效率较高，但缺乏 “投票 + 记录” 的规范流程。例如 Day3 讨论 “攻击盒半径设 0.3f 还是 0.4f” 时，许晓镔（中途接替张天荣负责攻击模块）认为 0.3f 精准，汪涛提出 0.4f 更适配新手，最终因汪涛负责测试，采纳了 0.4f 的建议，但未记录分歧点，导致后期联调时攻击盒与敌人碰撞体适配不佳，需重新调整。

2. 经验教训与改进

下次冲刺前，需明确 “核心目标 + 次要目标”，聚焦 2-3 个核心玩法（如战斗体验、探索引导），将元素攻击限定为 3 种以内，避免功能蔓延；
提前 1 天开展 “用户场景研讨会”，明确典型用户（新手 / 熟练玩家）的操作习惯，形成《场景适配清单》，例如 “新手玩家：攻击判定范围扩大、敌人攻击节奏放缓”，指导功能设计；
建立 “分歧决策流程”：重要问题（如数值平衡）采用 “3 分钟阐述 + 投票” 机制，少数意见记录归档，便于后期复盘，避免 “拍板式” 决策导致的适配问题。

二、计划

1. 核心问题与反思

原计划工作完成情况：核心功能完成，优化功能未全落地
玩家移动、敌人 AI、攻击技能等核心功能按计划完成，但 “技能连招成就”“地图隐藏区域引导” 等优化功能因前期进度滞后未实现；未完成的核心原因是 “任务优先级未明确”，初期未区分 “必须实现” 和 “可选优化”，导致莫馥玮在开发 DashStab 技能时，同时兼顾连招提示和成就系统，精力分散。
无效工作：存在重复开发与过早优化
部分模块存在重复工作，比如汪涛在玩家模块中写了碰撞检测逻辑，许晓镔（接替张天荣）在攻击模块中又重新编写，未提前规划复用；还有 “过早优化” 问题，如陈志豪初期花 2 小时调整敌人巡逻路径的平滑度，后期因追击逻辑变更（添加 “超出范围返回原点”），该优化失去意义。
任务交付件：定义模糊，联调成本高
多数任务仅明确 “实现 XX 功能”，未定义具体交付件。例如 “攻击模块需实现元素攻击”，未明确 “交付攻击判定范围文档 + 3 条测试用例”，导致联调时发现攻击盒大小与敌人碰撞体（半径 0.3f）不匹配，许晓镔需重新调整攻击盒半径至 0.4f，浪费 1 小时。
计划执行与缓冲区：整体按进度，缓冲区作用显著但分配不均
每日站立会同步进度，整体按计划推进；预留的 2 天缓冲区（Day5-6）用于修复 Bug（如技能穿透、UI 适配），有效避免了核心功能带病上线，但缓冲区分配不均，前期未预留模块联调时间，导致 Day3-4 联调时出现拥堵 —— 攻击模块需配合敌人模块验证伤害判定，同时配合 UI 模块同步伤害数字，许晓镔需同时对接陈志豪和胡定赟，进度延误。

2. 经验教训与改进

采用 “MoSCoW 优先级法” 划分任务：Must（必须实现）、Should（应该实现）、Could（可以实现）、Won’t（暂不实现），明确每个任务的交付标准（如 “敌人模块交付件：AI 脚本 + 数值配置表 + 测试用例 3 条”）；
冲刺前开展 “功能复用规划会”，梳理可复用逻辑（如碰撞检测、状态管理），指定汪涛开发通用工具类，避免重复工作；
调整缓冲区分配：将 6 天冲刺分为 “核心开发（3 天）+ 联调（1 天）+ 优化 Bug（2 天）”，提前预留联调时间，减少后期拥堵。

三、资源

1. 核心问题与反思

资源充足性：编程资源均衡，测试与非编程资源不足
6 名成员分管 6 大模块，编程资源充足，但测试资源过度依赖汪涛一人，导致部分模块（如地图碰撞）测试覆盖不全，后期才发现 “窄道卡角色” 的问题 —— 阮航宇在开发地图时未测试窄道场景，汪涛因同时负责玩家模块测试，未覆盖该场景；非编程资源（美术图标、音效）低估难度，胡定赟初期使用低像素技能图标，后期需重新制作 2 倍尺寸图标，浪费 3 小时。
时间估计精度：核心功能偏差小，优化与联调偏差大
核心功能（如玩家移动、敌人巡逻）时间估计较准确（误差 ±1 小时），但优化功能（如 UI 平滑过渡）和联调时间估计不足（原计划 1 天联调，实际用了 1.5 天），原因是未预判 “模块衔接问题” 的数量 —— 攻击模块的伤害判定与敌人模块的血量计算逻辑冲突、UI 模块的血条更新与玩家模块的血量同步延迟，均需额外时间调试。
资源复用：存在 “专人专事” 但缺乏 “能力互补”
每个模块由专人负责，但未培养备份人员，比如阮航宇负责地图模块时生病，导致地图碰撞层修复延迟 1 天；部分简单工作（如数值配置、文档整理）可由多人分担，但未明确分配，导致模块负责人负担过重 —— 陈志豪在开发敌人 AI 的同时，还要整理掉落物数值表，影响核心逻辑开发效率。

2. 经验教训与改进

建立 “测试分工表”：除专职测试外，每个模块负责人需承担本模块的单元测试，提交 “测试用例 + 测试报告”，确保测试覆盖全面；
提前 1 周规划非编程资源：明确美术、音效的交付时间和标准（如 “技能图标需提供 256256px、512512px 两种尺寸”），避免后期返工；
实行 “模块备份制”：每个模块指定 1 名备份人员，参与核心逻辑讨论，确保负责人临时缺席时能无缝衔接；简单工作（如文档、配置）拆分给时间相对充裕的成员，平衡工作量。

四、变更管理

1. 核心问题与反思

变更通知：及时但缺乏书面记录
冲刺中的功能变更（如攻击判定优先级调整为 “攻击盒→SphereCast”）通过每日站立会口头通知，虽及时但无书面记录，后期莫馥玮在开发技能连招时，忘记该变更，导致技能攻击判定与普通攻击冲突，需重新调整逻辑。
功能优先级决策：民主但效率偏低
遇到 “是否推迟连招提示功能” 这类问题时，团队讨论时间过长（约 20 分钟），缺乏明确的决策标准。有人认为连招提示提升体验，有人认为开发成本高，最终因进度紧张推迟，但浪费了大量时间。
出口条件：定义模糊，“做好了” 无明确标准
对于 “攻击模块做好了” 的定义仅为 “能造成伤害”，未明确 “判定准确率≥95%、无重复伤害” 等量化标准，导致后期测试时发现大量细节问题 —— 攻击盒与 SphereCast 检测范围重叠，出现重复伤害，许晓镔需重新规划判定逻辑。
应急计划与意外请求：缺乏预案，被动应对
遇到 “技能穿透敌人”“敌人追击迷路” 等意外问题时，无应急计划，只能临时暂停其他工作调试。例如 Day4 发现火球术穿透敌人，莫馥玮需暂停 DashStab 开发，优先修复碰撞层过滤逻辑，影响整体进度；对于用户潜在需求（如多玩家适配）的临时请求，缺乏过滤机制，导致阮航宇花时间调研联机方案，精力分散。
角色变更处理不规范
冲刺中途发生核心角色变更：攻击模块负责人由张天荣更换为许晓镔，但该变更仅通过口头通知，未制定书面交接文档，也未开展知识传递。许晓镔接手后，对攻击模块前期的判定逻辑（如攻击盒锚点位置、元素伤害计算规则）不熟悉，需重新梳理代码，导致攻击模块进度延误 0.5 天；同时因未同步攻击模块的历史变更记录（如攻击判定优先级调整），许晓镔在联调时误将 SphereCast 检测范围与攻击盒重叠，引发重复伤害 Bug。

2. 经验教训与改进

建立 “变更记录文档”：每次变更（含功能变更、角色变更）均记录 “变更内容、原因、影响模块、生效时间、交接人员”，同步至团队群，确保全员知晓；
制定 “功能优先级决策矩阵”：从 “用户体验影响度、开发成本、是否核心玩法” 三个维度打分，总分≥10 分必须实现，否则推迟，缩短讨论时间；
明确各模块出口条件：采用量化标准（如 “UI 模块：多分辨率适配无遮挡、按钮响应延迟≤0.1 秒”），完成后需通过 2 名成员交叉验证；
设立 “意外请求过滤机制”：所有临时请求需由 PM 统一接收，评估影响后再分配，避免盲目响应；
规范角色变更流程：角色变更时需输出 “交接文档”（含模块核心逻辑、未完成任务、待解决问题），组织 1 小时专项交接会议，确保接手人员快速上手。

五、设计 / 实现

1. 核心问题与反思

设计时机与人员：部分设计过早，人员适配不足
初期过早讨论 UI 细节（如血条颜色、按钮尺寸），胡定赟花 1 小时确定血条颜色为渐变绿→黄→红，后期因功能变更（添加受击闪烁效果），需重新调整颜色参数；敌人 AI 的路径规划设计由陈志豪独立完成，未征求测试人员汪涛意见，导致追击迷路问题未提前预判 —— 陈志豪设计的 “超出巡逻范围 10 秒返回” 逻辑，未考虑地形阻挡，敌人易卡在障碍物后。
模棱两可问题：缺乏统一标准，靠经验调试
对于 “攻击盒大小”“敌人追击范围” 这类模棱两可的问题，团队无统一标准，靠开发人员经验调试。例如许晓镔将攻击盒半径设为 0.4f，陈志豪设计的敌人碰撞体半径为 0.3f，联调时出现 “攻击盒覆盖敌人但未触发伤害” 的适配问题，原因是攻击盒锚点与敌人碰撞体中心未对齐，需重新调整锚点位置。
工具使用：单元测试覆盖率低，缺乏自动化工具
仅玩家模块和攻击模块使用了少量单元测试，其他模块（如敌人 AI、技能系统）未使用，导致后期 Bug 较多（如敌人 AI 的追击绕路）；未使用 UML 等设计工具，模块间接口定义不清晰，莫馥玮开发的技能模块需调用玩家模块的 MP 数值，但未明确接口参数（如 MP 消耗计算方式），导致 MP 消耗异常（基础消耗为 0 时未兜底）。
Bug 集中功能与代码复审：敌人 AI 和技能系统 Bug 最多，复审流于形式
敌人 AI 因涉及路径规划、状态切换，Bug 数量占比约 40%，原因是逻辑复杂且未充分测试 —— 陈志豪在开发 “返回原点” 逻辑时，未考虑 “中途遇到玩家重新追击” 的场景，导致路径计算重复绕路；代码复审前期较严格，后期因进度紧张，变成 “口头确认”，例如莫馥玮提交 DashStab 技能代码时，仅口头告知许晓镔 “已完成”，许晓镔未仔细检查代码，导致斜向冲刺距离不均（正向 2 米，斜向 1.5 米）。

2. 经验教训与改进

调整设计顺序：先完成核心逻辑设计（如攻击判定规则、AI 状态机），再进行 UI、音效等细节设计；重要设计需组织跨模块讨论，征求开发、测试人员意见；
制定 “技术标准文档”：明确攻击盒大小、追击范围等关键参数的参考标准（如 “近战攻击盒半径 0.4f±0.05f”“敌人追击范围≤15 米”），减少经验依赖；
强制要求单元测试：核心模块（敌人 AI、攻击、技能）的单元测试覆盖率≥60%，使用 Unity Test Framework 工具，提前发现逻辑 Bug；重要模块使用 UML 绘制类图、时序图，明确接口参数；
规范代码复审：采用 “书面复审 + 口头沟通” 模式，复审人员需填写 “复审清单”（如是否符合代码规范、是否有性能隐患），确保复审不流于形式。

六、测试 / 发布

1. 核心问题与反思

测试计划：有框架但缺乏细节
制定了 “全流程测试” 的框架，但未细分 “单元测试、集成测试、压力测试” 的具体内容，导致测试时存在遗漏。例如未测试 “连续释放 10 次 Dash 技能” 的场景，汪涛在 Day5 压力测试时才发现 “角色移动速度累积加速”（从 5m/s 增至 6.2m/s），需紧急修复。
验收测试：非正式，缺乏量化指标
验收测试仅为 “团队成员玩一遍”，未明确 “通关成功率、帧率稳定性” 等量化指标，导致发布前未发现 “20 + 敌人混战时帧率降至 45fps” 的问题 —— 汪涛仅测试了 5 个敌人的场景，未覆盖高负载场景。
测试工具：单一，缺乏自动化支持
仅使用 Unity 自带的调试工具，无自动化测试工具，重复测试（如每次修改攻击逻辑后需手动测试 10 次）浪费时间；未使用性能分析工具，帧率问题的根源定位耗时较长 —— 汪涛花 1 小时才排查出帧率下降是因敌人尸体未及时销毁，内存占用过高。
发布意外：无明显问题，但潜在风险未排除
发布过程顺利，但后期模拟多玩家场景时发现 “恢复泉水多玩家使用时效果叠加” 的潜在问题 —— 阮航宇开发时未考虑多玩家并发，未添加冷却机制，导致 2 名玩家同时触发时恢复量翻倍，违背设计预期。

2. 经验教训与改进

细化测试计划：拆分 “单元测试（模块负责人）、集成测试（联调人员）、压力测试（专职测试）”，明确每个阶段的测试用例（如压力测试：20 + 敌人混战、连续释放 10 次技能）；
制定量化验收标准：明确 “核心功能无致命 Bug、帧率≥55fps、通关成功率≥90%” 等指标，未达标则需继续优化；
引入辅助测试工具：使用 Unity Performance Profiler 分析帧率问题，引入简单的自动化测试脚本（如自动测试攻击判定准确率），减少重复工作；
增加 “多场景测试”：覆盖单玩家、多玩家、高负载、极端操作（如连续按攻击键）等场景，提前排除潜在风险。

七、AI 技术员工作实例分析

Alpha 阶段，AI 技术员作为辅助工具深度参与开发，但未形成标准化使用流程，其应用场景、贡献与问题如下：

1. 核心应用实例与贡献

实例 1：代码模板生成（技能模块 / 攻击模块）
莫馥玮开发 DashStab 技能的碰撞检测逻辑时，AI 生成了基于 Unity2D 的连续碰撞检测代码模板，包含OnTriggerEnter2D回调、碰撞层过滤逻辑，莫馥玮仅需调整参数（如检测层设为 Enemy），节省了 1.5 小时编码时间；许晓镔（接替张天荣）开发雷元素连锁攻击时，AI 生成了OverlapCircleAll检测代码模板，帮助快速实现范围伤害判定，核心贡献是降低重复编码成本，让开发人员聚焦核心逻辑优化。
实例 2：Bug 排查辅助（敌人 AI / 玩家模块）
陈志豪遇到 “敌人追击迷路” 问题时，AI 通过分析ReturnToPatrolOrigin逻辑，提示 “未重置路径点导致重复绕路”，引导陈志豪在重新触发返回时清空原路径点，10 分钟内定位问题根源；汪涛排查 “Dash 技能累积加速” 时，AI 提示 “临时速度变量未重置”，帮助快速找到tempSpeedBonus未在冲刺结束后清零的问题，核心贡献是缩短复杂逻辑的 Bug 排查时间，提供新的分析视角。
实例 3：文档与注释生成（UI 模块 / 地图模块）
胡定赟完成背包 UI“99+” 功能后，AI 生成了功能说明文档，包含参数配置（字号 12 号、间距 8px）、适配场景（720p-2K），减少了文档编写时间；阮航宇开发恢复泉水时，AI 为HealPlayer函数补全了详细注释，说明参数含义（如healAmount为最大生命值的 10%），核心贡献是提升代码可读性，降低后期维护成本。

2. 存在的问题与局限

代码准确性不足：AI 生成的碰撞检测代码未考虑 “斜向冲刺时的速度归一化”，导致莫馥玮初期未发现 DashStab 斜向冲刺距离不均的问题，需后期手动优化；
场景适配不足：AI 生成的文档未覆盖多玩家场景，阮航宇未意识到恢复泉水需要多玩家冷却机制，导致后期出现效果叠加 Bug；
过度依赖人工校验：AI 生成的代码和文档均需人工逐一校验，例如 AI 生成的攻击判定范围文档中，数值单位错误（将像素误写为米），需许晓镔手动修正。

3. 经验教训与改进方向

明确 AI 使用边界：AI 仅用于生成代码模板、Bug 排查思路、文档初稿，核心逻辑（如数值平衡、路径规划算法）需人工开发，避免直接使用未验证的 AI 代码；
建立 AI 输出校验流程：AI 生成的内容需由模块负责人 + 1 名交叉验证人员共同审核，重点校验参数准确性、场景适配性，例如 AI 生成的碰撞代码需验证不同方向冲刺的效果；
积累项目专属 Prompt：针对游戏开发场景，整理专属 Prompt（如 “Unity2D 敌人 AI 路径规划代码，需包含追击、返回原点、地形阻挡处理”），提升 AI 输出的精准度。

总结

1. 团队当前状态

CMM/CMMI 档次：处于 CMM1（初始级）向 CMM2（可重复级）过渡阶段，核心流程（如开发、测试）已形成框架，但缺乏标准化、量化的管理体系；
团队发展阶段：从 “磨合阶段” 进入 “规范阶段”，成员间协作默契提升，但部分流程（如代码复审、变更管理，尤其是角色变更）仍需规范；
相比前期改进：从 “各自为战” 转变为 “模块化协作”，每日站立会、Git 版本管理等机制有效落地，核心功能交付能力显著提升；
最需改进的方面：变更管理的标准化—— 包括功能变更、角色变更的书面记录、交接流程，这是避免信息断层、减少联调冲突的关键。