基于 Leantime 的小团队敏捷协作实践

最近，我正在针对自己作为 Technical Project Manager 所管理的一个大型项目，做项目管理层面的方法论复盘。

大型项目无论采用 SAFe 还是其他框架管理，拆解到开发类子项目时，往往还是以敏捷模式运转。因此，要复盘项目集管理，就必须先从小团队的协作方式入手。

敏捷宣言与敏捷理论在技术团队里早已耳熟能详，但每个团队在落地时，或多或少都会对敏捷实践做一些“定制化”调整，也会搭配不同的工具来推进。

在我所管理的项目集中，不少子项目实际跑成了“假敏捷、真瀑布”的模式——更像是“螺旋迭代式”管理，只是把一个大瀑布拆成了许多小瀑布。

因此，我也想借助 Leantime 这类可开源自部署的工具，从工具设计的角度重新梳理：如何借助工具把“真敏捷”协作落到实处。

为此，我和 Gemini 4 Argon 一起做了一轮推演：以一个 8 人技术团队（1 名 PO、1 名 Tech Lead 兼 SM、5 名研发和 1 名 QA/DevOps）、两周一个 Sprint 为例，探讨如何基于 Leantime v3.9.8 开展敏捷实践。

在讨论过程中，我也在自部署的 Leantime 上按这套思路做了实际演练。整体跑下来，我认为这套做法具备不错的现实可操作性，于是把讨论和演练整理成下文。如果你也在探索小团队的敏捷落地，希望这份记录能给你提供一些参考。

先想清楚工具要解决什么问题

给小团队选协作工具时，我更关心的不是功能列表有多长，而是它会不会让大家多维护一套与实际工作脱节的记录。如果卡片只是为了汇报而更新，换一个工具通常也解决不了问题。

我选择尝试 Leantime，是因为它把待办、里程碑、Sprint、回顾画布和 Wiki 放在同一个项目里，有机会减少信息在不同地方来回搬运。但这些模块并不会自动组成敏捷流程。在配置字段和看板之前，更值得先讨论的是：哪些信息值得留下，什么时候算完成，以及遇到变化时由谁一起做取舍。

比流程完整更重要的三件事

在 2 周一个 Sprint（W1 周一启动，W2 周五结束）的节奏下，建议先约定以下三条原则，并在回顾会上按实际情况调整：

记录应该帮助工作流转

• 少做只服务于汇报的记录：卡片首先服务于协作，不必把所有自定义字段设为必填。工时记录也可以按需使用，例如用来了解公共支撑消耗了多少时间，而不是要求每个人按小时解释一天的工作。
• 卡片字段极简化：一张合格的卡片只需明确 “是什么（Title & Description）”、“谁负责（Assignee）”、“归属哪（Milestone & Sprint）”、“多大工作量（Effort）”、“什么优先级（Priority）” 五要素。
• 让日常更新足够轻：更新状态和补充一句进展最好只花几十秒；整理需求本身则值得认真花时间。如果维护卡片持续打断工作，就需要检查字段和流程是否过多。

完成比同时开工更重要

• 围绕问题开会：站会不必变成逐人汇报，更值得围绕看板讨论“哪张卡卡住了，今天怎样才能继续推进”。限时的意义是保持聚焦，复杂问题可以留给相关成员继续讨论。
• 以端到端交付（Done）为完成口径：子任务完成、代码写完都不等于故事完成。主卡片需要满足团队统一的 DoD（完成定义），才可进入 Done；是否产生业务价值，还需要发布后的使用与业务反馈验证。可演示不应替代质量门禁。
• 阻塞问题当场暴露：遇到技术卡点或需求歧义，立即在对应 Leantime 卡片标题前标记 【🔴阻塞】 并在评论区 @相关人，把问题消灭在日常流转中，而非等到周五才暴露延期。

讨论可以分散，结论要能找回来

• 工作需要可追溯：产品需求、技术债和缺陷修复都应有卡片或公共母卡记录。线上事故先恢复服务再补卡，小于 2 小时的零碎支撑可处理后集中记录，不能为了填表延误响应。
• 把结论带回卡片：即时通信很适合快速讨论，但变更后的验收标准、接口约定和边界条件还需要补回卡片或 Wiki。以后接手工作的人不应该靠翻群聊拼出需求。
• 让记录彼此关联：里程碑、Backlog、Sprint、回顾画布与 Wiki 可以放在同一个项目里，再通过链接保留上下文。信息集中并不保证信息完整，关联与更新仍要由团队维护。

把协作概念落到工具里，而不是一一套用

开始用工具之前，先说清楚大家指的是什么，往往比配置字段更重要。下面是我整理的一种对应方式，便于把讨论落实到具体记录中。

这里的映射是工作协议，不是概念等价：Product Goal 是产品长期目标，Milestone 是阶段性交付节点，Epic 则是一种常见的需求组织方式，并非 Scrum 的规定工件。团队可用里程碑承载阶段目标，但不能用完成百分比替代价值判断。

下文假定已有一个主要产品工作区，任务通常按 To Do → In Progress → Testing & CR → Done 流转；Backlog 表示尚未分配 Sprint 的需求集合，不必另建状态列。将 Testing & CR 归入未完成状态类型，只有 Done 归入完成类型。阻塞用标题前缀和标签保留原阶段，WIP 上限由团队共同维护。

最小 DoD 建议包括：约定的 AC 已验证、代码完成同行评审并合并、自动化检查和必要回归通过、需更新的文档已同步，且增量可发布。上线可以早于 Sprint 结束，不必等 Review 才发布。开发子任务完成后才提测，测试子任务在 QA 执行后完成，不要求提测时将所有子任务勾完。普通卡片不明确报小时；公共支撑母卡不估故事点，只记录支撑耗时，且只消耗已经预留的 Buffer。

v3.9.8 的内置类型包含 task、subtask、story、bug；Effort 的 XS/S/M/L/XL 对应存储值 1/2/3/5/8，另有 0.5 和 13；优先级另含 Lowest。本文仅约定使用其中一部分，不要求修改程序。Daily Scrum 是交付成员检视目标和调整计划的活动，SM 可以协助，PO 按需参与，不是领导逐人派活的会议。

从阶段目标到日常协作

flowchart LR
    subgraph SG_PLAN["战略与规划层"]
        M["Milestones 里程碑<br/>Product Goal / Epic"]
        B["To-Dos: Backlog 视图<br/>Product Backlog"]
    end

    subgraph SG_SPRINT["双周迭代执行层 (Sprint 容器)"]
        S["Sprints 迭代管理<br/>W1周一 ~ W2周五"]
        STORY["To-Do 主卡片: Story/Task<br/>用户故事 / 工程任务"]
        BUG["To-Do 主卡片: Bug<br/>独立缺陷修复卡"]
        SUB["Subtasks 子任务<br/>前端/后端/联调/测试"]
    end

    subgraph SG_METRIC["度量与持续改进层"]
        BURN["Sprint 仪表盘<br/>燃尽图 & 速率度量"]
      RETRO["Blueprints 回顾画布<br/>Sprint 复盘改进项"]
        WIKI["Wiki / Docs 文档库<br/>PRD / 架构ADR / 规范"]
    end

    M -->|拆解关联| B
    B -->|Sprint 规划拉取| S
    S -->|包含| STORY
    S -->|包含| BUG
    STORY -->|研发拆解| SUB
    STORY -->|Effort 点数汇总| BURN
    BUG -->|Effort 点数汇总| BURN
    S -->|W2周五复盘| RETRO
    RETRO -->|改进项转办| S
    WIKI -.->|挂载/双向链接| STORY

各类记录分别承载什么

职责要清楚，但不必把协作变成审批

小团队里常常一人兼任几个角色。这里把职责分开写，不是要划出互不干涉的领地，而是为了回答两个问题：这件事由谁持续跟进，做取舍时需要找谁一起讨论。

PO 持续维护需求顺序、解释业务价值并提供反馈；Tech Lead 关注技术风险，兼任 SM 时还需要促进协作，而不是替所有人决定实现与排期。研发和 QA 从需求澄清起就一起参与估算、拆解与验证，DevOps 的环境和发布工作也应进入计划，而不是等到最后再补。

落实到 Leantime，可以为每张主卡指定一个持续跟进的人，再用子任务标明实际协作者。但“有人跟进”不等于“只有这个人对交付负责”，更不意味着别人在评审、测试或阻塞时可以不参与。

可以用几个交接问题检查职责是否清楚，而不必先做一张复杂的权限矩阵：

Sprint Goal 不变时，范围可以随着新信息协商调整。这里说的“锁定”，是避免不经讨论就加活，不是冻结学习。这些职责约定也不等同于 Leantime 中的应用权限。

先把需求整理到可以开始的程度

看板让当前工作变得可见，却不一定能说明为什么要做这些事。一边需要阶段目标，避免每天只处理零散任务；另一边需要足够清楚的需求，避免开发开始后才发现关键条件没有讨论。

