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

项目	内容
这个作业属于哪个课程	2026年春季软件工程(北京航空航天大学-计算机学院)
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	在学习课程的过程中掌握软件工程的基本知识，并能够熟练将其投入到日后的工作中加以应用
这个作业在哪个具体方面帮助我实现目标	在课程结束之际回顾一学期的收获，总结反思，提炼经验

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

问题一：如何使结对编程从“形式主义”转变成“实用主义”？

问题核心： 在此问题中，我聚焦于结对编程虽然在理论上有诸多优势，但其在实际操作中能否充分将其优势发挥出来？如何使结对编程在项目开发中成为推动进度的工具而不是拖慢进程的“绊脚石”？同时，应如何规范结对编程流程，使得其真正发挥效用而不是两个人在屏幕面前进行“伪结对”的无意义工作？
我的解答： 要想最大化结对编程的实际优势，我认为选择合适的任务场景是非常重要的。在本学期结对编程项目操作中，不难感受到结对编程对于代码开发的阻力，磨合的时间对于简单，机械的编程任务在某种意义上拖慢了任务进度。相较而言，在彼此双方有一定磨合基础的情况下，有着复杂业务逻辑的核心模块更适合于结对编程开发，在选择正确的思路以及错误的出现上都有较大的优势。同时，为避免“伪结对”的情况，在二人编程水平相差不大的情况下，明确规范两种角色的任务目标，并在一定时间后（如45min）强制更换角色，从而真正实现结对编程“1+1>2”的终极目标。

问题二：QA岗位日后是否可能会不再需要技术人员？

问题核心： 我的疑问在于，随着ai技术能力的飞速增长，QA岗位在未来的定位是什么？换言之，QA岗位的核心价值是高水准的编程能力，还是对于风险的把控能力和对于质量优劣的判断能力？
我的解答： 经过课程的学习，我的观点是未来 QA 的核心价值将不在于高强度编码执行这类可被 AI 替代的工作，而是风险把控、质量优劣判断、业务场景深度理解与测试策略统筹能力，AI 会成为 QA 提升效率的工具，QA 人员要依托技术基础驾驭 AI、聚焦复杂业务的质量决策与全流程风险管控，岗位定位会从重复用例执行转向更高阶的质量体系把控

问题三：用户调研的方法在当下时代是否真正高效？

问题核心： 在课程开始前，经过对作业讲义的阅读，我了解到用户调研对于软件工程开发的重要性。同时通过讲义的介绍，我认识到了一些用户调研的方法，同时不免有一些疑问：这些方法放在当下的快节奏发展社会，仍然适用且有效吗？有一些方法诚然有效但对用户隐私有较大威胁，而另一些方法保护隐私却不够精准和高效，有没有方法能够平衡两者呢？
我的解答： 在经过一学期的项目开发的经验积累后，我对这个问题有了新的认识：传统用户调研方法在当下依然具备极高实用价值，只是需要结合时代特点优化形式来平衡调研效率与用户隐私保护。可以通过匿名化采集数据、脱敏处理用户个人信息等方式规避隐私风险，同时搭配AI数字化分析工具等新时代工具来补充调研样本，在一定程度上能够有效实现调研与隐私保护的平衡。

问题四：如何使绩效管理促进团队发展？

问题核心： 绩效管理一直是团队管理中很重要的课题，不合理的绩效考察的严重性远比专业水准的短板要严重得多。在阅读完讲义后，我设身处地的把我自己带入“一个团队中制订绩效规则的角色”，发现我依然无从下手，无法确立一个“完美”的规则使得发挥大的人评分高，同时还能有效惩罚摸鱼钻空子的人。所以我依然对如何制订合理的绩效考核标准表示疑惑
我的解答： 恰巧的是，我在课程的项目开发小组中，被分配到了制订绩效考核的任务，根据课程组提供的往年优秀范本，制订伊始我大致有了一些了解：考核的规则不必非常“完美”，但要足够“服众”，要让团队中大多数人都认同此项规则。所以在绩效规则可以通过成员投票提案的方式，以确保最大限度上的“服众”。同时，也要合理确立每项规则的具体分值，以确保难度高，耗时久的任务完成人有合理的回报机制，同时对超时、影响他人工作进度的现象予以惩罚，以确保整个项目流程顺利继续。

