Bob Jiang 敏捷开发培训敏捷认证Scrum Master

简介

作者: 【加】马尔科姆•格拉德威尔（Malcolm Gladwell）出版社: 中信出版社副标题: 如何引发流行译者: 钱清 / 覃爱冬出版年: 2014-4 页数: 288 定价: 36.00元装帧: 精装丛书: 格拉德威尔经典系列 ISBN: 9787508635736

《引爆点-如何引发流行》这本书中的核心观点：流行的三法则（即引爆观点）

个别人物法则
附着力因素法则
环境威力法则

我对于书中的观点进行了精炼，流行的三要素是：人、信息和环境。请参考下面的思维导图：

个别人物法则（人）（Law of the Few）

在人这个层面，作者把观点的传播者分为三类：

联络员
内行
推销员

联络员（Connector）

联络员是那种有着极广人脉的人，他们几乎和所有人都认识，并且是许多不同领域的。书中的例子是保罗*里维尔，是他把英国人要开战的消息传到了波士顿的北部，使民兵有了准备从而打响了美国的独立战争。

书中继续提到了2个概念：六度空间和微弱关系。六度空间指的是你和世界上的任何一个人只需要通过6个人就可以互相认识。（注：随着互联网的发达，六度空间慢慢变成了五度空间）微弱关系，书中的例子是找工作。大部分人找工作是通过这种微弱关系（只听说过某人，就可以获得一次面试机会并有可能入职）。

内行（Maven）

内行指的是对某一领域非常精通，发表的观点非常有说服力。虽然看起来内行不如联络员认识的人多，但是内行的影响力是一流的。因为他们对于你的产品，或者消息，了解的非常透彻。想一下，你在买车或者买房的时候，有没有受到旁边同事的影响？有可能他们就是你身边的内行。

推销员（Salesman）

推销员是极具感染力的，可以用任何方式说服你来购买（或相信某事）的那些人。这个是需要有天赋的。书中采访了一名推销高手-汤姆*高，他的特点是说话抑扬顿挫，喜欢为客户着想，有朝气、热情、魅力、可爱。认为“世界上没有不可能的事情”，并愿意去尝试。

附着力因素法则(Stickiness Factor)

想要信息得到推广，信息本身需要有包装或者叫做易于传播。比如书中给出“直销员旺德曼的金盒子”这个例子，就是设计一个对于客户的触发器，让客户看到信息后可以采取行动。这个可以设计到课程当中去。（后续采取行动）后面的《芝麻街》和《蓝狗线索》也是差不多的例子，通过反复的实验，找出最适合小朋友的电视节目。

环境威力法则（Power of Context）

书中提到两个重要的事情：破窗理论和邓巴数字。

游戏目标

这个游戏的目的是让“开发团队”根据“需求团队”写的书面需求文档创建一幅图形。

游戏步骤

每组对半分成2个小组。一半是“开发团队”，另一半是“需求团队”。最好是2个小组能地理上分开。比如一个小组在屋外，另一个在屋内。（注意：分组的时候可以让原来写需求的人做开发，而不写需求的人来写需求）
（开发团队到屋外休息）需求团队留在屋内，给他们展示一幅图形。然后让需求团队在10分钟内根据图形写出需求。
需求写好之后，开发团队进屋，需求团队到屋外休息。（注意：开发团队和需求团队的成员要一一对接，即找到自己的接口人）
开发团队根据写好的需求进行开发，时长10分钟。开发团队如果对于需求有问题，可以给需求团队写邮件沟通（写好之后由引导师送信）。写信的内容只能是文字沟通，不能用图形，数字或者符号。
需求团队和开发团队不能进行口头沟通或者暗示等。
所有的需求必须是以文字形式描述。不能用图形，符号或数字。
需求文档要求尽可能的详细。
开发团队完成后，大家一起评审结果。

原文：https://www.bigvisible.com/2010/11/spec-writing-game/

游戏中用到的图形可以参考附件： Specification Exercise_oppgaveomkravformidling1

这个游戏一共分两轮

第一轮

两人结对
一人是老板，另一人是走路人
老板负责给出指令：走，停，左，右，快，慢
走路人必须遵守老板的命令
老板负责保证走路人在60秒内完成60步
走路人负责数步子
老板可以命令走路人，但不能有身体接触，也不能帮忙
不能站在原地，必须结对行动
必须在房间内

第二轮

