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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习系统的软件工程方法，强化团队协作能力
这个作业在哪个具体方面帮助我实现目标	总结学期课程学习内容及经验

提问回顾与个人总结

项目	内容
提问博客	[I.1] 个人作业：阅读和提问
结对博客	[P] 结对项目：花见小路
团队博客	FruitInc主页

一、对开学时问题的回顾与解答

问题一：在不同业务场景下，“是否按时交付”的评判标准是否应该有所不同？

我现在的理解是：应该有所不同，但“不按时”不能被轻易合理化。

在开学时，我对 PSP 中“稳定、一致的交付时间”有些怀疑，担心它会让探索型项目变得保守。经历结对项目和团队项目后，我发现按时交付本身不是为了束缚创新，而是为了让团队和用户能够建立预期。不同的是，成熟维护型项目更强调承诺的精确性，探索型项目则更适合用时间盒、阶段性原型和可验收的 MVP 来管理不确定性。

结对项目里，T1、T2、T3 的任务边界和测试入口都很明确，所以我们可以用 PSP 表估算、实现、复盘。团队项目 HexaVigil 的 Beta 阶段则复杂得多，新增了九天三幕流程、地图化随机事件、盟约与遗物、Boss、教程、音频和 CI/CD。这个时候如果仍然追求“一开始计划的所有内容都完整做完”，反而会失控。更合理的做法是先保证主循环闭环，再把风险较高的地图生成、敌人寻路、发布构建等内容提前工程化，最后持续修复体验问题。

所以我对这个问题的答案是：按时交付的标准应该结合业务场景调整，但调整的是“交付物的粒度和承诺方式”，不是放弃交付纪律。

问题二：当出现必须立即响应的紧急需求变更时，Scrum Master 该如何抉择？

我现在认为，Scrum Master 不应该简单地在“打断 Sprint”和“完全拒绝变更”之间二选一，而应该建立一个紧急变更的判断和处理流程。

真正需要插入当前 Sprint 的变更，应该满足比较严格的条件，例如：阻塞发布、影响核心流程、造成严重用户损失、合规或安全风险、无法通过临时方案绕过。对于这类变更，Scrum Master 应该先明确它的影响范围，再和团队一起调整 Sprint 目标：要么替换掉等量的低优先级任务，要么拆出最小修复版本，而不是直接把所有新需求塞进当前周期。

在 HexaVigil Beta 阶段，这一点给我的体会很深。比如路线预览与实际敌人移动不一致、教程流程无法顺畅衔接、UI 弹窗不可见、后期性能压力等问题，都比“再加一个新内容”更优先，因为它们会直接破坏玩家的完整体验。团队通过 fix 提交、Issue/PR 和回归测试来处理这些问题，本质上就是在 Sprint 节奏和现实反馈之间做平衡。

因此，Scrum Master 的关键职责不是保护计划本身，而是保护团队对目标的聚焦。

问题三：里程碑应该如何划分？

我现在更倾向于用“可验收的能力增长”划分里程碑，而不是单纯按时间平均切分。

如果里程碑太细，团队会频繁被总结和对齐打断；如果太粗，问题又会积累到后期才爆发。比较合适的里程碑应该满足几个特点：有清晰交付物，有可验证标准，有明确风险收敛目标，并且完成后能支持下一阶段继续开发。

结对项目中，T1 是规则和基础函数，T2 是完整历史局面分析，T3 是能参与对局的策略函数，天然就是逐层递进的里程碑。团队项目中，Alpha 和 Beta 也是不同层次的里程碑：Alpha 关注核心玩法原型，Beta 则要推进到可完整体验、可发布、可回归的版本。Beta 内部又可以拆成“玩法主循环闭环”“地图与敌人系统重构”“表现与内容扩充”“发布与质量修复”等阶段。

这让我意识到，好的里程碑不是日程表上的日期，而是一次可以被验证的系统状态变化。

问题四：如何衡量一位 PM 的能力？如何成为一位优秀的 PM？

开学时我觉得 PM 需要的能力太宽，几乎像“全能角色”。现在我觉得 PM 的能力确实很宽，但衡量时不能只看能力清单，而要看他是否让产品和团队持续朝正确方向前进。

一个 PM 的核心能力至少包括：能不能把真实需求说清楚，能不能排出优先级，能不能把复杂问题拆成可执行任务，能不能发现风险，能不能推动沟通闭环，能不能在范围、质量和时间之间做取舍。不同项目里这些能力权重不同。工具型产品可能更重视需求分析和用户反馈，游戏项目还需要更重视体验节奏、内容完整度和试玩反馈。

HexaVigil 的经历让我看到，项目管理不是写几份文档就结束了。Issue、PR、燃尽图、CI、发布说明、测试报告、文档同步，这些东西共同组成了团队的“协作记忆”。PM 或承担 PM 职责的人，需要让这些信息流动起来，让每个成员知道自己做的事情如何接到主流程里。

我认为优秀 PM 不一定什么都亲自做，但必须让团队少做无意义的事，并尽早发现真正重要的事。

问题五：严格遵守 NABCD 模型是否会限制颠覆性创新的诞生？

我的答案变成了：NABCD 本身不会限制创新，僵硬地使用它才会。

之前我担心 NABCD 过于依赖已有竞品和现有市场，可能不适合从 0 到 1 的产品。但实践后我发现，NABCD 更像是一个逼迫自己说清楚想法的框架。即使是新赛道，也仍然有 Need，只是需求可能还没有被用户明确表达；仍然有 Competitors，只是竞争者可能不是同类产品，而是用户当前的替代方案；仍然需要 Delivery 或 Data，只是早期验证可以是原型试玩、访谈、问卷或小范围灰度。

