北航2026软件工程作业

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习专业团队的==软件开发流程==，提升团队协作能力，项目管理能力；锻炼==软件开发技术==，为职业发展打下坚实基础；培养==解决复杂工程问题==的能力，提高技术壁垒和专业性。
这个作业在哪个具体方面帮助我实现目标	在完成该作业的过程中，我对《构建之法》这本书进行了==泛读、重读、精读三轮阅读==，同时认真钻研字眼，提出有价值的问题。在这个过程中，我收获了很多软件工程相关的专业知识技能，也锻炼了我的批判性思维和提出好的问题的能力，==我认为这些基础知识和个人能力有助于让我熟悉软件开发流程，磨炼软件开发技术，提升专业壁垒，从而帮助我实现目标==。

问题一：在 vibe coding 时代，软件开发的工作量和质量的衡量标准是否还与书中的四个因素一致？

书中原上下文：

软件开发的工作量和质量怎么衡量呢？第 2 章提到的 PSP 认为有下列 4 个因素:

a. 项目/任务有多大？

b. 花了多少时间？

c. 质量如何？

d. 是否按时交付？

——第 2 章个人技术和流程

目前市面上已经有很多成熟度很高的 vibe coding 软件了，如 Cursor、GitHub Copilot 等。过去需要程序员花费两三天才能完成的软件开发任务，现在只需要输入几段 prompt，AI 就能在几分钟内生成数千行代码。==在这种新编程方式下，书中提到的衡量标准是否还有效？==如果按代码行数计算，尽管项目有数万行代码，但大部分代码都是 AI 生成的，开发者甚至不需要写一行代码。同时，虽然生成代码的时间被极度压缩，但开发者的时间会花费在更多隐形的环节，比如阅读和理解 AI 生成的代码，或者让 AI 接着 debug，可能后续工作的时间要大于一开始做自己写代码花费的时间。
书中的描述在现代不再适用，我觉得==传统软件工程模型的底层假设将被颠覆==。
书中所述的 PSP 的前提是：写代码的时间和代码总行数和任务大小是正相关的。然而 AI 可以毫不费力的降低开发成本，缩短开发时间，这使得代码行数和编码时间不再是可信的衡量标准。

问题二：AI 辅助编程提供了成倍的生产力提升，是否还需要进行功能分析？

书中原上下文：

这四个象限能让软件团队清楚地看到自己感兴趣的功能处于什么地位，有了这些分析，我们就可以决定怎么处理不同类型的功。重要的是，不要把资源平摊到所有象限中，而是倾斜到可以产生差异化和独特用户价值的地方。

资源有限，我们对不同功能有哪些办法呢？有下面五种办法。

图 8-8 功能分析的四个象限

外围功能杀手功能

必要需求第二象限第一象限

辅助需求第三象限第四象限

维持——以最低成本维持此功能。

抵消——快速地达到“足够好”，“和竞争对手差不多”。

优化——花大力气做到并保持行业最好。

差异化——产生同类产品比不了的功能或优势（我有人无的优势，或者一个数量级以上的优势）。

不做——砍掉一个功能也是一个办法，我们并不一定要做所有的功能。

——第 8 章需求分析

	外围功能	杀手功能
必要需求	第二象限	第一象限
辅助需求	第三象限	第四象限

现在的 AI 编程非常强大，开发一个功能的时间和人工成本可以忽略不计。以前需要 pm 和开发团队反复权衡的边缘功能现在完全不用考虑，直接交给 AI 就能在极短时间内生成代码。==在这种生产力大幅跃升的情况下，书中基于资源稀缺性提出的功能分析策略不再适用==。过去为了节省开发资源，对不常用的功能只用最低成本维持。但现在 AI 可以轻松且低成本地给出极其完善的代码实现，团队不需要考虑投入，可以采取全都要的策略，不会面临曾经艰难的取舍情况。
功能分析前提与目前代码生产力不再适配，我觉得==传统功能分析没有现代价值==。
书中提出四个象限和五种处理办法的前提是：开发团队的时间、精力和试错成本都是极其有限的，必须把好钢用在刀刃上。然而在代码产出速度成倍提升的今天，代码开发成本几乎为零。这让我产生疑问，当基础代码开发可以轻易解决时，严格按照这四个象限来划分功能优先级是否还有意义？

问题三：在企业普遍压榨 PUA 员工的今日，如何识别并避免假团队的出现？

书中原上下文：

17.3.5 效能曲线和假团队

讲团队管理的书籍很多，其中的经典著作《The Wisdom of Teams》提到团队的效能曲线：

它提到的团队的几个阶段（有团队潜力，真的团队，高效的团队）和上文的四个阶段有类似之处。更要注意的是，它提到从各自为政的“工作组”（还记得王屋村一帮搬砖的人么？）到各种阶段的团队状态之间，往往还有一个“假团队”（Pseudo-team）的阶段，“假团队”名义上有团队的组织，但是成员互相掣肘，面和心不和，有人打酱油，这样的团队的效率还不如各人单干的工作组。有时候一个企业也会展现出“假团队”的特性：
领导非常努力地让员工相信公司非常关心员工；员工也非常努力地让领导相信自己完全领会了公司的大爱。私下里双方都不相信对方的话，也看不起对方。

