《现代软件工程》团队项目Alpha阶段启动

5 minute read

Published:

FocusPet 团队博客：Alpha 阶段启动宣言

项目地址:

一、项目的需求分析和商业前景

1. NABCD (Need, Approach, Benefits, Competition)

关于项目的核心价值，我们已经在 NABCD 分析报告中达成了共识。这里是关键摘要：

N (Need - 需求)

用户的核心痛点是启动困难（拖延症）、工具冰冷且割裂（番茄钟/待办事项分离）、缺乏即时正反馈。

A (Approach - 方法)

我们的方法是构建一个“任务-专注-宠物”三位一体的情感化效率闭环。经过团队会议，我们决定采用一个性能卓越、职责清晰、高度专业化的混合架构：

  • 后端主进程 (Backend Core): 使用 Tauri (Rust) 来构建主进程。它负责所有核心逻辑（计时器、分心检测、数据库），以获得极致的性能和系统 API 调用能力。
  • 主 UI 前端 (Main UI): 使用 Web UI 框架 (如 React/Svelte/Vue) 运行在 Tauri 的 WebView 中。它负责“待办事项”、“商店”、“设置”等所有数据驱动的 UI 界面。
  • 宠物渲染前端 (Pet Renderer): 使用 Godot 游戏引擎。它作为一个独立的渲染进程运行，只负责“宠物”的动画、交互和状态机，以实现最顶级的视觉表现力。
  • 通信 (Communication):
    • Tauri (后端) <-> Web UI (前端A): 通过 Tauri 原生的 Commands 和 Events 高效通信。
    • Tauri (后端) <-> Godot (前端B): 通过 WebSocket (由 Tauri 后端提供服务) 进行实时的、解耦的状态通信。
  • 数据库 (Database): 使用 SQLite 作为持久化数据库，由 Tauri 后端统一管理。

B (Benefits - 好处)

核心好处是将生产力从“自我逼迫的苦差事”转变为“有陪伴的养成游戏”，显著提高用户的任务启动率和完成率。

C (Competition - 竞争)

相比 Forest (静态种树) 和 Habitica (复杂 RPG)，我们的优势在于提供“可养成的动态伙伴”和“任务-专注-奖励”的深度闭环。

D (Delivery - 交付)

Alpha 阶段将交付一个功能完整的跨平台（Win/Mac）桌面应用，并通过学生和效率社区进行推广。

2. 新闻稿 (Press Release)

FocusPet 团队发布革命性桌面效率工具，让“拖延症”成为过去

[你的城市/日期] — FocusPet 团队今日宣布推出其 Alpha 版桌面应用。这是一款专为学生、设计师和知识工作者打造的“情感化效率工具”，它巧妙地将番茄工作法、待办事项列表与电子宠物养成相结合。

“我们受够了那些冰冷的计时器”，“FocusPet 的核心理念是，你的专注力是你宠物的唯一食粮。当你完成一个任务时，你的宠物会为你欢呼。这种即时的情感联系，是战胜拖延症的强大动力。”

FocusPet 通过一个“效率闭环”工作：用户从待办列表中选择任务，启动番茄钟，专注期间宠物会安静陪伴。如果用户中途分心（可选功能），宠物会表现出焦虑。当任务完成时，宠物会获得奖励和成长。

FocusPet Alpha 版现已开放下载，支持 Windows 和 macOS。

3. FAQ (常见问题解答)

Q: FocusPet Alpha 阶段收费吗？
A: Alpha 阶段完全免费。我们目前专注于根据用户反馈打磨核心功能。

Q: 你们支持哪些平台？
A: Alpha 阶段支持 Windows 和 macOS。

Q: 你们会同步我的数据吗？我的隐私安全吗？
A: 在 Alpha 阶段，我们不会有任何云同步功能（W3 功能）。您所有的待办事项、金币和宠物数据 100% 存储在您本地电脑的 SQLite 数据库中，由 Tauri 进程管理，确保了隐私和安全。

Q: 你们如何预估发布后的活跃用户？
A: 这是一个课程项目，但我们以产品标准要求自己。我们预计在 Alpha 发布后 8 周内，通过学生社区和效率论坛（如 V2EX, 小红书）的推广，能达到 500-1000 名下载用户，并实现 20% 的周活跃用户（WAU），约 100-200 名。

