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

项目 内容
这个作业属于哪个课程 2025年春季软件工程
这个作业的要求在哪里 [T.13] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是 学习现代软件构建的工程方法，锻炼团队协作能力。在团队的共同合作下产出符合流程的高质量软件。
这个作业在哪个具体方面帮助我实现目标 对我们团队在Alpha阶段的开发进行系统的总结和复盘，为Beta阶段进行预热。

一、设想和目标

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

    我们在开发伊始便确定了游戏的定位与目标，是为碎片化时间的用户打造一款轻快、玩法新颖、能够进行联机游戏的轻策略游戏。我们清晰定义了典型用户（例如休闲玩家阿杰）以及围绕用户的典型场景，并通过玩家画像进行测试驱动。

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

  • Alpha阶段我们的核心功能进行了全覆盖：包括抽卡、羁绊、单位召唤、2~4人房间等；
  • Alpha 版本按时交付，具备可运行、可测试、可反馈的完整功能；
  • 通过相应的宣传以及试玩，在Alpha公测期间玩家最多时在20人左右，比预想要相对弱。

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

    公测阶段，超半数玩家对于玩法的整体认可度较高。但在用户量以及实际公测的结果来看，依然存在一些问题亟待解决。虽然在玩法上已经大幅降低了难度，但是仍有部分玩家反映上手难的问题，这与我们在新手引导方面的不足有关。同时部分 UI 与平衡性问题被频繁提及，表明我们距理想状态还有提升空间。

    在用户量上，经团队讨论后认为玩法以及UI是限制的主要因素。

    因此我们在复盘会上仔细讨论了每个问题的解决方案，力求在Beta阶段达到更近的目标。

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

​ 我们提出的用户解决方案并不总是能够满足大多数用户，因此和用户共同改进是必要的。此外初期缺乏完整 引导设计等，新手上手体验不足。

​ 如果历史重来一遍，我们会在开发过程中即和用户进行接触，及时改进。

二、计划

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

​ 有。因为大多数团队成员对于Unity等游戏开发工具是第一次接触，因此有必要留充足的时间进行计划。

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

​ 汇总后，由 PM 召集讨论，采用投票+目标共识解决分歧。

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

​ 没有完全做完。

​ 因为团队成员在开发前半部分，一是有其他事情急需完成，另外由于对Unity等工具的不熟练，前期进度是较 慢的。因此我们在不影响最终交付以及不明显降低用户体验的前提下，对部分卡牌、特效的实现进行了削 减。但这是为了保证最终按时交付的必要决策

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

​ 最初设计的特殊卡牌机制，实际公测下来认为较为鸡肋。

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

​ 均在飞书上有明确的定义。衡量的交付件以测试结果为准。

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

​ 并非完全按计划进行。例如我们虽然计划的较为完善，但是没有全面考虑成员的实际情况导致前期的进度较 慢。我们采取了两个方式来进行补救：

​ ① 在不影响最终交付以及不明显降低用户体验的前提下，削减部分工作。

​ ② 我们在开发阶段末期，组织了2-3天的集中开发。这极大的提高了我们的开发效率，也是保证我们按时交付 的直接原因。

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

​ 我们将测试周的前半部分用于缓冲周，即五一假期间。这段时间有专人值守，用于修复紧急bug与收尾测试， 极大缓解交付压力。

  1. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    我们制定的计划要同时考虑到团队成员本身的情况，同时制定合理的预案。集中开发可以进一步扩展到隔天 进行，以进一步交流，提高效率。

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

  • 计划不是静态文档，而是随实际情况调整的动态流程；

  • 团队效率的核心是“沟通+理解”，光有分工远远不够；

  • 与其一次到位做完所有内容，不如阶段性交付、持续完善。

​ 如果重新来过，我们会：

  • 更早建立测试用例与自动验证机制，节省后期回归人力；
  • 更积极利用周会进行阶段性复盘，避免方向性偏移。

三、资源

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

​ 整体而言，团队资源基本满足项目开发需求。开发人力配置合理，后端、前端、策划、测试、UI 各职能均有 明确负责成员。在图形设计与美术资源方面也有专人负责，但是由于美术工作量较大以及要求较高，导致部 分界面细节与美术效果未能按原设计落地。

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

