Scrum

物以类聚 - Scrum特性团队之社区

今天读到 Scrum模式社区中的一个模式（物以类聚 - Bird of Feathers），觉得很有启发。

公司或组织内，往往是用层级方式（加上组件团队或职能团队）来搭建组织结构。

这个方式非常符合我们的学习方式，即还原论方式。
把一个系统切分成若干个小块，然后认真学习其中的每一块。（西方哲学的基础是还原论[1]）

看一下我们的组织（或公司），是不是也是拆分成很多的小块，然后期望每一块都可以做到极限的效率。

Scrum的重要基础是特性团队（特性团队有两个阶段，后续可以讨论）。据我观察，愿意且能够组成特性团队的公司不超过10%。

原因呢，我猜测是不好管理。试想一下，是把同样技能的人放在一起好管理，还是特性团队好管理。（这里的管理指的是直接可见的效率数字，如KPI等）

而反直觉的特性团队，会给产品开发带来巨大的收益。

比如Spotify的例子，很多人都在研究，如下图：

Spotify规模化敏捷模型图：展示Squad特性团队、Chapter技能社区、Tribe部落和Guild联盟的组织结构

这个图中的Squad就是特性团队，而Chapter是类似于职能、技能。

需要项目经理看到这个图后，都会跟我讨论是弱矩阵还是强矩阵。

其实这个根本不是矩阵。

只有一个方向 Squad 的负责人是PO（即产品负责人），另 Tribe 会有管理者。Chapter的负责人不是管理者。而不论是Chapter也好，Guild也好，都是某种形式的社区。即同类的人。

对于公司来讲，赚钱（盈利）是首要目的。因此以首要目的来组织人员没有问题。

至于相同技能、兴趣的人，是以非正式的社区形态存在。（如果公司小，可以考虑和外部社区进行关联）

如下图是另外一个呈现的形式：

物以类聚模式图：Scrum组织模式中特性团队与技能社区的关系示意图

原文链接

参考资料

[1] 还原论 https://zh.wikipedia.org/zh-hans/%E8%BF%98%E5%8E%9F%E8%AE%BA

思考

组织结构永远不可能有完美的，但一定要记住，无论怎么调整结构，都是为组织目标服务的。（产品是核心）

每日问题

你的组织结构是怎么样的，你会怎么调整？（虽然不一定有权限，但这个是作为管理层必备的技能）

欢迎加入自由职业者俱乐部 微信群，请加微信：

baobaotalk_com ；添加微信后，发送消息 dream

版权声明

本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！

关于作者

BoB Jiang

中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者

Think BIG, act small

First heard this sentence ’think big, but act small’, I am totally inspired. Why?

I am a trainer, and have many friends like me as trainers or consultants. Often I have some ‘great’ ideas, but I didn’t move forward, so I would miss some opportunities as well. Then if I have any idea, and would like to make it real, and I have to do something, aka. act a small step.

交付还是交代

了解过Scrum的同学，或拿到 Certified Scrum Master (CSM) 认证的同学，应该都知道Scrum是一个框架，3-3-5-5，分别是：

3个角色
3个工件
5个事件
5个价值观

然而这里面有很多重点，或可能被人忽略的地方。

今天要反思的一个点是我最近1年的感悟，即交付。

什么是交付

交付不仅仅是交出答案，而更应该是有“响”，即付出有对应的回报（最直观的回报，可以用金钱衡量，或可以和金钱挂钩的度量）。

举个简单的例子：比如我们要开发软件中的一个特性（feature）。

如果只是完成了开发和对应的测试工作，（或甚至有的只完成了需求分析或设计文档工作）那么这个时候的特性，无法使用，也不能为团队带来直观的回报。
可能团队会很辛苦，996，天天加班。但作为没有办法度量结果的团队，只能说他们有了交代，而不是交付。

什么是真正的交付呢？

交付指的是，特性真正完成，可以交付给客户使用。由此，客户（以及用户）的问题得到真正的解决，并且变得很高兴。然后团队也变得很兴奋。（当然，客户变得高兴之后，从长远看，收入也会变得顺畅）。

我们要选择交付还是交代

答案毋庸置疑，但往往我们会局限于自己的视角，以为我们选择的是交付，而实际是交代。

我们可以尝试通过如下的问题，来检验是否是交付：

这个工作对于客户的价值是什么？
这个工作是否解决了客户的某个问题？
这个工作是否节省了客户的时间或金钱？
这个工作是否帮客户带来了更多的用户？
还有更多的问题吗？欢迎一起来探讨

赶快扔下那些交代，一起来专注于交付吧！

想要学习 CSM敏捷认证，一起来报名吧！

关于Bob Jiang

BoB Jiang

HiBlock区块链社区（hiblock.net）发起人
中国北方的第一位CST（Certified Scrum Trainer）
国内的敏捷（Agile）大咖
敏捷变革中心（Center for Agile Transformation）合伙人
敏捷一千零一夜社区合伙人
敏捷之旅核心组织者
《Scrum精髓》译者

Scrum 官方权威指南