4. 软件的典型用户 (User Persona)

我们的典型用户“Lily”：

  • 姓名： Lily
  • 角色： 20 岁的大学生 / 24 岁的初级设计师
  • 场景： 需要长时间（但非连续）地在家中书桌前学习或工作，需要管理一个简单的任务列表。
  • 核心痛点： 启动困难（拖延症）、工具冰冷、缺乏正反馈。

5. 典型用户使用软件的典型场景 (User Scenario)

  1. 计划 (Planning): 早上 9:00，Lily 打开 FocusPet 的主窗口（Web UI），在“待办事项”中输入今天的任务：“(M3) 完成论文第三章”、“(M3) 回复客户邮件”。
  2. 启动 (Initiation): Lily 盯着“论文第三章”，感到抗拒。但她看到桌面上独立的 Godot 窗口里，宠物正期待地看着她。
  3. 关联 (Linking): 她在主窗口（Web UI）中点击“论文第三章”，选择“开始专注”(M4)。
  4. 专注 (Focus): 25 分钟的番茄钟启动。Tauri 后端通过 WebSocket 通知 Godot 窗口。Lily 的宠物戴上“学习眼镜”，开始安静地“工作”(M5)。
  5. 分心 (Distraction) (C1): 15 分钟时，Lily 习惯性地想打开 Twitter。Tauri 后端检测到了“黑名单”应用，立刻通过 WebSocket 通知 Godot，宠物立刻发出“焦虑”的动画。
  6. 完成 (Completion): 25 分钟结束，铃声响起。
  7. 奖励 (Reward): Tauri 后端通知 Godot 窗口，宠物跳起来欢呼。主窗口（Web UI）弹出提示：“专注完成！获得 10 金币 (M6)。你是否完成了任务‘论文第三章’？”
  8. 闭环 (Loop): Lily 点击“是”。Tauri 后端再次通知 Godot，宠物爆发出一阵“盛大庆祝”动画 (M8)。
  9. 休息 (Break): Lily 进入 5 分钟休息，宠物也在 Godot 窗口里“玩耍”。

6. 你们团队是用什么样的方法来发现用户需求的？

我们综合运用了以下方法：

  • 解决自己的痛点（吃自己的狗食 - Dogfooding）： 这是我们最核心的驱动力。团队成员都是学生/开发者，我们深刻理解“拖延症”和“工具割裂”的痛点。
  • 深入面谈（基于 Persona）： 我们基于“Lily”这个典型画像，访谈了身边的同学和朋友，验证了“情感激励”的吸引力。
  • 竞品分析（用户日志研究）： 我们深入分析了 Forest 和 Habitica，发现了它们共同的短板：Forest 激励物静态；Habitica 过于复杂。

二、项目的团队、估计和设计

1. 团队成员的角色、团队模型和 Scrum Master

根据我们的新架构和分工，团队角色和职责调整如下：

角色成员职责
Godot / 宠物前端工程师\(成员 A 李永康\)专注于“角色”的实现。负责 Godot 客户端的全部开发，包括“宠物状态机”(Module 2)、所有宠物动画、以及实现 WebSocket 客户端来接收后端的状态。
Web / 主 UI 前端工程师\(成员 B 申鹏\)专注于“主进程 UI”的实现。负责 Web UI (React/Svelte/Vue) 的开发，实现待办列表 (M3)、商店 (S1)、设置菜单，并通过 Tauri Commands 与后端通信。
Tauri / Rust 后端工程师\(成员 C 毛一戈\) & \(成员 D 赵昱\)专注于“Tauri 后端”的实现。负责所有 Tauri (Rust) 核心逻辑：实现“番茄钟引擎”(M1)、“干扰检测器”(M3)、管理 SQLite 数据库 (M3/M4)，并同时搭建 Tauri Commands (服务 B) 和 WebSocket 服务器 (服务 A)。
PM / QA / Scrum Master\(成员 C 毛一戈\) & \(成员 D 赵昱\)敏捷流程管理、集成测试、CI/CD 和文档。（注：QA 职责极其重要，必须测试 A、B、C 三个独立组件的端到端集成）。
AI 助手…视为团队的第 5 位“初级工程师”，辅助我们编写 Rust、JavaScript/TypeScript 和 GDScript/C#。

