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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	进一步加强协作完成项目能力，最终开发出功能完善的软件
这个作业在哪个具体方面帮助我实现目标	对本学习的软件工程作总结，感悟其中的科学方法

博客链接

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

问题回答

一、是否应该由最熟悉的人写单元测试？

通过一学期的实践，我发现一个折中方法更有效：即代码作者负责覆盖常规路径和边界条件，而由“代码审查者”（另一位同学）补充异常路径和极端用例。这样既发挥作者理解代码的优势，也兼顾不同视角，提升覆盖率和稳定性。

比如在beta阶段中，我作为pm让测试人员负责核心模块的测试用例写作，而其搭档即其他开发者主动加入了“异常输入”和“系统交互”测试。这种协作模式让测试更全面，Bug 数明显下降。

二、如何确保MVP（最小可行产品）一定得到“最小集”且提高效率？

MVP本身就是在策划阶段确定的，是通过一定时间的投入才能得出结论，比如引入用户画像+问卷调研。这样就先明确目标用户群，然后设计问卷获取优先功能需求，再用快速纸质原型（paper prototype）做 A/B 测试。

后续查资料发现，这里的最小更不意味着简单，要确保 MVP 是“可行”，也就是Viable，它必须具备一定的用户价值 — 即至少能够解决核心用户痛点，并允许用户真实使用和反馈 。所以提高效率可以说是MVP的原生需求，这也反方向说明了前期调研的重要性。明确 MVP 面向的“早期采用者”，能够聚焦极简使用场景，避免功能蔓延或用户分歧。

三、MSF敏捷开发模式中的“充分授权和信任”原则是否与平等协作相矛盾？

通过分阶段观察发现，敏捷团队在初期确实有较多“一对多教学”，但这属于知识传承；随着共识提升，团队会自然形成“模块自治”，再辅以定期的交流协作，可以基本上平衡协作和效率。

也就是说，两者应该不是矛盾，反而“充分的信任”能够促进后期的平等协作。进一步讲，MSF 强调每个成员被视为平等，彼此之间无高低等级，但仍清晰分工，每个角色对自己模块负责，同时为整体成果承担责任。就算如果某人未在预期中完成，团队内部透明暴露问题，其他成员协助支持，这种机制更加能减少责怪，促进主动意识。

四、如何确保“总体模型”对“功能列表”的高效映射？

在开发前期中我们虽然没有明确提出，但其实隐含了促进高效的“结构化分层法”：先定义总功能域，再按每层输出文档，每层做一次内部评审，确保无遗漏，这也是课程团队提供的开发框架中默认给出的。

这就引申出了一个新问题：

因为在组内开发过程中发现在区分功能优先级上较为粗糙，大致都在例会上草草评估时间后决定。那么既然这个映射是开发前期做的，随着用户反馈和竞品变化，功能列表会变动，如何动态调控“总体模型 ↔ 功能列表”之间的同步机制？有没有一种方法能科学调控功能优先级？

五、用户反馈的认知阻力和开发者预期的工作效率如何进行平衡

通过后续查资料才懂（，参考了HCI（人机交互）中的“可用性成本收益模型”，对不同用户群体设定“学习成本阈值”+“效率收益点”，每个功能发布前通过“可用性测试”收集关键指标（如完成任务时间）。用户界面中任何迫使用户“停下思考”的设计都会引发认知摩擦，干扰流程，但有时适度摩擦（如我们航准答的确认对话）是必要的，以防错误操作。

我的理解是比如测试版本中同时统计新老用户使用的指标，可以是页面停留时长、输入错误次数等日志指标，然后增加类似“新手提示”机制，这样就满足了不同用户需求。

学习到的知识

需求

学会用NABCD模型，同团队协商并提出一个靠谱的软件项目展望计划

设计

掌握使用数据流程图等方式将系统整体架构进行分层表达，并生成详细设计文档，以便后续开发与评审。而自己作为PM，更是学会了如何把系统设计变成团队共识，并让计划落实到每个人身上，继而稳定执行。

实现

通过持续集成平台自动构建代码、运行单元测试，同时在团队内部开展代码评审，代码评审不仅是查错，更是提升代码一致性、可维护性、安全性等指标的重要手段。

测试

学会如何制定从单元测试到集成测试、系统测试、验收测试的一套多级测试流程，确保逐层发现并修复缺陷，以及在项目中使用Apifox等工具进行前后端API对接，并进行初步调试

发布

在发布上大致了解如何实现可控扩散上线，降低运行风险，同时进行快速回滚与反馈收集。

反馈

发现了完善的文档在后续运维的重要性，理解维护不仅是修复缺陷，更包括持续接受用户反馈、进行完备性更新、进行性能优化和技术迭代。

心得体会

总得来说，这次软件工程让我以亲身实践体会了开发的全流程，是一次独特的经历。

结对编程让我学习了webAssembly有关的知识，并实践了两人”一人指挥，一人操作”这一更加重视开发质量和效率的编程模式；团队合作让我学习了真正的敏捷开发过程，也让我切身感受到，没有频繁而高效的沟通，会让整个项目的进度拖慢、冲突积压。我们前期的主要问题就是沟通不够及时，导致认知不同步。在未来项目中，我会更重视提前对架构与 API 的统一定义，通过每日对接、频繁讨论，避免这样的问题再次发生。

最后引用团队总结的一句话：软件工程不仅仅是技术，更是一种系统化的思维方式，开发者必须应用科学的方法和管理手段，以提高软件的质量和开发效率；对用户需求的探索是贯穿始终的，团队对功能的完善往往伴随着对其提问回答的场景的补充和思考。