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

[I.1] 个人作业：《构建之法：现代软件工程》阅读与提问

项目	内容
这个作业属于哪个课程	2025年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习现代软件构建的工程方法，锻炼团队协作能力。在团队的共同合作下产出符合流程的高质量软件。
这个作业在哪个具体方面帮助我实现目标	帮助构建现代软件工程方法的基本知识框架，学习如何提出有价值的问题。

问题1：结对编程是否只适合于二者技术水平差距不大时？

• 问题来源：书P82页中提到了不适合结对编程的例子。其中提到：如果不能有效发挥出”领航员“的作用，那么无需结对。

• 问题描述：对于结对编程而言，驾驶员负责编码等开发工作，领航员负责审阅与指导。在二者水平差距不大时，就如书中所说，能在一定程度上提高软件的质量以及开发的效率。但是，如果二者水平存在着明显差距，我们设想以下两种情况：

  1. 水平较高的一位做驾驶员，水平较低的一位做领航员：领航员需要花费更多的时间来理解驾驶员的代码，既难于实时地审阅驾驶员的代码，也难以提出丰富的解决方法。在很多情况下反而是驾驶员成为了主导。领航员的作用难以体现，结对编程实际更多是驾驶员的个人车技展示。
  2. 水平较低的一位做驾驶员，水平较高的一位做领航员：在领航员看来，驾驶员需要花费比自己更多的时间理解自己的构想，同时需要频繁审阅驾驶员的文档。在这种情况下，领航员会认为结对编程的效率反而更加低下，难以高效完成高质量任务。

  在二者水平差距较大时，无论谁做领航员，谁做驾驶员，都无法达到结对编程理想的情况。特别是在面临短期高强度任务时，这样的方式不仅难以发挥二者的能力，反而压力全部给到了技术水平更高的人。但实际环境下，分配和自己技术水平相近的人员来进行结对编程的概率是不高的，那么从总体来看，结对编程带来的效果是否还能够达到预期？

问题2：用户需要的痛点解决方案是否等同于需要一件产品？

• 问题来源：书第8章需求分析，有这样一段话：

我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。但是用户往往也不了解颠覆型的创新。例如，不但用户不太能描述自己的需求，有时候开发者也陷入固定的“产品导向”的思维，开发网站的，就认为用户一定需要一个网站；开发移动应用的，就认为用户一定需要一个 App。事实上，用户并不需要“产品”，用户需要解决痛点的方案”。

• 问题描述：用户自然需要解决问题的方案，但是这个解决问题的方案最终以何种形式呈现？是已有产品的新功能，还是一个全新的app？当然，一个全新的app除了要包含以前app的全部功能，还需要解决新痛点的功能。但是无论是已有app的新功能，还是全新的app，这个解决方案对于项目团队来说最终结果都是做出一件产品，产品就是我们向用户提供的解决痛点的方案。因此，我个人认为，用户需要解决痛点的方案——产品只是其中一种表现形式。但是对于大部分项目团队而言，这个方案的最终结果就是产品。

问题3：PM一定不做与开发和测试相关的工作吗，小型团队与大型团队中PM的职责是一样的吗？

• 问题来源：书P185页提到PM负责与开发和测试之外的所有事情。
• 问题描述：在大型团队中，因为开发人员(小组)以及测试人员的众多，一遇到问题就把所有人聚集在一起来沟通效率是低下的；除此之外，还有很多与开发测试无关的工作——汇报，调查分析等等。这时，一位全职的PM的确能够起到非常重要的作用，他可以带领团队高效地完成项目活动。但在小型团队——尤其是像软件工程团队项目这种7人以下，但任务又较为紧张的情况下，一位PM其实更需要快速的带领团队厘清需求，快速开发。而在开发人数并不多的情况下，一位了解团队项目的PM也参与到开发或测试当中我认为是有好处的。一方面，PM更加清楚团队项目的真实进度与开发环境，有助于进一步的调整；另一方面，也提高的团队的效率。因此，我认为，在小型项目中，其实并不非常需要一位全职的PM。当然——PM是需要的，但是这位PM显然也可以参与到项目的开发和测试当中。所以针对一个这样的项目，不一定只有1个PM。有两个或者更多，甚至尝试PM轮值也许也是一个提高团队工作力的方法。

问题4：场景和用例的区别是什么？它们之间的关系又是怎样的？

• 问题来源：在第10章典型用户与场景当中，作者介绍了场景和用例这两个概念。(P210)场景是典型用户为了达到一个目标所必须经历的过程，也可以叫故事。(P214)而用例是也是一个简单的故事。
• 问题描述：场景和用例在概念上有相似之处：它们都是用户为了达到一个目标而需要经历的过程，是一个故事。它们都有对用户以及达成目标的描述。那既然如此，场景和用例到底有什么区别？它们之间有何联系？
• 相关资料与书本解释：作者在书中描述了一个用例包含的基本元素：标题、角色、主要成功场景、扩展场景。这说明，用例实际包含了不止一个场景。查阅资料后，我也发现，用例就是一组相关的成功和失败场景的集合。例如，一个用户在ATM机上取钱的用例，实际上包含了用户插卡登录，用户取款这两个场景。其中每个场景还恶意进一步拓展：如登录密码错误，取款余额不足等等场景。我们可以用讲故事方法来把这个用例讲述出来。场景可以说是每一个用户与系统交互的最小单位，是我们开发的基础。各个场景就可以组成一个完整故事，也就是我们说的用例。

问题5：新技术到来如果会迫使用户改变软件使用习惯，变相降低用户体验。需要先放弃新技术的应用，保证用户体验吗？

• 问题来源：书第12章用户体验中(P260)，作者提到了一个关于GE公司的故事：

20 世纪90年代，韦尔奇注意到核磁共振机的通道特别狭窄，在长达几十分钟的检查过程中，病人常常有得了幽闭恐惧症的感觉。韦尔奇做过类似的检查，深有体会。他问专家，能不能把通道做得宽一些？专家说那样会降低扫描成像的质量。他又问，对于那些不需要太高精度的检查，能否牺牲一些成像质量，换取用户的良好体验呢？专家说，他们会考虑的…然后就没有下文了。不久，竞争对手推出了宽通道的扫描设备，并夺取了大量的市场份额。GE被动迎战，花了两年时间才赶上对方。

• 问题描述：在这个故事中，GE研发人员之所以并没有把宽通道的设计纳入更新重点，无非是因为这样会降低产品质量。但事实上，用户体验也是产品质量重要组成部分。许多公司其实也面临这样一个问题，如果一个提高产品质量的新技术的应用，会降低用户体验感，该如何进行抉择呢？我参考了一些公司的做法：包括苹果、微软等，它们的核心处理方法一直是：秉持着对新技术的看重，但是一定把用户体验放在首位，这二者都不可以放下。新技术是一个产品的核心竞争力，也是一个产品能否进入用户法眼的第一要素。因此，如果单纯因用户体验而放弃推广一项新技术是极不明智的，这一定会让企业付出更长时间以及更多代价。相反，企业在新技术的研发过程中，就一定要融入用户体验的考虑。也就是在这个过程中，也要为用户的各种体验做出相应的设计和调整。在保证新技术的推广的同时，确保大部分用户对产品的使用依然保持积极评价。当然，如果在反复的试验当中，都无法做到二者的统一，我们反而更应该考虑这项技术是不是真的能对我们的产品产生良好的作用。