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

作业信息

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15608
我在这个课程的目标是	学习现代软件工程的基本思想，理解敏捷开发、结对编程、软件项目管理等方法，并能够在实践中应用这些方法完成软件项目。
这个作业在哪几个具体方面帮助我实现目标	通过快速阅读课程博客并提出问题，训练自己主动思考软件工程方法背后的逻辑，加深对结对编程、敏捷开发、项目建议书和软件分类等内容的理解。

---

阅读提问

问题1

问题：
结对编程在实际的软件开发团队中，在什么情况下能够真正提高开发效率，而不是增加开发成本？

引起提问的章节与上下文：
在《结对编程》相关内容中提到，两个人一起工作可以提高代码质量，减少 bug，并且促进知识共享。文章中描述了 Driver 和 Navigator 两种角色，一个人负责写代码，另一个人负责思考和检查逻辑。

支持提问的事例或资料：

• 在一些敏捷开发实践中，Google、Microsoft 等公司都曾在部分项目中使用结对编程。
• 学术研究（例如 University of Utah 的实验）表明结对编程可以减少约 15%–40% 的 bug。
• 但是一些开发者社区（如 StackOverflow 讨论）也认为结对编程会降低开发速度，特别是在任务较简单时。

提问原因：

主要是自己的经验假设与书中的描述之间存在疑问。
从直觉上看，两个人做一件事似乎会增加成本，因此我想知道在什么场景下结对编程的收益能够超过成本，例如在复杂算法开发、代码审查或新人培训时是否更有效。

---

问题2

问题：
在 Scrum 或 Sprint 开发过程中，团队应该如何进行任务时间估算，才能保证计划的可行性？

引起提问的章节与上下文：
在介绍敏捷开发和 Sprint 的内容中，文章提到团队需要在每个 Sprint 开始时进行任务规划，并估算完成任务所需的时间，然后在 Sprint 中逐步完成这些任务。

支持提问的事例或资料：

• Scrum 方法中常用 Story Point 来估算任务复杂度。
• 团队通常会通过 Velocity（团队速度） 来估算每个 Sprint 可以完成多少工作量。
• 在实际开发中，需求变化和技术问题经常导致任务延期。

提问原因：

这里的疑问主要是对推理过程的疑问。
书中提到 Sprint 计划应该可预测，但在现实项目中，开发任务往往存在较大不确定性。因此我想知道是否有成熟的方法可以提高估算的准确性，例如通过历史数据或统计方法进行预测。

---

问题3

问题：
在使用 NABCD 方法写项目建议书时，如何确保提出的需求是真实存在且有价值的？

引起提问的章节与上下文：
在介绍 NABCD（Need, Approach, Benefit, Competition, Delivery） 方法时，文章强调在项目建议书中必须清楚地说明用户需求（Need）以及解决方案带来的好处（Benefit）。

支持提问的事例或资料：

• 在创业领域中，很多项目失败的原因是“没有真实需求”。
• 例如一些互联网产品在上线后发现用户数量很少，因为开发者只是根据自己的想法设计产品，而没有进行用户调研。
• 在产品设计中，常见的需求验证方法包括用户访谈、问卷调查和数据分析。

提问原因：

这里的疑问主要是对术语和实际操作之间的差距产生的疑问。
书中提出了一个很清晰的框架，但在实际操作中如何验证需求却没有详细说明。因此我想进一步了解如何在现实项目中验证需求的真实性。

---

问题4

问题：
“软件的血型”这种分类方式在实际软件工程中有什么具体作用？

引起提问的章节与上下文：
在文章中，作者用“血型”来比喻不同类型的软件系统，用这种方式说明软件项目在开发方式、维护方式和生命周期上可能存在差异。

支持提问的事例或资料：

• 一些软件系统（例如操作系统或数据库）生命周期非常长，需要长期维护。
• 另外一些软件（例如网站活动页面或短期产品）生命周期较短。
• 不同类型的软件在测试、架构设计和维护成本上差别很大。

提问原因：

这个问题主要是希望理解概念背后的工程意义。
虽然“软件血型”这个比喻很形象，但我希望进一步理解这种分类如何影响实际的工程决策，例如架构设计、测试策略或团队组织。

---

问题5

问题：
在软件项目结束后，如何进行一次有效的事后复盘（post-mortem），从而真正改进团队的开发流程？

引起提问的章节与上下文：
在关于软件工程实践的内容中提到，在项目结束之后团队应该进行事后分析，总结项目中的经验和教训。

支持提问的事例或资料：

• 在很多公司中，项目结束后会进行 retrospective（回顾会议）。
• 一些团队使用 5 Whys 分析法 来寻找问题的根本原因。
• 但是在很多实际团队中，复盘往往只是简单总结问题，没有形成具体改进措施。

提问原因：

这个问题来源于书中的描述与实际经验之间的差异。
理论上复盘应该帮助团队改进流程，但在现实团队中，复盘往往流于形式。因此我想知道如何设计一个有效的复盘流程，使团队能够真正从项目经验中学习。