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

项目	内容
这个作业属于哪个课程	2026年春季软件工程(北京航空航天大学-计算机学院)
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	在学习课程的过程中掌握软件工程的基本知识，并能够熟练将其投入到日后的工作中加以应用
这个作业在哪个具体方面帮助我实现目标	在阅读教材《构建之法：现代软件工程》并提出问题的过程中，初步对软件工程的整体流程及细节有了大致的认识，为我这门课程的学习指引了方向

---

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

讲义第3节结对编程中提到，结对编程是一对程序员如同驾驶飞机一样共同使用一台电脑来编写程序，特点是过程中会有大量且随时的复审和交流，从而减少许多错误，剩下大量的修改时间，获得更高的投入产出比。同时讲义还指出了结对编程是一个渐进的过程，开发效率会随着时间而明显改善。

我的问题在于，理论上的结对编程确实是一个能够大幅提高编码效率的方式，可实际上真的能摆脱“两个人挤在一台电脑前走流程”的形式主义吗？如果有一方有明显短板或者浑水摸鱼，结对编程是否会让他们更好的“隐藏”？所以在团队协作中，我们该如何避免一方主导编码、另一方被动旁观的“伪结对”？如何根据成员的技术水平、性格特点灵活调整结对模式，让交流和复审真正服务于代码质量与开发效率，而不是沦为一种流于表面的团队实践？我们该怎样使结对编程从“为了做而做”的形式，落地为能切实提升团队产出、促进成员成长的实用方法？

---

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

讲义第5节角色-QA中提到，QA的工作是运用各种手段, 在软件工程的各个阶段确保软件的质量能帮助软件团队实现目标。同时详尽的解读了QA用来测试的各种方法，还明晰了QA与TEST的区别。

我的问题在于，随着AI辅助测试、DevOps流程的不断成熟，很多重复性的测试与质量监控工作都能被一些ai工具替代，那么QA岗位未来是否会逐渐脱离对技术人员的依赖？甚至演变为纯流程管理类岗位？在技术工具高度自动化的背景下，QA人员的核心价值究竟是技术能力，还是在于判断质量体系、业务逻辑与风险的把控能力？这是否意味着未来的QA岗位会更偏向“质量专家”而非“技术专家”，抑或是直接被ai所取代?仅保留一个责任相关的负责人用来验收决策即可？

---

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

讲义第7节用户调研的方法中，详细探讨了在我们开发软件的过程中，如何通过用户调研来调查用户需求以便更好地完成软件的设计与维护，讲义中强调用户调研的方法可以通过项目开发组内部来讨论用户喜好（焦点小组、卡片分类），也可以通过实地调研用户来总结（深入面谈、用户调查问卷、软件可用性研究），抑或是通过学术性/技术性方法来解决用户调研的问题（用户日志研究）。在讲义中，这些方法能够帮助我们避免“秋千图”一类的问题，精准且准确的了解到用户真正“需要的东西”。

我的问题在于这些方法在当下社会背景是否能高效的调查出用户需求，结合我自身作为“用户”这一身份的实际经验来看，我选择点击问卷的概率简直低的可怜，在快节奏的社会背景下又有多少人愿意花费时间去完成一个问卷项目（又或者是为十分微薄的报酬糊弄了事）。诚然，通过用户日志研究(User Survey)得到的结论准确度比其他几种方法要高上许多，但为了收集这些数据，开发者是否会侵犯用户的个人隐私红线？在为了满足"充分了解用户需求”的目标下，有多少个人隐私数据会悄无声息的被项目“偷走“？反过来说，在完全保证用户重要隐私数据不被侵犯的情况下，用户日志研究得到的数据是否能够准确反映用户的需求？“问卷调查”和“日志研究”是我认为这些方法中较为高效的，其余方法在全面性、经济性、时效性都有所欠缺，那是否能通过改善上述的两种方法或者存在一种更高效的新方法来使调研出的用户需求更准确更高效？

---

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

讲义第10节绩效管理中，探讨了衡量个人在团队中的贡献的许多方案，也指出不合理的绩效管理会引发一系列的“蝴蝶效应”，可能会导致“人的问题"频繁出现，甚至出现违背”职业道德“的问题，最终导致整个软件项目的开发受到极大阻力。讲义中还提到，衡量个人可以从这些一维指标入手，例如工作量，工作难度，互相评分和效率等等，也可以将这些一维指标组合成二维的评价系统来衡量绩效，同时还提到加权评比也可以作为一种绩效考核的形式。

我的问题在于这些绩效管理方案能否真正做到在奖励真正付出的个人的同时，有效识别并惩罚那些浑水摸鱼的个人？在实际项目中，单纯依赖代码量、任务完成数等量化指标，是否反而会鼓励 “刷数据” 的行为，让踏实解决核心问题的成员反而得不到应有的认可？而过于主观的多维度评估，又是否会因为评价者的偏见或信息偏差，让浑水摸鱼者钻了空子？这些机制究竟能否在 “激励贡献” 和 “约束投机” 之间找到平衡，避免团队陷入 “劣币驱逐良币” 的困境？同时，当我作为一名项目开发组的成员时，我更应该倾向于项目什么部分的工作，才能使我做的“工作”能最大限度地被呈现？

---

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

讲义第10节同时还提到了Postmortem-事后诸葛亮会议，它指出Postmortem 是项目结束后的复盘会议，核心是回顾项目全过程、总结经验教训，目的是避免重复犯错、持续改进团队流程。同时也指出，若复盘流于形式、只追责不解决问题，就会变成浪费时间的走过场。

我的问题在于，在实际团队协作中，如何设计Postmortem的流程与规则，才能避免会议变成互相指责的“批斗会”或空喊口号的“总结会”？很明显，在讲义中完成一场Postmortem需要消耗大量的人力物力以及时间，尤其是对于一个已经结束的项目来说，花费这么大精力如何能确保获得足量的产出投入比？怎样才能让复盘真正聚焦于问题根源与可落地的改进方案，让每一次Postmortem都能切实推动团队进步，而不是沦为浪费时间的形式主义？