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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程的基础知识，在结对以及团队任务中实践各种开发方法与流程，学会如何与其他人更好地合作，和团队成员们一起开发一个让我们值得骄傲的项目
这个作业在哪个具体方面帮助我实现目标	总结这学期软件工程课学到的内容并回答学期初提出的几个问题

提问题博客链接

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

回答以前的问题，并谈谈收获与新的思考

在第一篇个人博客中，我提出了六个和软件工程实践相关的问题。经过课程学习、查阅资料以及团队项目的亲身实践，我对其中大部分都有了更深入的认识。

关于“结对编程时双方是否真正平等”的问题

对于“结对编程时双方拥有平等决策权”的问题，我最初认为实践中经验丰富的人往往更容易主导讨论，初学者的意见常常被忽视。不过，在结对编程《影舞蛇》任务中我和队友尝试了交替驱动和轮流主导的方式，比如每20分钟换一次“驾驶员”和“导航员”的角色，同时把分歧记下来留到每天讨论时再解决，这样可以减少“强者说了算”的局面。虽然实际完全平等并不容易实现，但通过设计一些机制，确实可以让彼此的声音更容易被听到。真正的“平等”不只是每个人都有发言权，更是团队有没有创造一个鼓励表达、允许犯错的氛围。

关于“敏捷开发能不能和TSP兼容”的问题

强调质量管理的TSP与追求快速迭代的敏捷开发在描述上看似存在冲突，但深入理解后发现，两者并不矛盾。TSP主张用数据来指导团队改进工作方式和提升软件质量，敏捷则强调快速响应变化。在项目中，我们在每次迭代后复盘成员的任务完成时间与缺陷情况，逐步建立了团队内部的“规矩”。这种做法让我们既能保持敏捷节奏，也能稳步提升质量，证明效率和质量是可以相辅相成的。

关于“WBS在敏捷开发中是否可用”的问题

WBS在传统项目中很好用，但我起初认为它在快速变化的敏捷开发中太死板。但实践中我们发现，可以先用 WBS 搭出大框架，然后再在每个迭代周期内逐步细化每个子任务，这种“滚动细化”的方式既有计划性，又保留了敏捷的灵活性。在我们团队项目进行的过程中先用WBS搭出项目框架，方便制定计划。在推进计划的过程中采用“结对编程”的敏捷开发思想攻破困难问题。所以WBS不是不能用，而是要用得“活”。

关于“不受欢迎的典型用户该怎么办”的问题

我们的项目在试用和发布的过程中都没有遇到这类“不受欢迎的典型用户”。我认为一个比较好的方法是在维护阶段加强对用户行为的监测，因为这些用户行为往往隐蔽、动态变化，这个问题值得进一步思考与探讨。

关于“团队效能曲线为什么是曲线”的问题

我在读书时对团队效能曲线产生了疑问：为什么“假团队”效率还不如“工作组”？团队项目初期我们也经历了“假团队”的阶段——开会不做决策、沟通成本高、合作不默契，感觉大家都在“各自为政”，效率还不如分开干活。所以我认同曲线的走势：一个团队刚刚组建时如果缺乏协作默契，确实可能“看起来是团队，效率却更低”。团队建设不是简单地把人凑在一起，而是需要花时间和心力去建立信任和有效沟通。

关于“RASCI模型中S（Support）的存在意义”的问题

最后一个问题是关于 RASCI 模型中“Support”角色到底有没有必要。一开始我觉得“支持”这个概念太模糊，好像可以被“咨询”或“通知”代替。但后来我们在部署项目时，确实有 DevOps 同学全程帮我们维护项目，并为服务器设置代理什么的，他不直接参与决策，但又非常关键。这时候用“Support”来描述他们再合适不过。因此，这个角色并不是多余的，只是我们以前对“支持”的定义太狭窄了。

在项目六大阶段中，我分别学到了什么知识点？

需求阶段
不能着急去想我们要具体实现哪些功能，而是先去想清楚用户到底是谁、他们会怎么使用这个产品。通过画图和讨论，我们对用户的使用过程有了清晰的了解，做出来的功能更贴近实际需求。

设计阶段
把项目分成了很多小部分，每一块都独立清晰。这样做的好处是，后面如果要加功能或者修改某个部分，不会影响到其他地方，省了很多麻烦和重复工作。

实现阶段
学会了借助CI工具，在每次代码提交后自动执行语法检查、单元测试和打包流程，显著减少了低级错误进入上线环节的风险。

测试阶段
在测试阶段不仅要确保前后端接口提前对齐，还要把重心放在功能测试与边界测试上，确保各模块在不同输入下都能稳定运行。通过持续补充测试用例更早发现问题，减少了系统上线后的不确定性。

发布阶段
我们在更新系统的时候采取了比较稳妥的方法，不是一口气全部替换掉，而是先让一小部分用户用上新版，没问题再推广给所有人，这样可以避免“刚更新就崩了”的风险。

维护阶段
系统上线后继续强化测试思维，对用户反馈的问题构造对应的测试用例并补充到测试库中，逐步提高了测试覆盖率。维护不仅是修 bug，更是不断完善系统的过程，测试在这一阶段依然是关键保障手段。

课程心得

回头看这些问题，软件工程这门课给我带来的最大收获是：软件工程并不仅仅是实践，它需要理论进行指导。很多看似“理论”的知识，其实都是为了解决实践中的痛点。这些问题一开始令我困惑，但在做中学、学中做的过程中，我逐渐把它们转化成了自己的经验。虽然仍有一些问题没有完全解决、值得继续探索，但我已经从一个“只会写代码”的学生，成长为了一个更懂工程思维的开发者。软件工程不是靠背书，而是靠在项目中“踩坑-思考-总结”走出来的。