​ 初期任务估时以开发总负责人过往项目经验与开发者与PM的主观判断为基础。非代码类任务估算偏差较小， 但对卡牌开发以及Bug修复的复杂度明显低估，实际耗时为预估的1.5~2 倍。

  1. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  • 我们安排了 2 名测试（每名开发也要自主测试）进行功能验证，基本覆盖所有功能分支；
  • 测试设备涵盖 macOS、Windows主流操作系统，不同配置设备，保证兼容性测试的充分性；
  • 美工、文案工作由专人承担，但部分 UI 占位图延迟替换、卡牌描述临时补写，影响部分体验。
  1. 你有没有感到你做的事情可以让别人来做（更有效率）?

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

  1. 有没有什么经验教训?如果历史重来一遍我们会做什么改进？
  • 后续项目中需对非开发任务（美术、文案）进行资源与工时独立规划，不能简单归入“开发类任务”中；
  • 对于关键非功能性模块（如 UI/UX），应提前确认责任分工与验收时间点，确保用户体验稳定。

四、变更管理

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

​ 是的。我们通过微信群作为主要沟通平台，并配合飞书文档、看板工具同步任务状态。每次功能修改或任务 变更后，PM 会在群内进行“变更播报”，必要时在会议上重点强调，确保信息传达到所有相关人员。

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

​ 团队以“影响用户体验 + 对主流程耦合度”为核心评估标准。任何非关键、不影响首局体验的功能（如部分卡牌 机制、界面装饰）可延期处理；涉及玩法闭环、联机稳定性等的功能则列为“必须实现”。最终决策由 PM 与开 发负责人主导，参考开发的优先级评估。

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

​ 是的，我们对 Alpha 阶段出口条件设立了评估维度，包括功能完成度、系统稳定性、Bug 闭环情况、文档与 可用性验证，均具备可验证的判断标准。

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

​ 能。

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

​ 大部分时候可以。但是意料之外的工作请求基本交由空闲或相对能完成的人员进行。

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

​ 中途变更若未文档化，容易出现“理解偏差”与“重复劳动”。

​ 如果重来一遍，我们考虑引入正式的“变更申请”流程，每次调整记录版本、责任人、变更理由与影响评估。

五、设计/实现

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

​ 项目初期，由制作人符悦牵头完成游戏系统与核心架构的初步设计，包括战斗引擎、回合控制与卡牌管理逻 辑。该阶段选择的技术栈与架构方向较为清晰，能够较好支撑功能扩展。

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

​ 关于卡牌的数值模型我们进行了多次的争论与调整，最后通过多次会议讨论敲定。

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

​ 进行了单元测试，是以游戏功能进行的单元区分。对于测试与稳定是有效的。

  1. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  • 房间系统（联机逻辑）：因为涉及多人状态同步与并发控制，初期设计考虑不周导致频繁出现“房间锁死”“掉线判定不准确”等 Bug；
  • 卡牌召唤逻辑：由于召唤条件受多项因素影响（等级、金币、场上单位数等），出现多种“召唤失败无提示”“卡牌无响应”等问题。
  1. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

​ 团队采用 GitHub PR 流程，每次合并需至少 1 人审核。我们定义了基本代码规范，对于核心模块（如战斗逻 辑、房间控制）还安排了多人交叉 Review。

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

​ 我们意识到，架构设计初期越清晰，越能减少中后期返工。

​ 如果重新来过，我们会对所有主功能组件设计阶段配套完整的 UML 图与交互流程文档，降低沟通成本。

六、测试/发布

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

​ 我们制定了完整的 Alpha 阶段测试计划，测试覆盖了功能流程测试、场景测试、平台兼容性测试和边界异常 测试，并由测试人员负责测试矩阵的记录与追踪。

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

​ 是的。每次版本发布前，安排 2~3 名成员进行模拟用户对局，检验功能链是否通畅。测试人员根据反馈更新 I Issue，由专人限时修复。

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

​ 目前以人工测试为主，搭配开发日志打印与状态复现工具，尚未引入自动化测试框架。我们计划在 Beta 阶段 引入 Unity Test Framework，实现对卡牌逻辑、召唤流程、房间同步等模块的自动验证。

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

使用 GitHub Action 在每次 Pull Request 时触发构建 + 基本回归测试脚本。

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

    我们在房间并发 4 人对战、召唤密集单位情况下进行稳定性验证。这些测试非常有用，测出了很多Bug。但是对于测试来说耗时相对多了。可以考虑进行一些基本的自动测试辅助。

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

