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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	将软件工程理论与实践相结合、提升批判性思维和团队协作能力
这个作业在哪个具体方面帮助我实现目标	通过让你分析实际项目中流程与管理的各种问题，帮助你在理论学习的基础上掌握实践中的平衡与优化方法。

问题1

我看了这一段文字：“软件开发过程中的各个阶段——包括需求分析、生成设计文档、设计复查、具体编码和测试……PSP在设计复查阶段明确要求和同事对设计文档进行审核，以确保设计质量”（出自2.3章节中关于PSP各阶段的描述），有这个问题：

在团队中高效开发代码时，是否需要严格遵循PSP中的每一步，尤其是设计复查阶段？

我查阅了相关资料，有研究指出：

• 有效的团队沟通和实时反馈机制可以在一定程度上替代形式化的设计复查，从而提高开发效率。

• 而一些业界专家则认为，虽然形式化流程显得繁琐，但它能显著降低后期维护成本，因为大部分代码的阅读时间远超过编写时间。

根据我自己的实践经验，我在实习过程中发现：

• 起初需要做一个大致设计并与同事大量沟通以明确目标；

• 在编码过程中，我会及时询问同事意见并遵循团队代码规范；

• 经过反复讨论和仔细的code review，我深刻认识到每一次详细审查都对代码质量和个人成长有正面影响，但也感觉到了流程带来的时间消耗。

然而，我还是不太懂，我的困惑在于：

• 在实际项目中，怎样平衡形式化流程（如PSP要求的设计复查）与高效开发的需求？因为设计的点难免与实际开发有出入,一些细节必须要在代码开发时才会发现,而这时花费大量时间在设计复查上与快速开发相违背。

• 怎样对设计复查等流程进行适当的简化或调整，使其既能确保质量，又不会过多拖慢开发进度？

这种疑问源于我在实际工作中对沟通和即时反馈依赖较大，而书中强调的完整流程似乎与我实际经验中的快速迭代存在一定冲突。

问题2

我看了这一段文字：“结对编程让两个人所写的代码不断地处于‘复审’状态，正如前所述，复审是不断地审核，提高设计和编码质量的过程……在我的经历中，如果同伴的coding经验远超于另一位，是会影响到整个团队的进程的。也并不是所有内容都需要结对，只有一些卡点才需要讨论。”（出自4.5结对编程章节，关于结对编程优劣及适用情况的讨论），有这样的问题：

在实际项目中，结对编程是否能比两个人各自独立开发再进行严格的code review更有效率？

我查阅了一些资料，发现有观点认为结对编程通过实时互补和不断的复审可以及时发现问题、减少返工，从而提高开发质量和效率；而另一些研究则指出，如果结对编程双方水平悬殊，或者不适当地强制所有任务都使用结对编程，其效率优势可能并不明显，甚至可能导致资源浪费。

根据我的实践经验，我在参与结对编程时体会到：

• 两个程序员一起工作可以迅速交换意见、共同解决技术难题，减少了后期调试的时间。

• 但在某些任务中，结对编程可能显得冗长，尤其是对于一些熟悉且简单的模块，单独开发后再进行code review也能达到很好的效果。

我的困惑在于：

• 如何在实际工作中判断哪些任务适合结对编程，哪些可以采用独立开发加严格的code review？

• 是否存在具体的量化指标来证明结对编程在整体效率和代码质量上优于传统开发模式？

这种疑问源自于书中对结对编程优势的描述与我在项目中看到的现实差异，以及对“投入产出比”评价方式的质疑。

问题3

我看了这一段文字：“在Sprint阶段，团队成员每天开立会汇报‘我昨天做了啥、我今天要做啥、我碰到了哪些问题’”（出自6.1章节关于Scrum/Sprint流程的描述），有这样的问题：

如果我来主导一个项目，怎么做才能合理地执行Scrum，并有效地设定Sprint？

我查阅了一些资料，了解到敏捷开发的会议和Scrum流程并不只是为了简单地推动进度，而是为了帮助项目管理者识别风险、调整任务和解决团队内出现的瓶颈。例如，一些经验分享中提到，ScrumMaster不仅要组织每日立会，还要主动调度资源、调整任务优先级；而看板、燃尽图等工具也是用来监控任务进展和预估剩余工作的关键手段。

根据我的实践经验：

• 我们在项目中曾尝试让每个团队成员自行制定详细计划，并在每日立会中反馈进度，但实际情况往往是：有些任务卡点明显，需要更有经验的同事来解答疑问；

• 敏捷会议不单是为了“推”进度，更重要的是帮助识别风险，判断是否需要换人、调整任务或者改变计划。

因此，我的疑问是：

在一个实际的项目中，我该如何合理指定Scrum流程，如何设定一个既能充分识别项目风险又能确保团队高效推进的Sprint计划？如何建立这样的沟通机制？要点是什么？我的困惑源自于书中描述的理论与我实际与同事沟通、制定计划时观察到的情况之间的差异。

这种疑问对我来说非常重要，因为我希望在主导项目时，能既保证每个Sprint的目标明确，又能灵活调整流程以应对不断变化的风险和卡点。

现在我有以下一些想法：

