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

项目	内容
这个作业属于哪个课程	2026 年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	参与一次完整的团队开发工作，熟悉项目协作的全部流程，积累有关软件开发、维护、运营、测试相关的经验，为实习与就业做准备
这个作业在哪个具体方面帮助我实现目标	通过回顾学期初提出的问题，总结个人项目、结对编程和团队项目中的实践经历，重新理解软件工程中的度量、协作、需求、反馈、测试、发布与责任

学期初的阅读和提问博客：[I.1] 个人作业：阅读和提问

一、学期初问题回顾

在学期初完成阅读和提问作业时，我提出了五个问题。现在回头看，这些问题都不是简单地通过教材某一页内容就可以回答的，它们更多是在问：软件工程中的方法论，到了真实开发或课程项目中究竟应该怎样落地。

经过一个学期的学习和实践，包括个人项目、结对编程、团队项目的 Alpha 和 Beta 阶段，以及中间经历的转会和协作调整，我对这些问题的理解已经不再停留在“概念上是否合理”，而是逐渐变成了“在有限时间、有限人力和不确定需求下，怎样让项目尽可能可控”。

1. PSP 在现代软件工程教育体系中的定位，是否应从“个人度量工具”转向“团队协作的基准参考”？

学期初我认为，PSP 如果只作为个人记录时间、缺陷和生产率的工具，价值会比较有限。因为在真实团队中，很少有人会长期以非常细的粒度记录自己的每一段开发活动。经过一个学期后，我的理解更加具体：PSP 的价值不在于强迫每个人机械地填表，而在于让我们意识到开发过程是可以被观察、被复盘、被改进的。

在个人项目中，我最直接的感受是，自己最初对时间的估计往往是不准确的。很多任务看起来只是“写一个功能”或者“修一个 bug”，但真正做起来会包含阅读已有代码、理解需求、调试边界情况、补测试、修改文档等一系列隐形成本。如果没有记录和回顾，我很容易只记得“我写完了”，却忽略“为什么这里花了这么久”。

到了团队项目中，PSP 的意义就不再只是个人效能，而是可以转化成团队协作中的参考。比如某个模块缺陷比较集中，某类任务总是延期，某个接口反复修改，这些都说明团队过程里存在问题。我们不一定需要严格套用 PSP 的完整表格，但可以借鉴它的思路：把感觉变成数据，把数据放进复盘，把复盘转化为下一轮改进。

所以我现在认为，PSP 在课程中的定位确实应该从“个人度量工具”扩展为“团队协作的基准参考”。它不是为了评价某个人写得快不快，而是为了帮助团队发现：时间花在哪里，缺陷出现在哪里，沟通成本来自哪里，下一轮迭代应该改进什么。

2. 结对编程在教学场景中的作用，是否更应聚焦于“思维碰撞”而非“代码输出”？

学期初我提出这个问题，是因为我担心结对编程被简化成“两个人一起写代码”，甚至变成“一个人写、一个人看”。经过结对项目后，我更确认：结对编程的核心价值确实不是简单提高代码产量，而是让两个人对同一个问题形成共享理解。

在结对过程中，驾驶员更容易关注当前代码如何写出来，领航员则更容易站在整体角度检查规则是否遗漏、状态变化是否合理、接口设计是否清楚。这个过程里最有价值的部分，往往不是某一行代码是谁写的，而是两个人在讨论中发现了原本没有意识到的问题。比如一个边界条件、一个状态转换、一个命名不清的变量，单独开发时可能会被自己自然跳过，但结对时就更容易被提出来。

不过，实践也让我意识到，不能把“思维碰撞”和“代码输出”完全对立起来。没有代码输出，讨论就容易停留在空泛层面；没有思维碰撞，代码输出又容易变成机械分工。比较理想的结对编程，应该是以可运行代码为目标，以讨论和互审为过程，以测试和复盘作为验证。

所以我现在对这个问题的回答是：教学场景中的结对编程确实应该更强调“思维碰撞”，但这种思维碰撞必须落在设计取舍、代码实现和测试验证上，而不是只写一份讨论记录。它训练的不是两个人写同一份代码，而是两个人如何一起理解问题、拆解问题、发现问题并对结果负责。

3. 敏捷开发中的“用户反馈”在真实项目中怎么操作？课程项目中怎么模拟？

