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

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

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的需求在哪里	[I.3] 个人作业：结课总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	通过学习软件工程理论与敏捷开发实践，熟悉产品从立项到交付的全流程，提升团队协作与工程开发经验。
这个作业在哪个具体方面帮助我实现目标	回顾一学期的软件工程实践，整理自己对工程流程、团队协作和项目质量的理解

一、对曾经提出问题的解答

在软工课程的第一次博客作业个人作业：阅读和提问中，我围绕《构建之法》提出了五个问题。经过一学期的个人项目、结对项目和团队项目实践后，我对这些问题有了新的理解。

问题一：在当今Ai时代，程序员的核心竞争力是什么？

我现在的回答是： 核心竞争力已经从“代码编写能力”转变为“系统级架构设计、需求解构与AI代码审查能力”。

学期初我认为，底层逻辑并未改变，仅仅是侧重点转移，我们需要利用AI作为杠杆，并保持沟通和抽象建模能力。经过实际开发后，我发现这个侧重点转移的幅度比我想象的要大得多。AI 确实能一键生成样板代码甚至基础算法，但它缺乏全局上下文。现在，最稀缺的能力不再是把业务逻辑翻译成代码，而是将模糊的现实需求拆解为AI能理解的精确Prompt，以及在AI生成大量代码后，敏锐地嗅出其中的安全漏洞、边界条件遗漏和架构坏味道。

这个问题主要是通过结对项目和团队项目中的实践弄清楚的。 在项目中，我尝试用AI生成了大量的中间件代码。一开始我觉得效率极高，但在集成阶段却遇到了无尽的Bug，因为AI并没有考虑到我们团队特定的数据一致性规范。这让我意识到，在AI赋能的新范式下，我们不是在做“打字员”，而是在做“审计员”和“架构师”。日常训练的重点必须放在培养代码品味、测试驱动开发和全局系统观上。

问题二：结对编程在极度抽象和高复杂度逻辑中的真实投入产出比究竟如何？

我现在的回答是： 结对编程并非要求100%的开发时间都在一起写代码，在极度抽象的硬核场景中，它的价值在于“设计阶段的架构碰撞”与“实现后的严格复审”，而非“编写过程中的实时监工”。

学期初我认为，两人随时交流会打断心流，在底层系统开发这种需要极度专注的场景下，结对编程的投入产出比极低，甚至会起反作用。经过实际开发后，我发现我对结对编程的理解过于绝对化了。在复杂的算法推导或底层设计时，单人确实需要深度思考的空间。但如果在前期缺少白板上的逻辑对齐，单人闭门造车极易陷入“死胡同”。科学的边界在于：将结对拆分为“白板结对（共同推导架构与接口）” - “单人异步实现（保持心流专注）” - “结对审查（代码审查与测试用例验证）”。

这个问题主要是通过团队项目中的核心模块开发弄清楚的。 当我们尝试实时双人编写复杂的并发控制逻辑时，确实感到思维互相干扰、效率低下。后来我们调整了策略，两人先花一小时在黑板上画出状态机和数据流转图，然后一人负责具体编码，另一人去编写对应的单元测试，最后再坐在一起跑测试、修Bug。这种“松耦合”的结对方式，既保全了心流，又守住了代码质量。

问题三：如何选择最合适的团队模式进行软件开发？

我现在的回答是： 在学生团队这种缺乏强力职场约束的环境中，单纯依赖“模式（如主治医师）”注定失效，必须依靠“机制设计（如垂直切片划分与CI/CD卡点）”来倒逼全员参与。

学期初我认为，项目难度跨度大、人员能力参差不齐会导致“主治医师模式”退化为一人包揽，但我不知道该如何通过前期设计来避免这种“搭便车”现象。经过实际开发后，我发现，问题出在任务的横向切分上。如果我们按“前端、后端、数据库”划分，能力弱的同学往往在某一环节卡住，导致全盘延期，最后核心同学不得不接手。正确的做法是采用“特性团队”模式，将任务进行“垂直切片”。

这个问题主要是通过团队敏捷迭代的教训弄清楚的。 我们后来改变了分工，不再按技术栈分人，而是每个人负责一个具体的、小颗粒度的业务功能，独立走完一个微小但完整的闭环。这种机制将责任落实到了具体的交付物上，大大减少了打酱油的现象。

