[I.1] 个人作业：阅读和提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 掌握软件工程原理与敏捷协作，实现高质量系统全周期工程化，开发出一款令人满意的软件。 |
| 这个作业在哪个具体方面帮助我实现目标 | 定义需求边界、解构系统设计矛盾，强化对软件全生命周期中需求分析、质量验证的工程化实践认知 |
-
微软的Program Manager模式能否适用于所有类型的软件团队？在小规模或创业团队中是不是可能会会增加沟通层级？
书中介绍，微软为解决大规模团队的交流成本问题引入Program Manager（PM）角色，强调“PM与开发、测试平等协作，不担任行政领导”。PM的核心职责是“推动团队完成功能，降低N×(N-1)/2的交流复杂度”。
书中有强调PM不担任行政领导以促进平等讨论，微软的PM模式诞生于大规模团队，但小团队是否需要如此明确的角色分工？这是我疑惑的点。
PM模式的核心是降低大规模团队的沟通复杂度，但对小团队（就像咱们软工）而言，增设PM可能导致角色冗余，甚至因层级增加而拖慢决策速度。如何判断何时需要引入专职PM？是否应根据团队规模或项目复杂度动态调整呢？书中观点是认为PM的平等协作优于行政领导，但若PM本身是技术权威，就是相当于包含了技术负责人的责任，是否更有利于快速决策？
-
书中将“技能的反面是解决问题”作为衡量标准，是否低估了创新和复杂问题解决在软件工程中的价值？
技能的反面是“解决问题”（Problem Solving），以魔方为例说明低层次问题解决会阻碍高层次技能展现。书中强调通过反复练习将基础操作变为“自动动作”，从而去释放脑力来处理更高层次问题，“一个不精通的面试者把时间花在解决低层次问题上，无法展示算法技能”“通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。”
作者认为技能熟练的标志是“无需思考的自动操作”，但我看来，软件工程中许多场景，如架构设计、紧急故障排查需要我们动态调整和创新，单纯依赖“肌肉记忆”可能无法解决复杂问题，而且现实中的优秀工程师，有很多是通过创造性解决问题而脱颖而出的。
书中将“解决问题”视为技能的负面表现，但实际工程中，解决未知问题恰恰是核心能力。我觉得，这种能力是否被“技能的反面”这一表述忽视？我们是否应区分“机械技能”与“创造性问题解决”，而非将其对立？这可能是书本所忽略的。
-
瀑布模型在现代敏捷主导的环境中是否仍有不可替代的适用场景？
书中5.3.2节提到瀑布模型的局限性有步骤分离、回溯困难、最终产品出现晚，但也指出其适用场景包括需求稳定、技术成熟、团队分布等情况
瀑布模型适用于“产品定义非常稳定”的场景，但实际经验中，用户需求即使在传统行业（如金融、医疗）也可能因政策、技术更新而变化。
那么就有问题，是否存在真正“需求绝对稳定”的软件项目？若需求始终存在变动风险，瀑布模型的“不可逆”特性是否本质上不适用于现代软件开发？书中提到瀑布模型适合“团队分属不同机构或地理位置”，但分布式团队通过工具（如Git、CI/CD）也能实现敏捷协作，这是否削弱了瀑布模型的优势？
-
在分布式团队中，敏捷流程强调的“面对面交流”是否与远程协作的现实需求存在根本矛盾？
书中6.2节提到敏捷专家肯•施瓦伯强调团队成员必须面对面开会才能有效沟通，但现实中许多团队分布在不同的地理位置或时区，导致传统敏捷方法难以直接应用。
书中认为敏捷依赖“面对面、高容量的交流”，现代软件团队（尤其是跨国或远程团队）有时无法满足这一条件。但是这样是否就不敏捷？敏捷是否本质上排斥远程协作？若必须妥协“面对面”原则，是否意味着团队不再“真正敏捷”？
书中可能将“面对面交流”视为理想状态，但未充分探讨工具和流程如何弥补地理距离。实践中，个人认为，分布式团队可能需要引入“异步敏捷”等变体，通过更细致的任务拆分、自动化测试和文档化需求来维持敏捷核心价值。
-
NABCD模型在动态市场环境下是否仍能有效指导竞争性需求分析？
书中8.4节介绍了NABCD模型（Need需求、Approach做法、Benefit好处、Competitors竞争、Delivery推广）作为竞争性需求分析的框架，强调通过差异化优势满足用户需求。
现实中许多新兴领域（如AI应用）的需求可能在产品开发过程中发生根本变化。这引发疑问：NABCD模型是否预设了需求稳定性，难以应对快速变化的市场？
NABCD作为静态分析工具，在敏捷开发成为主流的今天，是否需将其与持续探索（如持续发现框架）结合？比如我设想一种，将NABCD拆分为快速迭代的小周期，每个冲刺验证部分假设，而非一次性完成全部分析。
-
在软件稳定阶段的会诊（Triage）过程中，如何避免主观偏差影响对Bug修复优先级的判断，是否存在客观的评估标准或工具支持？
在《构建之法》第15章“稳定和发布阶段”中，作者提到会诊小组需要对每个Bug决定修复、标记为设计如此、不修复或推迟。文中提到“Must修复”的门槛会随着项目进展逐渐提高，但并未详细说明如何避免团队成员的主观判断导致决策不一致。
根据我的项目经验，团队常因对“大问题”的定义不同而争论，例如：一个界面错位Bug，设计师认为影响品牌形象（Must修复），开发者则认为可推迟。因此，如何建立共识或引入数据驱动的评估标准是关键矛盾点。
