很多团队跟我说我们已经在用Scrum了但走进去一看往往只有Daily Standup长得像Scrum剩下的全是挂羊头卖狗肉——产品经理还在逐个派活项目经理还在催进度开发人员还在等着被分配任务。问题的根源基本都出在同一个地方三个角色的定位从一开始就没立住。Scrum框架本身很简单满打满算三个角色、五个事件、三件工件但越是看起来简单的东西越容易被经验主义带偏。大多数团队学Scrum时注意力全放在了流程和会议形式上反而把最核心的角色与分工问题忽略了。结果就是Daily Standup开得像汇报会Sprint Review开得像验收会Retrospective开得像批判会。流程一个不少但该做决策的人不敢拍板该负责过程的人变成了行政秘书该自组织的团队还在等着被管理。这篇文章我想把Scrum的核心角色与分工这件事彻底聊透。适合正准备引入Scrum的团队、已经在用但总觉得别扭的团队以及被三个角色到底怎么分困扰的Scrum Master和产品负责人。1. 为什么Scrum一定要把角色切成这三块很多人理解Scrum角色时喜欢用传统的岗位思维去套Product Owner就是产品经理Scrum Master就是项目经理Developer就是程序员。这个理解不能说全错但会错过Scrum设计这三个角色的真正意图。1.1 三个角色分别盯住哪一类不确定性问题Scrum诞生的背景是复杂项目的管理。所谓复杂项目最大的特征就是需求不清晰、方案不确定、过程不可预测。传统项目管理假设事情可以被预先规划清楚但软件开发的现实是客户自己都不知道自己要什么技术方案要试了才知道团队速度要跑了才了解。面对这种不确定性Scrum把三个必须被持续回答的问题拆给了三个角色做什么才能让价值最大化这是Product Owner的职责。需求怎么排序、先做哪个后做哪个、做到什么程度算完成这些决策需要一个人持续地收集信息、做出判断并且承担后果。怎么做才能让过程更顺畅这是Scrum Master的职责。团队怎么协作、流程怎么优化、障碍怎么清除需要一个不站在任何一方利益立场上的人专门盯着。用什么方式把承诺变成可用的增量这是Developer的职责。具体的技术方案、工作量估算、质量保障需要一群具备跨职能能力的人自主组织、共同完成。你会发现这三个角色不是按职能划分的而是按决策类型划分的。PO做的是价值决策SM做的是过程决策Developer做的是技术决策。每一种决策都需要不同的信息输入、不同的能力结构、不同的问责方式硬把它们塞给同一个人或者同一个岗位必然顾此失彼。1.2 为什么这个结构里没有项目经理这是我在企业里被问得最多的问题。很多团队习惯了项目经理的存在觉得没了PM项目就没人兜底了。但Scrum的设计理念恰恰是项目管理的事被拆解并分担到了每个角色身上。进度管理不是某个人的专职而是团队在Sprint Planning里共同承诺的结果风险识别不是某个人的专职而是Daily Scrum和Review里持续暴露的信息沟通协调也不是某个人的专职而是每个角色在自己的职责边界内自然发生的。项目经理这个角色的消失不是Scrum在偷懒而是它认为传统PM的很多工作本身就是团队应该自己消化掉的。保留一个PM在Scrum外面指手画脚反而会破坏自组织——这也是很多Scrum团队转型失败的隐性原因。管理层觉得没PM不放心又安插了一个结果所有事情都被PM协调走了团队永远长不大。2. Product Owner价值最大化这件事必须有人说了算如果说Scrum里只能有一个人说了算那个人一定是Product Owner。但说了算不等于什么都管PO的权力和职责是有清晰边界的。2.1 PO的核心职责到底是哪几条我见过很多自称PO的人实际干的活是需求传话筒——把客户的原始诉求记下来转手丢给团队然后等着收结果。这不是PO这是翻译官。一个合格的PO核心职责就是三件事第一管理Product Backlog的内容和顺序。Backlog里的每一条需求为什么存在、优先级多高、验收标准是什么PO必须能给出理由。排序的逻辑不是客户说这个急而是做这个对业务目标的贡献最大。这意味着PO需要持续收集各方反馈、分析价值大小、和干系人博弈然后把结论固化在Backlog的排序里。我给团队培训时常说一个判断标准如果Backlog里的条目顺序随便换个位置团队无感说明PO没在做他的核心工作。Backlog的顺序就是PO的决策结果它应该体现PO对价值的判断。第二明确需求的验收标准。PO不是写需求文档的他是定什么叫做完的那个人。很多冲突都出在验收标准上——开发觉得做完了PO觉得还差得远。根本原因就是PO没有在Sprint开始前把Done的定义描述清楚。实操里的一个有效做法是PO在Sprint Planning时对每一条要进入Sprint的需求当面和团队过一遍验收场景。不要发文档让团队自己看一定要对齐。团队理解偏差导致的返工永远是Scrum里最隐蔽也最昂贵的浪费。第三在Sprint进行中随时回答团队的问题。很多PO有一个错误习惯Sprint启动后就消失了等Review时才出现。但团队在开发过程中每天都会遇到需求层面的问题——这个字段到底要不要校验这个异常场景用户会怎么操作这个按钮的位置对不对。如果这些问题不能得到即时回答团队只能猜猜错了就是返工。所以我建议PO每天至少要留出固定时间给团队答疑哪怕只是半小时。这不是流程要求这是价值保障。2.2 PO与产品经理、项目经理的本质区别PMA和PO的区别值得单独说。产品经理往往是为一个产品线的长期发展负责关注市场、用户、商业模式而PO在为某一个Scrum团队的交付负责关注的是Backlog的颗粒度和交付节奏。一个PO完全可以同时是产品经理但角色意识必须切换。项目经理和PO最大的区别在于项目经理对按时按预算交付负责PO对交付的东西有没有价值负责。前者追求的是做完后者追求的是做对。这两种目标在日常决策中经常冲突如果由同一个人兼任他会在不知不觉中选择更稳妥的方案而不是更有价值的方案。2.3 PO最常见的三种失职方式我在辅导团队时反复看到PO在三个地方掉链子把Backlog当成需求堆不排序不清理。条目两三百条谁也不知道先做哪个团队只能自己挑或者由SM代劳。Backlog就失去了决策工具的意义。对最终结果不承担后果。Sprint Review时PO把增量展示给干系人干系人觉得方向错了PO第一反应是客户当时就是这么要求的而不是我的决策错了。PO的问责意识缺失会让整个Scrum的反馈闭环失效。跳过Sprint Planning。让SM代替主持自己找个借口不来然后Sprint进行到一半开始质疑团队的承诺。这三种失职的共同根源都是同一个PO没有真正把自己当成对价值负责的决策者而是把自己当成了流程中的一个信息节点。角色的重量感一旦缺失整个团队都会跟着失焦。3. Scrum Master不是秘书不是保姆更不是项目经理Scrum Master是全公司最容易被误解的位置。在很多人眼里SM就是那个组织会议、维护白板、催大家更新状态的人。有这种理解基本说明团队已经从根上跑偏了。3.1 SM的真正服务对象是谁Scrum Guide里写得很清楚SM要为三个对象服务Product Owner、Developer和组织。逐条拆开看服务PO是帮他提高做决策的能力。比如帮PO学会把大需求拆成可估算的条目帮PO学会和干系人谈判优先级帮PO理解团队的速率和容量从而做出靠谱的承诺。服务Developer是帮团队提升自组织的能力。比如在Daily Scrum里引导团队聚焦当天的协作而不是逐人汇报在Sprint Planning里帮团队把承诺做到有依据而不是拍脑袋在遇到障碍的时候协助移除而不只是记录。服务组织是帮组织理解Scrum并扫清制度障碍。比如管理层习惯用工时利用率考核开发人员时SM需要帮组织理解为什么这个指标在Scrum里是毒药比如跨团队依赖重重叠叠时SM需要推动组织调整协作结构。你看这三类服务的共同点是什么? 都不是替别人把事情做了而是帮别人把事情做好的能力变强。SM的产出不是团队这周没出问题而是团队这周解决了一个上周还解决不了的问题。前者叫看守后者才叫辅导。3.2 为什么SM不应该兼任开发角色这是一个很有争议的话题。我的态度很明确新团队建议不要兼任成熟团队可以考虑但要有明确边界。兼任的核心问题在于角色冲突。Daily Scrum的时候你是团队的一员要参与承诺发现团队承诺明显不靠谱时你要不要说话? 如果说话你就同时扮演了裁判和运动员如果不说话你作为SM的职责就失守了。再有SM需要和团队保持一定的过程距离。如果一个SM自己也在写代码他会天然地把注意力放在自己的开发任务上过程中许多细微的协作问题他就看不到了。就像一边开车一边看路况的教练两件事都做不好。当然小团队、资源有限的团队非得让SM兼任开发也不是完全不能转。但至少要把时间分清楚把SM的职责和开发的职责放在不同的时间段里并且明确告诉团队现在我是以开发身份在参与不是以SM身份点评。这种切换对个人状态的要求很高做不好就容易两头都不讨好。3.3 SM的衡量标准团队越来越不需要他我见过不少团队对SM很依赖。Daily Scrum没人主持就不开Backlog排不下去就找SM开会起冲突了也喊SM来断案。表面上看SM很有存在感实际上这是SM最大的失败——团队对SM的依赖程度应该随着时间递减。好的SM在做的每件事都应该带有自我淘汰的意味。帮团队定了冲突解决机制以后类似的冲突就不用再请SM出面教PO学会了拆分需求以后PO就不用什么都问他帮组织建立了跨团队沟通渠道以后依赖协调的事情就变少了。所以如果你是一个SM判断自己合不合格的标准很有意思团队是不是越来越不需要你了?如果是恭喜你做对了。如果你发现自己每天都在被各种会议和问题淹没反而要警惕——你可能在用战术上的勤奋掩盖战略上的失职。4. DeveloperScrum里没有我只有我们Developer这个角色在Scrum里指的是整个开发团队不是某个程序员个体。凡是参与交付增量的角色——后端、前端、测试、交互、运维——在Scrum里都叫Developer。这个命名本身就传递了一个信号Scrum不关心你是什么岗位只关心你为增量贡献了什么能力。4.1 自组织到底是什么意思自组织Self-organization是Developer团队的核心特征。但这个词被太多人误解了不少管理者一听自组织就紧张觉得团队没人管了要翻天。实际上自组织的意思是团队内部如何分配任务、如何协调协作、如何解决技术冲突由团队自己决定而不是由外部指令驱动。举个例子。Sprint Planning确定了要交付的目标之后具体谁做哪张卡、两个人之间的依赖怎么衔接、遇到困难先求助谁这些事都是团队自己协商的。SM不分配任务PO更不分配任务。如果你们团队的Daily Scrum上SM或PO在逐个人问你今天的任务完成了吗那不是Scrum那是披着Scrum皮的职能管理。自组织的心理学前提是承诺感。人对自己承诺的事情责任感远远强于被分配的事情。Scrum让团队自己估算、自己承诺、自己拆分任务就是要在机制上保证每个人对结果的投入感。这也是为什么我反复对PO说不要在Sprint里强行给开发加塞任务——一旦团队认为自己没有决定权他们就不会为结果负责。4.2 为什么必须是跨职能的Scrum Guide要求开发团队具备所有将Backlog条目转化为可用增量所需的全部技能。翻译成人话就是把一个需求做成一个可发布的增量团队内部所有人都应该能独立完成不需要求助于外部。这个要求一落地很多团队就露馅了。最常见的情况是UI设计在外部测试在独立的测试组运维在另外一个团队。每次开发完成之后要排队等测试测试提了一堆bug开发改完再排队功能要上线了运维说这周窗口满了。整个流程全是队列和等待团队一周能干完的事被拉长到三周。跨职能不是一个漂亮的词它是一个非常硬性的效率要求。如果你的团队正在经历开发等测试、测试等环境、环境等运维的死循环别急着优化流程先想办法把这些能力请进团队内部。4.3 Developer对质量的集体责任在Scrum里质量的责任属于整个开发团队不属于任何个人。传统团队里质量是测试的职责——开发写完了丢给测试测出bug了就是测试没把好关。Scrum把这种心态连根拔掉团队共同对完成的定义负责测试只是质量保障的手段之一不是最后的防线。具体到实操层面这意味着三件事第一每一次Sprint结束交付的增量必须是可用的不是开发完成了但还没测试的半成品第二团队的Definition of Done要包含完整的质量标准和发布标准不能由着PO说先能用就行第三如果质量问题在Sprint Review或者生产环境暴露了团队要集体复盘而不是揪出某个人背锅。质量一旦被定义为集体的责任团队的行为模式会立刻发生改变——开发会在提交前多做自测会主动找测试同事聊边界场景会在估算时把质量成本算进去。这些东西靠KPI是催不出来的只能靠角色定位的转变慢慢养出来。5. 三个角色在Sprint各个事件里是怎么咬合的角色不是放在组织架构图里看的是在日常运作里不断表演出来的。一个Sprint周期里的五个事件就是检验角色是否到位的试金石。5.1 Sprint Planning谁在输入谁在承诺Sprint Planning的输入是PO他要讲清楚这个Sprint要解决什么问题、哪几条需求优先级最高、验收标准是什么。Developer负责输出把需求拆成可以执行的任务做出容量判断并给出一个有依据的承诺——这个Sprint我们能完成这些。这个环节最常见的角色错位是PO直接把任务分给了具体的人或者SM替团队拍板说这点活两天就够了吧。正确的状态是PO对做什么有最终决定权但做多少是团队基于历史数据和容量估算的共同判断。PO可以挑战团队说你们是不是太保守了但最终的数字必须由团队自己说出来——因为承诺的主体是团队不是PO也不是SM。5.2 Daily ScrumDeveloper的协作站不是汇报台Daily Scrum是给Developer用来对齐当天协作节奏的不是给PO和SM用来查岗的。我常说一句话如果一个人参加Daily Scrum只是为了回答昨天干了什么、今天要干什么、有什么障碍那这个会有他没他都一样。Daily Scrum真正应该暴露的信息是我和谁之间有依赖需要提前沟通我发现哪个地方和原计划出现了偏差哪个需求的理解我不确定需要找PO确认。这类信息只有团队成员自己知道它天然是团队内部的沟通工具——所以PO和SM可以参加但应该尽量往后站把时间留给团队自己讨论。5.3 Sprint ReviewPO的决策质量接受检验Sprint Review时团队展示的是增量本身而不是PPT。PO要当着干系人的面把Backlog里有哪几条做完了、哪几条没做完以及为什么原原本本说清楚。没做完不是什么羞愧的事真正重要的是这个Sprint的成果有没有解决当初说好的业务问题。如果PO在Review上只会说大家看一下这个功能做好了却说不清楚这个功能和业务目标之间的关系那这个PO就是在用交付数量掩盖价值判断的缺失。Review是PO最应该感到压力的事件——因为干系人的反馈会直接检验他的决策水平。5.4 Retrospective三个角色共同补位的地方Retrospective是Scrum里唯一一个不区分角色的活动。PO、SM、Developer坐在同一张桌子上讨论上个Sprint我们协作得怎么样——不是互相找问题而是找出一个可以立刻改进的点在下一个Sprint里落地验证。从角色分工的角度来看Retrospective里值得关注的是每个角色有没有看到自己职责范围内的改进空间?Developer说我们估算总是不准那就该讨论改进估算方法PO说我发现Backlog的颗粒度太大导致Planning总是超时那就该调整拆分方式SM说你们好像又开始等我来解决问题了那就该讨论如何让团队自主推进。如果Retrospective里只有团队在反思PO和SM全程沉默那三个角色的协作结构一定出了问题。我用一个表格把各事件中的角色侧重点总结一下Scrum事件PO侧重点SM侧重点Developer侧重点Sprint Planning讲价值、定优先级、说验收标准引导对齐、确保承诺有依据拆任务、估容量、做出承诺Daily Scrum待命答疑不插手过程观察协作不主持不查岗对齐计划、暴露依赖与障碍Sprint Review展示成果与业务目标关系保证讨论聚焦、记录反馈演示增量、回答技术问题Retrospective反思自己的价值决策质量引导团队找到可落地的改进反思协作方式、提出改进项6. 我辅导团队时反复遇到的六个角色错位问题说完了 应该怎么样必须说一说实际会怎么样。我带过、辅导过、观摩过的Scrum团队不下几十个角色错位的问题翻来覆去就是下面六种非常典型大家可以对照自查。6.1 PO和SM是同一个人小团队里很常见因为人不够。我见过不少成功的案例但失败的更多。核心问题在于PO需要对价值做出强势判断SM需要保持中立来引导过程。当这两个角色变成一个人时他很难在对PO的决策提出挑战的同时又站在SM的位置上去引导它。如果一定要兼任我建议严格区分时间场合。做PO时就明确我是在以PO的身份做决定做SM时就明确我现在的职责是引导过程而不是拍板。而且最好在团队层面说清楚允许团队在需要的时候切换频道。即便如此这种兼任也只能算短期过渡方案长期来看还是要分开。6.2 SM从项目经理转型而来控制欲刹不住这是最典型的转型难题。做了十年PM的人转成SM满脑子还是进度、风险、里程碑。他会在Daily Scrum上追问进度会在Sprint开始前压制团队的估算会在团队遇到技术问题时直接给出建议。表面上看他很有担当实际上他在用旧模式的新瓶子装旧酒把团队自组织的空间全挤掉了。这种SM需要刻意练习一个习惯把我来搞定改成你们打算怎么搞定。刚开始会很难受感觉自己在推卸责任但撑过两三个Sprint等团队开始自己做决定、自己承担结果时SM就真正从管理者变成了辅导者。6.3 Developer把PO当老板团队习惯了向领导要任务到了Scrum里还是等着PO分配需求、分配优先级、甚至分配做法。如果PO也顺势扮演了导演的角色那团队的自组织就是一句空话。这里要区分清楚PO对做什么有决策权对怎么做没有。团队可以也应该在技术方案、实现顺序、人员分配上自己拍板。如果团队里的技术负责人还在等PO来确认怎么实现某个功能他实际上是在放弃自己的角色职责。从我个人的经验看这种情况往往不是团队不行是PO的手伸得太长——他愿意放权团队才可能接得住。6.4 测试不在团队里很多公司为了资源共享把测试放在独立的测试团队里让Scrum团队按需排队取测试。这在Scrum里是结构性缺陷——团队无法对交付增量负责因为质量这件事绕不过去要依赖外部。这个问题的解法不是让SM去跟测试部门协调排期而是从组织架构上把测试资源固化到Scrum团队里。哪怕一个测试同事同时支撑两个团队也比没有固定测试但在公共队列里排队强得多。优先级和资源绑定带来的效率提升远远高于所谓资源共享带来的利用率。6.5 管理层在外面又加了一个项目经理有些公司虽然让团队跑Scrum但不放心进度又设了一个交付经理或者项目总监在外面盯着。这些角色不和团队坐在一起但每周要汇报进度、要跟踪里程碑、要协调资源。这个角色的存在会让Scrum变得极其拧巴团队在Sprint里做的承诺到经理那里变成了截止日期PO定的优先级经理可能不认同又来插一脚团队的自主空间被一双外部眼睛盯着自组织发育不起来。如果管理层的目的是保证项目成功那他们更应该做的是信任Scrum机制而不是用另外一个角色来对冲Scrum。6.6 团队对完成的标准不一致Definition of Done是团队内部的共识不是PO单方面定义的标准。我见过有的团队Done就是代码写完有的团队Done是提测完有的团队Done是上线了三天没有重大bug。这三层标准对Sprint Review时的信任度影响天差地别。解决方案很简单在Sprint Zero或者Retrospective里花时间让整个团队——包括PO和SM——坐在一起把Definition of Done逐条写下来然后每一条都问一句这个标准做得到吗、做得到的话如何验证。白纸黑字贴出来每次评估是否完成时都对表执行。这个动作的价值不在于标准多完美而在于它把完成从模糊变成了可验证的共识。7. 落地到底怎么操作从今天开始可以做的最小调整聊了这么多原则和误区最后给一些可以直接抄走的操作建议。如果你的团队正在跑Scrum但总觉得角色不对别急着大动干戈先把下面这几件事做了大概率能感受到明显的改善。7.1 给三个角色写一份具体的职责卡别写套话要写可观察的行为。比如PO的职责卡上可以写每个Sprint开始前Backlog前10条都有清晰的描述和验收标准而不是负责管理需求SM的职责卡上可以写每周至少有一个障碍被清除且这个清除过程团队全程参与而不是保障流程执行Developer的职责卡上可以写所有Sprint承诺项由团队内部完成不依赖团队外资源而不是认真开发。这份职责卡贴在团队看得到的地方。日常协作中如果出现模糊地带直接对照职责卡判断——这比争论你该不该做这个高效得多。7.2 Sprint Planning结束前加一个角色自检环节我辅导团队时常用这个方法Sprint Planning快结束时让每个角色自己复述一遍这个Sprint他要做什么、要如何与其他角色协作。PO说我会在每周二下午固定在线答疑验收标准我在Planning时已经口头对齐过SM说我会帮团队清掉XX系统权限的问题并在内部推动自动化测试的落地Developer说我们决定这周用结对的方式处理支付模块防止单点风险。这个环节看起来简单但它强制每个角色把职责转化为约定——从抽象的概念变成了具体的承诺。比贴任何制度和流程都管用。7.3 让SM的周报内容聚焦在能力变化上如果你现在还在让SM写那种本周完成了会议组织、记录了风险、更新了看板的周报趁早换掉。SM的周报应该回答三个问题团队本周相比上周在自组织上有什么进步PO在决策质量上有什么变化组织为团队扫除了哪些障碍这三个问题会逼着SM做真正有价值的事。他会开始琢磨怎么样让团队少依赖他会开始花时间教PO做更好的Backlog管理会主动去和管理层谈制度问题。周报的引导作用比任何KPI都有效。7.4 用Review环节暴露角色问题而不是掩盖Sprint Review不是给团队打分的地方它是检视三个角色协作质量的窗口。如果Review上团队演示的东西PO没参与验收那问题在PO如果团队总是做不到承诺的量那是估算和拆分的问题如果SM每次都把Review变成顺利发布会那是SM在掩盖问题。我建议在Review结束时增加一个简单的环节干系人留五分钟PO把Backlog里接下来要做的三件事讲给他们听问一句如果只做这三件哪个最该优先? 这个动作一方面检验PO对价值的理解是否和干系人同步另一方面也给下个Sprint的规划预留了宝贵的信息输入。很多PO在这个环节会发现自己对干系人真实想法的判断是有偏差的。8. 实际带团队过程中的一点个人体会最后聊点掏心窝的话。Scrum这个框架本身很轻轻到三个角色、五件事、三条工件就能说完。但越是轻的框架越考验人的角色意识。我见过很多团队一开始怀着热情引入Scrum跑了不到三个月就退回老路理由千篇一律Scrum不适合我们。但你去细看根本不是Scrum不适合而是三个角色的权责从一开始就没立住。PO不敢拍板团队就没有方向SM想当领导团队就永远长不大Developer等着被安排Scrum就退化成一套开会仪式。角色不是组织架构图上的一个框是日常协作中每一次选择的总和。我个人在带团队时还有一个体会角色分工这种东西永远不可能一蹴而就。它需要在一个个Sprint里反复校准有时候一个季度就要重新对齐一次。团队在变、业务在变、人在变角色的边界也要跟着调。关键是每个阶段都要有人把这个话题放到桌面上来谈——这个人通常应该是SM但如果SM没做任何一个角色都可以发起。把一个说不清的模糊地带拿到台面上来本身就是在践行Scrum的精神。