学期初我最困惑的是：敏捷开发强调用户反馈，但课程项目很难真的找到大量真实用户。如果没有真实用户，我们是不是只能“假装敏捷”？经过团队项目后，我的理解发生了变化：用户反馈不一定要求一开始就拥有大量正式用户，但必须尽量让需求和评价来自真实使用场景，而不是完全来自开发者想象。

在课程项目中，老师和助教给出的要求可以看作一种高层约束，但它并不能替代用户反馈。同学互评、组间测试、展示过程中的提问、实际试用时暴露的问题，都可以成为反馈来源。它们可能不如工业项目中的真实用户数据充分，但至少可以帮助团队跳出“我觉得这个功能很好用”的自我判断。

我现在认为，课程项目中模拟用户反馈可以分成几个层次。第一层是角色扮演，即团队内部站在目标用户角度写用户故事和使用场景。第二层是小范围真实测试，让同学、朋友或其他组成员实际使用系统，并记录他们在哪里卡住、哪里不理解、哪里不符合预期。第三层是根据反馈做取舍，而不是把所有意见都照单全收。因为用户说出的往往是表层感受，团队还需要分析背后的真实需求。

所以我现在对敏捷反馈的理解是：重点不是“有没有 100 个真实用户”，而是团队有没有把软件放到使用场景中接受检验，有没有根据反馈调整需求、设计和实现。如果只是开发者自己闭门造车，然后在最后展示时说“用户应该会喜欢”，那确实不算真正理解敏捷。

4. PM 在软件团队中到底该做什么？团队项目时 PM 的角色会不会被“技术主导”淹没？

学期初我担心，在学生团队里 PM 容易变成写文档、填表格、整理展示材料的人，而真正的决策被技术负责人掌握。经过团队项目后，我认为这个问题确实存在，但也不是简单地把 PM 权力写大就能解决。

PM 的核心价值不在于是否写代码，而在于能否把用户需求、项目目标和团队能力连接起来。一个好的 PM 应该能回答：我们到底在为谁解决什么问题？当前最重要的功能是什么？哪些需求必须做，哪些可以延后？用户反馈应该怎样转化成任务？如果进度不够，应该砍掉什么而不是盲目加班？

在学生团队中，技术成员天然更容易掌握话语权，因为很多决策最后都要落实到代码、接口和部署上。但如果所有决定都只由技术视角推动，项目就容易变成“能做什么就做什么”，而不是“应该做什么才有价值”。这时 PM 的作用就是不断把讨论拉回目标、用户和交付标准上。

当然，PM 也不能只停留在抽象表达。如果 PM 不理解基本技术约束，不了解开发成本，也不跟进任务进度，那么就很容易变成边缘角色。比较合理的方式是：PM 不一定负责具体编码，但必须参与需求评审、迭代规划、任务拆分、风险识别和验收标准制定，并且要对项目方向和交付结果承担责任。

所以我现在的回答是：PM 的确可能被技术主导淹没，但避免这种情况的关键不是“给 PM 一个头衔”，而是让 PM 真正掌握需求、计划、反馈和验收这几条主线。只有当 PM 能把用户价值翻译成工程任务，并能对取舍结果负责时，这个角色才是有效的。

5. 软件工程中的“道德”和“职业素养”在真实工作中真的会被重视吗？我们怎么判断自己的行为是否“符合职业规范”？

学期初我觉得职业道德比较抽象，似乎不像需求、设计、测试那样能直接落到代码上。经过团队项目后，我对这个问题的理解更加现实：职业素养不是写在教材里的口号，而是会出现在很多具体选择中。

比如，测试不充分时能不能发布？发现已知 bug 时是否应该在文档或展示中说明？引用开源代码时是否注意协议？处理用户数据时是否考虑隐私？为了赶进度是否可以牺牲代码质量和基本安全？这些问题看起来不一定每天都被叫作“职业道德”，但实际上都在考验开发者是否对软件后果负责。

在课程项目中，虽然项目规模不如真实工业项目大，但也有类似场景。比如一个功能只是“看起来能用”，但边界情况很多；一个模块是临时赶出来的，但后续别人还要维护；一个展示效果很好，但内部实现并不稳定。这个时候，如果团队只追求表面完成度，就会忽视软件工程中非常重要的一点：软件不是写完就结束，而是要被别人使用、理解、测试和维护。

所以我现在认为，判断行为是否符合职业规范，可以看几个标准：是否诚实呈现系统能力和缺陷，是否尊重他人的代码和成果，是否保护用户数据，是否为自己的提交负责，是否给未来维护者留下足够的信息。职业素养并不一定表现为做了什么惊天动地的决定，更多时候体现在日常开发中有没有守住底线。

