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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	通过软件工程方法，和团队成员一起打造出可靠、可维护、用户满意的软件
这个作业在哪个具体方面帮助我实现目标	了解软件工程概念和敏捷开发流程

问题1

章节：2.1.2 好的单元测试的标准

上下文：
“单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。”

疑问：
单元测试由程序的作者来写，是否会忽略自身代码的逻辑缺陷？作者过于熟悉自己的代码，在测试时可能因思维盲区或过度自信，导致测试用例覆盖不全、难以发现自身代码的逻辑缺陷。作者最了解代码的内部实现，可能会按照代码当前的实现路径去写测试，而不是去思考代码“应该”做什么。这种“测试偏见”可能导致一些隐藏的逻辑漏洞被遗漏，忽略一些边界条件。

示例：
在 OO 的互测中，每个同学都最了解自己写的代码的内部实现，提交的最后一版都是自己已经在本地自测过的，但在互测时依然被刀。每个同学都过于熟悉自己的代码，在测试时会陷入陷入思维定势，难以发现自身代码的逻辑缺陷。

问题2

章节：4.5.2 为什么要结对编程

上下文：
“每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。”

疑问：
在结对编程中，当两位程序员的技术水平、思维方式或编码风格差异较大时，如何避免水平较高者主导全部决策，从而让双方都能有效提升能力并保证代码质量？如果结对编程时处理不当，可能会演变成“一人写、一人看”的模式，不仅浪费人力，还会让水平较低的一方沦为“旁观者”，无法真正参与团队合作。如果不能解决“主导 - 跟随”的失衡问题，结对编程的优势就难以充分发挥，反而可能激发团队矛盾。

示例：
新手和专家结对时，专家可能会直接给出所有技术决策和代码实现，而新手只是被动接受，无法理解背后的设计思路。且专家可能需要不断向新手解释一些基础概念和他的代码逻辑，导致专家的效率下降，新手也没有机会锻炼自己的能力。

问题3

章节：5.3.6 渐进交付的流程，MVP 和 MBP

上下文：
“一个社交网站已经有很多用户，都是免费的，产品团队想设计一个付费的VIP服务，MVP的做法可以是这样——在目前的用户入口页面中加一个‘VIP服务’的链接，指向一个简单的介绍页面（用最小成本做出来）。观察到底有多少用户点击这个链接。如果点击量太小，那么这个VIP服务就不用做了。”

疑问：
在 MVP 实践中，当通过最小成本验证出用户需求很弱时，团队应该如何在果断放弃和优化迭代之间做出科学决策？是否存在一些关键指标或判断框架，帮助团队避免因过早放弃而错失潜在机会，或因过度坚持而浪费资源？书中 MVP 的核心价值是尽早用最小成本验证用户需求，但现实中很多团队在得到负面反馈（如点击率低）时，容易陷入两难的决策困境：要么直接砍掉项目，导致有潜力的方向被过早放弃；要么无视数据继续投入，造成资源浪费。书中只给出了 “点击量太小就不用做” 的简单结论，但实际商业环境远比这复杂。例如，用户不点击可能是因为入口不明显，而非需求不存在；又如用户点击链接的行为不一定能真实反映购买意愿，点击链接可能只是因为好奇。因此，需要更系统的决策框架来指导实践。

示例：
在 iPhone 正式发布前，苹果内部曾推出过一个 “iPod Phone” 的概念产品：在 iPod 的基础上增加了简单的电话功能，使用点击轮盘进行拨号。如果用 MVP 方法验证，可能是 “用户是否需要一个兼具音乐和通讯功能的设备”。然而，用户的反馈非常糟糕：点击轮盘拨号极其不便，通话质量也差强人意。如果苹果团队仅凭这个负面反馈就放弃，那么今天的智能手机时代可能会被彻底改写。
乔布斯和团队并没有因为 iPod Phone 的失败而放弃，他们深刻分析了失败的原因：不是用户不需要融合设备，而是 MVP 的实现方式（点击轮盘）完全错误。于是他们重构了一个全新的方向——多点触控屏幕。这个新的 MVP 彻底改变了人机交互方式，最终验证了用户对智能手机的需求，催生了划时代的 iPhone。
iPod Phone 的失败是实现方式的失败，而非用户需求的失败。如果苹果团队因为一开始用户反馈不佳而过早放弃，就会错失整个智能手机市场。

问题4

章节：6.1 敏捷的流程

上下文：
“整个产品的实现被划分为几个互相联系的冲刺。产品订单上的任务被进一步细化了，被分解为以小时为单位（参见WBS工作划分的办法）。如果一个任务的估计时间太长（如超过16个小时），那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。如果团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。”

疑问：
如何避免因个人估计偏差导致冲刺阶段的任务延误？上述内容阐述了产品实现的冲刺划分、任务 WBS 细化规则和成员自主认领的分配方式，该模式的核心优势是发挥团队成员能动性，但任务时长估计的主体是成员个人，必然存在主观判断偏差的可能性，而任务以小时为单位细化且冲刺阶段任务互相联系，单个任务的时长估计偏差容易传导至整体项目，进而影响冲刺目标达成。

示例：
新手对项目业务熟悉度不足，将一个需要 18 小时的需求梳理任务估计为 8 小时，未进行分解便认领，执行过程中因对业务细节反复确认耗费大量时间，不仅自身任务逾期，还导致与其对接的设计人员后续的设计任务无法按计划开展，打乱整个 Sprint 的计划。

问题5

章节：8.3 获取用户需求——用户调研

上下文：
“通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这通常是一对一的采访。这种方法费时费力，效果往往取决于主持面谈的团队成员的能力。深入面谈这一方法也可以用在某一特定领域，例如软件的用户可用性和用户界面，这也可以称为软件可用性研究。”

疑问：
为了确保可用性研究结论的准确性与可靠性，可以采取哪些系统性措施来规避或减轻 “观察者偏差” 的干扰？书中明确指出，深入面谈这类方法的效果“往往取决于主持面谈的团队成员的能力”。那么在研究过程中，研究人员（观察者/访谈者）自身的经验、预期、甚至无意识的肢体语言，都可能对用户的行为和反馈产生引导或误读，这就是“观察者偏差”。当研究结论高度依赖个人能力时，其客观性和可靠性就容易受到影响。

示例：
不同能力的访谈者可能会在用户遇到困难时，给出不同程度的暗示。例如，在可用性测试中，经验不足的访谈者可能会问：“你是不是觉得这个按钮很难找？” 而有经验的访谈者会问：“请说说你刚才寻找某个功能时的想法”。前者是引导性问题，后者是开放式问题，而前者可能将用户暂时的困惑引导成一个确定的负面结论。