[I.1] 个人作业：阅读和提问
[I.1] 个人作业：阅读和提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 学习软件工程的基础知识，在结对以及团队任务中实践各种开发方法与流程，学会如何与其他人更好地合作，和团队成员们一起开发一个让我们值得骄傲的项目 |
| 这个作业在哪个具体方面帮助我实现目标 | 学习相关基础知识，帮助我了解软件工程的全貌，并对其中的一些理论知识有自己的思考 |
1.两人结对编程的过程中双方一定拥有平等的决策权利吗？
第四章 87页 4.5.4向我们说明了如何结对编程，其中第5条指出：
两人结对，尽管级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
我并不完全同意两人结对的过程中双方都拥有平等的决策权利。在我看来，实践中的决策权的分配往往受经验以及一个人在团队中地位的影响。
- 经验和知识的不对等影响决策权。资深开发者通常具有更丰富的经验，对架构、设计模式、代码优化等问题有更深入的理解，因此他们的建议在团队中更有分量。而初级开发者可能缺乏系统性思考能力或不了解项目的长期技术战略，在关键决策上，他们的意见往往无法与资深开发者等量齐观。
- 现实团队中不同的角色进行结对也可能会造成决策权利的不平等。结对编程虽然提倡平等协作，但并不意味着组织结构和团队职责会被完全打破。资深开发者通常在团队中承担指导责任，而初级开发者更倾向于学习和执行。
是否应该通过选择两个资历、地位相差不大的人来结对使得双方拥有相对平等的决策权利？
2.以质量为先的TSP原则能否和以效率为先敏捷开发兼容？
第五章 5.3.7 中提到的TSP的原则指出：
要尽量使用成熟的技术和做法、尽量多地收集数据以及专注于提高质量、做全面而细致的设计工作
第六章 6.1 中提到的敏捷开发原则指出要尽早交付有价值的软件、发布软件的时间间隔能短则短、保持简明
以及可用的软件是衡量项目进展的重要指标
通过了解我得知我们的软件工程课程很注重敏捷开发，因为它能够很高效地发现项目搭建过程中的痛点并推进项目进度。通过阅读上述两章中的相关内容我发现敏捷开发和TSP原则存在很多矛盾之处。由于TSP原则是优秀模式和流程的共同点，于是我便提出问题：敏捷开发能否与TSP兼容来提升开发体验？
在查阅资料后我发现TSP原则和敏捷开发都同时注重质量和效率，只不过方式有所不同。TSP 通过数据驱动的质量管理，敏捷通过持续反馈和测试来提升产品质量；TSP 依赖详细计划和数据跟踪，敏捷依靠短周期迭代和灵活调整来保证开发效率。因此，可以结合 TSP 的数据管理和敏捷的灵活性来寻找最适合某个项目的开发流程。
我还查到了一些TSP原则和敏捷开发结合的实例：航空航天、银行、医疗等行业会使用TSP 的数据收集方法，同时采用Scrum 进行敏捷开发。微软等大公司有些团队会使用 TSP 风格的数据分析，但保持敏捷的开发模式，以优化团队生产力。
所以TSP原则和敏捷开发并不是互斥的，在不同的项目、不同的团队中适当地加入TSP和敏捷开发元素或许能够产出更好的产品。
3.WBS模型如何合理地将工作分而治之？
第八章 8.7 讲述了如何利用WBS将大型交付件分割为小型并举出了WBS的几个要点：
所有子节点要覆盖全部父节点、子节点不相互覆盖、叶节点要足够小以及从结果出发构建WBS。
分治是面对复杂工程问题时很不错的解决方法。在阅读完瀑布模型和敏捷开发的章节后我认为WBS适用于瀑布模型，但在敏捷开发环境下过于静态，难以保证开发效率。而且在拆解工作的过程中如何保持任务的先后顺序、保证任务见的依赖性不被破环也是一个很重要的问题。
4.既然有不受欢迎的典型用户，那我们该如何降低我们项目对于这些用户的“吸引力”呢？
第十章 10.1.3 怎么定义典型用户 中提到不受欢迎的典型用户是有可能出现在我们的系统当中的，
随后便大段举例论述我们如何通过典型用户来深入理解用户的需求。
阅读完上述的一段内容后我发现“不受欢迎的典型用户”只是被提了一嘴，之后便没有说明这一角色在帮助我们深入理解用户需求中的作用。根据我的经验，不受欢迎的典型用户的作用在于引导我们思考如何降低他们在系统中的出现频率。通过查阅资料，我整理出来了一些比较常见的方法。通过技术手段防护，如手机号/邮箱验证，防止批量账号注册；检测异常行为，如果短时间内大量请求数据，封禁 IP。还可以通过用户引导降低滥用风险，比如对新用户和可信用户进行分级，新用户只能使用有限功能，避免滥用。
不过我认为这些资料还不足以解决我的疑惑。在我看来典型用户仅仅是开发人员对用户的一种假设和模拟，掺杂了很多的主观因素，并不能体现用户的真实情况。这时书中所提到的用户调研便尤为重要，真实的用户信息与体验可以让我们排除掉那些不合实际的典型用户，更准确地理解用户的需求。但是对于那些不受欢迎的典型用户我们很难进行用户调研，因为他们的很多行为都游走在法律的边缘，甚至是犯法的。
因此我认为对于不受欢迎典型用户的分析是缺失的，如何降低项目对于不受欢迎典型用户的“吸引力”是一个值得探讨的问题。
5.团队效率和团队影响力之间有什么关系？团队效能曲线的趋势为什么是这样的？
下面这张图片来自于第十七章 图17-3 团队效能曲线与假团队
书中原文提到：从各自为政的“工作组”到各种阶段的团队状态之间往往还有一个“假团队”阶段。“假团队”阶段主要是成员之间面和心不和，效率不如工作组，然而图中假团队的团队效率和工作组相当，区别只在于影响力。于是我便上网搜索团队效率和团队影响力之间的关系：一个高效的开源团队能够快速修复 Bug、优化性能、发布高质量版本，从而让更多开发者信赖并推广它，最终提升行业影响力；如果团队的影响力变大，可能会带来更多外部合作、用户反馈、行业压力，这可能让团队花更多时间在非核心任务上，导致效率下降。也就是说团队效率和团队影响力并没有直接的关系，团队效能图确实应该是一条曲线。
书中提到的“工作组”是一种各自为营、临时拼凑的状态，而“假团队”虽假但已经形成了一个团队，其内部应该已经形成了一定的分工。所以我认为“假团队“的影响力或许是高于“工作组”。
综合上述两段文字，我对团队效能曲线的疑惑可以分为两点：1.书中说工作组效率高于假团队，这与17-3相矛盾。2.通过我的分析我认为假团队的影响力会高于工作组，这也与17-3矛盾，不过这可能是因为假团队（工作组）之间也存在差异。
6.RASCI模型中S（support）权责模糊，是否有存在的必要？
第十七章 17.4的最后部分提出了RASCI模型来帮我们在跨部门合作时理清不同部门的权力、责任和流程：
R负责做好具体的事情；A对人物负权责并有批准的权力；S负责对任务提供支持；
C负责咨询项目所需的信息；I负责在事后及时通知结果。
RASCI模型的作用就是使得跨部门合作的权责被清晰地分配，但是S所代表的支持可以表达的含义又过于广泛。我可以认为模型中的C和I都属于对项目的一种支持。
S角色可能显得多余，甚至会增加沟通成本和管理复杂度，所以S是否还有在这个模型中存在的必要？
