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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习系统的软件工程方法，强化团队协作能力
这个作业在哪个具体方面帮助我实现目标	快速了解课程大纲，并培养批判性思维

问题一：在不同业务场景下，“是否按时交付”的评判标准是否应该有所不同？

在PSP: Personal Software Process中，作者在讨论 PSP 提出的衡量软件开发的工作量和质量的第四个因素——“是否按时交付”时，提出“在团队工作中, 稳定，一致的交付时间是衡量一个员工能力的重要方面”，并引用杰克·韦尔奇的话强调标准差对于建立信任的关键作用。

讲义中的例子和结论，似乎更适用于对计划性、可靠性要求极高的成熟型项目或维护型项目。但在更具探索性、创新性的项目中，如果仍然机械地套用“稳定性至上”的标准，会不会导致团队变得保守，不敢挑战有难度但有突破潜力的任务，从而错失市场机会？在这两种不同的业务场景下，“是否按时交付”的评判标准或许应该有所不同。我认为，软件工程的评估体系应该结合项目类型和业务目标而产生适当的变化。

问题二：当出现必须立即响应的紧急需求变更时，Scrum Master 该如何抉择？

在Scrum/Sprint部分，作者强调：“在冲刺阶段, 外部人士不能直接打扰团队成员。一切对交流只能通过SCRUM MASTER 来完成。这一措施较好地平衡了‘交流’和‘集中注意力’的矛盾。有任何需求的改变都留待冲刺结束后再讨论。”

但是工业界中，项目常面临不可预见的紧急变更：例如监管机构突然出台新合规要求、核心客户提出影响业务存续的需求调整。这些变更若等到冲刺结束后处理，可能导致合规风险或客户流失，但若中途响应，又会打乱冲刺节奏、影响原有目标达成。

我认为讲义给出的 “冲刺结束后再讨论” 是理想场景下的解决方法，但未覆盖紧急变更无法拖延的现实情况。那么 Scrum Master 该如何界定紧急变更的标准？对于确需响应的紧急变更，是否有流程能最小化对冲刺的影响？

问题三：里程碑应该如何划分？

在MSF-Agile中提到“MSF在每一个里程碑结束时都要做一个‘里程碑回顾’，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。”

“里程碑回顾”能够在短期内进行准确地反馈、及时解决错误、推广团队内较好的做法。但是文中并未明确里程碑应该如何界定，划分不当又会带来一定的问题：里程碑划分过细可能会导致回顾成本过高；划分过粗又可能造成问题的积累。那么团队应该如何划分里程碑以减少问题、达到最好的效果呢？

问题四：如何衡量一位PM的能力？如何成为一位优秀的PM？

Program Manager开篇就点明，PM要做开发和测试之外的所有事情，并列出了一系列广泛的能力要求：学习能力、观察理解能力、分析管理能力、销售能力、交流能力、专业能力、转换角色能力、自省能力等等。感觉PM得是一位全方位发展发展的人才。

这与之前讲义中提及的工程师成长形成了一定的对比。工程师的成长往往伴随着在某一技术领域的深度积累，而PM的成长似乎更依赖于知识和技能的广度，以及在不同角色间切换的灵活性。既然PM需要掌握多种能力，那么应该怎么衡量一位PM的综合能力？这些多样的能力是否存在一定的权重？

问题五：严格遵守 NABCD 模型是否会限制颠覆性创新的诞生？

在如何提出靠谱的项目建议中，作者提出的解法是：一个系统的框架—— NABCD 模型。该模型从Need（需求）、Approach（做法）、Benefit（好处）、Competitors（竞争）、Delivery（交付）/Data（数据）五个维度，帮助团队系统性地构思和验证项目创意。

曾经阅读过一个观点：优秀企业管理决策可能导致其在技术变革中丧失优势地位。NABCD模型强调通过分析现有竞争对手（C），其作为一个严谨的工程框架，似乎天然适合在已有参照物的领域进行迭代和优化。但是，当我们希望从0到1创造一个前所未有的产品时，即进行讲义中提及的“还没有明确定义的市场或竞争对手”的“颠覆性创新”，NABCD法是否会因为过于依赖现有参照和量化反馈，而成为发现新赛道的思维桎梏？我们该如何灵活运用这个框架来支持而非限制颠覆性创意的诞生？