二、仍未完全解决的问题与新问题

经过一个学期，学期初的五个问题都有了阶段性答案，但并不是所有问题都被彻底解决。相反，实践让我产生了一些新的问题。

第一个问题是：团队中的过程度量应该精细到什么程度？

PSP 和团队复盘都说明，数据可以帮助我们改进开发过程。但如果记录过细，就会增加负担，甚至让成员为了填表而填表；如果记录过粗，又无法真正发现问题。课程项目中我们可以用比较轻量的方式记录任务、缺陷和进度，但到了更复杂的项目中，如何平衡“过程透明”和“管理成本”，仍然需要进一步思考。

第二个问题是：结对编程的贡献如何公平评价？

结对编程强调共同思考，但最后的代码提交记录往往只能体现谁写了更多代码。领航员提出的设计建议、发现的 bug、对边界条件的提醒，可能很重要，但不一定会直接体现在代码量上。如何评价这种隐性贡献，是我觉得教学和团队协作中都值得继续讨论的问题。

第三个问题是：课程项目中的用户反馈如何避免流于形式？

我们可以找同学测试，也可以做问卷和展示，但这些反馈可能仍然比较浅。很多同学会出于礼貌给出宽泛建议，或者只关注界面是否好看，而不是深入使用核心功能。如何设计更真实的测试任务，让反馈真正暴露需求问题和体验问题，是我在团队项目之后仍然觉得没有完全解决的问题。

第四个问题是：短期交付和长期可维护性之间如何取舍？

课程项目时间有限，Alpha 和 Beta 阶段都有明确截止时间，因此团队有时会优先选择最快能跑通的方案。但软件工程又强调可维护性、文档、测试和架构质量。什么时候应该快速实现，什么时候必须停下来重构，什么时候应该补文档和测试，这种判断不是靠教材一句话就能解决的，而是需要更多实践经验。

三、软件生命周期六个阶段中学到的知识点

阶段	我学到的一个知识点	结合项目的理解
需求	需求不是想法，而是可验证的使用场景	学期初我容易把“想做一个有用的系统”当成需求，但团队项目让我意识到，真正的需求应该说明用户是谁、在什么场景下遇到什么问题、系统完成到什么程度才算有效。如果需求不能被验证，后续设计、实现和测试都会变得模糊
设计	设计的核心是控制变化影响范围	在结对编程和团队项目中，我都体会到，如果一开始没有划清模块边界，后面修改一个地方就可能牵连很多代码。好的设计不一定是复杂架构，而是让规则判断、状态管理、接口交互、数据处理等部分尽量清楚，方便协作和维护
实现	实现要优先保证主流程可运行	团队项目中，很多功能单独看都能做，但软件真正可用的标志是用户能完整走通核心流程。Alpha 阶段最重要的是先形成可运行闭环，而不是追求每个细节都完善；Beta 阶段再根据反馈修复问题、补充功能和优化体验
测试	测试是对需求和设计的反向验证	以前我容易把测试理解为写完代码之后找 bug，但实践中发现，测试其实会反过来暴露需求不清和设计缺陷。边界情况、异常输入、接口不一致、用户误操作，很多都不是靠主观感觉能发现的，必须通过测试把问题具体化
发布	发布需要明确出口条件	发布不是把代码部署上去或完成展示就结束，而是要确认核心功能可用、主要缺陷已处理、使用说明清楚、团队成员知道当前版本有哪些能力和限制。如果没有出口条件，发布就会变成“差不多能跑了”，风险很大
维护	可维护性从第一次开发时就开始了	维护不是项目结束后的附加工作，而是从命名、注释、接口约定、文档、Issue、测试样例开始积累的。团队项目中我明显感受到，如果信息只存在于某个人脑子里，一旦任务交接或成员变动，维护成本就会迅速上升

四、结合个人项目、结对编程和团队项目的心得

1. 个人项目：工程能力首先体现在自我管理

个人项目让我最直接地意识到，软件开发并不是“会写代码就能顺利完成”。一个人独立完成项目时，没有队友帮忙提醒，也没有明确的外部分工，所有需求理解、时间安排、调试、测试和文档都要自己承担。

在这个过程中，我发现自己最容易低估的不是写代码本身，而是理解问题、处理边界条件和调试错误所需要的时间。很多时候，功能主流程很快可以跑通，但真正让它稳定、清晰、可提交，还需要补充测试、整理代码结构、检查异常情况。个人项目让我理解了 PSP 和个人度量的意义：它不是为了记录一堆形式化数据，而是让自己看清开发过程中的真实成本。