1. 明确Sprint目标与范围

   1. 在Sprint规划会议上，与团队一起从产品Backlog中挑选优先级最高、风险较低、可以在Sprint周期内完成的任务。

   2. 明确每个任务的“完成定义”（Definition of Done），确保任务交付后能够满足验收标准。

2. 合理拆分任务与时间估算

   1. 将大任务拆分为可管理的小任务，每个小任务的预估时间尽量控制在几个小时到一天以内。

   2. 结合团队过去的实际工作数据（如velocity）来合理预测本次Sprint的工作量，避免任务堆积或过于宽松。

3. 团队协作与任务分配

   1. 让团队成员参与任务的估算和分解，鼓励他们根据个人专长和兴趣主动认领任务。

   2. 在任务分配时保持均衡，避免某个成员过载而另一些成员工作量过少，确保团队整体协作顺畅。

4. 灵活应对变化与风险管理

   1. 尽管Sprint期间尽量避免频繁变更，但仍需预留一定缓冲时间应对突发需求或卡点。

   2. 定期回顾与总结（Sprint Retrospective），通过团队讨论识别流程中的瓶颈，并在下一次Sprint中进行调整和改进。

5. 项目管理者与ScrumMaster的角色

   1. 项目主导者或ScrumMaster需要在Sprint开始前，充分了解团队的能力和历史数据，制定合理的Sprint计划。

   2. 在整个Sprint期间，通过每日例会及时收集团队反馈，判断是否需要调整任务分配或者重新评估任务难度，从而确保项目按预期推进。

是否还有一些需要注意的地方呢

问题4

我看了这一段文字：PM 最大的、最独特的贡献是什么？答：保持团队的平衡……在我们的团队中，实际上没有明确的需求和用户，大家都想参与开发积累经验，因此PM目前最大的任务就是将大家的产品调研总结，针对共性不足设计项目。那么，PM还可以做些什么呢？”（出自9.1章团队中不同角色任务和PM角色的讨论）

我查阅了一些资料，有观点认为优秀的PM不仅需要平衡团队，还要能有效整合产品调研、引导需求发现，并通过组织跨部门讨论促进团队协作；另有一些实践经验表明，在需求模糊的环境下，PM可以主动收集市场信息，设定初步的产品方向，进而引导开发与测试工作的协同推进。

根据我自己的实践经验，我发现：

• 在没有明确需求的团队中，PM需要通过调研和总结，制定初步的产品规格，并协调各方资源；

• 同时，PM也应当发挥桥梁作用，帮助开发人员和测试人员更好地理解项目目标，从而提高项目整体的执行效率。

但是我的困惑在于：

在一个需求不明确、大家都想参与开发积累经验的团队中，除了“保持团队平衡”之外，作为PM究竟还应当承担哪些具体职责和策略，才能更有效地提升产品质量和团队协作效率？

目前我的想法只有：是将大家的产品调研总结整理，然后去针对共性不足不断设计，优化自己的项目

问题5

我看了这一段文字如何兼顾用户体验，并考虑设计师何时与工程师进行交互？不同的团队成员和项目需求有不同的设计方案，而产品的细节设计，像[确定]与[取消]按钮的排列设计、静音功能是否涵盖闹钟铃声的关闭、以及动画的设计等，都是优化用户体验的重要因素。”（出自12.1章用户体验，涉及设计师、工程师的协作，以及产品设计细节的讨论），有这样的问题：

在设计中，如何平衡界面简洁和功能发现，合理地决定何时使用图标以及何时避免它？

我查阅了相关资料，有观点认为图标在移动端能使界面看起来更简洁，但同时也可能隐藏重要功能，降低用户的发现性。另外，也有实践案例表明，在桌面应用或需要高可见性导航的场景中，传统的菜单布局更为直观。

根据我的实际体验，我发现部分手机App采用图标后确实节省了界面空间，但有时一些网页用户反映找不到某些常用功能。

我的困惑在于：如何根据具体项目和用户类型来确定这种设计是否适用，或者是否应采用其他更易于发现的导航设计？

问题6

我看了这一段文字：……每个人的能力、投入和工作影响都有差异，简单按比例分配奖金会导致‘内卷’和不公平——比如同一团队的成员贡献差别巨大，却可能都被评为‘好’，或者优秀的人被稀释在平均主义之中。”（出自关于17.1章软件团队绩效管理和绩效考核的讨论） 问题： 在一个软件团队中，如何设计一个既能准确衡量个人贡献，又能防止按比例分配导致内卷和不公平现象的绩效评价体系？

我查阅了资料，有观点认为绩效评价应从任务完成、团队贡献和工作影响力三个维度进行综合考量，并结合同伴评价、客观数据（如代码质量、缺陷率）以及市场和用户反馈来进行多维度评价。同时，有实践者提到单一的量化指标容易引发内部竞争和短期行为。

根据我在团队中的实践经验，我发现：

• 如果仅仅依靠简单的比例分配，优秀者的贡献往往被稀释，而基础工作被过度奖励。

• 另一方面，过于复杂的评价体系又会使得绩效考核流程冗长，降低团队协作的积极性。

我的困惑在于：如何在设计绩效评价时，既能体现每个工程师的独特贡献，又能让奖金分配公平合理，从而促进团队长期成长而非引发内部内卷？