FocusPet Alpha Postmortem

2 minute read

Published:

FocusPet Alpha Postmortem

贡献排名

  • 毛一戈 — 32%：主导后端核心、WebSocket、DB、Session/Record 与 Subtask 重构、CI 与打包脚本；多次解决集成/race 问题。
  • 李永康 — 28%：主导 Godot 端及原生集成（C++ Extension）、WebSocket 客户端、托盘/退出/进程同步等桌面关键实现。
  • 申鹏 — 20%：主导 React 前端 UI/交互、设置/统计界面重构、路由与前端兼容修复，负责前端联调与用户体验。
  • 赵昱 — 20%：担任 Scrum Master/协调者，负责 TimerService、统计后端 API、CI 协调与打包流程跟进，保障交付节奏。

设想与目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？
  • 目标：把番茄工作法、待办管理与桌面宠物结合，利用“宠物行为”提供即时的情感反馈，帮助用户提升专注与持续使用率。核心用户是希望用可视化与拟人化反馈来管理专注时间的桌面用户（主要为开发者/学生）。
  • 评价：目标定义清晰，典型场景（开始番茄钟→专注→完成任务→宠物反馈→查看统计）覆盖了主流程，团队在设计稿与用户故事上达成一致。
  1. 我们达到目标了么？
  • 功能达成度：核心功能（待办 CRUD、番茄专注、Subtask、桌面宠物渲染、统计视图）均在 Alpha 阶段实现并能闭环演示。部分 polish（跨平台签名、完整自动化打包）仍在收尾。
  • 交付时间：按内部计划多数功能在 11.18 前已实现并能演示，但“发布级别的打包/签名”未完全按最初计划完成。
  • 用户预期：尚未大规模发布到外部用户，无法用真实用户量衡量，但内部测试表明核心交互可被典型用户理解并使用。
  1. 团队工程质量提高了吗？如何衡量？
  • 提高点：引入 CI（fmt check、构建流水线）、代码审查流程加强、增加单元/集成测试（初期）。这些在合并前拦截了若干语法与格式性错误，提升了提交质量。衡量：CI 拦截率、PR 回滚次数下降、主分支稳定性提升。
  • 仍需改进：测试覆盖率和自动化回归尚不足，最后的“集成问题”仍需更多自动化回归来提前发现。
  1. 用户量与接受度是否符合预想？
  • 结论：Alpha 主要面向内部与小范围测试用户，目标用户量未达最终目标，但功能完成为后续外部测试打下了基础。

计划（Planning）

  1. 是否有充足时间来做计划？
  • 在 Alpha 前期，计划时间有限（短周期冲刺），但团队在站会中频繁调整优先级，能够快速响应。总体来说“规划充足”与否取决于对“最后一公里”的估计，显然我们低估了打包与兼容工作量。
  1. 计划阶段如何处理分歧？
  • 通过每日 Scrum 与快速技术讨论（短会），以及由 Scrum Master 提出优先级建议，必要时由负责人拍板（毛一戈/申鹏/李永康 分别负责各条技术线）。这种决策机制快速但仍依赖三方信任。
  1. 是否完成原计划工作？未完成的原因？
  • 大部分功能完成。未完成：跨平台签名（macOS code signing）与发布脚本的最后验证。原因：跨平台签名流程复杂，证书/审核耗时被低估。
  1. 有没有做了事后看来没必要的工作？
  • 部分临时兼容性补丁在短期内解决了问题，但后续发现应在后端统一修正而非前端多处打补丁。建议将兼容策略集中管理。
  1. 是否每项任务都有清晰交付件？
  • 大部分功能任务有明确的验收标准（例如：待办可以创建/进入番茄、统计显示基本卡片），但少数依赖外部资源（证书、平台测试）缺少清晰的时间节点。
  1. 过程是否按计划进行？出现了什么意外？
  • 意外：WebSocket 在高频消息下出现内存增长与断连；统计数据在前后端结构变更后出现重复聚合问题；打包证书问题影响 macOS 发布。
  1. 缓冲区是否有作用？
  • 有一定作用：计划中保留的小量缓冲使我们在遇到兼容性问题时得以调优，但缓冲量不足以覆盖 code signing 的多次阻塞。
  1. 将来计划要做的修改？
  • 建议在计划中为“跨平台打包与签名”单独预留较大时间窗口，并在早期就开始证书申请与自动化脚本验证。