团队模型： 我们不是“一窝蜂编程”，而是采用职责明确的功能团队 (Feature Team) 模型。

2. 第一版（Alpha）发布时的功能列表与分类

Alpha 版的目标是完成所有“Must-Haves (MVP)”功能，即 M1 至 M8。

功能 ID功能描述需求分类功能分类体验分类
M1标准番茄钟（专注/休息）必要需求核心功能卫生属性
M2[Godot] 桌面宠物窗口必要需求杀手功能让人惊喜
M3[Web UI] 极简待办事项 (CRUD)必要需求核心功能卫生属性
M4关联任务到番茄钟必要需求核心功能核心功能
M5[Godot] 宠物与计时器实时同步必要需求杀手功能让人惊喜
M6专注成功 -> 奖励金币必要需求核心功能让人惊喜
M7专注失败 -> 宠物难过必要需求核心功能让人惊喜
M8[Godot] 完成任务 -> 额外庆祝必要需求杀手功能让人惊喜

3. 工作估计的方法

我们计划采用敏捷开发中成熟的估计方法：

  • 故事点 (Story Points)： 我们不用“小时”来估计任务，而是用“故事点”（如 1, 2, 3, 5, 8）来评估一个功能（User Story）的相对复杂度。
  • 规划扑克 (Planning Poker)： 在 Sprint 规划会议上，团队所有成员（A, B, C, D）对同一个 User Story 进行匿名出牌（打分），直到达成共识。
  • WBS (Work Breakdown Structure)： 对于一个复杂的功能（如 C1 或 M5 的通信），我们将首先进行 WBS 分解。(关于 WBS 的详细实践，我们将在另一篇专门的博客中发布：\(链接到 WBS 博客文章\))。

团队必须注意：C1（分心检测）和 M5（实时同步）功能的复杂度（故事点）因我们的混合架构而显著提高，需要重新评估。

4. 如何收集 NPS (净推荐值)

我们将在 Alpha 版本中内置 NPS 收集机制。

  • 触发时机： “用户累计成功完成了 10 个番茄钟周期”或“累计完成了 5 个待办任务”之后。
  • 收集方式： 在用户达成上述条件后的一次休息时间，在主 UI 窗口 (Web UI) 中弹出提问：“你有多大意愿（0-10分）把 FocusPet 推荐给你的朋友？”
  • 后续： 如果分数（9-10），我们会鼓励用户分享；如果分数（0-6），我们会追问一个开放性问题：“我们还有哪里可以改进？”。

三、项目的具体开发和推进

1. 代码仓库如何保证代码质量？

代码质量是我们的生命线。我们将严格执行以下规范：

  • Git 工作流 (Git Flow)： 我们采用简化的 GitHub Flow。main 分支是受保护的、永远可部署的。所有开发都在功能分支 (e.g., feat/M3-todo-list) 上进行。开发完成后，提交 Pull Request (PR) 到 main。
  • 代码审查 (Code Review)： 任何 PR 必须至少有一名其他团队成员（A, B, C, D 均可）审查 (Approve)。
  • 自动化 (CI/CD)： 我们使用 GitHub Actions 作为 CI 工具。[挑战] 我们的仓库将是一个 monorepo（或三个独立仓库），CI 必须处理所有组件：
    • 后端 (Rust) CI: 运行 cargo check (检查), cargo test (单元测试) 和 rustfmt (代码规范)。
    • 前端 (Web) CI: 运行 npm run lint (ESLint/Prettier), npm test (Jest/Vitest 单元测试)。
    • 前端 (Godot) CI: 运行 godot –headless –check-only 确保脚本无误。
    • CI 检查不通过的 PR，严禁合并 (Merge)。

2. 如何运用 AI Coding 工具？