问题五：如何避免Postmortem成为浪费时间的形式会议？

问题核心： 在团队协作中，应该如何设计Postmortem的流程与规则，才能避免会议变成流于形式的“走过场”？讲义指出一场会议需要消耗较为巨大的资源，但应该如何合理设计使其获得足够的回报？在一个项目结束后花费如此精力准备，会不会得不偿失？
我的解答： 通过在项目开发阶段中一轮又一轮的复盘会议，我对Postmortem会议有了大致的构想：想要避免 Postmortem 流于形式，需要精简参会人员、并且要限定会议时长，依托项目客观的数据来深挖问题根源，只聚焦可落地的改进方案并明确执行责任人；同时按故障严重程度分级复盘，小问题通过腾讯会议做轻量化线上记录，只有遇到重大事故时才召开正式的线下会议，会后跟踪整改落地，让复盘真正沉淀经验，避免精力白白浪费。

“做中学” —— 在实践中学习知识：

  需求阶段： 在明确产品的核心功能时需要确保其能够完全实现

    在项目开发初期构思产品雏形时，需要确立一个或多个明确且能够实现的核心功能需求，并将其从Alaph阶段贯彻到Beta阶段，如果将核心功能反复修改调整，会使产品整体的调性无法统一，与之相关的附加功能也会因其修改而变得无效。同时，在确立核心功能时开发组是站在整体宏观的视角确立的，而后期开发过程中对核心功能修改的想法是仅仅基于开发角度而提出的，丧失了整体视角会导致构思时的其他设计也受牵连。

  设计阶段： 团队应当使用模块化结构设计

     在设计中需要按业务边界拆分独立模块，降低模块间的耦合度，才能方便后续人员进行迭代开发。合理的模块划分不仅能让多人并行开发互不干扰，加快任务进程。同时也可以为后续功能扩展、代码维护打下良好基础，减少多余的返工。

  实现阶段： 团队应当使用Git 版本来进行协同管理

     通过分支管理、代码提交、合并与冲突处理完成多人协作开发。规范的版本控制可以完整留存每一次代码改动记录，既能保障团队并行开发互不冲突，也能在代码出错时快速回滚恢复，极大提升了多人项目的开发安全性。

  测试阶段： 团队可以使用边界值分析法设计测试用例

     我在团队中负责测试的相关任务，这个方法可以针对输入范围的临界值做重点测试，高效发现常规测试易遗漏的 bug。同时喔也理解了 QA 不只是简单点点测，更要通过系统化用例设计提前规避线上潜在风险。

  发布阶段：团队在发布产品时应使用灰度发布策略

     先面向小部分用户放量，在验证稳定性的同时还能规避全量上线带来的大规模故障风险。小范围试运行可以快速捕获隐藏问题，给团队预留充足的回滚和修复时间，最大程度保障用户使用体验。

  **维护阶段：团队应在产品维护阶段使用Postmortem会议

    Postmortem可以深挖问题根因，经过讨论后形成改进方案，也能避免同类故障重复发生。规范化的复盘不是反复的无意义追责，而是沉淀项目经验，让每一次问题都能转化为团队后续优化的宝贵经验。

个人项目/结对编程/团队项目的收获：

个人项目锻炼了我的独立思辨能力，学会结合现实软件案例来分析软件工程的优劣，跳出了片面化的认知误区；同时在写博客的时候熟练掌握 Markdown 撰写规范，能够将课本理论与实际产品结合，搭建起基础的软件工程思维体系。

结对编程“花见小路”使我熟悉了协作的开发模式，在掌握 Git 仓库 fork、私有托管等版本管理规范方面上变得更加熟练；通过分配研讨分工完成任务，提升了沟通协商、互补查漏的协作能力，懂得如何避免形式化结对，高效达成了协作目标。

开发“时光航迹”使我体验一个软件全生命周期流程，同时在分工中学会多人任务拆分、并行开发与项目进度管控；通过担任不同任务岗位使我理解了团队各岗位的协作价值，懂得要通过流程规范来规避项目风险，在实战中把软件工程理论落地，践行了做中学的学习方式。