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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	提升前后端开发能力，掌握软件工程方法，强化团队协作和项目管理能力，实现高效的软件开发实践。
这个作业在哪个具体方面帮助我实现目标	理解软件工程核心概念，培养批判性思维，提高对需求分析、软件设计、测试及团队协作的理解

问题一：结对编程中的“角色互换”是否理想化？

（讲义 -3.b- 结对编程）：文中建议“驾驶员与领航员每小时轮换”，以避免疲劳并保持效率。
疑问与矛盾：

1. 在实践中学识或经验差异较大的结对中（如资深工程师与新人），频繁轮换是否导致主导权模糊或效率下降？
2. 是否存在“伪轮换”——即形式上交换角色，实际仍由一方主导？如何避免此类问题？

案例与资料：

​ 在一些开源项目中“导师-学徒”模式常采用固定角色，新人以观察为主。北航超算队也经常采用“老带新”的开发模式。
提问原因：作者假设角色互换能平衡参与度，但未考虑技能差异对协作动态的影响，是否需制定差异化的轮换策略？

问题二：“反馈汉堡包模型”在高压场景下的可行性

（讲义 -3.c- 给人提意见的方式 - 送一个汉堡包）：文中提到将反馈包装为“铺垫-建议-鼓励”的汉堡结构。
疑问与矛盾：

1. 在紧急故障处理中（如线上系统崩溃），是否仍有时间构建“汉堡包”式反馈？
2. 过度结构化反馈是否会显得不真诚，削弱信任？

案例与资料：

​ 在一些赶得较急的任务和比赛，尤其是我在参加ASC这样的比赛时，尝尝会有紧急问题，一般就直接采用简洁的指令式沟通，避免冗余铺垫。
提问原因：作者提倡结构化反馈，但未界定适用场景，是否需区分日常改进与危机沟通的反馈策略？

---

问题三：充分授权是否导致“责任分散效应”？

（讲义 -4.d- MSF-Agile）：2.2.3引用匠石斫垩说明信任，但实践中出现“互相推诿”。
疑问与矛盾：

1. 授权后如何避免“三个和尚没水喝”？
2. 自下而上计划可能导致“DDL战士”，如何与敏捷迭代结合？

案例与资料：

​ 我查了一些资料找到了谷歌的OKR制度，在谷歌OKR制度中，个体目标与团队目标强关联，避免责任分散（《Measure What Matters》）。
提问原因：作者主张“信任替代控制”，但未讨论如何建立追责机制（如代码所有权制度），是否需平衡自组织与问责制？

---

问题四：过度设计与重构的界限如何界定？

（讲义 -6.c- 目标和远景 - 反面例子画扇面）：乙不断将“美女”改为“张飞”“山水”，最终涂黑扇面，类比开发中的频繁重构导致项目失控。
疑问与矛盾：

1. 《重构》提倡“小步快跑”，但材料显示重构可能演变为“推倒重来”。如何区分合理重构与过度设计？
2. 是否应通过代码规范或设计评审会限制重构范围？

案例与资料：

​ 在之前OO第二单元时，有同学三次作业连续重构了两次，过度追求结构完美造成开发压力失控。
提问原因：作者强调“解决小问题不易”，但未说明如何平衡技术追求与交付压力，是否需定义“重构阈值”（如代码复杂度指标）？

问题五：关于“小强地狱”阈值的科学性与灵活性

（讲义 -7.c- 目标和远景 - 开发阶段的日常管理）：14.6.5中提到“阈值由团队根据实际情况确定”，且“开发人员同时入狱的比例应在5%~30%之间”。
疑问与矛盾：

1. 如何科学确定阈值？例如，是否存在行业通用的公式（如基于团队规模、Bug严重性加权等）？
2. 若团队初始设定阈值为15，但后续发现20%的成员长期处于“地狱”中（如项目后期Bug集中爆发），此时是否应调整阈值？书中提到“阈值不宜频繁调整”，但未说明如何应对极端情况。

案例与资料：

• 查了一些资料，发现敏捷开发中常通过“燃尽图”动态调整任务优先级，但Bug修复的阈值设定缺乏类似模型。

提问原因：作者强调“事先宣布阈值”，但未提及如何应对动态变化的项目风险（如需求变更导致Bug激增），是否需结合其他指标（如Bug解决率）综合决策？