[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	I.3 个人作业：结课总结
我在这个课程的目标	提升团队协作能力，项目管理能力；学会编写一个完整软件项目的技能，为职业发展打下坚实基础；培养批判性思维和解决复杂工程问题的能力。
这个作业在哪个具体方面帮助我实现目标	总结在课程中学到的技能和方法

一、对曾经提出问题的解答

在学期初的 I.1 阅读与提问 作业中，我提出了五个问题。经过一个学期的"做中学"，我有了新的理解。

问题一：PSP的"自我记录"如何避免成为形式主义的过场？

我的解答：在结对项目中，我和搭档真实地使用了 PSP 表格来记录计划耗时与实际耗时。我的体会是：PSP 的价值不在于数据的绝对精确，而在于记录行为本身带来的反思。当看到自己预估的 60 分钟任务实际花了 120 分钟时，这种"认知偏差"本身就是最有价值的反馈。关于"修饰数据"的问题，我认为 PSP 的定位应是自我改进工具而非绩效考核工具——当数据只用于自己的复盘而非上级评价时，造假就失去了动机。在团队中我们可以建立一种"无责备"的文化，让时间记录真正服务于过程改进，而不是作为追责的依据。

问题二：如果"用户并不需要产品"，NABCD的Need该如何捕捉？

我的解答：在团队项目 Sephiroth 的策划过程中，我对这个问题有了切身的体会。我们选择的是一款强调"数值守恒 + 标签系统"的科幻推理 RPG——这个创意本身就属于"用户说不出来"的类型。没有用户会说"我希望有一款能剥离物体标签的游戏"。我们的做法是：不依赖用户的直接表述，而是观察用户在现有产品中的行为模式和未被满足的深层需求。例如，通过分析解谜游戏玩家的共同痛点（"RPG 同质化严重"、"解谜缺乏系统性"），我们推导出"通过理解规则来掌控世界"的深层次需求。同时，我们在 Itch.io 发布 Demo 后，通过真实用户的下载量（首日 32 次 Downloads）和反馈来验证需求是否真实存在。这让我认识到，颠覆性创新的"Need"不是被"发现"的，而是被构建的——团队基于对用户和领域的深刻理解，通过 prototypes 和用户反馈的迭代循环来逐步确认。

问题三：代码复审时，面对"风格问题"与"逻辑问题"，应如何分配精力？

我的解答：在团队项目中，我们严格执行了 Code Review 制度。我的体会是：复审的重点应根据项目阶段动态调整。在 Alpha 阶段初期，代码风格的一致性更重要——因为团队成员初次合作，如果没有统一的规范，后续的代码将变得难以维护。我们在初期花时间制定了 C# 编码规范，并在 Review 中严格执行。而在 Beta 阶段末期（临近发布），复审的重点则转向了逻辑正确性和边界条件——因为风格已趋于一致，此时任何逻辑 Bug 都可能导致发布延迟。另外，我发现使用自动化工具（如 CI 流水线中的静态分析）可以有效分担"风格问题"的检查负担，让代码复审者能将精力集中在更有价值的逻辑问题上。

问题四：如何从"写了再改"的模式过渡到"有流程"的开发？

我的解答：这个问题的答案，我在团队项目中亲身经历了。从"写了再改"到"有流程"的过渡，最有效的策略不是一步到位，而是渐进引入。我们的做法是：先引入一两个"低垂果实"——比如 Issue 管理和分支规范。在版本控制上机作业（BUAASE2026-TeamVersionControl）中，我们实际演练了 Git 的分支策略、Code Review 流程和 PR 合并规范。这些基础的流程约束给团队带来了立竿见影的效果：代码冲突减少了、合并更顺畅了。在此基础上，我们逐步引入了每日站会、看板管理（Backlog → Ready → In Progress → Review → Done）、Sprint 规划等更高级的实践。最重要的是，流程不是为了限制人，而是为了帮助人——当团队成员亲身体验到流程带来的好处（如不再担心合入冲突、Bug 能被及时追踪），对流程的接受度自然会提高。

问题五：测试人员应该在什么时候介入？不同阶段怎么介入？

我的解答：团队项目的经历让我深刻理解了"测试人员从项目开始就要积极介入"的含义。在 Sephiroth 项目中，测试同学在 Alpha 阶段初期就参与了需求评审和架构设计讨论。他在开发阶段就编写了单元测试（Unity Test Framework），覆盖了标签系统和数值守恒系统的核心逻辑。这让我认识到：测试人员早期介入的价值不在于"提前写测试用例"，而在于以测试思维参与设计评审，从源头发现问题。例如，在讨论时间机制的设计方案时，测试同学提出的"边界条件"问题让架构设计更加健壮。当然，需求变更确实会导致测试用例需要调整——但这不是"浪费"，而是测试用例自然演化的代价，远比在项目后期发现重大缺陷的代价小得多。

二、原来不明白的问题

在经历了一个学期的实践后，我原来的问题都已经有了不同程度的理解和解答。如果说还有不明白的地方，那就是关于PSP 在团队协作层面的应用：我理解了 PSP 作为个人工具的用途，但如何在团队层面（比如 6 人团队）有效汇总和利用 PSP 数据来改进团队流程，仍然缺乏实践经验。这可能是一个需要在更长周期、更大规模的团队中才能深入体会的话题。

三、新产生的问题

在课程项目结束后，我产生了以下新问题：

1. 游戏开发中的"玩法创新"与"工程规范"如何平衡？ 在 Sephiroth 的开发中，我们经常面临"探索性玩法原型"和"规范化工程流程"之间的张力——创新的玩法需要快速试错，而工程规范要求严谨的设计先行。如何在保证创新活力的同时维持工程质量的底线？

2. 对于单机游戏这类"用户使用数据难以回收"的产品，敏捷开发的反馈循环如何有效建立？ 在课程中，我们通过 Itch.io 的下载数据和 QQ 群的用户反馈来获取信息，但这与互联网产品的实时数据分析相去甚远。对于这类产品，有没有更系统化的方法来建立用户反馈闭环？

3. "做中学"的教学模式中，如何保证"学"的深度不被"做"的紧迫性所挤压？ 在课程的高强度实践中，有时为了追赶进度，我会不自觉地跳过一些重要的理论学习环节，优先保证代码能跑通。这种"实用主义"倾向虽然高效，但可能会影响对软件工程原则的深层理解。

四、各阶段学到的知识点

软件工程涵盖需求、设计、实现、测试、发布、维护六个阶段，在每个阶段中我都有具体的收获。

需求阶段：

在《第四轴（Sephiroth）》的选题过程中，我们团队完整地实践了 NABCD 需求分析框架。我们不仅分析了市场痛点（RPG 同质化、解谜缺乏系统性），还做了详细的竞品分析（对比《Baba Is You》《Outer Wilds》《极乐迪斯科》等），最终明确了我们的核心差异化优势。最关键的知识点在于：需求不是凭空想出来的，而是通过系统化的竞争分析和对目标用户的深刻理解推导出来的。我们的三张用户画像（硬核科幻爱好者、规则驱动型解谜玩家、剧情导向型独立游戏玩家）贯穿了整个开发周期，帮助团队在做功能取舍时始终有据可依。

设计阶段：

在技术规格说明书中，我们设计了清晰的 MVC 三层架构。通过 Unity 引擎的实际开发，我真正理解了分层设计的价值：Model 层（EntityData、TagContainer 等）独立于视图和控制器，使得我们可以为标签系统、数值守恒系统编写独立的单元测试；View 层与 Controller 层的分离让美术同学可以并行开发 UI 而不会阻塞后端开发。此外，UML 类图在架构对齐中发挥了重要作用——我们在上机作业（lab2）中练习了根据代码逆向生成 UML 类图，又在团队项目中从 UML 出发指导代码实现。设计阶段的核心知识点是：好的架构设计的标志不是"完美"而是"可并行"——让团队成员能够尽可能地独立工作而互不阻塞。

实现阶段：

在 Beta 阶段实现时间机制时，我深刻体会到了接口契约的重要性。时间机制需要与标签系统、数值守恒系统、存档系统等多个模块交互。开发同学在实现前共同定义了接口，然后分头实现——但在联调时仍然遇到了意料之外的集成问题。这让我认识到：接口契约不仅要定义"输入输出"，还要定义状态转换的边界条件，最好配合接口测试来确保双方的理解一致。另一个学到的知识点是渐进式重构：我们没有一次性重写所有代码来适应新机制，而是通过"时间轴状态快照"的方式，在保持 Alpha 阶段代码稳定的同时引入了新功能。

测试阶段：

在测试阶段，我们不仅做了常规的单元测试和集成测试，还做了一个让我印象深刻的实践："逃课路径"测试。测试同学不仅仅是验证"正常流程能否通过"，还主动尝试各种非常规的玩法组合——比如在第一章中不按引导顺序操作、在第三章中跳过部分调查直接指认。这种测试思维对于游戏开发尤为重要，因为玩家的行为是不可预测的。另一个知识点是测试金字塔的实际应用：单元测试（覆盖核心逻辑）→ 集成测试（跨模块交互）→ 手动场景测试（用户体验），每一层都有其不可替代的价值。我们通过 Unity Test Framework 实现了自动化单元测试（覆盖率约 65%），通过手动测试覆盖了 UI 交互和用户体验。

发布阶段：

在 Alpha 和 Beta 两次发布中，我学到了发布检查清单（Release Checklist）的重要性。Alpha 阶段发布时，我们遇到了一些意外问题（如 Mac 端不兼容、资源打包遗漏），这些经验在 Beta 阶段被系统化为一份发布检查清单——涵盖构建配置、资源引用、版本号、跨平台适配、宣发物料等多个维度。Beta 阶段还实践了"预发布（Dry Run）"策略：在正式发布前先进行一次完整的构建-部署-验收流程，确保所有环节无误后再对外发布。这有效避免了 Alpha 阶段"发布后发现资源缺失"的尴尬。

维护阶段：

通过 Alpha 到 Beta 的迭代，我学到了用户反馈驱动的维护策略。Alpha 发布后，我们通过 Itch.io 的用户评价和 QQ 群的反馈，识别出三个核心痛点：缺少新手引导、物品获取无反馈、没有小地图。这些反馈被系统化地转化为 Beta 阶段的开发任务（优先级定为 Must have），并设置了可量化的验收标准（如"10 分钟内核心机制理解率达 90%+"）。维护不仅仅是在修复 Bug，更重要的是倾听用户的声音，让产品在对用户有价值的方向上持续演进。

五、个人项目/结对编程/团队项目的心得体会

个人项目：

上机作业（lab1~lab4）虽然规模不大，但每一个都针对性地训练了不同的能力：lab1 的 EPP 训练了个人编程规范，lab2 的 UML 类图训练了设计表达能力，lab3 的 Java 编程训练了在给定框架下实现复杂逻辑的能力，lab4 的项目运行训练了环境配置和调试能力。个人项目的价值在于：在没有队友可以依赖的情况下，你必须独立解决每一个问题——这迫使你真正理解每一行代码的含义，而不是依赖他人的"代码补全"。

结对编程：

结对项目（花见小路 WebAssembly）是让我印象最深刻的经历。我和搭档从零开始学习 AssemblyScript 和 WebAssembly，在限时 12 小时的条件下完成了一个完整的游戏 AI 模块。最让我受益的是结对编程的"导航员-驾驶员"模式：当我作为"驾驶员"编写代码时，搭档作为"导航员"可以即时发现逻辑错误和风格问题——这比事后 Code Review 的效率高得多。在 Debug 环节，两个人的思维互补更是发挥了巨大作用，往往我一个人盯着代码半小时找不到的 Bug，搭档一眼就能看出来。结对过程中我们也有分歧，比如在选择算法策略时（贪心 vs 搜索），通过讨论和快速原型来验证各自的方案，最终选择了更优的解法。结对编程教会我：好的代码不是一个人写出来的，而是两个人"讨论"出来的。

团队项目：

团队项目 Sephiroth 是这学期最具挑战性也最有收获的经历。作为团队的 PM（项目经理）兼策划，我负责排期、风险跟踪、任务调度、例会组织和剧情设计。以下是我最深的三点体会：

1. 计划的重要性与局限性

Alpha 阶段我们对工作量过于乐观，导致最后需要集体加班赶工。Beta 阶段吸取教训，计划更加务实，预留了缓冲区，工时偏差从 ±40% 缩小到 ±20%。我认识到：计划不是一成不变的蓝图，而是一个需要持续校准的指南针。每日站会和每周例会的价值不在于"汇报进度"，而在于"及时发现问题并调整航向"。

2. 沟通是项目的"隐形基础设施"

6 个人的团队，沟通成本远高于 2 人结对。我们通过微信群（日常同步）、每日站会（进度对齐）、共享文档（任务看板）、Issue（任务追踪）等多种渠道来保持信息通畅。作为 PM，我学到的最重要的事情是：不要让信息在传递过程中失真——关键决策要做会议记录，任务分配要落实到具体人和具体时间。

3. 从"做出来"到"做得好"

Alpha 阶段的目标是"让核心机制可玩"，Beta 阶段的目标是"让游戏体验完整"。从 Alpha 到 Beta 的转变中，我体会到软件工程的真正挑战不是"把功能做出来"，而是"把产品做好"。新手引导、物品反馈、小地图——这些看起来"不酷"的功能，恰恰是决定用户体验的关键。一个软件产品的品质，往往体现在那些用户可能注意不到、但缺失了会感到不适的细节中。

总结

一个学期下来，我从"只会写代码的学生"成长为"理解软件工程流程的开发者"。我学会了如何做需求分析（NABCD）、如何设计架构（MVC）、如何管理版本（Git）、如何保证质量（测试金字塔、Code Review）、如何发布和维护（用户反馈驱动迭代）。但我最大的收获是：软件工程不是一系列教条，而是一套经过实践检验的思维方式——它教会你如何在不确定性中做决策，如何在约束条件下寻找最优解，如何与他人协作创造比个人能力之和更大的价值。

Sephiroth 中有一句台词："影子找到了他的主人。"我想说，这个学期的软件工程课程，让我找到了属于我自己的"软件工程思维"。