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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13465
我在这个课程的目标是	掌握软件工程方法，提升团队协作开发能力
这个作业在哪个具体方面帮助我实现目标

提问博客🔗

I.1 个人作业：阅读和提问

提问回顾

问题1：如何判断订单任务拆分粒度是否合适？

通过一个学期的项目实践和对敏捷流程的学习，我逐渐意识到，任务拆分粒度并没有绝对的标准，而是一个需要在实践中持续优化的问题。尤其对于依赖复杂、需求模糊的底层模块，评估其粒度本身就很有挑战性。在我们的团队项目中，由于对Unity不够熟练，因此我们先整体预估工作量并按模块分配给成员，再由各自进行更细致的拆分。这种方式虽然略显粗糙，但在实践中较为有效。
我们也发现，有些任务在拆得过细后，受限于依赖关系或突发问题，反而更容易出错。我们也有借助 GitHub Issues 等敏捷工具，及时识别任务拆分是否合理，进行动态调整。
尽管如此，目前仍难以系统性地判断拆分是否合适。我也产生了新的思考：是否存在可以量化任务不确定性的工具或实践，比如通过历史数据分析任务变动频率，辅助判断是否应进一步拆解。

问题2：项目需求生存期是否具有普适性

项目实践和相关案例阅读让我认识到，“18个月需求生存期”更像是一个对快速变化市场的提醒，而非放之四海而皆准的定律。在互联网产品中，需求确实迭代迅速；但政务、科研等领域的项目，其生命周期则远超18个月。

问题3：PM的技能是否应以牺牲技术深度为代价

这个问题在项目中感触最深。我们的PM角色最初偏重文档写作和计划安排，但在实际过程中我们发现，不懂技术的PM难以准确评估任务风险与进度。因此，我们的PM依旧参与了部分技术实现。虽然不够深入，但依旧行之有效。我意识到，PM 不需要具备深厚的技术能力，只要能理解系统架构与关键路径，就足以完成沟通协作工作。

问题4：RASCI模型是否存在职责模糊嫌疑？

我们实践中没有使用RASCI模型，然而，通过搜集资料发现，有些公司会通过设置任务完成的“依赖说明”字段，明确需要哪些支持，要求S角色确认并签字，才有效果。另一个有效的做法是在每周例会中明确“阻塞任务”与负责人，确保 R 与 S 的任务协同可视化、可追溯。

问题5：如何防止公开冲突走向另一极端？

在我们的团队中，冲突多数是在例会（Scrum Meeting）中讨论的，通常围绕公共内容或轻度分歧，例如任务优先级等。但当涉及设计理念分歧或潜在人际冒犯时，我们更倾向于先私下沟通，如果仍无法达成一致，再由相关负责人定夺。例如在卡牌设计中，我主张加入负面效果提高策略性，但实现同学认为实现成本过高。最终这个决策交给主策划定夺。这种“分级处理冲突”的方式既保障了团队氛围，也避免了不必要的信息冲突与情绪摩擦。这让我认识到，应根据冲突的性质与影响范围采取不同的沟通策略。

项目阶段学习到的知识点

需求阶段：需求的必然可变性

在需求阶段我们深刻体会到——需求不是一开始就能被完全确定的。在团队项目初期，我们设想了很多复杂的游戏功能，但随着开发深入，我们逐渐意识到有些设计并不符合实际开发能力，或者并非必要模块。尽管如此，接受需求的变化，并且始终保持以用户为导向的原则，就不会偏离原先的道路太远。

设计阶段：高内聚、低耦合

在设计阶段我们尝试划分模块，但本身划分模块需要考虑的事情就很多。由于职责划分不清，最初多个模块之间存在交叉调用，导致后续开发展开困难，部分同学工作被阻塞。后来，我们通过重新梳理功能，将逻辑清晰划分至各自模块，整体开发效率大幅提升。

实现阶段：版本管理

Unity 项目中许多文件是二进制格式（如 .unity 场景文件），无法通过常规合并工具自动处理，极易发生冲突。我们曾因误解文件用途，在解决冲突时错误保留了落后的本地版本，导致功能回退或损坏。通过反复踩坑，我们逐步理解了 Unity 各类文件的组织逻辑，并建立了更规范的版本控制流程。版本管理不仅仅是使用 Git，更在于理解每一个提交的实际含义与风险。还好，经过一个学期的挣扎，最后我们能够深入地理解unity各文件的作用，做到完美的版本管理。

测试阶段：尽早测试，尽快反馈

由于在alpha阶段未能重视测试环节，导致上线后出现了巨量的bug。在beta阶段我们紧急调整，加快开发的进度，并且进行内部充分的测试。这让我深刻认识到：测试不是项目的“收尾工作”，而是贯穿整个开发周期的关键一环。及时的测试和反馈，不仅提升了产品质量，也减少了后期修复的成本。

发布阶段：用户反馈与问题暴露

游戏首次发布后，收到了来自用户的多项反馈，主要集中在兼容性问题（如 macOS 无法正常安装）和交互细节不足（如操作指引不够）。这些问题在开发过程中未被充分预见，暴露了我们在跨平台部署和用户体验方面的不足，也促使我们及时进行修正与优化。

维护阶段：快速响应与问题追踪

维护阶段虽然时间有限，但反馈频繁且集中，要求我们随时关注反馈渠道并迅速处理问题。此阶段不仅涉及 bug 修复，也对问题定位、协作效率提出了更高要求。我们进一步完善了日志记录和错误追踪机制，提升了整体的维护响应能力。

个人总结

本学期最有成就感的事情，莫过于成功开发出一款完整的游戏。原本只是希望能做出一个简单的 demo，结果不仅实现了基本玩法，还在美术细节和系统设计上不断打磨，最终作品的完成度远超预期。
从零开始完成一款可运行的游戏，让我对“从想法到实现”的全过程有了更直观的理解。从基础功能到界面优化，每一处都经历了不断的试错与修改。虽然项目仍有不足，但每一行代码、每一个贴图、每一次调整，都是团队共同努力的结果，也见证了我们的成长。
开发过程中，真正的挑战不只是技术，而是“对齐想法”。设计、程序、美术、策划的语言和节奏各不相同，难免存在分歧。但也正是在这些磨合中，我们逐渐学会了倾听、协调与合作，这比单纯写代码更具价值。
Unity 对大多数成员来说是全新的工具。从最初连 Prefab 和 ScriptableObject 的概念都不了解，到后期能够独立实现动画、状态管理和系统扩展，我们通过大量查阅资料和实践，逐步掌握了关键技能。虽然课程本身没有教我们“如何做游戏”，但它提供了一个完整实践的机会，让我们在项目中不断学习和成长。
感谢软工这门课，它让我们从一组看似不现实的设想出发，逐步构建起属于自己的作品，也让我们对软件工程有了更深的理解。