收听有声版 | 官网下载PDF

由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护

版本：2017中文版

Scrum 指南的目的

Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本 Scrum 指南包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。

Scrum 的定义

Scrum（名词）： Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。

Scrum 是：

轻量级的
易于理解的
难以精通的

Scrum 是一个框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。

Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。

Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。

使用 Scrum 框架的其它不同特定技巧将不在本文中描述。

Scrum 的应用

Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范围内已得到了广泛应用：

1. 研究与确定可行的市场、技术和产品能力；

2. 开发产品和增强功能；

自敏捷宣言以来，随着敏捷软件开发方法的普及，很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架（Scrum和看板方法）——从它们的起源来分析各自的本质。

Scrum

Scrum的起源

Scrum一词来源于英式橄榄球（rugby）中重新开始比赛的争球的术语（是体育术语，不是缩写简写）。详情参考Wikipedia。

Scrum之父Ken Schwaber和Jeff Sutherland为什么选择这个词呢？这是因为他们受到一篇1986年哈佛商业评论上的论文影响——《The New New Product Development Game》。论文中开篇提到了：

许多公司意识到仅仅依靠高质量和低成本，已经无法从今天的市场中脱颖而出，它们还需要速度和灵活性。……而传统的顺序式或“接力赛”方法（比如按阶段的产品规划）可能和追求速度和灵活性的目标相冲突。相反，一种全局的或“英式橄榄球（rugby）”（团队通过前后配合传球的方式，作为一个整体单元推进）可能更好的适应了这种目标。另外，在Scrum指南中也非常强调团队（开发团队），它们具备如下特点：

自组织的，没有人来命令（或告诉）团队如何把产品列表变成潜在可交付的产品增量。
跨职能的，团队作为一个整体，拥有开发产品增量所需的全部技能。
全职的，团队成员100%在团队内工作。
规模较小的，一般5-9人虽然Scrum指南中还定义了Scrum框架的其他内容，但通过Scrum的起源（那篇论文）和指南中对于团队的描述，我们不难看出Scrum的本质是以团队为核心。

Scrum的本质

Scrum本质是以团队与产品（产品列表Product Backlog，这里就不展开介绍产品列表了）为核心。注意这里指的团队，和我们平时说的团队之间的差异。Scrum中的团队是自组织的、跨职能的特性团队。这样的团队的好处是：

特性（客户需求）在一个团队内完成，去除了移交、等待之类的浪费
团队的业务知识快速增长
团队稳定，从而有助于团队隐性知识的积累

“搭班子、定战略、带队伍” ——柳传志柳总的管理心法是在做事之前要先有一批志同道合的人，有班子，然后再考虑定战略。这个管理思路和Scrum是一脉的。Scrum的本质也是先打造自组织跨职能的特性团队，然后再遵守Scrum指南的其他规则。

看板方法

看板方法的起源

看板方法的重要来源是Donald G. Reinersten的《The principles of product development flow》。这本书强烈推荐大家读一下。该书中共介绍了175个产品开发的原则，其中不乏一些反常识性的原则，另外还介绍了一些具有实践性的方法：

改善决策的经济性
管理队列（对比一下肯德基和麦当劳的取餐模式，很有趣）
减小批量大小
应用WIP限制
去中心化

看板方法的本质

由上述Don的书中核心理论可以看出，（产品开发流动的原则）他强调的是流动以及价值流动，这个是看板方法的本质。看板方法通过一系列原则促进实现价值的快速流动，比如：

可视化
限制WIP
减小批量
管理度量队列
等等

Scrum和看板方法的对比

上面分析完Scrum的起源、本质和看板方法的起源、本质后，我们不难看出这是两个完全不同的解决问题的方法。

Scrum侧重于团队和产品，先有自组织跨职能的特性团队，然后围绕着产品列表进行交付。
看板方法侧重于工作事项，先让价值流动起来。那么这两种方法孰优孰劣，这个很难衡量。以下仅代表个人观点： Scrum的特点：
打造真正的团队
多数情况下组织结构需要变动（跨职能团队）
Scrum转型的切入点是组建团队和梳理产品列表 看板方法的特点：
价值快速流动
多数情况下组织结构不需变动（保留当前的现状）
看板方法转型的切入点是梳理工作的价值流

适合场景

Scrum更加适合产品开发，比如一个全新产品或原有系统的增强等。围绕着先组建特性团队、梳理产品，然后每个Sprint产出产品增量。

看板方法更加适合运营型（或运维性）项目。该项目特点是很难提前做出预测。比如我们无法预知明天会出现几个线上故障。

课后思考题

基于以上的Scrum和看板方法本质和特点，你会怎么选择呢？是否可以结合Scrum和看板方法呢？欢迎回复留言进行探讨。

最近听到有人说，敏捷就是快 - 快速发布，快速完成任务，甚至有人会问，这样快了以后质量有保障吗？那么我们先来看一下什么是敏捷。敏捷，英文是Agile，指的是敏捷软件开发。这里要特别感谢Alistair Cockburn博士给出的定义：

Agile is to deliver business value early and frequently.