——第 17 章人，绩效和职业道德

一提到大厂，许多人第一个想到的其实是大厂的末位淘汰和强制加班机制。为了压榨员工创造价值，管理层常常用狼性文化来鞭策员工，试图让员工无条件付出。在这种众所周知的职场环境下，==假团队已经成为了不言而喻的共识==，大家都是为了混口饭吃，对于这种风气也只能表面笑笑忍气吞声。为了应对内部竞争，员工之间都在伪装。大家在会议上表面和气，但在实际的项目中往往互相防备。管理层用画大饼进行高强度的压榨，而员工则用表演式加班和形式主义的汇报来保住饭碗。这印证了书中提到的双方都不相信对方的话，也看不起对方的现象。
假团队在当今已经成为常态，==有必要探讨在这种现状下该如何管理团队==。
在一个缺乏信任的组织里，是否还能识别并避免假团队的产生？假团队是否实质上已经成为了许多当代企业的普遍形态？

问题四：在 RASCI 模型中，为什么每个环节有且只有一个 R ？

书中原上下文：

RASCI 模型：

R：Responsible，负责把具体事情做好。

A：Accountable，对任务负全责，有批准的权力。

S：Support，对任务提供支持，辅助任务的完成。

C：Consulted，咨询，拥有完成项目所需的信息或能力的角色。

I：Informed，知会者，应该事后及时通知结果的角色。

当你的项目中有N多角色时，不妨想想他们属于 RASCI 的哪个角色，然后依照相应的规范行事即可。

在一个流程漫长、合作者众多的项目中，项目的管理者要把每一个环节的 RASCI 角色都列出来，每个环节有且只有一个 R。

——第 17 章人，绩效和职业道德

在软件开发工作中，结对编程是非常普遍的现象。开发一个核心模块，往往需要多人共同编写代码，大家都是负责吧具体事情做好的 R 角色。==我感觉书中关于角色分配的严格限制不太合理==。比如前端和后端共同开发一个网站，两人都在承担彼此的开发工作。如果强制规定只有一个 R，那么另一位该归为哪一类，强行将其划分为 S 也不合适。
书中的描述让我比较困惑，==我觉得 RASCI 模型不应该有强制限制==。
我比较困惑的是，书中是笔误将 R 和 A 的唯一性混淆了，还是有其他原因？

问题五：在团队中，该如何管理才能如何防止 P2、P3、P4、P5 这类人的出现？

书中原上下文：

作为万物之类的人，是能不能满足于仅仅只有三种花样的。很快，我们可以看到第四、第五类人的出现：

P = {P1 = 做事的，P2 = 不做事的，P3 = 不让别人做事的，P4 = 做假的事的，P5 = 假装做事的}

P4 = 做假事的人，可以磨牙芯片的例子。而假装做事的人（P5）往往和 P4 成对出现，例如负责评审汉芯并给予其很高评价的各位院士和专家。

有了这样的榜样，我们也不难发现身边的例子。2008 年夏天，在与某学院合作的“软件实现技术”课程中，有一个小组没有参加最终评比，得分
为零。为什么呢？原来他们的“电梯作业”原封不动地抄袭了前一年同学的方案。微软的工程师在评审时发现这个小组的作业看起来眼熟，后来注意到所有文件的日期都是一年以前的……如果我们也敷衍过去，那我们就成了 P5 了（写程序蒙到微软工程师头上，也真是令人佩服）。

人无完人，人非圣贤，总会犯错误，原因很多，有的是个人一念之差，有些是时间安排的问题，有的是有仿生学的原理，有的可以追溯到社会的潜规则或种种因素。但是为什么要这么多花招？为什么能都当一回简单的 P1 呢？

——第 17 章人，绩效和职业道德

由于绩效考核的压力，现在的职场中存在很多不干活、推脱活的现象。==在这种涉及到实际利益的情况下，书中提到的各类负面角色更加频繁的出现==。许多员工为了冲高个人的绩效分数，会故意制造毫无价值的材料来博得关注和肯定，或者汇报空洞糊弄人的材料，他们并没有创造真正的价值，只是为了敷衍管理者混日子的手段。这种现象就对应了典型的 P4 与 P5 几类人。同时在跨团队协作中，经常会遇到一些抢占了关键资源却不作为或者不作为但在汇报时抢风头抢成果的人。他们也就是职场中的 P2 和 P3。
书中更多是从职业道德的角度来告诫大家成为做事者，但现实情况并非如此。==如何坚守初心不被现实裹挟才是我应该提出的问题==。
如果一个团队的考评只看重表面的汇报材料而不是实际创造的价值，那么老实干活的 P1 员工就会被自然淘汰。这让我产生疑问，我们该如何保全自己，才能在形式主义下坚持做 P1 那样的程序员？