[I.1] 个人作业：阅读和提问
课程信息
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 系统掌握软件工程各阶段知识和技能，学会运用相关工具进行项目开发 |
| 这个作业在哪个具体方面帮助我实现目标 | 加深对软件工程理论知识的理解，如敏捷开发、软件测试等关键内容 |
问题一：燃尽图的波动如何影响敏捷开发？
在“敏捷流程”章节中，书中提到燃尽图（Burn Down Chart）可以展现整个项目的进度，理想状态下线条应有向下的趋势。然而，在实际项目中，燃尽图的走势往往受到任务预估不准确等因素的影响，可能出现较大波动，甚至无法真实反映项目进度。
当燃尽图波动较大时，部分团队会通过重新评估任务、调整计划来修正进度。然而，在敏捷开发强调快速迭代的背景下，频繁调整是否会违背其初衷？在我参与的一个小型项目中，由于对任务难度预估不足，燃尽图前期走势异常，导致团队成员对项目进度产生误解，进而影响了开发节奏。
我的疑问是：在不影响敏捷开发效率的前提下，如何让燃尽图更准确地反映项目进度？
参考章节：第6章 敏捷流程 - 6.1节 “敏捷的流程简介”
问题二：如何在复杂业务需求中合理应用SRP和OCP？
在“个人技术和流程”章节中，书中介绍了单一职责原则（SRP）和开放 - 封闭原则（OCP）。
- SRP（单一职责原则）：一个模块（类）应该只有一个导致它变化的原因，一个模块应该完全对某个功能负责。
- OCP（开放-封闭原则）：软件实体应该是可以扩展的，同时是不可修改的。
然而，在实际开发中，业务需求往往复杂多变，很难清晰界定一个模块的单一职责。同时，完全不修改模块代码来实现扩展也颇具挑战。许多开源项目在实际应用时，都会对这两个原则进行一定程度的妥协和变通。
在我参与的一个电商项目中，为了快速响应市场变化，部分模块承担了多种职责。虽然短期内满足了业务需求，但后期的维护变得异常困难。那么，在面对业务快速变化的情况下，如何更好地在实践中遵循这两个软件设计原则，以确保代码的可维护性？
参考章节：第2章 个人技术和流程 - 2.4.1节 “设计有实际意义的软件工程作业”
问题三：开发与测试之间的矛盾如何化解？
在“软件测试”和“实战中的软件工程”章节中，书中强调了软件测试的重要性以及测试与开发的紧密关系。然而，在实际项目中，开发人员和测试人员之间常常存在矛盾。例如，书中提到：
“有些团队把开发和测试有意无意地对立起来，好像二者是矛盾的。一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想‘帮’测试人员找到缺陷。”
在实际项目中，如何建立一种有效的机制，让开发和测试团队更好地协作，而不是相互对立？一些公司通过设定共同的绩效目标来促进双方合作，但如何具体制定这些目标，才能既保证开发进度，又确保测试质量？
我曾在一个项目中看到，由于开发和测试人员的绩效目标不一致，导致双方在工作中互相推诿责任，最终影响了整个项目的进度。那么，如何从根本上解决开发与测试之间的矛盾，实现二者的平衡协作？
参考章节：第7章 实战中的软件工程 - 7.2.7节 “投资质量”；第13章 软件测试
问题四：团队模式如何适配不同类型的项目？
在“团队和流程”章节中，书中介绍了多种软件团队模式，例如主治医师模式、明星模式、社区模式等。不同的团队模式适用于不同类型的项目，然而在实际情况中，如何准确判断一个项目适合哪种团队模式？
以创新型互联网创业项目为例，这类项目需要快速响应市场变化，同时面临资源有限的挑战。在这种情况下，应该选择哪种团队模式最为合适？
我查阅了一些创业公司的案例，发现有的公司在初期采用社区模式，成功吸引了大量志愿者参与，但在后期随着项目规模扩大，管理变得混乱，影响了团队的协作效率。这让我困惑，在项目发展的不同阶段，团队模式应如何进行调整，以更好地适应项目需求？
参考章节：第5章 团队和流程 - 5.2节 “软件团队的模式”
问题五：如何更有效地进行用户需求调研？
在“需求分析”章节中，书中介绍了多种用户调研方法，如焦点小组、深入面谈、用户调查问卷等。不同方法各有优缺点，例如：
- 焦点小组可能存在讨论者受主持人影响、意见被主导的问题。
- 问卷调查可能无法获取深入的用户需求。
在实际项目中，如何综合运用这些调研方法，以获取更全面、准确的用户需求？许多企业会根据项目特点和目标用户群体，结合多种调研方法，但如何确定各方法的使用比例和先后顺序？
在我参与的一个校园APP需求调研项目中，我们采用了用户调查问卷和焦点小组的方式，但最终获得的需求仍不够深入和准确。那么，如何才能更好地组合这些调研方法，提高需求获取的质量？
参考章节：第8章 需求分析 - 8.3节 “获取用户需求——用户调研”