我倾向于把这两件事分开处理：Milestone 用来组织阶段性交付，Backlog 里的卡片则回答具体要做什么、怎样验证。需求梳理负责连接两者，不必等到规划会才第一次讨论细节。

用 Milestone 保留阶段目标

Epic → Story → Subtask 是常见的需求组织习惯，并不是 Scrum 规定的三层结构。对于本文的小团队，可用 Leantime 的 Milestone 组织一个阶段版本或较大特性，再关联可独立验收的 To-Do，按需拆解 Subtask。产品长期目标应单独写清楚，不把 Milestone、Epic 和 Product Goal 当成同义词。

一个版本可以怎样拆到任务

flowchart TD
    subgraph SG_STRAT["战略与版本层（月度 / 季度路线图）"]
        M1["Milestone 1: [v1.2.0] 统一权限与SSO认证中心<br/>(充当 Epic / Release Goal)"]
        M2["Milestone 2: [v1.3.0] 实时数据看板与导出引擎<br/>(充当 Epic / Release Goal)"]
    end

    subgraph SG_DELIV["迭代交付层（2周 Sprint / Product Backlog）"]
        S1["To-Do (Story): 企业微信扫码登录与账号绑定<br/>Sprint S21 | Effort: 5 | Priority: High"]
        S2["To-Do (Story): RBAC 角色权限配置后台<br/>Sprint S21 | Effort: 8 | Priority: High"]
        B1["To-Do (Bug): Token 过期刷新偶发 401 循环<br/>Sprint S22 | Effort: 2 | Priority: Critical"]
        S3["To-Do (Story): 报表异步生成与 CSV 流式下载<br/>Sprint S22 | Effort: 5 | Priority: Medium"]
    end

    subgraph SG_EXEC["研发执行层（每日站会粒度 0.5~1天）"]
        T1["Subtask: [后端] 数据库 user_oauth 表结构变更"]
        T2["Subtask: [后端] OAuth2 回调接口与 JWT 签发实现"]
        T3["Subtask: [前端] 登录页扫码组件联调与异常态处理"]
    end

    M1 --> S1
    M1 --> S2
    M1 --> B1
    M2 --> S3
    S1 --> T1
    S1 --> T2
    S1 --> T3

里程碑记录到什么程度

PO 在每个季度初或大版本启动前，进入左侧导航栏 Milestones（里程碑 / 时间线） 页面，点击 + Add Milestone（添加里程碑） 创建版本目标：

1. 命名规范（可以考虑统一前缀）：
   • 按版本命名：[v1.2.0] 商户结算中心重构与自动化对账
   • 按业务史诗（Epic）命名：[Q4-Epic01] 多租户权限体系与审计日志
2. 设定起止日期（Plan Dates）：
   • 明确填写该 Milestone 的计划开始日期（Start Date）与目标上线日期（End Date）。
   • 建议将里程碑的结束日期对齐到某个 Sprint 结束日（周五），确保节奏同频。
3. 色彩编码（Color Coding）：
   • 蓝色（#1B75BB）：核心业务功能版本（Feature Release）
   • 紫色（#6F42C1）：技术架构演进/基建专项（Tech Debt / Infra Epic）
   • 橙色/红色（#FD7E14）：外部合规/硬性截止日期交付（Compliance / Hard Deadline）
4. 前置依赖设置（Depending Milestone）：
   • 若“v1.3 结算报表导出”强依赖于“v1.2 结算核心引擎”，可在创建 v1.3 里程碑时，将 Depending Milestone 设为 v1.2，甘特图上会自动绘制前驱连线。

进度条能说明什么，不能说明什么

在 Leantime v3.9.8 中，Milestone 的完成进度由关联任务计算：任务 Effort 乘以优先级权重后，以完成状态的分值占总分值的比例展示。未设 Effort 或优先级时还有默认值，因此它既不是简单卡片计数，也不是纯故事点完成率，更不是业务目标达成率。

1. 打开任意一条 To-Do 详情弹窗，或在列表视图（Table View）行内直接操作。
2. 在属性栏找到 Milestone（所属里程碑） 下拉框，选择对应的版本 Milestone。
3. 保存后，关联任务的 Effort、Priority 和状态类型会影响该 Milestone 的展示；不要为美化进度条修改优先级或点数。主卡与子任务可能同时关联里程碑，需核对统计范围，不能把这个百分比直接用作团队速率。
4. 用时间线辅助讨论：需要同步版本安排时，可以展示起止周期、依赖和当前进度，但仍需解释变化的原因与风险。工具视图是讨论依据，不是业务结果的替代品。

用 DoR 减少开始之后的等待

“做个导出功能”可以是一个需求起点，却还不足以支撑开发：谁来使用、导出哪些字段、数据量多大、失败时怎样处理，都可能影响实现与测试。提前澄清这些问题，是为了减少开工后的等待，而不是增加文书工作。

DoR（Definition of Ready，准备就绪标准）可以作为团队自己的检查清单，它不是 Scrum 规定的正式承诺。也不必追求消除所有未知；无法提前回答的问题，可以先通过小范围预研来降低不确定性。

一份可按需求类型调整的就绪清单

对近期准备进入 Sprint 的卡片，可以从下面六个方面检查。涉及 UI 的需求需要设计信息，纯工程任务则不必补一份没有意义的原型链接。

用一个导出需求说明卡片怎么写

下面以交易流水导出为例，保留一份较完整的 Story 模板。字段和性能指标都是示例，需要结合实际系统调整；简单需求只留下有用的部分即可。模板可以放在 Wiki，创建卡片时复制到描述框中。

### 1. 用户故事 (User Story)

- **作为 (As a)**：[填写具体用户角色，如：企业财务对账员 / 平台运营管理员]
- **我想要 (I want)**：[填写核心功能或操作，如：按月份和渠道筛选交易流水并一键导出 CSV 报表]
- **以便于 (So that)**：[填写带来的业务价值或解决的痛点，如：将每月初人工核对账单的时间从 4 小时缩短至 10 分钟以内]

---

### 2. 业务背景与设计资料 (Context & Assets)

- **业务背景 / Wiki 深链接**：[简述背景，或粘贴 Leantime Wiki 需求规格文档深链接]
- **UI/交互原型链接**：[粘贴 Figma / 蓝湖 / 墨刀具体页面链接，注明版本号]
- **核心业务规则**：
  1. 单次导出时间跨度最大支持 92 天（3 个月），超出时前端拦截并提示。
  2. 金额字段统一保留两位小数，币种符号置于表头而非单元格内。
  3. 仅拥有 `finance:export` 权限的角色可见“导出”按钮。

---

### 3. 核心技术约束与接口说明 (Technical Constraints)

> _（由 Tech Lead 或核心研发在梳理前/梳理会中补充）_

- **涉及模块/服务**：`order-service`、`report-worker`、`admin-web`
- **关键技术方案/约束**：
  - 数据量超过 1 万行时需走异步导出队列（Redis + Worker），生成后上传 OSS 并通过站内信通知下载。
  - 复用现有的 `/api/v1/orders/query` 筛选参数结构，新增 `/api/v1/orders/export-tasks` 异步接口。
- **外部依赖/风险**：依赖运维提前配置生产环境 OSS 临时导出目录生命周期规则（7 天自动清理）。

---

### 4. 验收标准 (Acceptance Criteria - AC)

> _（QA 验收与 PO 签收的唯一基准，全部满足方可流转至 Done）_

- [ ] **AC1（正常流-同步/小数据量）**：筛选结果 <= 10,000 条时，点击“导出 CSV”在 3 秒内直接触发浏览器下载，文件命名格式为 `结算流水_YYYYMMDD_HHMM.csv`。
- [ ] **AC2（正常流-异步/大数据量）**：筛选结果 > 10,000 条时，点击后提示“报表生成中，完成后将通过站内信通知”，后台任务在 60 秒内完成（基于 10 万条基准测试数据）。
- [ ] **AC3（数据准确性）**：导出 CSV 的总行数、实收金额汇总值与列表页顶部统计卡片完全一致，中文字符在 Windows Excel 与 WPS 中打开无乱码（含 UTF-8 BOM 头）。
- [ ] **AC4（异常与边界态）**：当选择时间跨度 > 92 天，或筛选结果为空（0 条）时，“导出 CSV”按钮置灰不可点，Hover 显示对应原因提示。
- [ ] **AC5（权限与文档同步）**：无 `finance:export` 权限的账号直接调用导出 API 返回 `403 Forbidden`；新增配置项已同步更新至 Leantime Wiki。

缺陷记录要让别人能够复现

独立 Bug 卡最重要的不是格式整齐，而是别人能不能复现和判断影响。下面的例子保留现象、步骤、预期与实际结果、环境证据几类信息；其中的账号、编号和日志均为示例。

### 1. 缺陷概述 (Summary)