HexaVigil 就不是简单复刻一个已有塔防。它把随机地图探索、Roguelike 构筑、多波次塔防、地图化随机事件和 Boss 演出组合在一起。这个创意需要想象力，但也需要不断回答：玩家为什么要玩？白天和夜晚的循环是否成立？随机性是否可控？新手是否看得懂？Web 和 Windows 是否能交付？

所以，NABCD 不应该成为创意的刹车，而应该成为创意落地前的压力测试。

二、仍然没有完全弄清楚的问题

原来的五个问题现在都有了阶段性答案，但我觉得仍有两个问题没有完全结束。

第一，PM 能力的量化仍然很难。提交数、Issue 数、会议次数都只能说明一部分工作，不能完全说明一个人是否做出了正确判断。尤其在课程项目中，很多沟通、协调、风险判断很难被仓库记录完整保留下来。

第二，创新和工程化之间的平衡仍然需要继续练习。框架能帮助团队降低风险，但如果过早把想法固定成表格和流程，也可能压缩探索空间。如何判断什么时候应该发散，什么时候应该收敛，是我之后仍想继续学习的问题。

三、新产生的问题

经过一个学期实践，我又产生了几个新问题：

1. 在 AI 辅助开发越来越常见的情况下，团队应该如何区分“工具提高效率”和“个人能力被工具掩盖”？贡献度、代码责任和测试责任应该如何重新定义？
2. 游戏项目的需求不像工具软件那样容易量化，很多体验只能通过试玩感受出来。那么在课程时间有限的情况下，如何设计足够有效的用户测试和反馈收集？
3. 文档经常会滞后于实现。团队应该如何决定哪些文档必须实时维护，哪些文档可以阶段性更新，从而避免文档维护本身变成负担？

四、六个阶段中学到的知识点

阶段	学到的一个知识点	我的理解
需求	需求不是功能清单，而是用户场景和优先级	个人作业中的案例分析让我开始从用户角度看软件。团队项目中，白天运营、夜晚防守、新手教程、Boss 战这些场景，比“新增某个按钮”更能说明真实需求。
设计	模块边界决定后期协作成本	HexaVigil 中 RunState、DataRepo、EventBus 和各类 Manager 的职责划分，让我理解到设计不是画图，而是在提前决定谁拥有数据、谁负责修改、谁只负责展示。
实现	先跑通最小闭环，再逐步优化	结对项目 T3 中，我们先让策略函数能合法出牌，再做加权贪心优化。团队项目也是先保证主循环完整，再扩充事件、遗物、Boss 和 UI 表现。
测试	测试要覆盖用户路径，而不仅是单个函数	课程组测试能验证接口正确，但团队项目还需要 CombatSandbox、headless 测试和人工完整流程测试，才能发现路线预览、教程衔接、UI 层级这类组合问题。
发布	发布是一条可复现流程，不是最后手动打包	Beta 阶段接入 Windows/Web 导出和 itch.io 发布后，我理解到 CI/CD 的意义是降低临近截止时的偶然性，让交付不依赖某个成员本地环境。
维护	技术债要持续偿还，不能只在最后整理	Beta 阶段大量 fix 和文档同步说明，维护不是项目结束后的事情，而是在每次功能落地后持续修复、回归、对齐文档。

五、结合个人作业、结对编程和团队项目的心得

个人作业阶段，我更多是在“看”和“想”。阅读和提问让我意识到，软件工程不是只有写代码，还包括如何评估项目、如何理解用户、如何组织团队。软件案例分析也让我开始从用户体验、缺陷、竞品和改进建议的角度观察一个软件。这个阶段最大的收获是：问题意识很重要，先能提出好问题，后面实践才有方向。

结对编程阶段，我第一次比较集中地体会到“双人协作”对代码质量的影响。花见小路项目从 Wasm 入门，到 T1/T2 的规则解析，再到 T3 的策略函数，任务逐步变复杂。我们在 T3 中先拆出“局势分析”和“出牌策略”两个部分，先实现固定策略，再优化为加权贪心。这个过程让我体会到模块化设计的价值：当策略想要更换时，只需要改一部分代码，而不是推倒重来。结对的另一个收获是，很多状态推断、行动合法性、先后手判断的问题，在讨论中会比单人开发更早暴露出来。

团队项目阶段，感受最深的是“软件工程是为了让多人能够把复杂系统做完”。HexaVigil 的规模已经远超结对项目，地图、敌人、单位、UI、事件、遗物、音频、发布都相互关联。我在 Beta 阶段参与了随机事件地图化、新手教程流程和作弊面板相关工作。随机事件地图化让我看到，一个看似简单的事件弹窗，放到地图探索流程里后，就会牵涉行动力、事件点铺设、地图刷新、结果结算和 UI 展示；新手教程也让我意识到，功能做出来不等于用户会使用。团队项目让我真正理解了为什么要有文档、接口、测试、PR 和 CI，因为这些不是形式，而是降低协作混乱的工具。

回看整个学期，我对“做中学”的理解变得具体了很多。读书时我会把很多概念看成抽象原则，比如 PSP、Scrum、NABCD、里程碑、PM、测试、发布。真正做过项目后，它们变成了一个个具体问题：这周能交付什么？这个需求是不是必须现在做？谁拥有这份数据？这个 bug 怎么复现？这个功能用户看不看得懂？版本怎么交出去？

软件工程最打动我的地方也在这里：它不是让代码变得更复杂，而是让复杂的人、复杂的需求和复杂的系统还能继续往前走。