我们将 AI 助手（GitHub Copilot）视为积极的代码贡献者（辅助工程师）。

  • AI 作为“副驾驶”： 我们鼓励在编码时开启 AI 助手，用于：
    • 生成样板代码：例如，Tauri 的 Rust 指令、React/Svelte 组件框架、Godot 的 WebSocket 客户端脚本。
    • 辅助算法：例如，“请帮我写一个 Rust 的 WebSocket 消息处理器”。
    • 生成测试：“请为这个 Tauri Rust 模块编写单元测试”，或“为 SQLite 编写一个复杂的 JOIN 查询”。
  • TDD 确保一致性： 我们绝不盲目信任 AI 的代码。AI 生成的每一行逻辑代码，都必须有对应的单元测试来覆盖。

3. 如何推动开发进展？

我们将严格执行 Scrum 敏捷开发：

  • Sprints： 按照项目计划书，我们以 2-3 周为一个 Sprint 周期。
  • Daily SCRUM (每日站会)：
    • 方式： 每天异步进行。
    • 地点： 在我们的团队博客（或 GitHub Issue）的“每日站会 (Daily Scrum)”专用帖下，每人以评论的形式发布。
    • 内容： 严格遵循“三问”：昨天做了什么？今天计划做什么？遇到了什么障碍 (Blockers)？
    • Scrum Master (我) 负责每天检查站会，并优先解决所有被提出的“障碍”。

四、个人在团队中的贡献

1. 团队如何决定每一个人的团队贡献分？

我们深知这是一个敏感但重要的问题。我们将采用透明、公开、量化结合的方式，参考《构建之法》推荐的贡献分评估模型。

  • 基本原则： 贡献分 = 工作量 (Quantity) + 工作质量 (Quality) + 团队协作 (Teamwork)。
  • 评估方式：
    • Sprint 互评： 每个 Sprint 结束（Sprint Review）时，团队成员进行匿名互评（也包括自评）。
    • 评分维度：
      • 任务完成度（50%）：是否按时完成了 Sprint 中承诺的 Story Points。
      • 代码质量（30%）：产出的代码是否健壮、有测试、符合规范（通过 Code Review 和 CI 数据体现）。
      • 团队协作（20%）：是否积极参与讨论、帮助他人解决障碍、按时参加 Daily Scrum。
    • 分数汇总： Scrum Master 负责收集匿名评分，计算加权平均值，并将其作为该 Sprint 的个人贡献分，对团队公开。

2. Alpha 阶段后，如何决定“离开”的成员？

依据具体情况定，暂时先不考虑离开的问题。团队成员应致力于完成 Alpha 阶段的目标。而且如果更换成员，风险较大，可能会影响项目进度和质量。

五、项目的总结

预先总结 (Pre-Mortem)

现在是 2025 年 10 月 29 日。让我们快进到alpha阶段结束后，假设 FocusPet 项目彻底失败了。我们聚在一起，用直觉快速复盘，最可能的原因是什么？

  1. “集成地狱” (Integration Hell): “我们最大的失败。Tauri (C) 和 Godot (A) 之间的 WebSocket 通信永远不稳定。状态不同步、消息丢失、断线重连……我们花了一半的时间在调试通信，而不是做功能。”
  2. “角色 C 过载” (Key-Person Bottleneck): “角色 C (后端) 成了唯一的瓶颈。他不仅要写 Rust 逻辑、数据库、分心检测，还要维护一个 WebSocket 服务器和一个 Tauri Commands API。他被卡住了，导致 A 和 B 都在‘等待’，团队士气崩溃。”
  3. “C1 分心检测”黑洞（Rust/Tauri 失败）: “我们低估了在 Rust 中跨平台调用原生 OS API 的难度（尤其是 macOS 的沙盒和权限）。角色 C 被卡住了 3 周，导致所有功能延期。”
  4. “体验割裂” (Fragmented UX): “我们有两个‘前端’。用户在主 UI (B) 中点击‘开始’，然后宠物 (A) 过了 2 秒才开始动。在主 UI (B) 中完成任务，宠物 (A) 的庆祝动画又慢了半拍。这种割裂的体验让产品感觉像个‘缝合怪’，失去了核心价值。”

结语

我们已经预见到了失败的陷阱, 我们的任务就是避开这些陷阱，严格执行我们的计划，交付一个我们自己都想每天使用的产品。

FocusPet 团队，Alpha 阶段，启动！

2025年10月29日

Leave a Comment