资源

  1. 资源是否充足？
  • 开发人力在短期冲刺下能够覆盖主要工作，缺点是某些专业任务（证书、平台兼容性测试）需要额外外部资源或更长时间。
  1. 时间估计与精度如何？
  • 对于常规功能估计较准（±1-2 天），但对集成/打包/签名这些外部依赖估计误差较大。
  1. 测试的人力与资源是否足够？
  • 自动化测试覆盖有限，手工测试比例高。美工/文案等非编程资源投入适中但不充足，影响最终 polish 效果。
  1. 有没有可以交由他人更高效完成的工作？
  • 游戏美工与 UI 设计工作，以提升视觉与交互质量，释放开发者专注于核心功能实现。

变更管理

  1. 变更传达是否及时？
  • 大体及时：通过站会与 PR 注释传达关键变更；但对后端数据结构的变更，需要更严格的版本声明与兼容策略文档。
  1. 如何决定“推迟”或“必须实现”？
  • 以“影响主流程闭环”为优先级：若功能直接阻断主流程（例如路由跳转、Timer 逻辑）则必须实现；次要 polish 可推迟。
  1. 出口条件（Exit Criteria）是否清晰？
  • 对演示级别清晰（可演示主流程），但对“发布级”缺少条目（如 code signing、安装包完整性检查）。
  1. 是否有应急计划？
  • 有基础降级策略（先发布 Windows 版本，macOS 用未签名包供测试）。建议将这些策略在计划阶段写入文档。
  1. 员工是否能处理意外请求？
  • 团队响应机制有效，短时内能处理突发任务，但频繁的上下文切换影响效率。

设计 / 实现

  1. 设计何时由谁完成？是否合适？
  • UI/交互由申鹏主导，后端数据库与 API 结构由毛一戈主导，Godot 动画由李永康主导。总体分配合理，职责清晰。
  1. 设计是否遇到模糊点？如何解决？
  • 遇到的模糊点多为跨进程消息格式与字段命名冲突。解决方式：临时约定版本化消息格式，并在短会中确认最终字段映射。
  1. 单元测试 / TDD / UML 等工具的运用？
  • 使用了部分单元测试与集成断言，但 TDD 未普遍采用。UML 文档为初版，之后因实现细节演化需要更新。
  1. 哪些功能产生 Bug 最多？为何？
  • 产生 Bug 最多的是统计聚合（重复计数）与跨进程通信（字段不一致、断连）。原因在于数据模型演进与缺乏集中兼容层。
  1. 代码评审是如何进行的？
  • 采用 PR 流程，CI 会跑格式检查和构建，团队执行代码走查，但部分小变更曾直接合并，建议更严格的保护主分支策略。

测试 / 发布

  1. 是否有测试计划？
  • 有基本测试计划，但更多依赖人工验收测试。未来需要把关键路径（Timer、任务创建、统计聚合）列为自动化回归项目。
  1. 是否进行了正式验收测试？
  • 尚未进行大规模 Beta 测试。
  1. 是否使用测试工具？
  • 部分自动化脚本存在（构建验证），但单元/集成自动化不足。建议优先在后端引入更多集成测试，并在前端保持基本 E2E 覆盖。
  1. 性能与压力测试？
  • 未进行大规模压力测试；内部运行表明 TimerService 在高并发消息下需要更多稳定性验证。
  1. 发布过程中出现的意外问题？
  • macOS code signing 延迟、部分环境下 Godot C++ Extension 编译差异、统计重复计数暴露前后端不一致。

经验教训与改进建议

  1. 早期就开始做跨平台打包与签名的准备（证书申请/自动化脚本），避免在最后一周被阻塞。
  2. 对后端数据模型变更采用版本化兼容策略，在后端统一做适配，前端仅实现降级与容错。
  3. 将关键路径测试（Timer、任务创建、统计聚合）优先用自动化 E2E 覆盖，减少人工回归成本。
  4. 将“最后一公里”工作（发布、签名、安装体验）纳入计划的显式验收条件（Exit Criteria）。
  5. 继续把 AI 用作“辅助开发者”，在代码生成、bug 定位、CI 配置等方面发挥效率，但对关键安全/签名流程仍需人工把关。

后续行动项（行动负责人 + 时间）

  1. 完成 macOS code signing 与自动化打包脚本（负责人：赵昱 & 毛一戈，目标：2 周内）
  2. 编写并执行关键路径 E2E 测试（负责人：申鹏，目标：1 周内）
  3. 在后端建立消息版本兼容层并更新文档（负责人：毛一戈，目标：1 周内）

风险分析与解决情况

下表列出 Alpha 阶段识别的主要风险点、我们采取的缓解措施、当前状态