老板也要参与到走路的过程，即老板也变成走路人
走路人自己负责找出如何走60步
限定时间30秒
其他规则同第一轮

总结

这个是一个非常简短而有力的游戏，快速地体会命令控制和自组织团队的差别。总结的时候可以结合Richard Hackman写的《Leading Teams》里面授权矩阵，介绍自组织（自管理）团队的职责，以及自指导和自统治团队是什么样子的。

这个游戏一共分两轮

第一轮

两人结对
一人是老板，另一人是走路人
老板负责给出指令：走，停，左，右，快，慢
走路人必须遵守老板的命令
老板负责保证走路人在60秒内完成60步
走路人负责数步子
老板可以命令走路人，但不能有身体接触，也不能帮忙
不能站在原地，必须结对行动
必须在房间内

第二轮

老板也要参与到走路的过程，即老板也变成走路人
走路人自己负责找出如何走60步
限定时间30秒
其他规则同第一轮

总结

作者: 马尔科姆•格拉德威尔出版社: 中信出版社副标题: 不一样的成功启示录译者: 苗飞出版年: 2014-5-1 页数: 264 定价: 36.00元装帧: 精装丛书: 格拉德威尔经典系列 ISBN: 9787508643946

昨天花了一天的时间看完了《异类》这本书，有不少收获。总结一下：

书中把成功人士归类为异类，因为他们与众不同。而这些成功人士都是天时地利人和的环境下产生的。

天时

书中开篇提到的是加拿大冰球队球员的出生月份，80%的球员都是1,2,3月出生的。而原因是球队的注册日期是每年的1月1日，也就是说1月1日出生的孩子，在达到年龄后（且成绩合格的话）可以入选球队，而他比同龄但12月出生的孩子几乎大了整整1岁。在10岁以下12个月的时间对于生理心理都会有极大的影响。

我的反思：出生日期不在范围内的孩子，由于无法入选而错过了优秀教练和环境，因此在接下来的10年内也会缺乏10000小时的不断练习，从而错过了成为异类的机会。那么如果我的孩子很喜欢某项运动，我会想尽一切办法让他去最优秀的环境去。（参考作者的后记：故事来自牙买加）

地利

本书中还从地理位置来解释为什么有哈伦小镇这样的世仇，为什么中国的稻田文化有利于数学。地域文化对于一个人的影响非常大。书中一开篇在引言中就提到罗塞托之谜，以及现在硅谷中的大部分财富掌握在犹太人手中。这些事实都说明了一个良好的地域文化对于成功太重要了。针对这点，我能做什么呢？思索中，暂时还没有答案。

人和

人和，指的就是与人打交道（或者说公关）能力。不论碰到什么事情，都可以大事化小，小事化无。

最后，从这本书中，总结最大收获的两点是：

10000小时刻苦练习。在教育儿子方面，第一步陪他一起找到兴趣，第二步就是提供足够好的优良的环境，来进行10000小时练习。
情商。在中国有句古话说，“女儿富养，儿子穷养。”而这本书的理念是不论女儿儿子都要富养，带他参加各种活动，让他从小就明白这个社会的规则是什么，如何利用社会规则为自己争取到利益。

在前一篇敏捷估算中，介绍了估算的最最重要的目的是达成共识。而实际上我们除了这个最重要的目标，还需要根据需求的规模（估算值）和价值来进行产品列表的排序。

下面介绍一种快速有效的方式，可以在短时间内把大量的需求进行估算并排好顺序。这种方法基于前一篇敏捷估算中的第二种方法 – 即三角估算法而改编的。

这种方法一共分为两大步：

估算需求规模
估算需求价值

整个过程需要由产品负责人来协调和做准备工作。这两步可以分别邀请不同的参会者，第一步需要开发团队的参与，而第二步需要客户的参与。

0. 准备工作

首先需要有一面足够宽的干净的墙
把所有的需求提前打印好，或者抄写在报事贴上
报事贴
记号笔

1. 估算需求规模

第一步，估算需求规模需要邀请开发团队参与。需求的规模用故事点来描述。具体的操作方法可以参考敏捷估算中三角估算法。最后的结果是所有的需求从左到右排成一条线，左边是最小的，右边是最大的。如下图：

2. 估算需求价值

第二步估算价值的时候，需要邀请客户来参与。要先对客户解释这面墙的作用，客户只需要根据每个需求的价值来上下移动卡片，最上面是价值最大的，最下面是价值最小的。如下图：