问题四：敏捷开发的适用性边界到底在哪里？

我现在的回答是： 敏捷开发在复杂系统级开发中依然适用，但“可运行增量”的标准需要从“用户可见的UI功能”重塑为“通过自动化测试的内部模块或接口契约”。

学期初我认为，底层编译器或高耦合系统需要海量的前期架构设计，强制拆分短周期迭代会导致架构破碎、频繁返工，敏捷似乎不适用于这类“硬核”项目。经过实际开发后，我发现，我误把敏捷等同于了“快速开发Web页面”。在底层系统开发中，如果憋大招搞瀑布流，往往在最后集成时才会发现致命的架构缺陷。敏捷的精髓在于“尽早且频繁地获得反馈”，而不是“尽早看到漂亮的界面”。

问题五：基于KPI或强制排序的绩效评估，如何避免扼杀团队的“心理安全感”？

我现在的回答是： 绩效评估体系必须从“衡量个人产出”转向“衡量团队整体价值与个人对团队的使能”，将评价重心从代码行数转向工程行为。

学期初我认为，任何强竞争导向、可量化的考评都会破坏敏捷所需的信任基础，像末位淘汰这种制度更是会扼杀团队的心理安全感。经过实际开发后，我发现，团队确实需要评估，但不能评估“人”，而应该评估“事”。如果不做任何评估，也会产生“大锅饭”的不公感。关键在于量化指标的选择：不能量化Bug数（会导致没人敢接难任务），也不能量化代码行数（会导致冗余代码），而应该量化如“Pull Request的审查响应时间”、“帮助他人解决Blocker的次数”以及“团队整体Sprint目标的达成率”。

这个问题主要是通过项目后期的复盘会议和互评机制弄清楚的。 我们发现，当团队分数占大头（70%），个人贡献分占小头（30%），且个人贡献分主要由队友互评（谁对我的帮助最大）来决定时，团队的氛围是最健康的。大家不再藏私，而是争相帮助卡壳的同学，因为“帮助他人”成为了被认可的核心价值。这既保证了工程效率的透明度，又完美守护了心理安全感。

二、原来仍不明白的问题

目前我仍然没有完全弄清楚的问题是：作为PM，当团队成员能力参差不齐且进度受阻时，如何在“放手让成员试错成长”和“亲自下场抢进度”之间找到平衡？

教材和课堂中给出了很多敏捷开发的方法，例如任务分解、站会、燃尽图等。但在实际学生项目中，面对大家各异的课程压力、技术基础和时间安排，这些工具常常失效。作为PM，我本学期最大的教训之一就是：当发现成员推进困难时，我没有找到合适的协调和督导方式，而是选择了最简单粗暴的解决办法——“我自己来写”。

这导致项目最终退化成了“带几个挂件的个人大作业”。单靠流程工具确实很难解决动力和能力不足的问题，但我依然没弄清楚：在缺乏强制性绩效考核的学生团队里，PM到底该用怎样的机制去拆解任务，

三、新产生的问题

经过本学期的“包揽式”实践，我产生了一个新的问题：

对于学生团队项目来说，PM在做技术选型时，是否应该拥优先考虑“团队现有能力”？

例如本学期我们最初选择做 Unity 2D 横板战斗小游戏，是因为这个方向在立项时大家都觉得很有趣，容易展示出炫酷的成果。作为PM，我当时妥协于了这种“热情”，却没有严格评估团队的技术基线。实际执行时，大多数成员完全不熟悉 Unity，学习成本被严重低估。

当进度开始滞后时，成员因为不会写而停滞，我因为着急交付而直接代劳。我现在认为，学生项目的技术选型绝不能只看最终效果，必须冷酷地评估团队的真实开发能力和最低可交付版本（MVP）。如果一个技术栈只有PM或少数人能掌握，它必然会导致协作失衡，进而演变成个人的独角戏。

四、六个阶段中学到的知识点