个人项目也让我意识到，独立开发更需要自我约束。没有人强制我写清楚注释、整理提交、补测试，但这些事情会直接影响后续维护和修改。如果只追求“当前能运行”，后面出现问题时就很难定位。因此，个人项目训练的不只是编程能力，也包括计划能力、验证能力和对自己代码负责的意识。

2. 结对编程：协作的核心是共同理解问题

结对编程给我的最大收获，是让我看到两个人协作并不只是把任务平均分成两半。真正有效的结对，是两个人在同一个问题上持续对齐理解。

在结对过程中，我们需要讨论规则、拆分模块、确定实现方式，也需要不断检查对方的想法是否和自己一致。很多时候，争论并不是坏事，反而说明双方都在认真理解问题。一个人可能更关注实现细节，另一个人可能更关注整体结构；一个人想到主流程，另一个人想到边界情况。通过讨论，这些差异会被提前暴露出来。

但结对编程也让我认识到，沟通本身并不能自动保证正确。如果两个人一开始对需求都有误解，那么结对也可能一起走偏。因此，结对编程还必须和测试、复盘结合起来。讨论帮助我们更快形成方案，测试帮助我们验证方案是否真的正确。结对的价值不在于保证不犯错，而在于让错误更早暴露，让隐性的理解差异变成显性的讨论。

3. 团队项目：软件工程首先是协作、集成与责任

团队项目是这个学期最能体现软件工程特点的部分。和个人项目、结对项目相比，团队项目中的复杂度明显更高，因为它不再只是“我能不能把代码写出来”，而是“大家写出来的东西能不能合在一起，能不能稳定运行，能不能满足用户需求”。

在团队项目中，需求、设计、实现、测试、发布和维护之间并不是完全分开的。很多需求是在实现过程中才变清楚的，很多设计问题是在测试和集成时才暴露的，很多发布风险是在最后准备交付时才发现的。这个过程让我理解到，软件工程中的流程不是为了形式，而是为了让多人协作在不确定性中保持可控。

团队项目也让我更理解责任的含义。一个模块不是写完就结束，而是要能被其他人调用、被测试验证、被文档解释、被后续维护。接口没有说清楚，其他成员就会被影响；任务状态没有同步，团队计划就会失真；bug 没有记录，后面就可能重复出现。很多看似繁琐的工程活动，比如任务分配、例会同步、Issue 管理、代码审查、测试记录和发布检查，本质上都是为了降低协作风险。

中间经历的转会和团队调整，也让我意识到团队不是天然稳定的。成员变化、任务变化、进度压力都会影响项目。如果项目知识只掌握在少数人手里，团队一旦发生变化就会付出很高代价。因此，文档、接口约定、任务记录和代码结构并不是可有可无的附属品，而是团队保持连续性的基础。

五、课程总结

在学期初，我对软件工程的理解还比较偏概念化：它似乎是一套关于需求、设计、编码、测试、发布和维护的流程规范。经过一个学期的实践后，我更愿意把软件工程理解为：在有限时间、有限人力和不完整信息下，让软件开发尽可能可沟通、可验证、可追踪、可维护的一套方法。

这个学期让我认识到，需求分析不是把想法写得更长，而是把用户、场景和验收标准说清楚；设计不是画复杂架构图，而是控制模块边界和变化影响；实现不是堆功能，而是持续保持一个可运行、可集成的主流程；测试不是最后找错，而是用证据验证需求、规则和设计；发布不是简单部署，而是达到团队共同认可的出口条件；维护也不是项目结束后的事情，而是从第一次命名、第一次接口约定、第一次提交代码时就已经开始。

我最大的收获，是开始用工程视角看待软件开发。以前我更容易问：“这个功能能不能做出来？”现在我会进一步问：“这个功能解决了谁的问题？它的成本是多少？它会影响哪些模块？有什么证据说明它是正确的？后续谁来维护它？如果用户反馈不好，我们如何调整？”这种思考方式，比单纯掌握某个工具或框架更重要。

软件工程并不是束缚创造力的流程，而是在复杂协作中保护项目的一种能力。它让个人开发不只依赖直觉，让结对协作不只依赖默契，让团队项目不只依赖热情。经过这一学期，我对软件工程的认识从书本上的抽象概念，变成了自己经历过的开发、沟通、取舍、反馈和复盘。这是我在这门课中最重要的收获。