最后的结果

最终，所有的需求可以分成四个象限。左上角，较小的且价值很高的需求，需要马上去实现。右上角，较大的而价值很高的需求，需要考虑需求拆分。左下角，较小但价值很小的需求，可能会随着时间的推移而忽略掉。右下角，较大且价值很小的需求，随着时间推移，需要不断优化提炼以发现其中的价值。或许会移除掉，或许会随着价值变化而改变顺序。

前言：本文主要从软件开发的架构设计根源、以及敏捷软件开发中如何做架构设计两个方面来进行阐述。

架构设计的根源

架构一词来源于建筑业，指的是“一个结构内的元素及元素间关系的一种主观映射的产物”。而软件开发是一个新兴产业，在高速发展的同时也在学习借鉴其他行业经验。架构就是软件开发学习建筑业的产物。这个学习（或参考、或借鉴）是完全错误的，软件开发和盖楼是完全不同的两件事情。软件开发是脑力工作（知识工作），是一件复杂的事情。而盖楼是体力工作，是一件繁杂的事情。如果说要和建筑业进行学习借鉴的话，软件开发的过程和设计建筑蓝图（blueprint）是具有相似之处的。因此为了更好的响应变化，软件开发不适合采用整体预先的架构设计。

软件开发是一个持续学习、不断反馈的过程。

软件开发的目的是为了产生可工作的软件，是为了解决一些人的问题。而这些问题是来自一个人的头脑中，如果想要知道一个人是怎么想的，就必须要持续沟通（学习），不断地和这个人进行反馈。这才是软件开发的本质。

敏捷软件开发中的架构设计

与软件社区的某些讨论相比，敏捷开发并非要求像船货崇拜那样热衷于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系列：

会议中

说几个聚会当中，我印象最深刻的人和事吧。

侯伯薇

我最需要感谢的人是侯伯薇！在14日上午开场的时候，面对60人的大场面，我hold不住啦，不知道如何能让大家静下来。就在这个时候侯伯薇站出来了（黄继光炸碉堡~~）！全天的过程当中，他很好地帮忙维持秩序，整个聚会有效的推进并圆满结束。

反思：开场时我尝试用铃铛让大家安静，但声音是此起彼伏，慢慢的大家对于铃声免疫了。后来侯伯薇做了什么呢，为什么他打铃就能够安静下来？他走到说话的人面前，打铃，“请安静”（说话）；然后走到下一个说话的人面前，重复上面的动作，打铃，“请安静”（说话）。很快全场就安静下来了。

张林

听张林聊天是一种享受！尤其是这次听到一个全新的角度看待互联网（信息时代）的故事。在信息时代之前，也就是没有互联网的时候，人与人之间是物理连接，是有空间感的。随着信息时代的到来，比如2000年左右，很多公司有了自己的网站。这就像物理时代，一个公司开业挂牌了。慢慢的，有了个人博客。这个好比物理时代，每个人有个身份证（或者门牌号）。继续深入挖掘，大家最痛恨中国互联网的是什么？（我猜有许多人会说GFW吧）这个对应到物理时代是什么呢？（我想到的清朝末年闭关锁国。。。）好了，不多说了，慢慢体会吧。

滕振宇

滕振宇是我的偶像！虽然这次聚会上没有很多交流，针对14日上午我的引导过程，他给出了很明确的反馈。在制定聚会基本规则（Ground Rule）的时候，我引导大家说出规则。结果是，当听到铃声时，“听Bob说话”。而当时我的回馈是，“这不是我想要的规则。。。” （太典型的反面案例了~）规则是谁的？滕振宇给我如上的反馈。是啊，看了这么多引导的书，也练习过很多，犯了这个错误实属不应该。

反思1：在说“这不是我想要的规则”时，我是带着情绪的。因为之前大概5分钟，我都无法控制场面，有些气馁。后来想了一下，大家的反馈“听Bob说话”是有开玩笑的意思的，我完全可以顺着这个方向，把规则明确细化，并和大家确认。比如，– 看来大家还想听我说话的，谢谢大家！那么我们在听到铃声后，马上举起双手，停止说话，看着说话的人，并听Bob说话。这个是大家刚才说的规则吗？（得到反馈后）那么有谁对这个规则有疑问吗？（如果没有疑问，可以把规则写在白板纸上）