1. 需求阶段：需求不只要可落地，还要“可分配” 在需求阶段，我学到的知识点是“需求分析不能只停留在系统层面，还要看人”。一开始我们设想了完整的游戏要素，但我作为PM，没有把需求拆解到“适合新手开发”的颗粒度。比如只分了“战斗系统”，却没有进一步拆出“角色移动数据结构设计”这样哪怕不写核心逻辑也能完成的具体任务。需求不够细致，导致我根本无法向能力较弱的成员分配工作。

2. 设计阶段：模块边界就是团队协作的防波堤 在设计阶段，我学到的知识点是“面向团队能力的设计”。之前我以为模块化只是为了代码解耦，但实践证明，如果没有清晰的接口定义，成员之间根本无法并行工作。因为UI和状态逻辑交织不清，成员不知从何下手，最后为了避免无休止的沟通成本，我干脆把UI和核心逻辑一起写了。设计阶段如果没有定义好API和数据流向，分工表就只是一张废纸。

3. 实现阶段：技术风险是压垮分工的最后一根稻草 在实现阶段，我学到的知识点是“永远不要低估技术栈的学习曲线”。Unity 的组件、生命周期和物理系统对初学者并不友好。当成员在实现阶段卡壳时，我犯了PM的大忌：没有组织技术攻坚或降低功能要求，而是直接接管了代码权。这让我认识到，实现阶段不仅仅是敲代码，更重要的是PM要提前做技术验证和Demo，扫清技术盲区，而不是等大家撞墙了再由PM去收拾残局。

4. 测试阶段：没有分工，测试就会成为灾难 在测试阶段，我学到的知识点是“单点故障的危险性”。因为大部分代码都是我赶工写出来的，大家对项目内部逻辑不了解，导致连找Bug、写测试用例的工作都无法分摊。游戏运行时的体验问题（如UI遮挡、判定失效）全压在我一个人头上。这让我痛定思痛：如果前期不分工，后期连测试都没人能帮你做，因为他们根本不知道怎么跑通这些代码。

5. 发布阶段：环境隔离与工程化的重要性 在发布阶段，我学到的知识点是“环境依赖是协作的死敌”。因为项目主要由我一个人开发，整个工程环境、依赖和资源路径都在我的电脑上。当我想在最后阶段让成员帮忙打包或写说明时，发现项目在他们的电脑上根本跑不起来。这也验证了工程化中CI/CD和标准化环境的意义：代码在PM电脑上能跑不算完成，任何成员拉取代码就能构建，才是真正的团队项目。

6. 维护阶段：文档是避免“一个人扛下所有”的唯一解 在维护阶段，我学到的知识点是“Bus Factor（公交车因子）”。本项目的Bus Factor就是——如果我生病了，这个项目立刻就会停摆。因为我一个人包揽了工作，为了赶进度我省去了所有中间文档。项目结构、数据流向全在我的脑子里。这在软件工程中是极度不健康的。哪怕是一个简单的Readme和接口说明，也能在成员想帮忙时提供入口，而不是每次都要来问我。

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

通过本学期的软件工程课程，我最大的体会是：软件工程的核心从来不是“怎么把代码写出来”，而是“怎么组织一群人把代码写出来”。

在个人项目中，我作为唯一开发者，可以凭借脑海中完整的上下文快速推进，这也是我最舒服的状态。结对编程中，沟通是1对1的，即使有分歧也能迅速对齐，互相兜底。

但到了团队项目，当我有意无意地把团队项目当成“规模大一点的个人项目”来做时，灾难就发生了。我错误地把“PM”理解成了“技术最强、兜底写代码的劳模”，却忽视了PM真正的职责：评估风险、拆解任务、制定规范、排除障碍，让每一个人都能输出价值。

由于我没有合理协调分工，选择了“自己来”的捷径，表面上似乎保证了项目有个能看的结果，但实际上却剥夺了团队成员参与软件工程完整流程的机会，也让自己陷入了极度疲惫的境地。这不仅不是英雄主义，反而是管理的失职，是违背软件工程初衷的。

这学期的项目虽然最终跑起来了，但从工程管理的角度看它是失败的。但这种“失败”让我触及了软工最真实的痛点：流程不能代替责任心，但缺乏管理的流程一定会导致个人英雄主义的悲剧。 在现实的约束下不断协调需求、人员和技术，这不仅是一门技术课，更是一场关于团队管理的深刻修行。