Scrum敏捷管理制度设计

背景

公司目前存在的问题:

  1. 团队产出无法量化考核指标,绩效考核不公平导致团队效率低下,凝聚力不足
  2. 产品需求质量不高导致研发反复返工

针对公司的问题设计了一套相当完整的敏捷开发流程,重点在于以下三个制度的联动:

  • 需求池管理
  • 故事点评估(故事点与工时脱钩,用计划扑克避免羊群效应)
  • 绩效考核(记录需求驳回次数作为产品考核)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
graph TD
subgraph 产品侧
A[产品经理提交需求] -->|标准化模板| B(需求池)
B --> C{PO每周刷新优先级}
C -->|排序| B
end

subgraph Scrum评审会
B --> D[需求评审会]
D --> E[计划扑克评估故事点]
E -->|全员共识| F[任务拆分]
F --> G{产能计算}
G -->|基准点*70% - 请假扣减| H[承诺需求清单]
end

subgraph 研发迭代
H --> I[研发自主认领任务]
I --> J[评估预估工时]
J --> K[开发实施]
K -->|发现复杂度遗漏| L[标记故事点膨胀]
end

subgraph 迭代回顾
K --> M[完成需求重估故事点]
L --> M
M --> N[分析膨胀原因]
N --> O[效能数据记录]
O --> P[[考核指标:<br>• 个人故事点<br>• 工时偏差率<br>• Bug密度]]
end

subgraph 反馈闭环
D -->|驳回| Q[需求修改]
Q --> B
O -->|产能基线| G
P -->|驳回率| R[产品考核]
end

style A fill:#4CAF50,stroke:#388E3C
style B fill:#E3F2FD,stroke:#64B5F6
style D fill:#FFECB3,stroke:#FFD54F
style E fill:#FFF9C4,stroke:#FFEB3B
style K fill:#C8E6C9,stroke:#81C784
style M fill:#BBDEFB,stroke:#2196F3
style P fill:#F8BBD0,stroke:#F48FB1
style Q fill:#FFCCBC,stroke:#FFAB91

需求池管理与Scrum团队协作制度

目标:建立透明高效的需求流转机制,平衡产品创新与研发效率,量化团队效能

一、需求池管理规则

  1. 入口标准

    • 产品经理通过标准化模板提交需求(含业务目标、用户场景、原型/逻辑说明)
    • 强制字段:业务优先级(P0-P3)预期价值关联业务模块
  2. 优先级排序

    • 动态调整机制:每周由产品负责人(PO)根据市场变化刷新需求优先级排序
    • 紧急通道:<10%的需求可标注紧急插入(需CTO联签说明)
  3. 需求驳回机制

    • 驳回条件
      • 逻辑矛盾(与已有功能冲突)
      • 技术不可实现(当前架构限制)
      • 需求描述不完整(关键流程缺失)
    • 考核指标
      • 产品经理季度驳回率 = 被驳回需求数/总提交需求数(警戒线≥15%)

二、迭代规划流程

(1)需求评审会(每周期1次,时长≤4小时)

环节执行动作输出物
需求讲解产品逐条说明需求场景与技术边界需求确认清单
故事点评估全员使用计划扑克(Fibonacci数列:1,2,3,5,8…)带共识故事点的需求列表
任务拆分前后端协作拆解技术任务(API/组件/数据模型)任务树状图

计划扑克执行要点

  • 每轮评估后差异≥3点需辩论(例:A说8点,B说3点 → A陈述技术风险,B提出简化方案)
  • 强制规则:必须达成全员共识(禁止平均取值)

(2)迭代承诺

  • 计算团队产能基准:基准故事点 = 近3次迭代平均完成点 × 70%(预留30%缓冲)
  • 扣减因子:成员请假天数 × 0.5故事点/人/日
  • 输出本期承诺需求清单 + 总故事点范围(如:85-92点)

三、迭代执行监控

环节规则
任务认领研发每日站会自主领取任务(禁止分配),需标注预估工时(精确到0.5天)
故事点膨胀开发中新增未评估复杂度 → 即时标记风险点,在每日站会同步
变更控制迭代开始后禁止新增需求(紧急需求需消耗团队故事点储备池

四、迭代回顾会(核心数据闭环)

  1. 故事点重估

    • 对实际完成需求重新打牌评估故事点
    • 实际点 > 原始点,责任研发说明膨胀原因(如:未预见的兼容性问题)
    • 记录需求ID | 原始点 | 重估点 | 膨胀原因
  2. 效能数据采集

    指标计算方式用途
    个人完成故事点∑(认领需求重估故事点)产能基线
    个人工时效率∑任务实际工时 / ∑任务预估工时计划能力评估(目标0.9-1.1)
    缺陷密度本期产生BUG数 / 个人完成故事点质量系数(警戒线≥0.5个/点)

五、绩效考核关联设计

PlantUML 1.2023.13 <b>This version of PlantUML is 609 days old, so you should<b>consider upgrading from https://plantuml.com/download[From string (line 2) ] @startuml* 绩效考核Syntax Error?

六、风险控制清单

  1. 故事点通胀预防

    • 建立复杂度对照库(例:简单CRUD=3点,跨系统集成=8点)
    • ScrumMaster每月审计重估需求膨胀原因TOP3
  2. 防止考核扭曲

    • 故事点上限封顶(个人单迭代≤35点,避免超负荷承诺)
    • 剔除无效故事点(如:因产品变更导致的需求作废)

这套制度实现了你要求的「需求闭环管理」+「量化效能」+「双向考核」,既保障研发话语权,又倒逼产品提升需求质量。

本作品采用 知识共享署名 4.0 国际许可协议 进行许可。

转载时请注明原文链接:https://blog.hufeifei.cn/2025/05/business/scrum/

鼓励一下
支付宝微信