- **所属功能模块**：[如：移动端结算页 - 优惠券抵扣计算]
- **严重程度 (Severity)**：[致命 / 严重 / 一般 / 轻微，描述影响范围]
- **修复优先级 (Priority)**：[Critical / High / Medium / Low，由影响、紧急程度与绕过方案共同决定；不与 Severity 自动等同]
- **关联需求卡片**：[填写对应的 User Story To-Do 编号或链接，如 #142]

---

### 2. 复现步骤 (Steps to Reproduce)

1. 使用测试账号 `test_vip_01` 登录预发环境（Staging）。
2. 将商品 SKU `10086`（单价 100.00 元，数量 2 件）加入购物车并进入结算页。
3. 先勾选“满 200 减 30 元店铺券”，再将商品数量手动扣减为 `1` 件。
4. 点击底部“立即支付”按钮，观察页面展示与请求响应。

---

### 3. 预期结果 vs 实际结果 (Expected vs Actual)

- **预期结果 (Expected)**：
  - 商品数量减为 1 件后（总额 100 元 < 门槛 200 元），系统应自动取消勾选“满 200 减 30 元”优惠券，实付金额更新为 `100.00` 元，并正常拉起收银台。
- **实际结果 (Actual)**：
  - 页面实付金额仍显示为 `70.00` 元，点击“立即支付”后前端无任何报错弹窗，控制台接口返回 `500 Internal Server Error`。

---

### 4. 运行环境与现场证据 (Environment & Evidence)

- **测试环境**：`Staging (v1.2.0-rc2)` | **客户端**：`iOS 17.4 / 微信内置浏览器 8.0.48`
- **测试账号/数据 ID**：`UserID: 99201` / `CartID: c_8839201`
- **接口抓包 / 报错日志 / 截图**：
  - 请求 URL：`POST /api/v1/checkout/submit` | TraceID：`7f8a9d10-3b2c-4e1a-9f00-123456789abc`
  - 核心报错摘要：`CouponDiscountExceedsThresholdException: coupon 4021 requires min_amount 20000, actual 10000`
  - _(在此处直接粘贴屏幕截图或录屏附件)_

把需求澄清放在规划之前

如果规划会上才第一次看见需求，选范围、澄清和技术讨论就会挤在一起。我更愿意在迭代中安排一次短的 Backlog 梳理，提前处理候选需求里的疑问，让 Planning 主要围绕目标、容量和取舍展开。

给澄清留出时间，也给复杂问题留出空间

• 召开时机：固定在每个 Sprint 第 2 周的周二下午（15:00 - 15:45）（或第 1 周周四下午）。距离下周一的 Sprint Planning 还有 3 个工作日，留给 PO 和 Tech Lead 补齐设计或技术预研缺口的时间恰到好处。
• 会议时长：严格控制在 30 至 45 分钟（单张卡片讨论超过 8 分钟仍无结论的，立即挂起会后专题对齐）。
• 参会人员：PO、实际参与交付的研发与 QA 一起澄清近期候选需求，Tech Lead 补充技术风险。小团队可以全员参加，但复杂专题不必让所有人一直陪会，梳理也不能保证消除全部信息差。

列表视图适合一起整理候选需求

一起梳理时，可以使用 To-Dos 的列表视图查看优先级、Sprint 归属和 Effort。一次讨论大致包括以下几件事，时间分配只是参考：

1. 第一步：会前过滤视图，锁定待梳理范围（1 分钟）
   • 进入 To-Dos 切换为 Table（列表视图），在顶部筛选栏将 Sprint 设为 Backlog（未分配迭代的需求池），按 Priority（优先级） 排序。
2. 第二步：优先级校准与废卡清理（5 分钟）
   • PO 快速扫视 Backlog 顶部的前 15 至 20 张卡片，利用表格行内的 Priority 下拉框现场调整优先级（Critical \rightarrow High \rightarrow Medium \rightarrow Low）。超过 2 个月未排期且无明确价值的低优卡片当场关闭归档。
3. 第三步：逐卡宣讲与验收标准（AC）对齐（15 至 20 分钟）
   • 从顶部第一张尚未估点的 High 优先级卡片开始，PO 用 2 分钟宣讲背景与 AC，研发与 QA 从“存量数据兼容、性能瓶颈、异常分支、幂等防重”角度提问挑战。
   • 当场补录：确认的边界条件或新增 AC，由 PO 或 Tech Lead 当场直接敲进卡片的 Description 框中并保存（走出会议室只认卡片文字）。
4. 第四步：斐波那契闪电估点与大卡拆解（10 分钟）
   • 倒数“3、2、1”，所有研发与 QA 同时在聊天框打出斐波那契数字（1, 2, 3, 5, 8, 13）或亮出手指。
   • 若数字高度一致，直接填入 Leantime 的 Effort 列；若分歧巨大（如有人出 2，有人出 8），由最低分和最高分者各用 30 秒陈述理由，对齐认知后二次亮牌定稿。
   • 凡评定为 13 点及以上的卡片，需要当场按业务步骤拆分为多张 \le 8 点的子 Story，或先建一张 2 点的技术预研卡（Spike）。
5. 第五步：检查“1.5 倍安全水位线”（2 分钟）
   • 在 Table View 筛选已满足 DoR 的 Ready 卡片，再汇总 Effort；不假定列表顶部会自动给出筛选结果的故事点总数。
   • 就绪水位建议：若本团队历史上每 Sprint 完成约 40 SP，可准备约 60 SP 的 Ready 候选项，供规划时取舍。40 SP 只是示例，不是 8 人团队的标准产能；不必为了凑齐点数提前细化遥远需求。

用一个双周迭代串起日常协作

需求有了基本准备，接下来要解决的是工作怎样持续流动，而不只是怎样排进一个 Sprint。这里用 Sprint 2026-S21 举例，把规划、开发、评审、测试与反馈放进同一条时间线。

下面的日历不是要求每天按表执行。它主要用来暴露一个风险：如果第一周只有编码，直到第二周末才集中交给 QA，两周迭代也可能只是缩短了的瀑布流程。

日历的作用，是提醒我们早点交付给下一环节

可以先约定第一周就有一批故事进入评审与测试，第二周前半段检查是否仍有大块工作没有提测。下表用“首周约 30% 的卡片开始验证、第二周周三检查剩余提测风险”作为试行提醒，而不是要求为了满足比例移动卡片。长期来看，更值得优化的是故事大小、测试介入时机与等待时间。

一个双周节奏示例

gantt
    title 8人团队 2周 Sprint (10个工作日) 节奏演进图
    dateFormat  YYYY-MM-DD
    axisFormat  %m-%d
   excludes weekends
    section 敏捷仪式
    Sprint Planning (60m内)       :milestone, m1, 2026-11-02, 0d
    每日站会 (每日15m)            :active, d1, 2026-11-02, 10d
    下期Grooming (45m内)          :milestone, m2, 2026-11-10, 0d
    Review 与 Retro (60m)         :milestone, m3, 2026-11-13, 0d
    section 研发与测试水位
    编码与单元测试 (主力期)        :dev1, 2026-11-02, 8d
    首批30%卡片提测线 (W1周四)     :crit, milestone, c1, 2026-11-05, 0d
    持续提测与交叉Code Review      :cr1, 2026-11-04, 7d
   全量提测红线 Code Freeze (W2周三) :crit, milestone, c2, 2026-11-11, 0d
   集中Bug收敛与预发回归 (W2周四)  :qa1, 2026-11-12, 1d

规划从目标和真实容量开始

会议时间：W1 周一 09:30 - 10:30（严格控制在 60 分钟内，前提是上一周周二已完成 Backlog Grooming）。
会议主持：Tech Lead 兼 Scrum Master（SM）。
核心目标：算清团队真实可用容量、锁定本迭代交付范围、完成子任务（Subtasks）拆解并达成 Sprint Goal 共识。

先算可用时间，再谈故事点

“一个人两周有十个工作日”不等于十天都可以用于新功能。会议、请假和固定职责会占用时间，研发、评审与测试之间也有瓶颈。容量估算首先是为了看见这些约束，而不是算出一个看似精确的承诺数字。

可用时间的一种估算方式

以示例中 PO 之外的七名交付成员为例，先分别估算可用时间，再汇总为团队容量：

C_{\text{计划}} = \sum_{i=1}^{7} (D_i - L_i - M_i - F_i) \times (1 - B)

所有时间项都以人天计：D_i 是实际工作日，L_i 是请假，M_i 是已知会议时间，F_i 是其他固定职责占用；B 是在余下容量中预留的突发支撑比例，可先试行 15% 至 20%。同一项职责只扣一次。Code Review、联调和测试属于交付活动，不应先从容量扣除，又重复计入故事工作量。

本文建议的 Planning、10 次站会、Grooming、Review 与 Retro 合计约 5.25 小时；若按 8 小时工作日，约为 0.66 人天，而不是固定 10%。实际还应根据团队其他会议据实核算。

人天约束与历史故事点预测分开使用

故事点是团队对完整交付工作量、复杂度与不确定性的相对估算，不固定换算人天，也不按个人分配故事点指标。冷启动时选择少量已就绪的故事，拆解后分别检查研发、CR 与 QA 的实际时间和并行能力；不要用一个预设点数硬填满看板。

已有 3 个以上可比较 Sprint 后，可以用最近完成主卡点数均值作为预测参考：

V_{\text{参考}} = V_{\text{最近三期均值}} \times \frac{C_{\text{本期}}}{C_{\text{最近三期均值}}}

分子、分母使用相同的扣减口径；历史容量若已经包含缓冲，本期不再额外乘一次 80% 至 85%。这是粗略预测，不是交付保证，关键人员缺勤与 QA 瓶颈还需单独判断。所有 1/2/3/5/8 点都以历史锚点故事横向比较，8 点是本文试行上限，大于 8 点的需求先拆分或预研。

再把候选需求变成可执行的计划

建立 Sprint，给日常支撑留位置

1. 操作人：Tech Lead / SM。
2. 操作路径：进入 Leantime 当前项目 \rightarrow 顶部导航栏点击 To-Dos（待办事项） \rightarrow 左上角 Sprint 下拉选择器 \rightarrow 点击 + Add Sprint / Manage Sprints。
3. 命名与日期规范：
   • Sprint 名称：采用 Sprint YYYY-S序号 (MM.DD-MM.DD) 格式，例如：Sprint 2026-S21 (11.02-11.13)。
   • Start Date（开始日期）：2026-11-02（W1 周一）；End Date（结束日期）：2026-11-13（W2 周五）。
4. 同步建立公共支撑收纳母卡：在当前 Sprint 下固定创建 [Sprint-S21] 线上协查与日常运营支撑收纳池（见后文的日常支撑部分），指定当周轮值工程师（Batman）。

按目标与容量选择故事

1. 切换视图：在 To-Dos 页面右上角，将视图从 Kanban 切换为 Table / List View（列表视图），并将顶部 Sprint 筛选器切换为 Backlog（产品待办列表）。
2. 二次就绪核验（DoR 检查）：PO 按优先级（Priority 由高到低：Critical \rightarrow High \rightarrow Medium）逐条过卡，确认每张拟选入的 Story 卡均已满足 DoR（含上周五 Retro 生成的 [Retro改进] 卡片）。
3. 批量划入：
   • 在列表视图中，直接点击目标 Story 行的 Sprint 下拉列，将其从 Backlog 修改为 Sprint 2026-S21 (11.02-11.13)。
   • 每划入一张卡，交付成员检查 Effort 总量、依赖与研发/测试容量；接近本团队历史预测范围时停止加卡。40 SP 只能作为示例，不能当作所有小团队的上限。Sprint Goal 应在选择故事前先提出，在最后一步共同确认。

用子任务暴露实现依赖

主卡说明要交付什么，子任务帮助大家看见完成它还缺什么。拆解的价值在于识别依赖和协调协作，不是把每一个编码动作都变成卡片。

1. 认领主卡（Story Owner 机制）：
   • 切回 Sprint 2026-S21 的看板或列表视图。
   • 每张 Story 主卡的 Assigned To（负责人） 只能指定 1 名主责研发（Story Owner）。哪怕该卡片需要前后端协作，也需要由一人担任端到端催办与提测第一责任人，避免多人共管等于无人负责。
2. 拆解 Subtasks（子任务颗粒度控制在 0.5 至 1 天）：
   • 全员并行点开各自认领的 Story 卡片弹窗，切换到 Subtasks（子任务） 标签页。
   • 将该 Story 落地所需的前端开发、后端接口、前后端联调、数据库变更、QA 用例编写与执行全部拆解为独立子任务。

• 颗粒度参考：可以先按半天到一天的可协作单元拆解，普通 Story 下约 3 至 6 个子任务。短任务不必凑时长，单人几个小时就能完成的故事也不必为了形式再拆一层。

【实操范例】主卡 #123 [Story] 企业客户账单按月导出 PDF 与异步邮件发送 (5 SP) 的 Subtasks 拆解示范：

• [契约] 输出账单导出 OpenAPI 接口定义并前后端确认 —— 负责人：研发 A | 计划耗时：4h
• [后端] 实现 PDF 模板渲染引擎与 OSS 临时签名上传 —— 负责人：研发 A | 计划耗时：8h
• [后端] 对接异步消息队列与邮件重试通知逻辑 —— 负责人：研发 A | 计划耗时：6h
• [前端] 账单列表页新增导出筛选弹窗与轮询进度条组件 —— 负责人：研发 B | 计划耗时：6h
• [联调] 前后端导出触发、异常超限提示与下载链路联调自测 —— 主责：研发 A，协作：研发 B | 计划耗时：4h
• [QA] 编写账单导出边界值测试用例并完成集成验收 —— 负责人：QA C | 计划耗时：6h

回到 Sprint Goal，确认这次想实现什么

1. 提炼一句话目标：PO 与全员共同用不超过 2 句话总结本迭代的核心业务价值，而非罗列功能清单。
   • ❌ 错误示范：“完成卡片 #123、#124、#128、#130 共 8 个卡片开发与测试。”（这是任务堆砌，不是目标）
   • ✅ 正确示范：“打通企业客户月度账单自助闭环（生成、PDF 导出、邮件投递），将人工财务开单工单量降低 80%。”
2. 录入 Leantime：将目标写入一篇命名为 Sprint 2026-S21 目标与复盘 的 Wiki，并在相关卡片引用，不依赖某个特定 Dashboard 字段。目标达成要看可检验的结果；“工单量降低 80%”只是示例目标，需要基线和发布后观察，不能在演示时直接宣告实现。

站会围绕卡片，而不是围绕个人报进度

可以每天固定 15 分钟，由交付成员打开当前 Sprint 的看板，一起检视目标和下一步。是否站立、由谁投屏并不重要；需要更多时间的技术讨论，留给相关成员会后继续。

从右向左看，先讨论怎样完成

“昨天做了什么、今天准备做什么、遇到了什么阻碍”本身不是问题。但如果只按人轮流说，很容易忽略工作之间的关系：

1. 沦为向领导汇报的报账会：每个人说完自己的话就开始低头看手机，没人关心别人的任务是否卡住。
2. 掩盖半成品积压（WIP 失控）：研发每天都在说“今天继续写 XX 模块”，直到 W2 周三才发现 5 张卡全部停在 80% 进度，没有一张能进测试。
3. 重“开工”轻“完工”：每个人都倾向于从 To Do 领新卡开工，而无人优先去帮同伴做 Code Review 或修复 Testing & CR 里的缺陷。

“从右向左”（Walk the Board）提供了另一种讨论顺序：先看接近完成的卡片还在等待什么，再看进行中的工作，最后决定是否开启新任务。这样有助于减少半成品堆积，但不意味着忽略业务优先级或紧急故障，也不是因为投入过成本就需要继续做。

flowchart RL
    subgraph SG_BOARD["Leantime 看板站会巡检顺序（从右向左）"]
        direction RL
        D["Done<br/>(本迭代已验收)"]
        T["① Testing & CR<br/>(第一优先：催审、促测、消缺)"]
        P["② In Progress<br/>(第二优先：查子任务进度、破阻塞)"]
        TODO["③ To Do<br/>(第三优先：按依赖认领今日新卡)"]

        D -.->|逆向聚焦临门一脚| T
        T -->|推进存量流转| P
        P -->|严控WIP上限后再拉取| TODO
    end

看板上的三个讨论位置

一起看板时，可以按 Testing & CR → In Progress → To Do 的顺序展开：

第 ① 站：聚焦 Testing & CR（评审与测试） 列（耗时约 5 分钟）

• 巡检问题：这张卡今天能不能挪进 Done？卡在谁的 Code Review 还是卡在 QA 环境/Bug 修复？
• 当场动作：
  • 若卡在 CR 未审，确认谁能接手、预计什么时候反馈，必要时调整其他安排。
  • 若 QA 已发现缺陷，一起判断影响和修复顺序，避免不断开新任务却让接近完成的工作长期等待。

第 ② 站：聚焦 In Progress（研发中） 列（耗时约 7 分钟）

• 巡检问题：子任务（Subtasks）勾选了几个？距离提测还有几个小时？有没有跨前后端联调阻塞？
• 当场动作：
  • 主责研发说话时，SM 直接在投屏上展开该卡片的 Subtasks 抽屉——昨日已完成的子任务如果忘了打钩，当场勾选。
  • WIP（在制品）检查点检查：4 至 5 名研发的团队，In Progress 列的 Story 主卡总数原则上不得超过 5 至 6 张（保持人均 1 至 2 张主卡并行）。若发现某研发名下同时挂着 3 至 4 张 In Progress 卡片，SM 当场要求其将暂未推进的卡片退回 To Do，集中精力先推完一张。
  • 驻留时长预警：若某张卡片在 In Progress 连续停留超过 3 个工作日且 Subtask 无新增勾选，立即触发下方的“阻塞标记机制”。

第 ③ 站：扫视 To Do（本期蓄水池） 列与燃尽水位（耗时约 3 分钟）

• 巡检问题：今天谁手头的卡即将提测，准备从 To Do 拉取哪张新卡？前置依赖（如第三方接口、设计图）是否完备？
• 当场动作：确认今日新启动卡片的联调对象，快速瞥一眼 Sprint Burndown 曲线是否偏离基准线，准时在 10:15 宣布散会。

把阻塞写清楚，把深入讨论留给相关成员

站会上发现问题，不一定要当场解决到每个细节。可以先写清阻塞原因、需要谁协助和下一次检查时间，再由相关成员继续讨论。五分钟适合快速协调，不足以解决的问题则另外安排时间，不必为了准时结束而仓促作决定。

1. 阻塞（Blocked）的 10 秒当场标记规范
   • 操作：保持卡片在原列（如 In Progress），在卡片标题前加上 【🔴阻塞】、添加 Blocked 标签，注明责任人与下一次检查时间。不要自动把业务优先级改成 Critical；阻塞状态和业务紧急程度是两个维度。
   • 记录：在卡片 Discussion（评论区） 写入一行阻塞原因及解阻责任人，例如：2026-11-05 站会记录：微信支付沙箱证书过期导致联调中断，@TL 跟进运维于今日 14:00 前更新。
2. 会后 5 分钟小范围拍板机制（10:15 - 10:20）
   • 减少陪会：不涉及后续讨论的成员可以回到原来的工作，相关成员继续协调。
   • 按问题找人：技术问题由相关研发与 QA 讨论，涉及范围和价值时再邀请 PO；可以缩小范围、安排结对或另开专题，不必每次都固定由同一组人拍板。

代码完成以后，协作还没有结束

看板里的“进行中”往往横跨编码、等待评审、部署与测试。把代码链接和交接信息留在卡片里，可以让其他人知道现在等的是什么，而不必再问一轮“这张卡到底做到哪里了”。

flowchart TD
    START(["Sprint Planning 划入迭代"]) --> ToDo["To Do / 本期蓄水池"]
    ToDo -->|研发认领并拉取 feat/LT-ID 分支| InProgress["In Progress / 研发中"]
   InProgress -->|研发子任务完成 PR发起 自测通过| TestingAndCR["Testing & CR / 评审与测试"]

    subgraph SG_VERIFY["Testing & CR 内部协同"]
        direction LR
        CodeReview["TL/同行完成 CR 并合并至测试环境"] --> QAVerify["QA 执行验收测试"]
    end

    TestingAndCR -.-> SG_VERIFY
    TestingAndCR -->|法则一: Story内生小缺陷<br/>原卡新增 Bug Subtask 并打回| InProgress
    TestingAndCR -->|AC全部通过 且 Wiki同步完成| Done(["Done / 已完成"])

    subgraph SG_BUG["法则二: 独立/回归/线上缺陷"]
        NewBugCard["新建 Type=Bug 独立卡片"]
    end

    NewBugCard -->|关联当前Sprint消耗Buffer 或入Backlog| ToDo

让任务与代码能够互相追溯

一种简单做法是在分支、Commit 或 PR 中带上任务编号，再把 PR 链接放回卡片。下面是命名示例，不需要为了采用 Leantime 推翻已有的代码仓库约定。

1. Git 分支命名规范：
   • 特性开发分支：feat/LT-123-monthly-bill-pdf
   • 独立缺陷修复分支：fix/LT-156-token-refresh-race
   • 工程/脚本/重构分支：chore/LT-140-ci-docker-cache
2. Git Commit Message 与 PR/MR 规范：
   • Commit 格式：feat(billing): add async pdf generation worker (Ref #123)
   • PR / MR 标题：[LT-123] 企业客户账单按月导出 PDF 与异步邮件发送
   • PR 描述首行需要贴入该卡片在 Leantime 的直达 URL，并将 PR 链接反向粘贴到 Leantime 卡片的 Discussion 评论区。

交给评审与测试时，把上下文一起交出去

进入 Testing & CR 应该表示这张卡已经具备评审和验证的条件，而不只是“代码写完了”。研发先走通主要流程，再说明环境、代码、配置变更和回归范围，可以减少 QA 反复补问背景的时间。

我准备从下面四项交接信息开始约定。它们是进入下一环节的条件，不替代最终的 DoD：

1. 研发类 Subtasks 100% 勾选完成：点开 Leantime 卡片的 Subtasks 标签页，所有标记为 [契约]、[前端]、[后端]、[联调] 的子任务状态需要全部打钩。
2. 代码已发起 PR/MR 并可在隔离环境验证：通过 CI 编译、静态检查与单测。优先使用 PR 预览环境；若只有共享 Staging，则先 Review 并合并后部署，再交 QA。不要为了提测将未经评审的代码直接覆盖共享环境。
3. 完成 Happy Path（主链路）与桌边走查（Desk Check）：主责研发已对照卡片描述中的 AC 亲手在测试环境走通一遍（复杂交互建议拉 QA 进行 3 分钟屏幕共享走查）。
4. 在卡片评论区附上《标准提测与自测说明》：打开 Leantime 卡片 Discussion 标签页，粘贴以下标准模板并 @QA 与 @Reviewer：

📋 Leantime 卡片评论区《标准提测与自测说明模板》

• 【提测环境与分支】：Staging 环境 | 分支：feat/LT-123-monthly-bill-pdf
• 【关联 PR 链接】：后端 PR #408 / 前端 PR #215（请 @TechLead 协助 CR）
• 【配置/数据库变更】：已执行 V20261105__add_bill_export_task.sql；Redis 新增配置项 BILL_EXPORT_TTL=3600
• 【自测结果确认】：
  • AC1：支持选择近 12 个月任意月份触发导出（自测通过）
  • AC2：单次账单超 10,000 条自动转后台异步生成并发送通知（自测通过，测试账号：corp_test_01）
  • AC3：无账单月份点击导出提示友好空状态（自测通过）
• 【影响范围与回归建议】：修改了公共邮件组件 MailSender，建议 QA 顺带回归“密码重置邮件”功能。请 @QA_C 开始验收。

缺陷是否独立建卡，取决于追踪需要

当前 Story 尚未满足 AC 的小缺陷，可以留在原卡下继续修复；跨模块、生产环境或需要独立跟踪的缺陷，则更适合单独建卡。判断重点是可追溯性，不是让看板上的卡片数量尽可能少。

两类缺陷的记录方式

小缺陷若需要独立审计或持续追踪，也可以单独建卡并关联原 Story。选择记录方式时，追踪需要比统一卡片数量更重要。

Review 看结果，Retro 看协作方式

Review 和 Retro 可以接着开，但回答的是不同问题：前者和干系人一起检视实际增量、目标与下一步，后者由团队反思协作方式。下面用各 30 分钟举例，时间不足时应调整安排，而不是为了塞进一小时而省略反馈。

flowchart LR
    subgraph SG_REV["前半场：Sprint Review (16:00 - 16:30)"]
        R1["16:00-16:05<br/>核对 Sprint Goal 与燃尽图<br/>盘点承诺 SP vs 完成 SP"] --> R2["16:05-16:25<br/>基于看板 Done 列真机演示<br/>拒绝 PPT，逐卡对照 AC 操作"]
        R2 --> R3["16:25-16:30<br/>处置未完成卡片<br/>移入下个 Sprint 或退回 Backlog"]
    end

    subgraph SG_RET["后半场：Sprint Retro (16:30 - 17:00)"]
        T1["16:30-16:35<br/>全员静默写卡 (5m)<br/>填写 Continue / Stop / Start"] --> T2["16:35-16:45<br/>归类合并与点投聚焦 (10m)<br/>每人2票锁定 Top 2~3 痛点"]
        T2 --> T3["16:45-16:55<br/>根因深挖与对策拍板 (10m)<br/>推导可执行工程动作"]
      T3 --> T4["16:55-17:00<br/>转化为候选 To-Do 卡 (5m)<br/>指定 Owner 下期规划确认"]
    end

    R3 --> T1

Review 不只是演示完成的卡片

Review 的重点是实际结果和业务反馈。可以用满足 DoD 的增量演示工作成果，也可以坦诚说明哪些没有完成、遇到了什么变化；未完成的工作不能被包装成已交付。是否使用幻灯片不是关键，关键是别让汇报形式替代真实检视。

1. 盘点 Sprint Goal 与检视燃尽图（16:00 - 16:05，5分钟）
   • 展示当前 Sprint 燃尽图及规划时留存的范围快照，分别说明目标结果、完成范围与新增/移出项。例如“初始选入 40 SP，完成其中 38 SP”只是初始范围完成比例，不等于 Sprint Goal 达成率；与干系人讨论实际结果、环境变化和下一步调整，而不只是逐卡验收。
2. 基于看板 Done 列的真机现场演示（16:05 - 16:25，20分钟）
   • 可以从 Done 列演示满足 DoD 的实际增量，再说明未完成工作和风险，不把它们算作交付成果。
   • 每张 Done 卡片的 Story Owner（或负责验收的 QA） 对照卡片内的 AC（验收标准） 在预发/生产环境进行端到端真机操作演示。
   • 演示中若产生非阻断性的体验优化新想法，SM 当场在 Leantime 快速新建一张 To-Do 卡放入 Backlog，不推翻已满足原 AC 的 Done 状态。
3. 未完成卡片（Carry-over）的标准化处置（16:25 - 16:30，5分钟）
   • 重新讨论去留：未完成卡片回到 Backlog 检视价值和剩余工作，可以标为下期候选，但是否进入 S22 仍在下一次 Planning 中共同决定，不自动结转为新承诺。
   • 故事点记账约定：未满足 DoD 的 Story 在本期计为 0 SP。先在 Sprint Wiki 留存本期初始范围、实际完成和移出项，再移动未完成卡片，避免修改 Sprint 归属后丢失历史上下文。若下期整体完成，按原故事点一次计入下期完成量；规划时另按剩余工作检查容量，不改写原估点、也不重复扣减。发生跨期较多时，讨论拆小故事，而不是用部分点数美化速率。

Retro 最后留下少量能跟进的改进

回顾需要让大家能够安全地谈问题，而不只是收集表扬或批评。比起列出很多结论，更有意义的是选出一两项可尝试的调整，明确负责人和完成条件，再在下一次回顾检查是否真的有帮助。

1. 开启回顾画布并静默写卡（16:30 - 16:35，5分钟）
   • 在 Blueprints 中使用 retros 回顾模板，创建命名为 Sprint 2026-S21 回顾 的画布，将链接记入 Sprint Wiki。它是项目画布，不依赖“选中当前 Sprint”的自动关联，在三栏中静默写卡：
     • 🟢 Continue（继续保持）：本迭代哪些工程实践让我们效率倍增？
     • 🔴 Stop（停止做 / 痛点）：哪些低效行为、流程阻塞或环境问题在拖慢我们？
     • 🔵 Start（开始行动 / 建议）：下个迭代我们可以尝试什么具体新动作？
2. 合并同类项与投票聚焦 Top 2 至 3 痛点（16:35 - 16:45，10分钟）
   • SM 合并语义重复的卡片后，全员每人 2 票 选择痛点，可在评论记录票数，不依赖额外的投票插件。仅圈定得票最高的 1 至 2 项进入讨论。
3. 根因深挖与对策锁定（16:45 - 16:55，10分钟）
   • 采用 5 Whys 快速推导可落地的工程级对策，避免产生“大家以后注意一点”、“加强沟通”这类无法验证的空话：

4. 当场转化为下个 Sprint 的改进 To-Do 卡（16:55 - 17:00，5分钟）
   • 针对 1 至 2 项具体改进创建 Type = Task 的卡片，标题以 [Retro改进] 开头，指定负责人、完成条件与目标日期，先放入 Backlog 并标记为下期候选。在 Planning 中检查容量、共同确认后再划入 S22；下一次回顾先检查这些改进的实际效果。

让知识留下来，而不只留下完成的卡片

迭代结束后，卡片可以归档，但接口约定、技术决策和发布注意事项还会继续影响后面的工作。如果这些信息只存在于当时参与讨论的人脑子里，后续协作仍然要靠反复口头同步。

这也是我尝试把 Wiki 和任务放在一起的原因：卡片记录这次要做什么，Wiki 保留跨迭代仍然有用的知识。需要额外维护文档是事实，目标是让这份投入减少未来的重复解释，而不是假定知识会随着任务完成自动沉淀。

文档放在哪里，不如能否找到并保持有效

分散使用文档工具并不一定有问题，真正的麻烦是找不到权威版本、链接失效，或者实现已经改变而文档没有更新。如果现有文档系统运转良好，保留固定入口和双向链接就够了，不需要为了统一而搬迁。

使用 Leantime Wiki 是其中一种选择，可以让项目知识离任务更近，但仍然需要明确维护责任：

flowchart LR
   subgraph SG_WIKI["Leantime 同库闭环生态"]
      A["产品愿景与里程碑"] -->|拆解规格| B("Leantime Wiki<br/>PRD / ADR / 运维手册")
      B <-->|深链接双向引用| C("Sprint To-Do 任务卡<br/>研发实现 / 验收标准")
        C -->|DoD 门禁反哺| B
    end

从少量常用目录开始

Leantime Wiki 支持层级文章。下面按新人环境、产品资料、技术决策、接口与发布整理了一个目录示例。实际使用时，可以从最常查的两三个入口开始，不必一开始就建立完整的空目录树。

📚 项目知识库 (Project Wiki Root)
├── 📂 01-新人入职与环境搭建 (Onboarding)
│   ├── 📄 团队沟通规范与敏捷日历（站会/梳理/评审/回顾时间表）
│   ├── 📄 本地开发环境半天跑通指南（含中间件安装、Hosts 与环境变量模板）
│   └── 📄 代码仓库分支策略与 Git 提交规范（附 To-Do 与 Bug 卡片模板）
├── 📂 02-产品需求与原型归档 (PRD & Specs)
│   ├── 📄 核心业务术语表（统一领域语言 Ubiquitous Language）
│   ├── 📄 [v1.2.0] 用户中心与权限模块需求规格及原型链接
│   └── 📄 [v1.3.0] 订单流转状态机与异常退款逻辑说明
├── 📂 03-系统架构与技术决策 (ADR & Architecture)
│   ├── 📄 系统全局架构图与服务模块划分
│   ├── 📄 ADR-001：为什么选用 PostgreSQL 而非分库分表方案
│   └── 📄 ADR-002：异步消息队列选型与重试幂等设计
├── 📂 04-接口契约与数据库字典 (API & Schema)
│   ├── 📄 全局接口规范（统一响应结构、错误码字典、鉴权 Header）
│   ├── 📄 核心表结构设计说明与索引变更记录
│   └── 📄 第三方外部服务对接凭据与沙箱环境说明（脱敏）
└── 📂 05-运维发布与应急手册 (Runbooks & Release Checklist)
    ├── 📄 测试/预发/生产环境拓扑与服务器资源清单
    ├── 📄 标准生产环境发版 Checklist 与回滚操作手册
    └── 📄 常见线上故障应急预案（数据库锁死、第三方接口超时降级等）

文档由谁维护

• 01-新人入职与环境搭建：由 Tech Lead 主导创建，最新入职的研发/QA 负责在实操过程中修补过期步骤。检验标准只有一个：新成员能否在不求助他人的情况下，半天内独立在本地跑通前后端服务并成功发起一次接口调用。
• 02-产品需求与原型归档：由 PO 负责维护，按里程碑版本或核心业务域归档。
• 03-系统架构与技术决策：由 Tech Lead 与核心研发 共同维护。重点在于记录“当时为什么这么选”，防止半年后团队成员推翻重来或踩入同一个坑。
• 04-接口契约与数据库字典：由 后端研发 主笔，前后端与 QA 共同查阅。若团队已使用 Swagger/OpenAPI 等自动化文档工具，此处只需维护全局规约、核心 ER 关系图及自动化文档的固定入口。
• 05-运维发布与应急手册：由 QA/DevOps 与 Tech Lead 共同维护，是保障双周迭代平稳上线的安全底线。

ADR 留下“为什么这样选”

技术决策记录不必长，背景、备选方案、取舍与后续影响几项就有价值。对于会影响后续维护的选择，可以用下面的 ADR 模板记下来；复杂决策需要多少讨论时间，不应由模板限制。

# ADR-[编号]：[用一句话概括技术决策标题，如：引入 Redis 实现分布式会话与高频缓存]

- **状态**：已采纳（提议中 / 已采纳 / 已废弃 / 被 ADR-XXX 替代）
- **决策日期**：2026-MM-DD
- **参与人**：@[Tech Lead] @[主责研发A] @[主责研发B]
- **关联任务卡**：#[To-Do ID]

## 1. 背景与痛点 (Context)

_简述当前业务或系统遇到了什么具体问题，以及我们的约束条件（如：团队仅 8 人，运维能力有限；要求在当前 Sprint 内上线）。_

- 现象/问题：
- 限制条件：

## 2. 备选方案对比 (Options Considered)

_列出讨论过的 2~3 个方案，无需长篇大论，直击优劣势。_

- **方案 A（最终入选）**：[简述方案]
  - 优势：
  - 劣势/风险：
- **方案 B（放弃）**：[简述方案]
  - 放弃原因：

## 3. 最终决策 (Decision)

_明确我们将采取的具体技术路径、核心组件版本及关键配置策略。_

## 4. 影响与后续行动 (Consequences)

_该决策落地后带来的正面收益、遗留的技术债，以及需要同步修改的模块。_

- **正面影响**：
- **代价/技术债**：
- **关联变更项**：需同步更新部署脚本 / 新增环境变量 `XXX`

发布清单记录容易遗漏的环节

发布不必等到 Sprint 结束。下面的清单只是一个示例，需要按服务架构、迁移策略和风险调整，尤其不能把示例部署顺序直接当作所有系统的执行脚本。

# [版本号，如 v1.4.0] 生产环境发版 Checklist

- **发版日期**：2026-MM-DD HH:mm
- **发版主理人 (Release Manager)**：@[姓名]
- **本次 Sprint 关联里程碑**：[里程碑名称/链接]
- **回滚触发条件**：按服务风险事先约定错误率、核心链路与观察时间阈值。数据损坏或安全风险应立即止损，不等待固定 30 分钟；是否回滚取决于经过验证的方案与数据兼容性。

---

## 一、 发版前准备 (Pre-Release)

- [ ] **代码合并与冻结**：所有纳入本版本的 To-Do 均已进入 `Done` 列，PR 已合并至主干并打好 Release Tag。
- [ ] **数据库变更检视**：
  - [ ] 是否包含 DDL/DML 脚本？（[ ] 无 / [ ] 有，脚本位置：_______）
  - [ ] SQL 脚本是否向后兼容（支持旧版本代码短暂共存）？
  - [ ] 生产数据库是否已完成发版前快照备份？
- [ ] **配置与环境变量**：
  - [ ] 新增/修改的环境变量、配置中心参数、密钥是否已在生产环境就位？（清单：_______）
  - [ ] 第三方回调地址、白名单 IP 是否已确认开通？
- [ ] **构建产物确认**：CI/CD 镜像或构建包已生成，且在预发/Staging 环境验证通过。

## 二、 发版执行顺序 (Release Execution)

1. [ ] **Step 1**：执行数据库增量迁移脚本，确认无报错及长事务锁表。
2. [ ] **Step 2**：刷入生产环境新增配置项 / Redis 预热数据。
3. [ ] **Step 3**：后端服务滚动更新（先灰度单节点，观察日志无异常后全量发布）。
4. [ ] **Step 4**：前端静态资源发布与 CDN 缓存刷新。
5. [ ] **Step 5**：开启定时任务 / 消息队列消费者。

## 三、 发版后验证 (Post-Release Verification)

- [ ] **核心链路冒烟（QA 主导）**：登录鉴权、核心业务主流程、支付/核心状态流转验证通过。
- [ ] **监控与日志巡检（主理人主导）**：观察发版后 15 分钟内，错误日志（Error Log）、CPU/内存水位、慢查询指标无异常飙升。
- [ ] **发布宣告**：在团队群同步“v1.4.0 发版完成”。

## 四、 紧急回滚预案 (Rollback Plan)

1. [ ] 将前后端服务镜像切回上一稳定版本 Tag：`[填写上一版本 Tag，如 v1.3.2]`
2. [ ] 配置项还原说明：`[填写需要还原的配置，若向前兼容则无需回滚]`
3. [ ] 数据恢复与兼容策略：`[说明向前兼容、修复或已验证的恢复方案；禁止未经验证直接执行逆向 SQL]`

把必要的文档更新放回交付过程

任务描述里可以放目标、边界、验收标准和 Wiki 链接，不必再复制一份完整方案。反过来，Wiki 也可以链接到对应的实现任务，方便以后追溯当时的调整。

任务卡与 Wiki 各自留下什么

哪些变更值得同时更新文档

环境配置、数据结构、接口契约和部署方式的变化，通常值得把文档同步纳入 DoD。这样在验收时检查的不只是功能是否运行，还包括后续接手的人能否正确使用和维护它。这里不需要额外设置一个个人审批权，而需要共同确认哪些更新属于本次交付的一部分。

flowchart TD
    A["研发完成编码与自测"] --> B{"是否触及 4 类架构/运维变更？"}
    B -->|否: 纯常规业务微调| D["进入 Testing & CR 验收环节"]
    B -->|是| C["更新对应 Leantime Wiki 目录"]
    C --> D
    D --> E{"QA & Tech Lead DoD 终审"}
    E -->|代码通过 且 Wiki 已同步| F(["允许拖入 Done"])
    E -->|Wiki 未更新或与实现不符| G["退回 In Progress"]
    G --> C

1. 环境变量与配置变更：新增或修改了配置文件项、密钥、第三方服务地址、Feature Flag 开关 \rightarrow 需要同步更新至 01-本地环境指南 及 05-运维发布手册。
2. 数据库与缓存结构变更：新增表、修改字段含义、新增核心索引、变更 Redis Key 命名规范 \rightarrow 需要同步更新至 04-接口契约与数据库字典。
3. 对外/跨端接口契约变更：前后端联调过程中临时商议修改了字段名、状态码枚举或分页逻辑 \rightarrow 需要在合并代码前修正 04-接口契约，杜绝“口头改了接口，文档还停留在上一版”。
4. 架构引入与运维脚本变更：引入了新的中间件、定时任务（CronJob）、数据修复脚本或特殊的发版顺序要求 \rightarrow 需要同步沉淀至 03-系统架构 (ADR) 或 05-发版 Checklist。

计划之外的工作，也要有位置

前面的安排看起来比较整齐，现实工作却不会只按计划发生。线上问题、运营咨询和临时需求都会占用时间。如果工具只记录计划内功能，它呈现出的容量和进度就会失真。

缓冲和取舍，比把计划排满更实际

我倾向于在规划时留出一定缓冲，再区分故障、紧急业务需求与日常支撑。它们都可能是必要的工作，但处理方式不同，不能一律塞进当前 Sprint 后仍假装原计划没有变化。

缓冲是一项需要校准的假设

在规划时，可以从扣除请假、会议和其他固定职责后的容量中预留 15% 至 20% Buffer，再根据实际支撑量调整。它与前面的容量公式使用同一口径，只扣一次；从已经含缓冲的历史速率预测时，也不再重复打折。

• 关注关键角色的可替代性：如果某个环节只有一人熟悉，他去处理线上问题时，受影响的不只是自己的新功能，还可能包括其他人的联调和评审。总体空闲时间不等于每个环节都有余量。
• 缓冲不必耗尽：若 W2 周三仍有余量，先协助 CR、测试、回归或改进工作。只有确认不威胁目标和质量、且剩余时间可端到端完成时，才与 PO 协商拉取极小的 Ready 卡片；不要在提测截止当天为填满工时再开启大功能。

先判断计划外工作的性质

出现计划外工作时，先判断是否需要立即响应，再把它对当前目标和容量的影响说清楚。事故处理优先恢复服务，业务插单需要共同取舍，日常咨询则可以集中接收：

flowchart TD
    A["Sprint 中途出现计划外任务"] --> B{"属于哪种类型?"}

    B -->|"1. 线上阻断性故障 P0/P1"| C["立即启动应急修复"]
    C --> D["先恢复线上服务, 后在 Leantime 补建 Bug 卡"]
    D --> E["打上 Hotfix 标签, 归入当前 Sprint, 记录真实耗时"]
    E --> F["消耗 15%~20% Buffer, 迭代末纳入 Retro 复盘"]

    B -->|"2. 外部临时加塞业务需求"| G["统一由 PO 拦截评估"]
    G --> H{"是否必须在本 Sprint 上线?"}
    H -->|"否: 可等下个迭代"| I["放入 Product Backlog 正常排优"]
    H -->|"是: 不做会导致重大业务受损"| J["触发【等量置换原则 Swap In / Swap Out】"]
    J --> K["Tech Lead 快速估算新卡点数 X"]
    K --> L["PO 从当前 Sprint 的 To Do 列移出同等 X 点旧卡"]
    L --> M["新卡打上 Swap-In 标签拉入当前 Sprint"]

    B -->|"3. 日常零碎咨询/导数据 (< 2h)"| N["归入当周值班工程师/公共支撑收纳母卡"]

线上故障先恢复，再补齐记录

1. 立刻止血：Tech Lead 立刻指派相关研发与 DevOps 介入，通过回滚或热修（Hotfix）恢复线上业务，此时不需要先去 Leantime 建卡审批。
2. 事后 2 小时内补卡留痕：故障解除后，责任研发需要在 Leantime 当前 Sprint 中补建一张 Type = Bug、Priority = Critical 的卡片，标题统一带 [Hotfix] 前缀，打上 #Hotfix 标签，并在 Hours Logged 中填入真实救火耗时。
3. 缓冲池击穿预警：如果当期 Sprint 的 Hotfix 累计耗时超过了预留的 15% 至 20% Buffer，SM 需要在次日站会上正式向 PO 发出预警，协商顺延当前 Sprint 末尾的低优 Story。

新需求进入时，也要讨论什么可以推迟

如果新需求确实不能等到下一次规划，可以参考 Swap In / Swap Out 的思路，讨论推迟哪些原定工作。点数相近并不意味着资源可以无损替换，还要检查依赖、已经投入的工作和测试瓶颈。

对外沟通时，与其只说“做不完”，不如把选择摆出来：如果本周优先做这项新需求，原定的报表优化可能需要推迟；它们各自的影响是什么？这种讨论仍然需要 PO 与交付成员共同参与，不能把责任简单转交给提出需求的人。

日常支撑不必拆成满屏卡片

导数据、回答接口问题、排查客服反馈，这些工作可能每次都不长，累计起来却会影响交付。全部独立建卡容易淹没看板，完全不记又无法判断时间花在了哪里。

一种折中办法是用公共支撑母卡收纳常规小事，再通过轮值减少所有人同时被打断的次数。技术债若需要独立验收或持续投入，仍然应该单独规划，不宜长期藏在收纳池里。

用收纳卡和轮值观察支撑成本

1. 在 Leantime 中设立固定额度的“收纳母卡” 在每次 Sprint Planning 时，由 SM 固定创建以下 1 至 2 张常驻母卡（Parent To-Do），预先占用 Buffer 额度：

2. 颗粒度分界线（2 小时法则）与 30 秒记账操作
   • 预估耗时 < 2 小时的常规零碎事务：可放入收纳母卡子任务，处理后记录事项、实际处理人和耗时。线上事故、安全问题和需要独立回归的缺陷，无论耗时多少，都应单独建卡。使用 Time Tracking 新增对应工作记录，而不是手工覆盖一个累计小时数。
   • 预估耗时 \ge 2 小时的独立事项：需要在 Backlog 中作为独立 Story/Task 建卡，走正常的估点与排期流程。
3. 配合“值班工程师（On-Call / Batman）”护航机制
   • 按周轮值：以 5 名研发组成轮值池，Tech Lead 为升级支援，不重复计入这 5 人。每周轮流 1 人接收日常支撑，将 Sprint 母卡负责人更新为当周轮值人，并记录另一周的交接及每项实际处理人。
   • 流量收口：所有来自运营、客服的临时排查与导数据请求，100% 先找当周值班工程师，保障其余 4 名研发享有不被打断的深度编码心流。
   • 数据驱动改进：若连续 2 个 Sprint 发现 Ops-Bucket 母卡耗时频频突破 24 小时，Tech Lead 即可凭子任务明细在 Planning 会上正式立项开发自动化后台工具，从根源消灭手工运维。

使用工具时，我会特别留意的几个偏差

子任务拆得过细，维护成本超过收益

• 典型症状：一张 3 点的 Story 下面拆出 15 个 Subtask（“建表 1h”、“写 Entity 0.5h”、“写 DAO 1h”、“写 Controller 1h”……），程序员每天花半小时挪卡片填工时，怨声载道。
• 可以尝试的调整：
  1. 以“0.5 天 ~ 1 天（4 至 8 小时）”作为拆解参考：普通 Story 可拆 3 至 6 个子任务，但不设最低数量。短任务无需为了满足粒度下限而膨胀，复杂任务超过一天时再检查是否可以拆小。
  2. 代码级细项降级为正文 Checklist：像“建表、写 DTO、加索引”这类几十分钟的编码步骤，直接写在卡片描述区或评论区作为个人备忘，不建 Subtask。

把故事点变成个人绩效指标

• 典型症状：月底按每个人完成的 Story Points 总数进行绩效排名，导致全员在 Planning 估点时集体“注水”（原本 2 点的需求喊成 5 点），且没人愿意做底层重构或帮别人 Code Review。
• 可以尝试的调整：
  1. 公开宣布“故事点脱钩个人 KPI”：Leantime 中的 Effort（故事点）仅在团队整体维度（Team Velocity）统计，用于预测迭代容量，避免导出个人点数排行榜用于绩效考核。
  2. 用“基线锚点卡（Anchor Stories）”遏制通胀：在 Wiki 中固定 3 张历史标准卡片作为 1点 / 3点 / 5点 的参照物，估点时直接横向比对。

看板只在汇报之前更新

• 典型症状：周一到周四看板纹丝不动，每天早上 9:55 全员突击挪卡，或者周五下午一次性把十几张卡从 To Do 直接拖进 Done。
• 可以尝试的调整：
  1. 绑定物理代码动作触发器（Action Trigger）：规定只有 3 个动作发生时需要顺手花 10 秒切屏更新 Leantime：
     • git checkout -b feat/LT-xxx 拉分支开始写代码 \rightarrow 拖入 In Progress。
     • 发起 PR/MR 并完成测试环境自测 \rightarrow 贴上提测说明并拖入 Testing & CR。
     • 遇到跨端等待或需求卡壳超过 2 小时 \rightarrow 标题加 【🔴阻塞】 并 @ 责任人。
  2. 站会坚持投屏走看板：口头说“已提测”但卡片还在 In Progress 的，SM 当场要求其在屏幕上拖过去。

两周迭代仍然把测试留到最后

• 典型症状：前 8 天研发埋头苦写，QA 无卡可测；第 9 天（W2 周四）下午 5 名研发同时把 10 张卡拖进 Testing & CR，1 至 2 名 QA 被彻底压垮。
• 可以尝试的调整：
  1. 严守两道提测水位线：W1 周四/周五需要有 \ge 30\% 的卡片进入 Testing & CR；**W2 周三 18:00（Feature Code Freeze）**本迭代 100% 特性 Story 需要完成提测。
  2. 明确执行在制品限制（WIP Limit）：限制每位研发名下处于 In Progress 状态的 Story 最多不超过 1 至 2 张，写完一张、提测一张，再拉下一张。

复盘有了结论，却没有后续行动

• 典型症状：回顾会开了 1 小时，白板上写满便签，但散会后无人跟进，下个 Sprint 同样的坑再踩一遍。
• 可以尝试的调整：
  1. 聚焦 Top 1 至 2 项改进：每次 Retro 投票只选出 1 至 2 个本团队职权范围内可解决的痛点。
  2. 当场建卡入池：将改进项转化为带 [Retro改进] 的 To-Do，指定负责人和完成条件，列为下期规划候选，确认容量后再纳入 Sprint。

先用两个 Sprint 观察，而不是一次配齐所有流程

整理出一套流程，比让团队愿意持续使用它容易得多。因此，开始尝试时，我更倾向于缩小范围：先让当前工作可见，建立共同的完成定义，再决定哪些功能值得继续引入。

第一个 Sprint，先看工作能不能顺畅流转

一个主要工作区、少量清楚的需求、To Do → In Progress → Testing & CR → Done 的状态流转，以及一个能找到模板和当前约定的 Wiki 入口，就可以作为起点。Backlog 是未分配 Sprint 的需求集合，不必额外增加一列。

比起一开始就追求准确估点，更值得留意的是：开始开发后还有多少关键信息需要补问，PR 和测试通常在哪里等待，临时支撑有没有被记录，以及卡片状态是否能帮助别人理解进展。第一次 Review 和 Retro 也围绕这些具体问题展开，再选一两项调整。

第二个 Sprint，再检查哪些约定真的有帮助

第二次规划可以参考上一期的完成量、出勤和插单记录，但一期数据不能成为稳定速率的证明。若测试集中积压，就检查故事是否过大、反馈是否太晚；若支撑持续挤占新功能，就考虑轮值和自动化；若文档总是在交接时缺失，再收紧对应的更新约定。

两个 Sprint 之后，重点不是是否满足一套“落地成功”的分数，而是能否解释计划与实际的差异，以及这些记录是否帮助团队做了更好的选择。维护工具本身花了多少时间，也应该放进回顾里讨论。

结语

这次重新整理小团队的敏捷实践，我更关心的是一套约定能不能减少等待、帮助取舍，而不是它看起来有多完整。Leantime 给了这些约定一个具体载体，但不会替团队决定优先级，也不会自动保证质量。

目前这些仍是准备在实践中检验的思路。先让工作可见，让反馈早点发生，再根据真实记录调整；如果某个字段、一场会议或一条规则没有帮助协作，就没有必要为了“像敏捷”而保留它。

版本依据与参考

• Leantime v3.9.8 源码：本文的工具能力核对基线。
• 任务类型、Effort、Priority 与状态类型：区分工具提供的选项与本文的团队取舍。
• 里程碑进度算法：参见 getMilestoneProgress，进度包含 Effort 与优先级权重。
• Sprint 统计实现：核对任务数、Effort、工时和快照口径，不把图表直接当作业务结果。
• 回顾画布模板、Wiki 实现：核对栏目与层级文章支持。
• Scrum Guide 2020：区分官方职责、工件与本文试行的团队实践。