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

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

项目	内容
这个作业属于哪个课程	首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.3] 个人作业：结课总结 - 作业 - 2025年春季软件工程（罗杰、任健） - 班级博客 - 博客园
我在这个课程的目标是	学习软件工程的理论知识并进行实践。
这个作业在哪个具体方面帮助我实现目标	梳理过去的问题，反思软件从 0 到 1 的过程，总结经验

一、提问回顾与解答

问题一：Wideband Delphi 方法如何避免讨论中的 “权威偏见”？

• 原问题思考：书中提到该方法通过多轮匿名估计达成共识，但担心团队中技术权威的意见会主导讨论，导致初级成员意见被忽视。

• 解答过程

  ：通过查阅资料与团队实践，发现可通过以下方式改善：

  • 引入严格的匿名反馈机制（如在线匿名投票工具），确保成员意见不被他人知晓。
  • 建立平等沟通文化，项目经理引导权威成员延迟发表意见，鼓励初级成员先表达。

• 当前理解：结构化匿名流程与文化建设可减少权威偏见，但需持续关注团队动态以确保机制有效。

• 新疑问：当匿名结果分歧较大时，如何高效引导团队达成共识？

问题二：PM 在 “管事不管人” 原则下如何有效推动项目？

• 原问题思考：PM 缺乏人事管理权时，如何在进度紧张或意见分歧时协调资源、化解冲突。

• 解答过程

  ：实践中总结出关键策略：

  • 明确项目目标与计划，通过飞书等工具跟踪任务，让团队方向清晰。
  • 强化沟通与数据支撑，用案例和数据说服成员，而非行政命令。
  • 建设协作型团队文化，通过共识而非权威推动决策。

• 当前理解：PM 软技能（沟通、协调）是核心，合理方法可弥补缺乏管理权的不足。

• 新疑问：当团队成员对项目目标存在根本分歧时，PM 应如何破局？

问题三：用户体验优化是否可能陷入 “过度设计” 陷阱？

• 原问题思考：担心优化导致技术复杂度上升或牺牲核心功能（如隐藏高级功能）。

• 解答过程

  ：项目中采取的措施：

  • 用户分层设计：为普通用户简化界面，为专家用户保留高级功能入口。
  • 建立优先级评估框架，从用户需求、技术成本、商业价值维度评估优化方案。

• 当前理解：分层设计与评估框架可避免过度设计，但需平衡不同用户需求。

• 新疑问：如何平衡普通用户与专家用户的体验需求，避免矛盾？

二、各阶段知识点总结

需求阶段：用户访谈技巧

• 知识点：通过开放式提问、避免引导性问题，从用户表述中挖掘真实需求。
• 项目经历：团队访谈时曾因提问方式不当导致需求偏差，后改用 “场景假设法”（如 “当你遇到 XX 情况时会怎么做”），有效获取了用户未明确表达的深层需求。

设计阶段：模块化设计原则

• 知识点：将系统拆分为低耦合、高内聚的模块，通过接口定义交互规则。
• 项目经历：团队将系统分为 “数据处理模块” 与 “界面展示模块”，开发时各模块并行推进，但因接口定义不清晰导致集成时反复修改，体会到接口设计的重要性。

实现阶段：代码规范协作

• 知识点：统一命名、注释、格式规范，提升代码可读性与协作效率。
• 项目经历：初期因成员代码风格混乱导致审查效率低下，后来多次在会议中强调，尽量统一了代码风格。

测试阶段：单元测试实践

• 知识点：对函数 / 类进行独立测试，验证逻辑正确性。
• 项目经历：为核心算法编写单元测试时，发现边界条件处理漏洞（如空值输入），通过测试用例覆盖后降低了线上故障风险。

发布阶段：CI/CD 流程搭建

• 知识点：通过自动化工具实现代码构建、测试、部署的流水线。
• 项目经历：使用 Github Actions 配置 CI 流程，避免了每次更新 master 后打包、上传的重复工作。

维护阶段：日志监控体系

• 知识点：设计结构化日志，记录关键业务流程与异常信息，便于故障定位。
• 项目经历：线上出现数据异常时，通过分析日志发现是缓存更新策略导致的竞态条件，及时修复避免了更大影响。

三、个人实践心得

结对编程：沟通与互补的价值

• 与同伴结对时，通过实时讨论代码逻辑，不仅快速发现了自己的逻辑漏洞，还从对方的设计思路中获得启发（如更优的数据结构选择）。沟通能力的提升比代码能力的提升更显著。

团队项目：工程思维的养成

• 从 “单兵作战” 到 “团队协作”，深刻认识到：
• 分工明确与接口文档的重要性（曾因模块间数据格式不统一导致集成延迟）。
• 版本控制（Git）与任务管理（看板）是团队效率的基石，而非 “额外工作”。

“做中学” 的核心感悟

• 理论知识（如 UML 建模、敏捷流程）需通过项目实践才能真正内化。例如，课堂上理解 “用户故事” 的概念，但只有在亲自访谈用户、编写故事时，才明白如何避免 “需求模糊”。