<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Scrum Master · 仁才德</title>
    <link>https://jared.lynskey.co.nz/zh-cn/tags/scrum-master/</link>
    <description>关于软件工程与研发团队领导力的短文——绩效评估、招聘与团队扩张、CI/CD、DevOps 监控、智能体 AI。写于首尔。</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <copyright>© 2026 仁才德</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/zh-cn/tags/scrum-master/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Scrum Master 的职责是什么？该盯的是流程，不只是结果</title>
      <link>https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-10-16-outcome-indepedent/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-10-16-outcome-indepedent/</guid>
      <pubDate>Mon, 16 Oct 2023 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>Scrum</category>
      <category>Scrum Master</category>
      <category>Agile</category>
      <category>Retrospectives</category>
      <category>Team Management</category>
      <description>按照 Scrum 指南，Scrum Master 到底对什么负责、和项目经理有什么区别，以及为什么这个角色该花力气改进流程，而不是盯着 Sprint 结果。</description>
      <content:encoded><![CDATA[<p>先给结论。按照 2020 版 Scrum 指南，Scrum Master 负责两件事：按指南的定义把 Scrum 建立起来，以及 Scrum 团队的效能。具体来说，就是为开发人员、产品负责人（Product Owner）和整个组织服务：辅导团队学会自我管理，推动清除阻碍进展的障碍，确保各项 Scrum 事件如期举行、开得有成效，并且不超出时间盒（timebox）。至于给人分派任务、催团队交结果，指南里从来没要求 Scrum Master 做。这篇想聊的，就是这中间的差别。</p>
<p>我经历过的最糟糕的几次回顾会，长得一模一样：Sprint 目标没达成，于是整整一小时变成&quot;为什么没完成&quot;的审讯大会。而最好的几次回顾会，几乎没怎么提目标本身。我们聊的是这段时间怎么干活的、什么东西拖了后腿、下次想换个什么做法。这个差别，就是所谓&quot;不被结果绑架的心态&quot;。自己带着团队跑了一段时间 Sprint 之后，我越来越觉得这是 Scrum Master 最要紧的一种素质。</p>
<p>先说清楚：结果当然重要。流程漂亮但什么都发不出去的团队，没人会发工资。但是，完成 Sprint 是团队的活儿；Scrum Master 的活儿是改进那台&quot;产出 Sprint 的机器&quot;。这是两份不同的工作，我见过的 Scrum 乱象，大多是从把这两件事搅在一起开始的。</p>

<h3 class="relative group">Scrum Master 和项目经理有什么区别
    <div id="scrum-master-和项目经理有什么区别" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#scrum-master-%e5%92%8c%e9%a1%b9%e7%9b%ae%e7%bb%8f%e7%90%86%e6%9c%89%e4%bb%80%e4%b9%88%e5%8c%ba%e5%88%ab" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>这两个角色经常被混为一谈，部分原因是不少公司干脆让一个人兼着。核心区别是：</p>
<table>
	<thead>
			<tr>
					<th></th>
					<th>Scrum Master</th>
					<th>项目经理</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>管什么</td>
					<td>团队怎么干活，干得顺不顺</td>
					<td>范围、进度和预算</td>
			</tr>
			<tr>
					<td>分派任务吗？</td>
					<td>不分派，开发人员自己规划</td>
					<td>通常会</td>
			</tr>
			<tr>
					<td>成功是什么样</td>
					<td>团队一个 Sprint 比一个 Sprint 好</td>
					<td>项目按时、按预算交付</td>
			</tr>
	</tbody>
</table>
<p>Scrum 本身没有项目经理这个角色。项目经理平时干的不少活，分到了产品负责人（决定做什么、先做什么）和开发人员（规划怎么做）身上。</p>

<h3 class="relative group">放下对结果的执念之后，会变好的几件事
    <div id="放下对结果的执念之后会变好的几件事" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%94%be%e4%b8%8b%e5%af%b9%e7%bb%93%e6%9e%9c%e7%9a%84%e6%89%a7%e5%bf%b5%e4%b9%8b%e5%90%8e%e4%bc%9a%e5%8f%98%e5%a5%bd%e7%9a%84%e5%87%a0%e4%bb%b6%e4%ba%8b" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>首先，团队才有空间真正当家做主。Scrum 的前提本来就是自组织团队，可一个为每个结果提心吊胆的 Scrum Master，不知不觉就会把手伸进决策里。团队很快就学会了：&ldquo;反正拍板的不是我们。&ldquo;把重心放回流程，你才能放手让大家去实验、偶尔做错决定、再从里面学到东西。主人翁意识只能这么长出来。</p>
<p><a href="https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-09-01-retrospecs/" >回顾会</a>也会变得诚实。当会议室里的问题是&quot;为什么数字没达标&rdquo;，真话就藏起来了；换成&quot;什么拖慢了我们、下次试点什么&rdquo;，大家才肯开口。Sprint 中途冒出来的障碍也一样：执着结果的 Scrum Master 会为交期慌了手脚，专注流程的那位则闷头去把拦路的东西清掉；如果拦路的是一个谁都还没摸清的问题，就提议做一个限定时间的 <a href="https://jared.lynskey.co.nz/zh-cn/posts/2023/2023-10-18-spike/" >Spike</a> 去查清楚。</p>
<p>跟利益相关方的关系也会缓和许多。如果你能讲的故事只有燃尽图，那任何一点波动看起来都像失败。要是还能讲清楚团队学到了什么、怎么在调整，大家的预期就会现实得多——很多本来会在 Sprint 中途砸到团队头上的压力，你也就能在外面替他们挡掉。</p>

<h3 class="relative group">如果你已经在为某个结果魂不守舍
    <div id="如果你已经在为某个结果魂不守舍" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%a6%82%e6%9e%9c%e4%bd%a0%e5%b7%b2%e7%bb%8f%e5%9c%a8%e4%b8%ba%e6%9f%90%e4%b8%aa%e7%bb%93%e6%9e%9c%e9%ad%82%e4%b8%8d%e5%ae%88%e8%88%8d" aria-label="锚点">#</a>
    </span>
    
</h3>
<p>道理都懂，做起来难，我知道。当你在某件事上投入很深的时候，&ldquo;专注过程&quot;听起来就像冰箱贴上的鸡汤。</p>
<p>说几个对我真正有用的办法。第一，别为&quot;在乎结果&quot;责怪自己——想要一个结果是人之常情，装作不在乎撑不了多久。第二，把结果目标翻译成你能控制的过程目标：不是&quot;赢下这场比赛&rdquo;，而是&quot;每天练 30 分钟&quot;。发布受不受欢迎你控制不了，但有没有做过评审、跑过测试、提前演示过，你控制得了。第三，看清是什么在给执念添柴。要是你一天刷十遍仪表盘或者股价，就定好固定的查看时间，其余时间不看。路上的小胜利也要记得庆祝，不然远处那个大目标会把你的注意力吃得干干净净。如果这种执念已经严重到影响睡眠和日常生活，去找专业人士聊聊很值得，一点也不丢人。</p>
<p>结果依然重要。但那些能稳定拿到结果的团队，背后总有一个人在照看&quot;怎么做&quot;，而不只是&quot;做出了什么&quot;。</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2023/2023-10-16-outcome-indepedent/featured.jpeg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
