[l.1] 个人作业：阅读与提问

[l.1] 个人作业：阅读与提问

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标	提升团队协作能力，项目管理能力；学会编写一个完整软件项目的技能，为职业发展打下坚实基础；培养批判性思维和解决复杂工程问题的能力。
这个作业在哪个具体方面帮助我实现目标	该作业要求我们快速读完一本软件工程的专业书，并提出好的，有价值的问题。这是帮助我培养批判性思维，在阅读过程中主动思考。同时阅读全书是我对软件工程各个领域（需求、设计、测试、流程、团队等）有了宏观认识，为顺利完成课程大作业，做出有品质的软件奠定基础。

问题一：PSP的“自我记录”如何避免成为形式主义的过场？

出处与上下文
这个问题来自第2章“个人技术和流程”中的2.3节“个人开发流程”。书中详细介绍了PSP模型，要求工程师记录自己在计划、开发、复审、测试等各阶段花费的时间，并以此为依据进行改进。表格2-3还对比了大学生和职业工程师在不同阶段的时间投入差异。

支持的事例与资料
教材第57页坦承了PSP的局限性：“如果数据不准确或有遗失，怎么办？让工程师编造一些？”“如果数据不利于工程师本人，我们怎么能保证工程师愿意如实地记录？”这正是“理性人修饰数据”的问题。网上关于“程序员填工时”的文章也提到，工时记录常演变成数字游戏。当记录者与被评估者为同一人时，PSP究竟是成长工具还是形式主义过场？

我的困惑与问题
我的困惑在于，“人”在这套系统中既作为被评估的对象，又作为评价数据的记录者，则数据的真实性如何得到保证呢？譬如，如果真实记录可能暴露自己的低效或错误，从而影响绩效，那理性人的选择似乎就是“修饰数据”。在这种情况下，PSP收集到的“数据”究竟是帮助个人成长的镜子，还是沦为一种形式主义的过场呢？

问题二：如果“用户并不需要产品”，那么NABCD模型的第一步Need该如何捕捉？

出处与上下文
这个问题源于第8章“需求分析”中的8.4节“竞争性需求分析的框架”。书中介绍了著名的NABCD模型，其中第一个字母N代表需求。同时，书中也引用了一句发人深省的话：“事实上，用户并不需要‘产品’，用户需要解决痛点的方案。”并举例说明颠覆性创新的需求在出现之前，用户自己也无法表述。

支持的事例与资料
教材第8.3节以偷菜游戏为例：“没有用户说‘我希望有一个偷菜的软件’”，但成功的团队从“用户需要和朋友互动”中挖掘出需求。第一代iPhone的案例同样说明，颠覆性创新无法通过传统调研获得。当创意属于“用户说不出来”的类型时，NABCD的Need该从何而来？是来自灵感，还是可被系统化捕捉？

我的困惑与问题
我的困惑是，当我们提出的创意属于书中提到的“用户说不出来”的颠覆性创新时，NABCD模型中第一个也是最重要的“N”该如何完成？是来自于偶发的灵感吗？我们又该如何向别人证明这个尚未被用户感知的“Need”是真实存在的，而不是我们一拍脑袋的空想呢？

同时，书中说到“在汽车出现之前，我们找一帮马车夫来畅想‘未来的交通工具’，他们未必会贡献很有价值的想法”。我们都知道颠覆性的，革命性的成就都来自于创意，这很难是能够被观测到的need所能激发的。我们该怎样获得这样的灵感和创意呢？

问题三：“代码复审”时，面对“风格问题”与“逻辑问题”，应如何分配有限的精力？

出处与上下文
这个问题来自第4章“两人合作”中的4.4节“代码复审”。书中提供了详细的代码复审核查表，从概要设计到具体代码、效能、可读性、可测试性，包罗万象。4.4.1节强调了复审的重要性，并指出“在代码复审中发现的问题，绝大多数都可以由开发者独立发现”。

支持的事例与资料
教材第4.7节提到“破窗效应”：细小规范被忽视会导致质量滑坡。但2014年Apple的“goto fail”漏洞却因一个逻辑错误导致严重安全问题，代价远高于风格问题。在时间有限的情况下，复审者如何权衡？

我的困惑与问题
我的困惑是，在时间资源有限的前提下，复审者应该如何战略性地分配自己的注意力？是应该优先死磕代码规范，保证团队风格的统一，还是应该聚焦于逻辑正确性和潜在缺陷？书中表4-1提到团队复审“覆盖率高……但效率可能不高”，同伴复审简便易行。那么，对于学生团队而言，如何根据项目的阶段和关键程度，动态调整复审的重点，以达到足够好的效果，而不是为了完成复审的流程而走过场？

问题四：如何从“写了再改”的模式，平滑过渡到“有流程”的开发？

出处与上下文
这个问题触及第5章“团队和流程”的核心。书中5.3.1节描述了最原始的“写了再改”模式，并指出其缺点。随后介绍了瀑布模型、RUP、敏捷流程等一系列正规军方法。第1章的图1-3和表1-1也将软件业与航空业类比，暗示从“爱好者的尝试”到“成熟的工业”需要流程的支撑。

支持的事例与资料
教材第7.5节描述了微软TFS团队从Excel、BBS表单逐步演进到统一工作项系统的过程，说明流程建立是渐进的。许多初创团队快速扩张后不得不引入Scrum，但《人月神话》指出过渡期常遇“焦油坑”。对于习惯了“写了再改”的学生团队，哪些流程要素是最易上手且能立竿见影的“低垂果实”？

我的困惑与问题
我的困惑是，对于一个长期习惯于“写了再改”的团队或个人，如何才能实现向规范化开发流程的平滑过渡？书中指出了各种流程的优点，但没有详细说明这个痛苦的转型过程该如何管理。是应该在一个项目中强行全盘应用所有规则，还是应该挑选一两个最关键的实践先行先试，逐步引入？对于初学者，哪个流程要素是最能立竿见影、帮助我们建立对流程信心的低垂果实？

问题五：测试人员应该在什么时候介入？不同阶段怎么介入？

出处与上下文

这个问题出自第13章“软件测试”。讲义中提到：“当你在项目后期发现了问题，问题的根源往往是项目早期的一些决定和设计，这时候，再要对其进行修改就比较困难了。这要求测试人员从项目开始就要积极介入，从源头防止问题的发生。”

支持的事例与资料
教材第13.3节要求测试人员参与需求评审，从源头发现缺陷。但Scrum实践中，若Sprint中期需求变更，已编写的测试用例需频繁调整，造成浪费。Spotify团队采用“测试人员全程嵌入开发”的方式，通过持续沟通应对变化。在项目初期需求不稳定时，测试人员应如何介入？是先参与设计评审，还是像TDD那样提前写测试？

我的困惑与问题

我的问题是，传统的测试必须基于一定完成程度的代码，在项目初期可能不具有该条件。同时，测试方案通常是基于明确的需求和设计来编写的，而在项目初期，这些往往还处于变动之中。此时若过早地编写详细的测试用例，会不会导致测试用例因需求变更而频繁修改，反而造成资源浪费？如果测试人员需要在初期进行介入，那么应该如何介入呢？