[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	提高工程能力，熟悉团队开发过程，积累沟通协作经验
这个作业在哪个具体方面帮助我实现目标	总结收获

学期之初，我在[I.1] 个人作业：阅读和提问中提出了六个问题；如今一个学期过去，经历了结对项目与两个阶段的团队项目，在这里结合这一学期的实践，对当初的问题做一个回顾和总结。

一、问题回顾与解答

问题一：PSP与团队流程的交互方式

当初的问题：PSP是团队中每个环节内的重复内容，还是与整体团队开发流程是平行关系？

现在的理解：经过整个学期的实践，我认为PSP与团队流程的关系既不是单纯的"嵌套"也不是"平行"，而是一种渗透与支撑的关系——PSP是每个成员在团队框架内执行任务时的"个人操作系统"，为团队流程提供数据基础和执行力保障。

在团队项目中，我切身体会到这种关系。Scrum或TSP定义了团队的整体节奏——冲刺计划、每日立会、评审与回顾——但每个成员如何完成自己认领的任务，靠的正是PSP式的自我管理：任务分解、时间估计、记录实际耗时、自我测试、代码复审。没有这些个人层面的 discipline，团队的计划板上的燃尽图就会失真，站会上的进度汇报就会变成"大概差不多了"这样的模糊表述。

DeepSeek在学期初给我讲的那个"小王"的故事，现在回头看，几乎就是我们团队的真实写照——设计复审提前避免了接口问题，代码复审发现了潜在缺陷，单元测试覆盖了边界情况。PSP让每个成员有能力做出可靠的估计，让团队能实时了解进度，将质量控制从测试阶段前移到开发阶段。

问题二：QA与Test的边界

当初的问题：为什么课程项目中很少提及"QA"角色？Test是否已经足够覆盖质量保证？

现在的理解：这个问题在实践中得到了最直接的解答。在我们团队中，确实没有设置专门的"QA"角色，但质量保证的工作从未缺席，只是被分散承担了。

需求阶段，大家一起讨论NABCD，确保需求合理可行；设计阶段，设计文档经过团队复审；实现阶段，每个人写单元测试、做代码复审；测试阶段，有专门的测试人员执行系统测试。QA所代表的"全过程质量保障"职责，实际上被团队在每个环节共同分担了。

这让我理解了为什么课程项目中很少出现"QA"这个角色名称——不是因为质量不重要，而是因为在5-6人的小团队中，质量是每个人的责任，而不是某个特定角色的专属工作。邹欣老师对QA和Test的区分——QA是贯穿始终的综合性活动，Test是验证代码的具体环节——在课程项目的语境下，前者由团队共同承担，后者由测试人员负责，分工清晰。

问题三：结对编程中技术水平不相等时的角色分配

当初的问题：两人水平不相等时，如何分配角色？水平高的一方当驾驶员是否会让领航员流于形式？水平低的一方当驾驶员是否会导致效率下降？

现在的理解：结对编程实践中，我对这个问题有了更具体的认识。

首先，初始角色的分配并不关键，关键的是频繁轮换。我和搭档在结对编程时，最初是我写代码、他看，大约半小时后我们互换。这种轮换让我们各自体验了两种角色，也避免了一方"当观众"的尴尬。

其次，水平较低的一方当驾驶员时，效率确实会下降，但这种"下降"是有价值的，它是一次实时的知识传递。领航员在这个过程中不断指出问题、解释思路，驾驶员一边写一边学。虽然代码产出速度慢了，但两个人的能力差距在缩小，后续的协作成本会降低。这印证了讲义中提到的"不间断地复审"的价值。

至于"主副驾双待"的说法，我的理解是：不是让两个人同时写两段代码，而是让两个人在同一段代码上保持高度的"双核"状态——驾驶员在敲键盘，领航员在思考更高层次的设计和潜在问题，随时可以接手。这种状态需要双方都有一定的投入度，而轮换正是维持这种投入度的有效手段。

问题四：Scrum在课程小组中的适配

当初的问题：课程小组无法每天投入，是否还应该借用Scrum思想？每日例会记录是形式主义还是确有帮助？

现在的理解：这个问题在整个学期的实践中得到了充分验证。

我的结论是：Scrum的核心思想完全适用于课程小组，但形式需要调整。

我们团队的做法是：将"每日立会"调整为"每次集中开发前后的同步会"——集中开发前快速对齐各自的任务和目标，集中开发后同步进展和遇到的问题。这实际上保留了Scrum"任务拆解、优先级排序、定期回顾"的核心原则，只是放弃了形式上的每日同步。

至于教学日历要求的"2周实现阶段至少10次每日例会记录"，我的体会是：这确实有帮助，但不在于"每日"的形式，而在于"规律性同步"的习惯。即使只是用微信发一条"今天做了XX，明天做XX，遇到了XX问题"，这种规律性的同步让团队始终保持着对彼此进度的感知，避免了"各做各的，最后发现做的东西对不上"的悲剧。

关于任务分配冲突，我们团队采用了贡献分加权的方式，对于难度大或不太吸引人的任务，在贡献分分配上给予更高的权重。这种方式虽然不能完全解决"有人就是不想干"的问题，但至少让愿意承担困难任务的同学得到了公平的回报。

问题五：课程项目中如何定义"用户"

当初的问题：课程项目的"用户"是谁？自我代入的persona是否准确？

现在的理解：这个问题在我们的实践中经历了一个"先设计、后验证"的过程。

我们团队在需求阶段并没有进行真实的用户调研，而是基于自己和身边同学的经验，设想了一个使用场景，构建了 persona，并据此设计了功能。这样做的好处是启动快、不需要额外的时间成本，但风险在于——我们以为的"用户需求"可能只是我们自己的想象。

这个风险在 alpha 版本发布后真实地暴露了出来。我们找了目标用户来试用，收集了他们的反馈，发现了一些意料之外的问题：

• 有些我们觉得理所当然的操作路径，用户却感到困惑；
• 同时，用户提出了一些我们从未想到的需求，而这些需求在他们看来是"必须的"。

这些反馈让我们在 beta 阶段对产品做了较大的调整。回过头看，如果在需求阶段就进行哪怕少量的真实用户访谈，很多问题可以更早发现。

但另一方面，alpha 版本作为一个"可运行的提案"，让用户有了具体的参照物，他们的反馈反而比抽象的问卷调查更精准——因为用户能看到"这个功能长什么样"，然后说"这不是我想要的"。

这又产生了新的问题（）

至于"不受欢迎的用户模型"（比如恶意用户），我们团队没有深入实践，但这个思考方向是有价值的。在安全设计中考虑"系统可能被如何滥用"，本身就是一种前瞻性的质量保障思维。

问题六：轻量级同步机制

当初的问题：在没有专业工具的学生小组中，如何管理代码冲突和协作？

现在的理解：这个问题在团队项目的实际协作中得到了充分验证。

我们最终采用的方案结合了"事前预防"和"事后协调"两种思路：

1. 任务分解时尽量做到模块隔离：确保不同成员的工作落在不同的文件或模块上，从源头减少冲突的可能。
2. Git + Pull Request流程：每次合并前先拉取最新代码，解决冲突后再提交PR，由其他成员进行代码复审。

事实证明，最有效的工具不是TFS或Jira，而是清晰的任务分解和及时的沟通。即使所有人都集中在同一个时间段开发，只要模块划分清晰、沟通及时，冲突是可以被有效管理的。

三、是否产生了新的问题？

有。 在经历了 alpha 测试和 beta 迭代之后，我产生了一个新的问题：

用户反馈应该尽量早地引入，还是等到有了可运行的版本再引入？

我们团队的做法是后者——先凭自己的理解做出来，alpha 后再请用户试用。这个做法的优点是：用户对着一个“活”的产品提意见，反馈非常具体、可操作，比对着需求文档空想要精准得多。但缺点也很明显：有些基础性的设计缺陷在 alpha 阶段已经固化，即使收到反馈，beta 阶段的修改成本也很高，甚至有些改动根本来不及做。

相反，如果早在需求阶段就去访谈用户，或许能避免方向性的错误，但那时项目还没有任何可演示的东西，用户可能自己也不清楚想要什么，给出的需求往往是模糊甚至矛盾的。

所以，我的新问题不是一个有标准答案的问题，而是一个权衡问题：在课程项目的有限时间和人力下，用户反馈的“时机”应该如何选择？是“早但模糊”，还是“晚但精准”？有没有一种折中方式，比如在需求阶段做一次轻量级访谈，在 alpha 阶段再做一次更深入的使用测试，两次反馈相互补充？这门课只给了我们一次 alpha 测试的机会，如果时间允许，我希望能探索这种多轮、渐进式的反馈机制，看看能否找到最佳的平衡点。

这个问题我暂时没有完美的答案，但它让我意识到，用户反馈不是一次性的活动，而应该是一个持续、分阶段的过程，每个阶段的反馈类型和价值不同。未来的项目中，我会更刻意地设计反馈的节奏。

四、各阶段学到的知识点

需求阶段：NABCD模型

在需求分析中，我学到了用NABCD框架来结构化地思考需求。以前做需求就是"想到什么写什么"，但NABCD强迫我们从"用户真正需要什么"出发，而不是从"我们想做什么"出发。这个框架让我们的需求分析更有说服力，也更容易向他人传达项目的价值。

设计阶段：设计复审的价值

在alpha阶段的设计中，我们提交了设计文档后进行了团队复审。复审中发现了一些方案设计上的问题，对于部分技术栈，更改了最后的选择；设计复审让我们在写代码之前就发现了问题，避免了后期的返工。这让我深刻理解了"在错误引入的阶段修复它，成本最低"这个道理。

实现阶段：代码规范的重要性

在团队项目中，我们制定了代码规范并严格执行。以前我觉得代码规范是"形式主义"，但多人协作时，统一的命名风格、缩进规则、注释格式，让代码的可读性大大提升，代码复审的效率也明显提高。

测试阶段：单元测试与代码覆盖率

在结对编程中，我养成了先写单元测试再写代码的习惯。这个习惯让我在后续的团队项目中受益匪浅——每次修改代码后运行测试，能立刻知道有没有破坏已有的功能。

发布阶段：用户反馈的收集与处理

在beta阶段发布后，我们收集了真实用户的反馈。有些反馈是我们预料之内的，有些则完全出乎意料——用户对我们的某个"亮点功能"完全不感兴趣，反而对一个我们觉得"很普通"的功能赞不绝口。发布不是终点，而是获取真实反馈的起点。

维护阶段：缺陷管理的优先级

在项目发布后的一周内，我们收到了几个Bug报告。我们学会了用严重程度和影响范围两个维度来给缺陷排优先级——影响核心功能且用户频繁触发的Bug优先修复，边缘情况的小问题可以放一放。

五、个人心得

在团队项目中，最困难的部分往往不是技术本身，而是沟通、协调、分工、决策这些"软技能"。一个人的代码写得再好，如果无法与团队有效协作，项目的整体质量仍然无法保证。

还有，实践是检验真理的唯一标准；学期初看书时，NABCD、Scrum、PSP这些概念都只是纸面上的文字。只有真正经历了需求分析、冲刺计划、代码复审、发布反馈这些环节，这些概念才变成了我自己的理解。

一个学期的课程结束了，但软件工程的学习才刚刚开始。感谢这门课给了我一次完整的、真实的团队开发体验。