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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	参与一次完整的团队开发工作，熟悉项目协作的全部流程，积累有关软件开发、维护、运营、测试相关的经验，为实习与就业做准备
这个作业在哪个具体方面帮助我实现目标	了解软件工程开发的常见思想，明确软件工程开发的基本概念和业界通识

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

教材第2章在讲 PSP 时，把重点放在“个人效能分析”“缺陷率统计”“时间开销记录”上，强调的是“个人如何量化自己的开发过程”，并认为这是“脱掉低效茧子”的关键。这种做法在工业界其实很难全面推行——很少有团队会要求每个成员每天填写工时、记录缺陷类型、计算生产率。但作为教学工具，PSP 的价值在于让学生意识到“开发不是凭感觉”，而是有数据可追踪、有过程可优化的。问题在于，如果只停留在“个人记录”，它的意义就容易被局限在“自我改进”，而难以迁移到团队协作。我注意到讲义后面讲到“团队中的角色与合作”“绩效管理”时，其实隐含了“过程可度量”的需求——比如“代码量”“树叶量”“Postmortem”等，都是团队层面的回顾指标。那么，PSP 是否应该被重新包装，不是作为“个人修行手册”，而是作为“团队协作的基准框架”？比如，团队可以用 PSP 的思路去统计“模块平均缺陷率”“修复时长分布”，再结合用户反馈，形成更系统的质量评估体系。这样，PSP 就从“个人修行”变成了“团队工程的基础度量”，也更符合讲义中“做中学 + 团队项目 + 反馈评价”的整体设计逻辑。

---

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

教材第3章专门讲结对编程，提到“送一个汉堡包”的提意见方式，强调沟通与协作，还指出“最早记载的结对编程发生在1987年”，暗示它是一种有历史支撑的实践。但在实际教学中，结对编程常被误解为“两个人一起写代码”，甚至变成“一个人写、一个人看”，效率低下。我观察到，很多同学在结对时，更关注“能不能把功能跑通”，而不是“为什么这样设计更好”“有没有更优解”。这其实偏离了结对编程的初衷——它不是为了“多一个人干活”，而是为了“两个人一起思考”。从讲义中“给人提意见的方式”“练习与讨论（工程师的成长）”等部分可以看出，作者的重心是“思维互动”和“技能互补”。那么，在教学设计中，是否应该弱化“代码完成度”的考核，转而强化“讨论深度”“意见质量”“反思记录”？比如，要求结对双方在每次Pair后提交一份“思维碰撞笔记”，记录“我们争论过哪个设计点”“最终为什么选这个方案”“对方给了我什么新视角”。这样，结对编程就从一个“编程活动”变成了“思维模式训练”，也更贴合讲义中“强调做中学 + 个人/结对/团队项目配合”的结构。

---

三、敏捷开发中的“用户反馈”在真实项目中怎么操作？我们做课程项目时怎么模拟？

教材第 4 章“软件过程/方法论”中提到敏捷宣言、Scrum、Sprint，第 6 章“需求”中也提到“用户调研的方法”“目标和远景”，第 7 章“设计和开发”强调“用户体验设计”。

我们在课程项目中，通常都是“老师给需求”或者“我们自己想个 idea”，然后做出来，最后展示给老师打分。但讲义里说“用户数量和反馈是项目重要的评价标准”，还说“在公开的社区中获得反馈”。这让我很困惑——我们怎么找“真实用户”？比如我们做一个校园二手交易平台，难道真要去拉 100 个同学注册、用、提意见？这在课程里不现实吧？我查了一些开源项目的案例，比如 GitHub 上的项目，确实会有 issue、PR、discussion，但那是在开发者社区里，普通用户很少参与。所以，敏捷开发中的“用户反馈”在课程项目中到底该怎么模拟？是“假装用户”还是“真找人测试”？

为什么提这个问题： 我的假设是“用户反馈必须来自真实用户”，但现实中课程项目很难做到。我担心我们学完敏捷，却不知道如何在没有真实用户的情况下实践。如果我们在课程里只靠“同学互评”或“老师点评”，那和传统的“瀑

---

四、PM（产品经理）在软件团队中到底该做什么？我们做团队项目时，PM 的角色会不会被“技术主导”淹没？

教材在第5章“团队中的角色与合作”里专门分析了 PM 的职责，包括需求规格制定、进度协调、风险管理等，并强调 PM 不是技术岗，而是协调岗。但在实际团队运作中，尤其是学生项目，技术负责人往往承担了大量原本属于 PM 的工作——拆分任务、安排进度、拍板技术方案，PM 容易变成“写文档、填表格”的边缘角色。这是因为技术成员天然掌握话语权，而 PM 如果不具备足够的需求洞察力和沟通影响力，很难在关键决策中占有一席之地。

要改变这种状况，首先要在团队认知上把 PM 定位为“方向掌舵者”和“价值翻译者”，其核心价值不是会写代码，而是能把用户需求转成清晰可执行的任务，并在多方利益间找到平衡。在课程项目中，可以通过让 PM 主导需求评审、迭代规划、用户故事定义等环节，并赋予其在技术争议中“最终拍板”的权力，来避免其被技术主导淹没。这其实是在训练我们理解，软件团队的健康运作，离不开一个能够超越技术细节、把握全局目标的 PM，而不是单纯依赖技术能力最强的人来兼任。

---

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

教材第10章“软件项目的管理”里提到软件工程师的职业道德、Postmortem 会议以及“人的问题”，强调反思和责任。这些看似抽象的原则，在真实职场中往往面临考验。比如，为了赶工期，团队可能默许测试不充分就上线；或者在商业压力下，选择暂时隐瞒某些已知缺陷。在这些情境下，职业道德并不是挂在墙上的口号，而是直接影响产品安全和用户信任的底线。

判断行为是否符合职业规范，不能只看公司当前的要求，而要依据更长远的行业标准和公众利益。例如，是否对潜在风险充分披露，是否在代码中避免引入安全漏洞，是否尊重用户隐私，是否对开源协议保持合规，这些都是可衡量的标准。在课程项目中，我们可以通过设定“红线规则”（如禁止抄袭、必须保障数据安全、明确版权归属）来提前培养这种意识，让职业素养从学习阶段就成为习惯，而不是工作后才临时补课。这其实是在训练我们理解，软件工程不仅是技术和流程，更是一套面向公众、面向长期价值的责任体系。