​ macOS 构建包首次发布时漏打资源文件，导致部分设备无法启动。

  1. 我们学到了什么?如果历史重来一遍我们会做什么改进？
  • 缺乏 CI/CD 流程支持导致打包测试耦合在个人设备中，未来需引入云构建与标准验证流程。
  • 更早引入自动化测试工具，提升回归效率。

八、团队角色、管理、工作

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

​ 我们秉持由成员自荐。每位成员都对自己擅长的部分进行了阐述。同时我们鼓励挑战，不少成员希望跳出舒 适圈，尝试以前没有试过的工作。整体来看，人岗匹配度较高，成员专长得到良好发挥。

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

​ 团队内部配合默契，尤其在 UI 接口、卡牌设计、测试执行等多角色协作频繁的环节中表现突出。策划与开发 之间常就技能描述、效果平衡进行多轮沟通，测试也在 bug 提交后积极跟进验证。集中开发期间，成员自发 分组对卡牌内容补充、代码梳理、UI 素材修复，展现出高度协同效率。

  1. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
  • 日常沟通问题：微信群即时沟通，PM 每日复盘是否有遗漏或歧义；
  • 决策性争议：会议达成共识；
  • 人员资源冲突：动态调整任务权重，临时调配支持协作人手。

九、总结

  1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

​ 定义级

  1. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

​ 创造

  1. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

​ 大家越来越放得开，效率也就越来越高了。

  1. 你觉得目前最需要改进的一个方面是什么?

​ 目前最需要改进的是自动化测试与持续集成机制*。Alpha 阶段的测试以人工测试为主，较为繁琐；同时缺乏 基础的 CI/CD 管道，使得版本验证、兼容性测试与部署流程存在人为耦合与效率瓶颈。

  1. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
  • "通过工作的软件衡量进展"：每一轮迭代交付可运行版本；
  • "团队内部频繁沟通"：借助微信群+线下集中开发保持高频协作；
  • "响应变化胜过遵循计划"：根据测试反馈快速调整部分卡牌机制和技能描述设计；
  • "以人为本，构建有激励的团队"：每位成员都参与核心模块，贡献突出，积极主动推动任务完成。
  1. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

​ 在程序质量上，提升代码清晰度、结构可维护性、增加测试验证机制；在工程质量上，建立完善的计划-执行- 回顾流程、工具链标准化、任务协作更加明确化。

  1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
  • 引入代码格式化工具；
  • 严格执行 PR 模式，增加“强制多人 Code Review”机制；
  1. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
  • 拆分卡牌逻辑、UI 控制器与状态管理逻辑，建立事件驱动与状态机系统；
  • 重构目标以“减少代码重复”“简化调用链”为衡量指标，采用函数复杂度、文件耦合度进行对比评估。
  1. 其它软件工具的应用，应该如何提高？
  • 使用 Unity Test Framework 进行核心逻辑单元测试；
  • 使用 GitHub Actions 实现基本构建流程检查；
  • 使用 Notion 或飞书搭建产品 Wiki 与研发记录系统。
  1. 项目管理有哪些具体的提高？
  • 每次迭代开始前进行 Sprint 计划会，明确目标与任务分解；
  • 采用燃尽图持续追踪进度；
  • 设置里程碑提交日与阶段验收节点，便于团队自检。
  1. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
  • 为每位玩家生成匿名 UID，记录启动、对战、退出等关键事件；
  • 增加对战日志统计模块，上传至云端或本地保存用于分析；
  • 使用简单脚本统计每日活跃、对战频次、常用卡牌分布。
  1. 项目文档的质量如何提高？

  • 所有模块文档遵循统一格式模板；

  • 区分“开发者文档”“测试文档”“用户帮助”三种角色维度文档类型。

  1. 对于人的领导和管理， 有什么具体可以改进的地方？
  • 引入任务贡献度记录机制，建立更清晰的角色责任体系；
  • 加强中期复盘与阶段总结会议，增强预警机制；
  1. 对于软件工程的理论，规律有什么心得体会或不同意见？

​ 我们体会到软件工程的本质并不是“如何写好代码”，而是“如何组织人高效地写出可持续演进的代码”。 需求总 是动态的，用户总是多样的，唯有良好的工程机制和团队协作模式，才能构建真正有生命力的产品。

十、讨论照片

posted @ 2025-05-18 23:53  杰后余生  阅读(45)  评论(0)    收藏  举报