团队敏捷转型实践：弃用Scrum与Jira，实现PR上线时间从6.4天降至2.1天

我们正亲历着传统敏捷实践的失效。本文将分享我们如何转向“开发者主导交付（Developer-Led Delivery）”的颠覆性模式，并详细介绍其背后的代码、架构与效能基准。

核心要点：我们并非简单地抛弃Scrum和Jira，而是重塑了软件从想法到代码，再到最终产生价值的完整路径。当敏捷无法匹配高产出的工程团队时，我们构建了一套行之有效的新体系。

敏捷的核心症结：仪式的异化

首先要明确，敏捷（Agile）思想本身并非问题。其精髓在于适应与响应变化。真正束缚现代团队的，是敏捷的仪式化。

我们最初的初衷是好的，希望通过每日站会、迭代规划、故事点估算和速率追踪来提升效率。但规模化后，现实往往演变为：

• 承诺的赋能团队 → 沦为 JIRA工单工厂
• 承诺的适应性规划 → 变为 规划表演
• 承诺的客户聚焦 → 退化为 代理人驱动的待办列表
• 承诺的持续交付 → 陷入 流程开销带来的混乱

我们曾拥有12个配置完整（产品经理、设计师、技术负责人）的产品团队，但总在以下环节出问题：

• 需求故事（Story）缺乏开发人员的早期输入与上下文。
• 工程师成为被动执行工单（Ticket）的角色。
• 质量保障（QA）介入过晚，且往往为时已晚。
• 开发人员交付的常是“功能”，而非真正的“价值”。

因此，我们决定停下来。我们废除了迭代（Sprint）、故事点（Story Point）和传统的待办事项列表（Backlog）。

新运作体系：开发者主导的交付（Flow Engineering）

我们称之为“流式工程（Flow Engineering）”——这套体系围绕自治团队、领域所有权和实时价值追踪构建，而非追逐虚假的速率（Velocity）。

团队工作流的架构

我们不再使用Scrum看板，转而利用GitHub PR、功能开关（Feature Toggles）和事件流（Event Streams）来驱动工作。

示意图：核心交付架构

[功能创意] → [提案PR] → [RFC评审] → [编码+测试]
    ↓              ↓              ↓           ↓
[领域负责人] [异步评论]  [自动部署] → [指标采集]
                                      ↓
                              [功能开关控制]
                                      ↓
                              [实时用户反馈]

代码工作流实战：以“高级用户通知”为例

1. RFC即代码
我们在Markdown文档中撰写提案，明确背景、方案和负责人。

# docs/rfc-premium-notifs.md
## 背景：
付费用户需要接收重要提醒，但现有投递机制不稳定。
## 提案：
- 在用户模型中添加 `premium_notif_enabled` 功能开关字段
- 通过 `notif_service` 启用推送
- 通过事件流追踪已读回执
## 负责人：@bugsy

2. 在PR中编码（无需Jira工单）
我们直接在代码库中实现功能。例如在Go语言的后端服务中：

// user.go
type User struct {
    ID           string
    Name         string
    Email        string
    IsPremium    bool
    NotifyPremium bool // 新增的功能开关字段
}

// notif_service.go
func SendPremiumNotif(user User, message string) {
    if user.NotifyPremium {
        sendPush(user.ID, message)
        publishEvent("premium_notif_sent", user.ID)
    }
}

3. 基于功能开关的渐进式发布
通过配置文件控制新功能的灰度发布。

# flags.yaml
premium_notif_enabled:
  enabled: false
  rollout: 10% # 先对10%用户开启

4. 可观测性与实时反馈

• 仪表盘按功能开关维度展示事件指标。
• 对用户进行实时的A/B测试。
• 若功能交付成功率低于90%，则自动触发Slack告警。

被替换的内部系统对比

旧的敏捷工具	替换为
Jira待办列表	GitHub Issues + Project Boards
迭代规划会议	RFC书面提案流程
每日站会	每周两次、每次15分钟的工程同步会
速率图	实时部署与功能指标
燃尽图	功能开关健康度与使用情况图表

转型后的效能基准数据

告别Scrum 3个月后，我们测量到以下变化：

指标	之前 (敏捷模式)	之后 (流式工程)
PR平均上线时间	6.4 天	2.1 天
月度线上事件数	9 次	3 次
周均部署频率	~ 3 次	~ 15 次
开发者满意度 (5分制)	3.2	4.7
周均会议耗时	7.5 小时	2.3 小时

关键的内部原则

1. 反馈 > 预测
   我们不再估算功能点。转而快速构建原型，通过功能开关控制，基于真实数据迭代发布。真正重要的是产品在真实世界中的使用情况，而非Jira工单的燃尽速度。

2. 所有权 > 流程编排
   每个团队拥有一个明确的业务领域（如支付、用户引导），并对其代码、基础设施和部署流水线负全责。不再有产品经理主导的集中式优先级排序，团队自主决定交付内容、时间和原因。

3. 功能开关与指标 > 质量门禁
   我们依赖功能开关（如Unleash）、金丝雀部署（如Argo Rollouts）和实时仪表盘（基于Prometheus+Grafana）来保障质量。所有功能都可在生产环境中通过开关进行测试与回滚。

4. 异步沟通 > 同步会议
   RFC通过书面提案，反馈通过PR评论，状态通过仪表盘查看。这极大地减少了低效的同步会议时间。

核心经验总结

• 敏捷原则依然有效，但固化流程并非如此：赋能团队、交付可工作软件、客户协作这些核心依然宝贵。但执着于故事点、追逐速率、为不确定性做详细规划则已失效。
• 获得信任后，开发者才能茁壮成长：移除层层流程后我们发现，工程师需要的不是被管理，而是清晰的上下文。当他们能自主提议功能、设计发布并亲眼看到影响时，他们会真正关心并对结果负责。
• 表演式规划毫无价值：我们用15分钟的异步提案评审和实时结果仪表盘，取代了长达2小时的规划会议，效率与效果反而大幅提升。

结语

我们放弃的并非敏捷思想，而是那些在规模化后已无法服务于团队和用户的僵化仪式。敏捷给了我们一个指南针，但在复杂地形中航行，我们需要一张更细致的地图。

流式工程（Flow Engineering）不是一个框架，而是一种哲学：信任开发者，给予他们真实的反馈循环，让他们自主交付价值。 正是这一转变，带来了天壤之别。