风险具体点我们采取的缓解措施当前状态是否属于过度工程化结论 / 建议
集成地狱 (Integration Hell)三个独立运行环境需实时同步；WebSocket 消息丢失/延迟/重连/一致性问题；monorepo 构建依赖复杂规范消息协议（JSON schema/version）；心跳与重连策略；设置专人联调时段；CI 中增加跨模块构建顺序检查部分缓解，仍需自动化回归覆盖关键路径否（但关联技术复杂度高）已缓解通信断连与重复统计问题；建议增加自动化集成测试与消息模拟工具，建立消息兼容层。
关键人物瓶颈 (Key Person Bottleneck)Rust/Tauri 负责人掌握核心计时器、通信、DB 逻辑，形成单点风险知识共享（pair-programming、PR 注释、文档）；分配次要任务给他人；关键区块写入设计文档已降低但仍存在否建议对关键模块建立更明确的接口与文档，并安排交叉培训/备援。
UX 割裂 (Fragmented UX)两套 UI（Web / Godot）状态不同步将破坏情感闭环统一消息版本；优先保证“开始/停止/完成”三条闭环的同步；前端降级策略已解决主要闭环，但细节延迟仍可见否继续优化前端延迟感知（感知层降级、动画占位提示），并在 E2E 测试中加入用户感知用例。
过度依赖新技术堆叠Tauri/Rust/Godot/WebSocket/AI/复杂 CI 堆栈增大学习曲线与兼容风险聚焦 MVP、对复杂功能分期交付、优先稳定核心路径属于明显风险点是这是典型的过度工程化案例。建议在下阶段明确“最小可行栈”，对非必要技术进行降级或延迟集成。
目标用户不聚焦同时面向多类用户，需求不一明确首发目标用户（桌面开发者/学生）；收集早期测试反馈部分明确，但需验证否需要尽快做小范围用户测试并据此调整优先级。
情感激励未经验证宠物反馈能否持续激励用户未知快速原型测试（内部使用）、收集定量指标未充分验证否建议设计 7 天留存与行为指标实验，验证激励效果。
缺乏留存设计无成长/社交/中期激励机制确定短期可做的轻量化留存策略（宠物成长、目标成就）高风险否将留存特性列入下个里程碑，优先级需提升。
与竞品差异不足USP 主要为视觉层面，互动不足会弱化竞争力提升互动质量、降低延迟、增加微交互进行中否继续打磨互动与情感反馈，并形成可量化的差异化指标。

关于“过度工程化（over-engineering）”的分析

过度工程化在本项目中的表现：团队同时采用了多项较新的技术栈（Tauri、Rust、Godot、WebSocket、AI 辅助开发、复杂 CI），并在短周期内尝试把它们全部整合到 Alpha 中。典型症状包括：集成成本远高于单项实现成本、调试与打包时间指数级增长、最后一公里（签名/发布）被外部流程拖住。

我们为什么会走到这一步：团队希望在 Alpha 阶段同时验证技术可行性与最终用户体验，因此把“验证”与“交付”放在了同一时间窗口，导致过多并行学习与集成工作。

如何改进（建议）：

  • 明确分层优先级：把“用户可感知的闭环”放最前面（Timer、任务、宠物反馈），把工程化、性能优化、跨平台签名分为后续迭代。
  • 采用渐进式集成：先以“最小可行协议”实现进程间通信，后续再按需引入复杂特性（例如高频 telemetry、AI 助手）。
  • 减少临时补丁：把兼容/降级逻辑集中在后端的兼容层，而不是在前端多处打补丁。
  • 在计划中显式留出“平台/证书/签名”时间块并提前申请证书。

成员退出

由于我们项目采用了许多新技术栈和复杂的集成方案，团队成员在项目中积累了宝贵的经验和技能。为了确保项目的持续发展，确保在课程结束之前完成一个稳定的Beta版本，我们一致认为团队成员应继续留在项目中。

Mid-Postmortem about this class

一、如果再来一遍，我们在这门课上希望这样做（6 条）

想停止的：

  1. 停止“临近里程碑才疯狂赶工”的节奏 之前在 Alpha 阶段我们也在最后几天集中解决打包、签名和兼容性问题，风险很大；并且，下次我们会把「跨平台打包、证书、CI 配置」这些“最后一公里”任务拆得更细、前移到 Sprint 1。

  2. 停止一次性大提交、含糊的 commit message 之前有好几次是“misc fix”“update front-end”的大杂烩提交；并且，下次我们会坚持小步提交 + 结构化 commit message，让 Postmortem 的时候能清楚看到每次改动的因果。

  3. 停止只在本机手工点点点做回归 在 Alpha 阶段统计聚合、WebSocket 这些问题，很多是因为缺少自动化回归；并且，下次我们会优先为「Timer、任务创建、统计」这些关键路径补上自动化测试。