敏捷是尽早频繁地交付商业价值。

这里，我们没有看到“快”这样的描述。

所以说，敏捷（Agile）本来就没有说要快速交付。那么敏捷到底是什么，为什么总有人说敏捷快呢？

我们一起来分析一下，假设有一个项目（比如说3个月的项目周期），分别由两个一样的团队（这里是假设，因为不存在两个完全一样的团队）来完成，（假设是A团队和B团队）A团队用传统的软件开发方法，B团队采用敏捷软件开发方法。那么由A团队来完成该项目，可能是3个月；B团队来完成该项目可能是3个月，或者更长。（这里忽略需求变更，人员变动等各种变数）这样看来敏捷软件开发并没有加速软件开发过程。那为什么那么多人说敏捷就是快，到底快在哪儿了？

敏捷的本质是反馈快！

我们还用上述的例子，如果是采用了传统软件开发方式，最终用户什么时间第一次看到我们开发出来的软件呢，基本上就是3个月后。而如果是采用了敏捷软件开发方法，最终用户最早可能是2周后（假设迭代周期是2周）就看到了软件。在用户看到软件并真正使用之后，他极有可能提出更多的反馈意见，也可能在使用过程中暴露出不同的问题。这些都是非常好的反馈，为后续迭代提供了方向（将会放入到产品待办列表中）。

除了反馈快，敏捷还有另外一个非常大的好处就是拥抱变化。在传统软件开发中，需求变化是非常难的（这里就不展开，想要了解的同学可以自行百度查询）。而在敏捷软件开发中，如果有需求变化了，直接就可以体现在产品待办列表中。唯一一点要求是不能改变当前迭代正在进行的工作！

如果您对本文有不同观点，欢迎和我微信交流：

如果您想要了解Scrum入门资料，可以点这里；如果您需要敏捷培训，可以参考这里。

为什么是Scrum书籍推荐

说一下为什么这里推荐Scrum书籍推荐而不推荐敏捷书籍。因为采用敏捷方法当中，有95%的人实际采用的是Scrum框架。这也就是说，很多人都在说敏捷，其实就是特指Scrum框架。（信息来源是2015年ScrumAlliance发布的Scrum状态报告）见下图：

Scrum书籍必读

入门必读

首当其冲推荐给大家的是《Scrum指南》（共14页，中文）。《Scrum指南》是Scrum的发起人Jeff Sutherland和Ken Schawaber共同撰写的，最后更新于2013年7月。下载链接如下（免费）

https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CN.pdf#zoom=100

实践必读

实践必读推荐两本很经典的读物：《Scrum简章》（免费）和《硝烟中的Scrum和XP》（免费）

下载链接：

《Scrum简章》 - https://scrumprimer.org/zh-cn/

《硝烟中的Scrum和XP》 - https://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches

英文第二版链接 - https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2

高级必读

如果了解完Scrum的理论和实践后，还想更深入的了解Scrum。那么这本书你绝对不要错过 - 《Scrum精髓》。书如其名，本书介绍了Scrum中的核心内容。

Scrum精髓书籍封面：Kenneth Rubin著敏捷转型指南经典著作

如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。作为业内领先的敏捷教练和培训师，Kenneth Rubin用通俗易懂的语言和丰富的实例与我们分享他十多年的实践经验，诠释Scrum的价值观、原则和实践，描述一些灵活、可行的方法帮助我们用好Scrum。针对Scrum新手和达人，本书从团队、产品和产品组合这三个层面来介绍、澄清和深化Scrum的相关原则和应用。Rubin曾帮助数百个组织成功应用Scrum，积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶，本书图文并茂，通过通俗易懂的描述和两百多幅图对Scrum进行了阐述，这些图采用的是一种全新的视觉图标语言，用于描述Scrum的角色、工件和活动。《Scrum精髓：敏捷转型指南》可以帮助团队成员、经理和执行主管了解Scrum常识，掌握可以拿来即用的通用词汇表，充分攫取Scrum的潜力，最终实现优秀团队能够做到持续、稳健发展的目标。

推荐敏捷教练书籍

敏捷教练

如何构建敏捷项目管理团队 : ScrumMaster、敏捷教练与项目经理的实用指南

敏捷软件开发 : 原则、模式与实践

推荐软件工程实践书籍

重构：改善既有代码的设计

解析极限编程 : 拥抱变化

代码整洁之道:程序员的职业素养

推荐Scrum书籍

Scrum指南

Scrum精髓

Scrum敏捷软件开发

物以类聚 - Scrum特性团队之社区

参考资料

思考

每日问题

版权声明

关于作者

Think BIG, act small

交付还是交代

什么是交付

我们要选择交付还是交代

关于Bob Jiang

Scrum 官方权威指南

Scrum 指南的目的

Scrum 的定义

Scrum 的应用

Scrum

Scrum的起源

Scrum的本质

看板方法

看板方法的起源

看板方法的本质

Scrum和看板方法的对比

适合场景

课后思考题

为什么是Scrum书籍推荐

Scrum书籍必读

入门必读

实践必读

高级必读