scrum

推荐Scrum书籍 直接上干货，推荐书籍清单如下（推荐有顺序的哦） Scrum指南 Scrum精髓 Scrum敏捷软件开发 Scrum捷径 硝烟中的Scrum和XP : 我们如何实施Scrum 敏捷软件开发:Scrum实战指南 Scrum要素 大规模Scrum:大规模敏捷组织的设计 用户故事地图 用户故事与敏捷方法 Scrum指南 作者：Ken Schwaber & Jeff Sutherland 出版社：Online 译者：Jiancheng Zhou 链接：https://scrumguides.org/ 内容简介： Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。 Scrum精髓 作者：Kenneth Rubin 出版社：清华大学出版社 译者：姜信宝 / 米全喜 / 左洪斌 / （审校）徐毅 链接：https://item.jd.com/11462889.html 内容简介： > 短短几年时间，Scrum跃升为敏捷首选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书以通俗易懂的语言、条理清晰的脉络阐述和提炼出Scrum的精髓。全书共4部分23章，阐述了七大核心概念：Scrum框架，敏捷原则，冲刺，需求和用户故事，产品列表，估算与速率，技术债；三大角色：产品负责人，ScrumMaster，开发团队以及Scrum团队构成：Scrum规划原则及四大规划活动：多层级规划、产品组合规划、产品规划和长期规划；冲刺四大活动：规划、执行、评审和回顾。 本书取自作者十多年的实践经验，对员工个体和管理层都具有重要的指导和参考意义，可以帮助企业顺利导入Scrum，在动态的商业环境中以积极心态拥抱变化，做出优秀、卓越的产品，走上创业、守业、常青基业的成功之路。 Scrum敏捷软件开发 作者：Mike Cohn 出版社：清华大学出版社 译者：廖靖斌 / 吕梁岳 / 陈争云 / 阳陆育 链接：https://item.

