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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15608
我在这个课程的目标是	学习软件工程思想与技能
这个作业在哪个具体方面帮助我实现目标	通过阅读优秀书籍提前了解课程内容，对软件工程有基础概念。练习编写博客

1.如何让单元测试发挥作用

来源：第二章

上下文：

单元测试必须是由最熟悉代码的人来书写。最好在设计的时候就写好单元测试

如果按照作者说法由代码作者编写单元测试并在设计阶段写好测试，是不是容易陷入过度设计或测试用例过多的问题？我查了资料发现，一般认为“谁写代码，谁写测试”可以保证测试覆盖率，而且单元测试是回归测试的基础。然而，我个人的实践经验是，还没有使用过单元测试，通常只是完成代码后用样例来测试，很多潜在的边界情况可能没有想到。我的困惑是：对于快速迭代的项目，如何在尽早编写单元测试与避免过度设计之间找到平衡？

2.结对编程在队友能力不均的情况下，如何调整结对编程模式以兼顾效率和质量？

来源：第四章

上下文：

每⼈在 各 ⾃ 独 ⽴ 设 计 、 实 现 软 件 的 过 程 中 不 免 要 犯 这 样 那 样 的 错 误 。 在 结 对 编 程 中 ， 因 为 有 随时 的 复 审 和 交 流 ， 程 序 各 ⽅ ⾯ 的 质 量 取 决 于 ⼀ 对 程 序 员 中 各 ⽅ ⾯ ⽔ 平 较 ⾼ 的 那 ⼀ 位 。这样，程序中的错误就会少得多，程序的初始质量会⾼很多，这样会省下很多以后修改、测试的时间。

作者高度评价结对编程，但现实中如果两人的能力差距大，是不是就难以保证这种高效？我查了资料发现，结对编程的好处包括快速纠错、知识共享、提升技能，但缺点是需要两人实力匹配，否则编程进度可能缓慢。虽然我还没有体验过结对编程，但是有过其他团队项目经验，经常会出现一人卡住另一人空闲的情况，感觉知识共享效果不明显。另外我并不认为结对编程可以发挥各个领域两个人的优点。

3.如何有效的用户调研？

来源：第8章

常见的调研方法：焦点小组，深入面谈，卡片分类，用户问卷调查，用户日志研究，人类学调查，眼动跟踪研究，快速原型调研，A/B测试

书中列出众多获取需求的方法，在资源和时间有限的情况下应如何选择合适的方法？查资料可知，卡片分类可揭示用户的思维模型，而焦点小组在界面可用性测试中效果不佳，只能宏观了解用户对产品概念的看法。根据我的实践，做学生项目时我通常只做简单问卷或访谈，很少做原型或眼动等复杂调研。我的困惑是：在实际开发中，应怎样平衡成本与效果，在不同阶段合理采用各种用户调研方法？

4.在实际团队中，一个PM具体应承担哪些职责？

来源：第9章

上下文：

P M 做 开 发 和 测 试 之 外 的 所 有 事 情

我 们 看 看 微 软 公 司 有 哪 ⼉ 类 P M P ° 。
• 有 做 功 能 设 计 的 P M ； 有 些 功 能 或 产 品 需 要 深 ⼈ 掌 握 各 个 计 算 机 科 学 分 ⽀ 的 专 业 知 识
才 能 做 好 。 例 如 V i s u a l S t u d i o 中 的 各 种 计 算 机 语 ⾔ 、 框 架 、 T F S 的 项 ⽬ 的 项 ⽬ 经 理 ，
S Q L S e r v e r 、 W i n d o w s S e r v e r 、 A z u r e 、 B i n g S e a r c h 核 ⼼ 算 法 等 团 队 的 P M
• 有 些 P M 需 要 对 商 业 和 客 户 有 很 强 的 了 解 能 ⼒ ， 例 如 O f f i c e 办 公 软 件 的 P M
• 有 些 P M 需 要 具 备 ⼴ 泛 的 经 验 和 知 识 ⾯ ， 以 及 商 业 拓 展 能 ⼒ ， 例 如 互 联 ⽹ M S N 部 ⻔
的 P M

查资料显示，在微软等公司，项目经理确实负责产品全生命周期，例如分配资源、控制进度、理解需求并协调各环节。根据我的实践，学校项目通常没有专职PM，大家分头完成需求分析和管理工作。我的困惑是：在实际团队中，一个PM具体应承担哪些职责？难道PM既要涉及产品设计，又要进行沟通和协调，就像书中所说几乎覆盖了开发和测试之外的所有内容吗？

5.团队如何高效交流

来源：第6章

上下文：

敏 捷 开 发 的 原 则 是 ：
1 . 尽 早 并 持 续 地 交 付 有 价 值 的 软 件 以 满 ⾜ 顾 客 需 求
2 . 敏 捷 流 程 欢 迎 需 求 的 变 化 ， 并 利 ⽤ 这 种 变 化 来 提 ⾼ ⽤ 户 的 竞 争 优 势
3 . 经 常 发 布 可 ⽤ 的 软 件 ， 发 布 间 隔 可 以 从 ⼏ 周 到 ⼏ 个 ⽉ ， 能 短 则 短
4 . 业 务 ⼈ 员 和 开 发 ⼈ 员 在 项 ⽬ 开 发 过 程 中 应 该 每 天 共 同 ⼯ 作
5 . 以 有 进 取 ⼼ 的 ⼈ 项 ⽬ 核 ⼼ ， 充 分 ⽀ 持 信 任 他 们
6 . ⽆ 论 团 队 内 外 ， ⾯ 对 ⾯ 的 交 流 始 终 是 最 有 效 的 沟 通 ⽅ 式

7 . 可 ⽤ 的 软 件 是 衡 量 项 ⽬ 进 展 的 主 要 指 标
8 . 敏 捷 流 程 应 能 保 持 可 持 续 的 发 展 。 领 导 、 团 队 和 ⽤ 户 应 该 能 按 照 ⽬ 前 的 步 调 持 续 合 作下 去
9 . 只 有 不 断 关 注 技 术 和 设 计 ， 才 能 越 来 越 敏 捷
1 0 . 保 持 简 明 — 尽 可 能 简 化 ⼯ 作 量 的 技 艺 — 极 为 重 要 ？
1 1 . 只 有 能 ⾃ 我 管 理 的 团 队 才 能 创 造 优 秀 的 架 构 、 需 求 和 设 计
1 2 . 时 时 总 结 如 何 提 ⾼ 团 队 效 率 ， 并 付 诸 ⾏ 动

作者描述敏捷流程中的这些管理任务，会不会占用过多开发时间？查资料发现，如果站会变成汇报时间而非解决问题，确实容易成为“僵尸”会议，浪费团队时间我的实践中，大学项目经常跳过一些仪式化会议，只做最低限度的沟通和计划。而且频率不高，这样的缺乏交流的工作模式我认为不能用于复杂的团队协作。但是作为大学生很难做到作者介绍的敏捷开发。我的困惑是：如何在团队中平衡敏捷管理与实际开发，既保障沟通效率，又避免被管理流程束缚？