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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程的理论方法，在实践中提高软件开发和团队合作的能力
这个作业在哪个具体方面帮助我实现目标	帮助我了解软件工程的总体框架，构建理论基础

问题一：PSP（Personal Software Process）是否适用所有的团队？这与软件工程要求的敏捷开发是否有一定的冲突？

在现代软件工程讲义 2 工程师的能力评估和发展，作者提到：

PSP的目的是记录工程师如何实现需求的效率, 而不是记录顾客对产品的满意度。

PSP强调通过严格的需求分析，设计，代码审查和审查来减少缺陷，开发者通过记录和分析错误，能够更好地理解并改进自己的开发过程，从而提高代码质量，即PSP强调软件开发的工程化方法，帮助开发者从“编码者”转变为“工程师”，注重过程管理和质量保证。但是，PSP是否适用于所有的团队？它是否和敏捷开发有所冲突？我们都知道，PSP强调详细的数据记录和过程管理，但对于小型、简单或快速开发的项目，PSP 的严格过程可能会显得过于沉重，导致效率降低。此外，PSP 的灵活性较差，其过程较为固定，可能不适合需要高度灵活性和快速响应的开发环境（如敏捷开发）。因此，我们是否应该灵活应用PSP，对于不同的类型的团队而“因队制宜”呢？

问题二：单元测试是否只能由代码作者来写？这样做的利弊是什么？

在现代软件工程讲义 2 开发技术 - 单元测试 & 回归测试中，作者提到：

单元测试必须由最熟悉代码的人（程序的作者）来写。

诚然，代码的作者最了解代码的目的，特点和实现的局限性，所以，由代码的作者编写代码测试能提高团队效率，节省不必要的事件浪费。然而，根据我的实践经验，代码作者在编写代码测试的时候容易受到之前编码的“思维定势”影响，编写者在编写代码时往往有特定的思维模式，这种思维模式可能会限制他们在测试时发现潜在的问题。此外，代码的编写者在编写单元测试时可能对异常分支和边界条件覆盖不足。因此，我认为测试代码的责任不仅仅需要代码作者，可能还需要独立的测试团队。

问题三：结对编程中“随时的复审和交流”是否真的能保证质量？

在现代软件工程讲义 3 结对编程和两人合作 中，作者提到：

结对编程让两个人所写的代码不断地处于“复审”的过程，正如前所述，复审是不断地审核，提高设计和编码质量的过程，结对编程让复审随时随地发生，这样才能及时地发现问题和解决问题，避免把问题拖到后面的阶段。

在结对编程中，任何一段代码都至少被两双眼睛看过，两个脑袋思考过。代码被不断地复审，这样可以避免牛仔式的编程。但是“随时的复审和交流”是否一定能保证质量？在某些情况下，结对编程中的实时交流可能会分散注意力，尤其是在处理复杂问题时，过多的讨论可能导致效率下降。此外，有些问题可能需要更深入的研究或独立的思考，结对编程的实时性可能无法完全替代个人的独立思考时间。因此，我们要怎样保证既有足够的复审和交流，又能够有独立思考的空间？

问题四：Scrum 强调的 self-managing（自我管理）、self-organizing（自组织）、cross-functional（跨职能） 团队理念是否过于理想？

在现代软件工程讲义4 Scrum/Sprint中，作者提到：

Scrum 的团队

Scrum对团队的要求很简单：self-managing， self-organizing， cross-functional， 但是这很难做到。软件项目的团队各式各样 (各种团队类型的介绍)， 假设一个团队做得还不错，现在要变成 Scrum 流程, 那团队要做下么的改变:

1. Self-managing: 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自我管理”不等于“没有管理”。
2. Self-organizing: 以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3. cross-functional: 以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责，自己搞定spec, 和别人沟通, 同时自己搞定测试。

Scrum对团队的要求真的很简单吗？我认为答案应该是否定的，Scrum 强调的 self-managing（自我管理）、self-organizing（自组织）、cross-functional（跨职能） 团队理念看似理想，但在实际落地中往往面临巨大挑战。

自我管理是否可行？我们知道“总结不足并提出改进”依赖个人的主观能动性，并非所有成员都愿意主动反思，尤其是在高压环境下。若团队缺乏心理安全感，回顾会可能流于形式，改进措施难以落实。

自组织是否可持续？“团队共同负责”容易导致权责模糊，传统团队中，责任边界清晰（如领导分配任务）；而自组织模式下，若无人主动承担责任，关键任务可能被忽视。因此自组织依赖团队成员的高度协作意愿和信任基础。若团队文化尚未成熟（例如存在竞争关系），强行推行自组织可能适得其反。

跨职能是否过于理想？“每个人全面负责”违反专业分工原则，要求开发人员同时编写需求文档（Spec）、设计、测试，可能导致工作质量下降。因此“跨职能”不应该等于“全栈”。“每个人都全面负责”可能牺牲效率和质量。

问题五：团队中PM，Dev，QA职责是否应该模糊化？

在现代软件工程讲义 5.1 软件的质量保证 (QA) 和测试 (Test) 中，作者提到：

团队中的管理人员/PM 负责分析市场, 设想功能, 定义用户到底要什么 – Why & What.

团队中的开发人员/Dev 负责实现功能, 搞清楚怎么才能满足用户的需求 – How.

团队中的测试人员/QA 搞清楚我们的软件是否满足了用户的需求 – Whether.

诚然，上述用户的分工方式使得每个角色职责分明，属于传统的瀑布模型。但这样做是否真的高效？对此，我提出一下质疑：

Why & What 完全由PM掌控？如果PM真的单方面定义用户需求，那么可能导致开发/测试人员缺乏业务上下文，沦为"需求执行机器"从而降低开发效率。

How 仅由开发决定？开发如果只关注How，可能忽略业务目标，导致解决方案不符合实际需求，也就容易带来技术傲慢风险。

Whether 由QA单独负责？测试如果只在最后检查Whether，可能无法早期参与，无法预防缺陷。此外，测试人员后期介入时，错误成本已指数级增长，从而使得成本大大增加。

因此，我们是否可以角色边界模糊化？即保证PM的开发者化，开发者的用户思维训练化，QA的架构参与权。