物以类聚 - Scrum特性团队之社区 今天读到 Scrum模式社区 中的一个模式（物以类聚 - Bird of Feathers），觉得很有启发。 公司或组织内，往往是用层级方式（加上组件团队或职能团队）来搭建组织结构。 这个方式非常符合我们的学习方式，即还原论方式。 把一个系统切分成若干个小块，然后认真学习其中的每一块。（西方哲学的基础是还原论[1]） 看一下我们的组织（或公司），是不是也是拆分成很多的小块，然后期望每一块都可以做到极限的效率。 Scrum的重要基础是特性团队（特性团队有两个阶段，后续可以讨论）。据我观察，愿意且能够组成特性团队的公司不超过10%。 原因呢，我猜测是不好管理。试想一下，是把同样技能的人放在一起好管理，还是特性团队好管理。（这里的管理指的是直接可见的效率数字，如KPI等） 而反直觉的特性团队，会给产品开发带来巨大的收益。 比如Spotify的例子，很多人都在研究，如下图： 这个图中的Squad就是特性团队，而Chapter是类似于职能、技能。 需要项目经理看到这个图后，都会跟我讨论是弱矩阵还是强矩阵。 其实这个根本不是矩阵。 只有一个方向 Squad 的负责人是PO（即产品负责人），另 Tribe 会有管理者。Chapter的负责人不是管理者。而不论是Chapter也好，Guild也好，都是某种形式的社区。即同类的人。 对于公司来讲，赚钱（盈利）是首要目的。因此以首要目的来组织人员没有问题。 至于相同技能、兴趣的人，是以非正式的社区形态存在。（如果公司小，可以考虑和外部社区进行关联） 如下图是另外一个呈现的形式： 原文链接 参考资料 [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.

交付还是交代 了解过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 在全球范围内已得到了广泛应用：

自敏捷宣言以来，随着敏捷软件开发方法的普及，很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架（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书籍推荐而不推荐敏捷书籍。因为采用敏捷方法当中，有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的价值观、原则和实践，描述一些灵活、可行的方法帮助我们用好Scrum。 针对Scrum新手和达人，本书从团队、产品和产品组合这三个层面来介绍、澄清和深化Scrum的相关原则和应用。Rubin曾帮助数百个组织成功应用Scrum，积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶，本书图文并茂，通过通俗易懂的描述和两百多幅图对Scrum进行了阐述，这些图采用的是一种全新的视觉图标语言，用于描述Scrum的角色、工件和活动。 《Scrum精髓：敏捷转型指南》可以帮助团队成员、经理和执行主管了解Scrum常识，掌握可以拿来即用的通用词汇表，充分攫取Scrum的潜力，最终实现优秀团队能够做到持续、稳健发展的目标。

本文谈及的均为Scrum中的估算行为，这些方法不是Scrum原创的。 为什么要估算 谈估算，我想先从为什么要做估算谈起。 每次在我的培训课上，学员们会给出各种各样的答案。比如为了估计成本、为了设定发布日期、为了知道什么时候可以做完、为了……。但我认为估算最重要的目的是为了 达成共识 如果没有进行估算，关于需求或任务会有一些假设或者背景被忽略掉。因此在Scrum中，估算是一个集体行为，而不是某个专家拍拍脑袋出来的结果。 如何做估算 估算的方式分为两大类，绝对估算和相对估算。绝对估算耗时更长，并且需要依赖上下文，最后的结果也会产生较大误差。而与之相对，相对估算更快，结果容易达成一致。Scrum中对产品列表（product backlog）的估算常常使用的就是相对估算，估算单位为故事点（没有意义的单位）。【注意：不要将故事点和小时数做一一对应！】最常用的方法就是计划扑克。 计划扑克是由斐波那契数列组成的一串数字扑克，如下图： 对产品列表条目（product backlog item）进行估算的步骤，简单描述如下： 首先估算需要开发团队所有成员参加，每个人手里有一套上图的扑克 取出一个产品列表条目，产品负责人进行描述 每个团队成员根据自己的理解，拿出一张代表估算值的扑克并扣着放在桌面上。（这个过程不要讨论，不要说话，不要把你的结果告诉其他人，具体原因参见百度百科“锚效应”） 所有成员出牌完成后，大家同时亮出自己的结果 接下来邀请估算最小的成员解释一下原因，还要邀请估算最大的成员解释一下原因。讨论过程中注意遵守团队礼节。 解释完毕后，重复步骤3到步骤5，直至最后大家的估算结果一致。 相对估算还有另外一种方法，称为三角估算法。 从产品列表中挑选一个较小但不是最小的条目，比如条目A，并设定它的估算值为3 （故事点） 从产品列表的最上面取出一个条目B，和A进行对比。如果比A大，放在A的右边。如果比A小，放在A的左边。如果和A差不多大小，放在A的下面。 继续从产品列表取出条目C，重复步骤2，分别和条目A与条目B进行比较。直到为条目C找到合适的位置。 重复步骤2和步骤3，直至所有的产品列表条目都完成放置。 比较一下A左边的产品列表条目，估算值为2还是1，把左边的所有条目估算值设置为2或1.同样的把A右边的条目，按列标明估算值。 最后的结果如下图： Scrum系列： Scrum系列之Scrum起源 Scrum系列之Scrum框架 Scrum系列之Scrum角色 Scrum系列之Scrum会议 Scrum系列之Scrum工件 Scrum系列之Scrum需求梳理 Scrum系列之Scrum估算

产品列表梳理会议是Scrum中非常重要，而很容易被忽略的一个会议。说它重要，是因为Scrum开始之前就需要有准备就绪的输入，这个输入就来自于产品列表梳理会议的结果，即初始的产品列表。而对于刚开始转型敏捷的团队，往往会忽略掉产品列表梳理会（需求梳理），从而造成迭代计划会时间过长，或者无法准时开始迭代等等问题。要想解决这个问题，需要首先明确为什么在迭代开始之前要进行梳理会议，以及谁需要参加这个会议，在这个会议都有哪些活动等。 产品列表梳理会议，是迭代就绪的很好的指示，即只有产品列表准备好了，才可以进入迭代。另外，梳理会议是由产品负责人发起或负责，可以召集开发团队参与，也可以只有相关的开发团队成员或相关的利益干系人参与。 产品列表梳理会议的内容可以总结为如下几个字：增删改。首先需要明确一点的是产品列表不是固定不变的，它是可以随着新需求的出现而变化的（即好的产品列表符合DEEP原则，参加博文产品待办列表和用户故事）。 增：那么当出现新需求的时候，就需要增加一条产品列表条目，并且针对新的条目也需要符合良好用户故事的标准（INVEST）。 删：某条需求如果已经不再需要，或者市场条件变化后该需求就可以删除了。 改：产品列表的修改还可以分为以下几类： 重新估算用户故事大小、 重新排用户故事的顺序、 用户故事拆分等。 调整发布计划 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算

Scrum工件主要包含一下3种： 产品Backlog Sprint Backlog 产品增量 产品Backlog 在Scrum中，主要由产品负责人[参见Scrum入门基础系列之Scrum角色]整理和维护产品Backlog。产品Backlog是Scrum中维护需求的主要工件，也是做好Scrum的第一步。一个好的产品Backlog，是要符合DEEP原则的，即，产品Backlog是详略得当的（Detailed Appropriate），涌现的（Emergent），估算的（Estimated）和排序的（Prioritised）。详情参考参考之前我发的博文“产品Backlog和用户故事的原则”。 一般来讲，产品Backlog里面都可能包含哪些内容呢？新特性、改进项、缺陷修复、文档需求等。 Sprint Backlog Sprint Backlog主要由挑选的当前Sprint要完成的产品Backlog条目，以及根据这些条目进行拆分后的任务组成的，在Sprint Backlog中还有一个很重要的东西就是当前Sprint的目标，团队根据这个目标以及产品Backlog的排序来进行挑选。 Sprint Backlog的内容是由团队来决定的，具体的工作方法和实现方式，也是团队自己来决定的。在这一点上，充分体现了团队的自组织能力。 产品增量 产品增量是Scrum中非常重要的工件，因为产品增量才是最终交付给客户的内容。因此每个Sprint团队必须交付产品增量，以符合如下原则： 交付的产品增量必须是高质量的。也就是说每个产品增量是潜在可以发布的。 交付的产品增量符合团队的完成定义（Definition of Done） 产品负责人（或客户）能够接受产品增量 另外，产品增量也是团队进展的一个标识。开发团队通过不断地交付产品增量，给团队本身和利益相干人以信心，促使产品最终发布。团队进展还有其他常用的标识是燃尽图和任务板。一般使用燃尽图和任务板时，是为了使当前的进度公开给更多的其他团队或干系人。 完成定义，指的是当产品增量完成的时候，必须是团队成员共同理解的完成，而不会出现歧义。并且产品增量需要是高质量的，潜在可以发布的。也就是说，当产品负责人要发布当前的产品增量的时候，马上可以发布出去。完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。还有，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成定义中。 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算