想继续的：

  1. 继续把课程作业和真实项目捆在一起做 FocusPet 把番茄钟、桌面宠物、统计结合起来，让课堂上的用户故事、用例图、CI/CD 都有了落地场景；并且，下次我们还是会用课程要求来“倒逼”自己做出可发布的产品，而不是只完成作业。

  2. 继续在博客里写正式的工程复盘 像 Alpha Postmortem 这样按“目标-计划-资源-变更-测试”结构写总结，很有助于对齐团队认知；并且，下次我们会在每个 Sprint 结束后固定写一篇小 Postmortem，而不是只在大阶段结束时才写。

想新增的：

  1. 新增一套“个人学习 Backlog” 现在很多 React/Godot/CICD 的知识都是临时查；并且，下次我们会在项目 Backlog 之外，再维护一个只属于自己的学习 Backlog，例如「掌握一套前端测试框架」「读完一次 Godot 官方教程」，每个 Sprint 清掉几项。

二、如果再来一遍，我们在这门课上希望这样不要做（6 条）

想停止的：

  1. 停止忽视“最后一公里”工作 之前我们低估了跨平台打包、签名、安装体验的复杂度，导致最后几天手忙脚乱；并且，下次我们会在计划阶段就把这些工作拆出来，预留充足时间。
  2. 停止忽视“用户体验细节” 之前我们过于关注核心功能实现，忽视了前端交互的流畅性和一致性；并且，下次我们会在每个 Sprint 结束时专门留出时间做 UX polish。
  3. 停止忽视“团队沟通” 之前我们在跨模块集成时出现了信息不对称的问题，导致一些 Bug；并且，下次我们会加强跨模块的沟通和文档共享，确保每个人都了解整体架构和接口规范。 想继续的：
  4. 继续使用敏捷开发方法 敏捷开发帮助我们快速迭代和响应变化；并且，下次我们会继续使用 Scrum 框架，保持每日站会和 Sprint 规划。
  5. 继续利用 AI 辅助开发 AI 工具在代码生成和问题排查方面提供了很大帮助；并且，下次我们会继续探索 AI 在开发中的应用，但会更加谨慎地验证生成代码的质量。 想新增的：
  6. 新增定期的技术分享会 之前我们在项目中积累了很多技术经验；并且，下次我们会定期举办技术分享会，让团队成员分享各自的学习和经验，促进知识共享。

三、对于团队 FocusPet，希望这样做（5 条）

想停止的：

  1. 停止一开始就设计过多“炫技”功能 Alpha/Beta 里我们就把“分心检测”“宠物进化”等高风险特性排到 Won’t-Have；并且，下次团队在立项时会更狠一点，只围绕“专注→奖励→消费”的闭环做精做透，提前砍掉不必要的技术堆叠。

  2. 停止把兼容性问题留给前端/客户端“打补丁” Alpha 里前端为了兼容后端字段变更，经常加临时代码；并且，之后我们会坚持“在后端和协议层统一修”，减少到处散落的补丁。

想继续的：

  1. 继续保持清晰的角色分工和贡献透明 像 Alpha Postmortem 里的贡献排名，把谁负责 WebSocket/DB、谁负责 Godot、谁管前端和 CI 都写得很清楚；并且，以后每个阶段我们都继续公开列出职责与贡献，让大家对彼此的工作有尊重也有期待。

  2. 继续用 Daily Scrum + Kanban 管理进度 目前每天站会 + 看板更新可以及时暴露风险（比如 code signing 拖延）；并且，下次我们会在看板上显式标出“有外部依赖”的卡片，方便提前预留缓冲。

想新增的：

  1. 新增团队级的 Definition of Done（DoD） 现在有些任务“写完代码就算完成”；并且，下次我们会在 DoD 里强制包含：通过 CI、关键路径测试通过、文档/变更日志更新、影响范围说明，确保每张卡片的完成是可验证的。

四、对于学院其他课程，希望这样做（5 条）

想停止的：

  1. 停止只关注理论知识的传授 许多课程过于注重理论，缺乏实际项目应用；并且，学院可以更多地结合实际项目，让学生在实践中学习和应用知识。
  2. 停止忽视跨学科的课程设计 课程内容往往局限于单一学科，缺乏跨学科融合；并且，学院可以设计更多跨学科的课程，促进学生综合能力的发展。 想继续的：
  3. 继续鼓励项目驱动的学习方式 项目驱动的学习方式能够激发学生的兴趣和创造力；并且，学院可以继续推广这种学习方式，让学生通过实际项目提升技能。
  4. 继续提供丰富的资源支持 学院提供的资源（如实验室、图书馆、在线资料）对学生学习非常有帮助；并且，学院可以继续丰富和优化这些资源，满足学生的多样化需求。 想新增的：
  5. 新增更多实践机会和实习项目 学生需要更多的实践机会来应用所学知识；并且，学院可以与企业合作，提供更多实习项目，让学生在真实环境中锻炼技能。

Leave a Comment