反思2：针对白板纸，或者说可视化这个事情上，我是可以改进的。1. 上面提到规则可以写到白板纸上，这样每个人都能看到并提醒大家。2. 日程安排可以提前准备好，并写到白板纸上。即使是错误的也没关系，让参会者知道整个会议的框架是必须要做的。

文开琪

文开琪是我心目中的大人物！自从我参加敏捷社区活动，就听说过文老师，并且最近几年文老师一直是默默的支持着社区活动！图书赞助敏捷之旅、精创周末、ScrumGathering等活动。后来也很有幸能和文老师一起合作翻译《Scrum精髓》这本书。这次聚会上，文老师也给了我很多启示。这么多年的中国敏捷社区，都是吸收国外的优秀经验，照搬国外的好东西。中国敏捷社区有没有自己的一些内容可以出版呢？

会议后

其实我是个懒人，这次聚会之后我也没有想到要总结的。不过看到了Kelvin同学的总结激起了我想写点东西的欲望。

谢谢Daniel的转发，谢谢Kelvin同学的文章。是你们让我“不要脸”的分享我的一些体会~~

一个产品找到了自己的主淫，不论你新加入了一个小创业公司，还是你在大公司中发起一个新的项目，头30天决定你的成败。

如何在第一个月内找到入口，请参考以下建议。重点在于团队、产品、自己：

People团队

与你的老板达成一致的、明确的目标。

一个萝卜一个坑儿，你的身上已经背负了要立刻向组织作出贡献的压力。回顾你与老板的共同目标，确保他对你的期望值不偏不离不高不低。你第一个月的任务就是要真正的融入一个团队。

和团队的每个成员来次一对一的谈话。

短则几小时，长达一个月，根据团队的大小而定。但一定要抽出时间和每个人单独约见。

我更喜欢俩俩单独散步——当两个人走在一起的时候，我们共同“向前望去、展望未来”而不是在会议室桌子的两头盯着对方。这本身就是鼓舞振奋的。

询问每个人“我能为你做点什么吗？”

你在这是为了帮助大家，而不是命令大家。他们的答案可以真实地反映他们如何看待产品经理这个角色，以及他们需要你做什么。

为其他组员做些什么

期望你能从谈话中找到一些可以让你立刻上手并有效提高团队工作效率的事情。也许工程师想让你把BUG分类，或每周帮大家去超市采购。

Product 产品

与你的首席工程师约时间，非常详细的过一遍产品的技术架构

不耻下问，但也没必要太纠结于没意义的小细节。

产品经理总是想以自己敏锐的技术嗅觉给工程师们留下深刻的印象。但以我的个人经历，能够提出问题并说出自己哪里不明白的产品经理更受工程师欢迎。

刚入职，低调、低调

你想要开始改进产品或开发流程。我建议你先缓缓。

在你真正奠定了自己的地位、得到认可、了解所有细节之后，你的建议才更容易被接纳。现在你也可以证明你是一个很好地倾听者。

靠近用户

在你刚入职的初期，好好花点时间与你的用户多多交流。做些电话销售以及客户访谈。找找用户需要怎样的支持服务。多和用户在论坛、微博、微信平台上进行交流。

搞点技术呗

我坚信产品经理应该是技术型人才，并且一个绝佳的切入点应该是自己搞定一个BUG或为产品“锦上添花”一个新特性。

建立一个开发的氛围，争取做一些力所能及的小事。但同时要考虑好自己以及团队的时间安排。归根结底你是产品经理而不是全职开发。

Personal 个人管理

读，甚至自己写

读任何可以让你对业务上手的东西——以前的绩效考核、说明书、设计文档、百度百科。当你发现文档缺失或失效时，自己来写。花时间把你已经学到的以及未来可以改进的东西写下来，为你的下一份工作累计经验。

制定个人目标

换工作可以让你感到有些自豪，但又有些无能为力。现在有机会让你就个人发展制定一些目标。简单说两句：

有没有一件你做的非常好的事，并且你愿意继续做？你要如何养成做这件事的好习惯？
有没有一件事你需要改进？你将如何改进，并且你如何最自己的改进过程进行评估？

欲做其事，必善其后。

备好所有工具、设备。装好所需软件。设置邮件过滤系统。接收各种关于你的产品以及竞争对手产品的新闻推送。

玩好！

原文链接：https://www.gv.com/lib/12-things-product-managers-should-do-in-their-first-30-days-at-a-new-company

感谢我的同事彭晓溪进行翻译~