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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件开发方法、培养协作能力，最终搭建稳定、高质量、扩展性强的软件
这个作业在哪个具体方面帮助我实现目标	了解总体框架、学会怎么交流问题、打好后续“学中做、做中学”的基础

问题一

P87

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作

结对编程中有两个角色:
1.驾驶员(Driver):控制键盘输人。
2.领航员(Navigator):起到领航、提醒的作用

AI辅助编程的当下，结对编程是否还有意义?

我的开发经历中没有结对编程，但是又较多的AI辅助编程。

结对编程因为只有两个人，更容易引发矛盾，作为驾驶员会想身旁的这个家伙老是问问题，他/她不会看书么？我都无法专心工作了。作为领航员会想“我只领航，不用敲键盘，多爽……”，如何避免结对编程中的一方摆烂现象？这个问题其实对于大学生二人开发很容易出现。

与此同时，随着copliot、comate这些代码补全工具的出现，保证了语法的正确性，同时，用户需求方面可以与ai工具进行交流，而且不会出现矛盾，这时结对编程的效率是否要低于AI辅助下的单人编程。

问题二

p141

软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。但要注意，我们是预期变化，不是期望变化。

最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。

既然软件存在生存周期，就一定有迭代周期，而软件的质量在敏捷开发中又至关重要。敏捷开发方法如何通过其核心原则和实践，在快速迭代中有效保障并提升软件质量？需具体分析测试驱动开发、持续集成、自动化测试等实践如何嵌入短周期开发流程，确保质量不因需求变动而妥协

问题三

P158

需求不仅来自外界，还可以来自软件企业本身。我们在第一章就提到，软件企业=软件商业模式。企业所采用的商业模式会对软件提出需求。一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入。例如一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不同等级的用户，在邮件中附带广告，或者在页面显示广告，等等。这些“需求”并不是来自用户，事实上绝大部分用户都反感这样的“需求”，但是企业需要一个能维持它生存和发展的商业模式，尽管这个模式的种种需求未必都是对用户有利的。

大部分工具类App项目，企业为盈利新增付费会员专属功能，但用户抱怨基础功能被削弱。团队采用迭代灰度发布，通过用户行为数据逐步优化付费模型，但初期仍导致部分用户流失。敏捷宣言强调“客户合作高于合同谈判”，但未明确“客户”是否包含企业自身作为利益相关方；在敏捷开发中，如何平衡企业商业模式驱动的内生需求（如商业化功能）与用户实际需求之间的矛盾，既保障企业可持续发展，又避免损害用户体验和产品质量？

问题四

P215

怎样才能定义典型用户呢?我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。如下面的例子: 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”不受欢迎的典型用户——指那些有不正当目的的用户,如在一个房地产业主论坛中滥发房屋中介广告的用户，这些用户也许在别的系统中(如房屋中介论坛)是受欢迎的。

社区电商项目，需区分“真实买家”与“刷单用户”。团队通过用户行为链（浏览-收藏-下单时长）定义角色，初期将“快速下单且无复购”的用户归为“不受欢迎”，后发现部分用户仅为紧急采购（如企业行政采购），误伤正常用户。在定义典型用户角色时，如何准确识别并分类“受欢迎”与“不受欢迎”用户，避免因角色边界模糊导致功能设计矛盾或安全漏洞？尤其是当同一用户行为在不同业务场景中可能被赋予相反角色属性时，应如何建立动态且一致的判定标准？

问题五

P260

我们常说做产品要从用户的角度考虑问题，这需要有“同理心”。软件团队的设计师和软件工程师有“同理心”(Empathy)么了?
什么是同理心?就是理解别人的处境、心理、动机的能力。西方谚语Put yourself in other people's shoes.正是此意。设计不同于传统的数学题，是没有唯一的标准答案的。有一颗为用户着想的“同理心”，是好的产品设计的出发点。

部分老年应用为了老人健康经常进行健康播报，但推送通知频率过高造成了用户焦虑。在软件工程实践中，如何有效培养和衡量设计师与工程师的“同理心”，以确保其真正转化为以用户为中心的设计决策？尤其是在技术实现复杂度高或商业目标与用户需求冲突时，如何避免“伪同理心”（如表面采纳用户反馈却未解决核心痛点）？