[I.3] 个人作业：结课总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.3] 个人作业：结课总结 |
| 我在这个课程的目标是 | 将软件工程理论与实践相结合、提升批判性思维和团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过深入回顾和总结，梳理了软件工程各环节，更加深刻理解软件工程理论的应用 |
链接到以前提问题的博客
0 写在前面
一个学期里，我先后完成了 个人练习 → 结对项目 → 团队项目（RAGnarok） 的完整梯度。
回头看，当初留下的六个问号，其实正好对应了我在团队里扮演过的六类角色：
设计评审者、结对伙伴、Scrum Master、产品经理、交互设计师，以及临时的绩效评审委员。
下面按问题逐一复盘
1.解答问题
1 PSP 中的设计复查 VS 快速开发
| 回顾 | 现在的答案 |
|---|---|
| 困惑：严格照 PSP 走（尤其设计复查）会拖慢节奏吗？ | 结论：1) 全量评审只保留“架构级”（影响多模块的接口 & 不可逆决策），其它改成 Pull Request (PR) 里滚动评审。2) 输出物从厚文档 ⇒ 轻量 ADR1（Architecture Decision Record），评审时间压缩到 ≤ 4 h/周。3) 缺陷密度对比：RAGnarok 首迭代（无正式复查）≈ 0.42 bug/百行；引入上述流程后 ≈ 0.18 bug/百行——节拍基本没降。 |
| 我是这样弄清楚的 | - 书本：重读《Clean Architecture》里“设计即沟通”章节，意识到评审的核心价值在于同步共识，而非产出文档。- 实践：两次 Sprint 里各做一次 A/B 对照（无 vs 有 ADR 评审）；用 SonarQube 和自建缺陷栈记录真实数据。- 讨论：参考学长团队的做法——只对“高耦合”改动强制走评审，其余走“先合后追踪”。 |
| 仍存疑 | 如何让 ADR 知识库在新人加入时快速吸收，而不是躺仓库吃灰？ |
| 新问题 | 能否用 RAG+ChatOps 自动把历史 ADR 里的关键决策内容拉出来回答新人提问？ |
2 结对编程 VS 独立开发 + 严格 Review
| 回顾 | 现在的答案 |
|---|---|
| 困惑：结对到底值不值？ | 结论：任务复杂度 × 不确定性 高时（例如 蛇影舞的代码编排），结对明显优；低复杂、IO 型任务（前端样式、脚本工具）单人 + PR 即可。 |
| 我是这样弄清楚的 | 书本：《Pair Programming Illuminated》里提到的“合计人时不升反降”只有在“不确定度高”场景才成立 → 与实验吻合。 |
| 仍存疑 | 跨时区远程时，实时结对难以落地——异步结对模式效果如何度量？ |
| 新问题 | 是否存在客观指标（而非主观打分）衡量“结对互补效果”？ 例如互补知识图谱重叠度？ |
3 如何落地 Scrum & 设定 Sprint
| 回顾 | 现在的答案 |
|---|---|
| 困惑：怎么让 Sprint 既稳又灵活？ | 结论：1) Sprint ≤ 2 周，目标不含“研究型任务”；探索性工作提前一 Sprint 做 Spike；2) 缓冲 10–15 % 容量，用于突发；3) 每日站会外再加 看板-卡点泳道：一有卡点就拖进泳道并 @Scrum Master |
| 我是这样弄清楚的 | 实践：两次 Sprint 里 A/B 对照（无缓冲、无 MC 预测 vs 有），后者延期率 0%，前者 25%。 |
| 仍存疑 | 研究型课题如何与固定 Sprint 节拍并存？ |
| 新问题 | 能否把科研 OKR 拆成“探索 Story + 成果 Story”以融入 Scrum？ |
4 需求不明确时，PM 还能做什么？
| 回顾 | 现在的答案 |
|---|---|
| 困惑：PM 在“大家都想写代码”环境下的职责？ | 结论：1) 共识锚点：让团队围着痛点而非功能讨论；2) 对外接口：Scrum Master 向内管节拍，PM 向外对 导师、潜在用户做 Demo & Workshop。 |
| 我是这样弄清楚的 | 实践：RAGnarok 最初“想做一站式问答” → 通过 12 份访谈沉淀三类用户（Dev / Ops / Non-Tech）→ 聚焦“工作流可视化 + 多协议” |
| 仍存疑 | PM 与 Tech Lead 的边界——在科研型项目中二者职责常重叠。 |
| 新问题 | 如何量化 PM 在“模糊需求探索”里的贡献？ （比如转化率、需求稳定度） |
5 图标、菜单与可发现性
| 回顾 | 现在的答案 |
|---|---|
| 困惑：界面简洁 vs 功能可发现？ | 结论：1) 对 高频常用 操作：图标 + 文本（e.g. “🔍 Search”），既节省空间又不牺牲可读性；2) 低频/高风险 操作：使用显式文案或二级菜单，避免“意外误触”；RAGnarok 后台仪表盘中，把“删除数据源”转成了带文字按钮，误操作率从 8% → 0%。 |
| 我是这样弄清楚的 | 讨论：与 UI 同学用 Figma 做两版 A/B，对比成功路径。 |
| 仍存疑 | 在多语言界面里，图标+文本 是否会因翻译膨胀而破坏布局？ |
| 新问题 | 能否根据真实使用频次，动态调整图标↔文本呈现？ |
6 绩效评价：公平 VS 内卷
| 回顾 | 现在的答案 |
|---|---|
| 困惑：如何既公平又不卷？ | 结论：1) 三维度模型：Delivery（Story Point 完成率）、Quality（缺陷率 & PR 审查得分）、Impact（文档/分享/提案）。2) 权重：0.4 / 0.3 / 0.3，周期 Review；3) 奖金分配走 目标档位 + 浮动系数：达标即基准，突破目标用“贡献系数 k”分池奖金； |
| 我是这样弄清楚的 | - 资料：字节OKR 文档；- 实践：期中阶段试行打分，团队满意度从 3.2 → 4.4（5 分制）； |
| 仍存疑 | 当团队目标受外部依赖（导师资源、云额度）影响大时，个人上限与团队系数绑定是否会打击积极性？ |
| 新问题 | 如何在科研导向/实验性团队里定义“Quality”维度？（实验 reproducibility？） |
2 六大阶段 & 我学到的关键知识点
需求阶段——用户故事地图
真正把需求讲清楚的转折点，是把知识库管理的全过程画成一张用户故事地图：从「上传文档 → 解析 → 检索 → 回答」一路拆到最细粒度。可视化之后，大家立刻发现了一个此前被忽略的缺口——批量导入失败后的恢复流程。一次访谈里有位运营同学提到：“如果我上传 100 份文档突然中断，必须知道哪些已成功、哪些要重传。” 这句话被贴在地图的空白处，随即衍生成一条新的用户故事和 API 设计需求。故事地图让我们首次体会到：需求不是列表，而是一条完整旅程，只有在旅程里看见空洞，才谈得上闭环。
设计阶段——设计冗余（适配层）
大模型接口千变万化，我们在业务逻辑和第三方 LLM 之间加了一层 Adapter。这层只做协议转换，核心逻辑永远面对统一的内部结构。去年 12 月 OpenAI 改了 JSON 字段名，外网一片“全量重构”的呼声，但我们只动了适配器 200 行代码、一天内就完全兼容。那次经历让我明白，冗余不是浪费，而是在“不控场”接口面前留出的安全缓冲；隔离变化 才是高可用设计的本质。
实现阶段——测试驱动开发（TDD）
在写嵌入（embedding）服务时，我们坚持“先写测试再写实现”。一个测试要求“必须正确处理包含 emoji 的 UTF-8 文本”，这迫使我们一开始就考虑编码细节。结果发现第三方分词库对高位 Unicode 默认会截断；要是照常先写功能、后补测试，这个坑多半要到线上才爆雷。那一次把“红灯→绿灯→重构”的流程走通后，团队再也没人质疑 TDD 的性价比：测试就是设计的一部分，不是事后保险。
测试阶段——逐步发布（灰度）
新对话功能上线时，我们把 CI 成功后的镜像先打到 “internal” 环境，只给团队自己用。很快发现移动端 Safari 会把气泡宽度撑满，影响阅读；修完再放 5% 外部流量，观察 24 小时无异常后升到 20%，最终全量。整个过程依赖 GitLab 环境标签和自动化脚本，回滚只需一条命令。灰度让“上线”从一次押注变成一条斜坡：问题越早暴露，代价越低。
发布阶段——更新文档（可视化变更日志）
每次版本发版，飞书文档里的「ChangeLog」都会自动更新：红底标记 Breaking Change，蓝底标记 Feature，绿底标记 Fix，并附带升级指引和截图。颜色一眼区分优先级，截图让非技术同学也能快速理解改动。这让沟通成本低到只需看一张表，版本越迭代越清晰。
维护阶段——分级告警（即时通知）
上线后最大的安心感来自飞书机器人的 分级告警：CPU 暴涨或接口 5xx 飙升会直接电话；SLO 逼近阈值则群里高频 @；日常小异常统一成日报。这样既保证了紧急问题秒级触达，又不至于把普通问题也打成“红警”造成疲劳。实践证明，告警不是越多越好，而是要有节奏、有层次——真正严重的报警必须响亮到让人立刻放下手头工作。
3 个人心得：从“读”到“做”，从“做”到“问”
- 书给框架，实践给温度
课堂与《PSP/XP/Scrum》教科书，为我提供了“该做什么”的模板；真正落地后，才体会到每一步的代价与价值。 - 数据驱动改进
过去我常凭感觉评估流程。RAGnarok 里第一次把缺陷率、人时、满意度量化并做 A/B，对“流程值不值”有了硬指标。 - 从“功能导向”转向“问题导向”
无论需求、设计还是绩效，本学期最深刻的变化是——先问“问题/痛点是什么”，再决定做什么，而不再是“看见技术就想加”。 - 持续提问
回顾期初的六个问号，今天依旧还有尾巴。技术在变，场景在变，提问本身就是成长的里程碑。
4 未来计划 & 新疑问
- 自动化 ADR 问答：尝试用自研 RAG Pipeline，把仓库 ADR / PR 记录嵌入知识库，为新人提供 ChatOps。
- 异步结对度量：设计一个“协同分布图”（协作时间轴 × 缺陷发现率）来评价跨时区结对价值。
- 科研型 Scrum：探索把“Spike Story + Research Outcome Story”纳入 Sprint，并建立对应验收标准。
- 共享 UI 可发现性：依据实际点击热度，动态切换“图标 + 文本”展示。
实践是检验真理的唯一标准。
我会继续用「提问 → 实验 → 量化 → 反思」的循环，继续探求这些新问题，也期待和伙伴们一起迭代更优的流程与产品。
浙公网安备 33010602011771号