项目经理必修管理方式-Scrum

wanghy 的头像
wanghy

介绍一个我最常用的管理方式，但前提是项目的需求非常明确，且确保在开发周期内不会打动产品设计需求！

Scrum 的核心是 “标准化迭代 + 明确角色 + 闭环协作”，流程规范围绕 “需求→计划→执行→反馈→优化” 展开，每个环节都有明确规则，确保团队高效且不跑偏，下面用大白话拆解得明明白白：

一、先明确 3 个核心角色（缺一不可）

Scrum 的流程能跑通，前提是角色分工清晰，没人推诿也没人越权：

  • 产品负责人（Product Owner，PO）：“需求管家”，对最终产品负责。核心工作是收集所有需求（比如客户、老板的要求），整理成 “产品待办列表（Product Backlog）”，并按重要性排序（比如 “登录功能” 比 “皮肤更换功能” 优先级高），还得拍板需求是否通过验收。
  • Scrum 大师（Scrum Master，SM）：“流程守护者 + 障碍清除者”，不直接管任务分配，而是确保团队按 Scrum 规则来。比如阻止无关人员打扰团队、帮团队解决工作中的障碍（如资源不够、跨部门对接卡壳）、组织会议并避免会议跑偏。
  • 开发团队（Development Team）：“执行军团”，通常 5-9 人（人太多难协作），跨职能搭配（比如包含开发、设计、测试）。核心是 “自组织”—— 不用 PO 或 SM 指挥，自己分配任务、自己把控进度，对每个迭代的成果负责。

二、完整流程规范（从启动到复盘，闭环运转）

Scrum 的流程以 “迭代（Sprint）” 为核心周期，一般 2-4 周（可根据项目调整，一旦定了就不能改），每个迭代都要交付一个 “可使用的产品增量”（比如 APP 的一个核心功能模块），全程分 6 个关键步骤：

1. 迭代规划会（Sprint Planning）—— 定好 “这周期要做啥、怎么做”

  • 时间：迭代开始的第一天，时长 = 迭代周数 ×2 小时（比如 2 周迭代开 4 小时，4 周迭代开 8 小时）。
  • 参与人：PO、SM、全体开发团队。
  • 核心流程：
    1. PO 讲解 “产品待办列表”，明确最高优先级的需求（比如 “这次必须做完用户注册 + 首页展示”），并说明验收标准（比如 “注册能收验证码、首页能加载 3 条内容”）。
    2. 开发团队讨论 “这些需求要怎么实现”，拆解成具体任务（比如 “画注册页 UI、写验证码接口、做首页数据渲染”），估算每个任务的工作量（常用 “故事点” 或 “人天”，比如这个任务 2 个故事点，那个任务 1 人天）。
    3. 最终确定 “本迭代能完成的任务清单”（即 “Sprint 待办列表”），团队承诺交付成果，SM 记录会议结论，避免后续扯皮。

2. 每日站会（Daily Scrum）—— 同步进度、解决障碍（不聊细节）

  • 时间：迭代期间每天固定时间（比如早上 10 点），时长≤15 分钟（超时就是无效会议）。
  • 参与人：开发团队 + SM（PO 可自愿参加，不强制）。
  • 核心规则：
    1. 每个人轮流说 3 句话，不展开讨论：
      • 昨天我完成了什么（和本迭代任务相关）？
      • 今天我要做什么？
      • 我遇到了什么障碍（比如 “接口对接卡壳”“资源不够”）？
    2. SM 的作用是 “记障碍、推解决”—— 比如团队说 “跨部门的接口没给”，SM 会后立刻去对接，不让障碍卡着进度。
    3. 禁止在站会上聊技术细节（比如 “这个 bug 怎么修”），要聊细节会后单独找相关人说。

3. 迭代执行（Sprint Execution）—— 自组织干活，聚焦交付

  • 时间：整个迭代周期（除了规划会、站会、评审会、复盘会的时间）。
  • 核心要求：
    1. 开发团队按 “Sprint 待办列表” 自分配任务，不用谁指挥，比如 A 擅长 UI 就主动接设计任务，B 擅长后端就接接口开发。
    2. 全程聚焦 “可交付成果”，比如每个任务做完后要能 “跑通”，不是只写了代码没测试。
    3. PO 可随时解答需求疑问，但不能中途加新需求（除非是极紧急的，加了就要调整原有任务，需团队同意）。
    4. 用 “看板” 可视化进度（比如 Jira 看板，分 “待做→进行中→测试→已完成”），所有人都能看到任务状态。

4. 迭代评审会（Sprint Review）—— 展示成果、收集反馈

  • 时间：迭代结束的前一天，时长 = 迭代周数 ×1 小时（比如 2 周迭代开 2 小时）。
  • 参与人：PO、SM、开发团队、客户 / 用户代表（或相关 stakeholders）。
  • 核心流程：
    1. 开发团队演示本迭代的成果（比如打开 APP 展示注册功能、首页加载效果），必须是 “能实际用的”，不是 PPT 演示。
    2. 客户 / 用户代表提反馈（比如 “注册按钮位置太偏”“首页内容要加分类”），PO 记录所有反馈。
    3. 大家一起确认 “哪些成果通过验收”“哪些需要优化”，优化的需求会加入 “产品待办列表”，留到下一个迭代排序。

5. 迭代回顾会（Sprint Retrospective）—— 总结经验、优化流程

  • 时间：迭代结束当天（评审会之后），时长 = 迭代周数 ×1.5 小时（比如 2 周迭代开 3 小时）。
  • 参与人：PO、SM、全体开发团队（仅限内部，不邀请客户）。
  • 核心规则：
    1. 聚焦 “流程” 而非 “个人”，只聊 “怎么做更好”，不指责谁做得差。
    2. 所有人轮流说 3 件事：
      • 本迭代做得好的地方（比如 “站会效率高，障碍解决快”）？
      • 做得不好的地方（比如 “需求拆解太粗，中途返工”）？
      • 下一个迭代要改进的 1-2 个具体行动（比如 “下次拆解任务时多花 30 分钟讨论细节”“PO 提前 1 天确认需求优先级”）。
    3. SM 记录 “改进行动清单”，并在下个迭代跟踪落实，避免 “光说不做”。

6. 迭代收尾与规划衔接 —— 无缝启动下一轮

  • 迭代结束后，开发团队整理交付成果（比如代码归档、测试报告），PO 更新 “产品待办列表”（加入新反馈的需求、调整优先级）。
  • 休息 1-2 天（可选），然后立刻启动下一个迭代的 “规划会”，进入下一个闭环。

三、必须遵守的 3 个关键规则（打破就乱了）

  1. 迭代周期固定不变：一旦定了 2 周迭代，就不能中途改成 3 周，保证节奏稳定。
  2. 不随意加需求：迭代中 PO 不能临时塞新需求，除非团队同意移除原有低优先级任务，避免 “无限加活”。
  3. 成果必须 “可使用”：每个迭代的交付物不能是 “半成品”，要能独立运行、满足基本使用场景（比如注册功能能完成从输入手机号到登录的全流程）。

希望对大家有所帮助