前言

为了写这篇文章，把无敌哥的视频《打通任脉的影响地图》又看了一遍，敏捷无敌的书里也有专门一个 章节来介绍。看视频的时候，居然很多内容都没什么印象了，可见我的忘性是有多大。赶紧把这两天的学习心得记录下来，省的又忘记了。

从为什么开始（Why）

测试小T走到开发小D身边，对小D说，这个功能逻辑有点怪，为什么要这么实现呢？小D眼睛一翻，我只负责实现，至于为什么，你得去问设计。

如何您碰巧也是一位测试，或者项目经理，这样的场景是否很熟悉呢？开发人员只关心how，对于why，很少去想。甚至，他自己也觉得这功能逻辑有点怪，但还是会继续去做。这难道就是现实版的“南辕北辙”？

也曾经和开发聊过，为什么开发都不怎么关心业务？得到的回答是，IT技术更新迭代太快了，而且分工越来越细，每个细分领域都有很多技能要学习。我们开发，都想把精力放在技术的打磨上，没有太多的精力和兴趣去了解业务，再说，不是还有产品经理吗。

听上去也没毛病！只是，让我想起了一句话“每个人都觉得自己做的很好，但最终结果却是一团糟”。给大家举个例子。

在20世纪80年代，美国制造受到了德国和日本的巨大冲击，尤其是在汽车制造行业，德国和日本的汽车以更优的质量和较好的舒适度迅速占领了美国市场。令美国厂商百思不得其解的是，美国在生产技术、装备、设计和工艺方面并不比德国和日本差，在汽车制造领域积累的时间甚至超过他们，但是为什么美国汽车的质量和精度就是赶不上人家？

在那个时候，质量管理已经汽车制造领域十分普及了。光学测量被应用在产品线上以后，在零部件生产和车身装配的各个工序已积累大量的测量数据。但问题是，即便测量十分精准，在各个工序和零部件生产和车身装配都进行严格的质量控制，但是在组装完毕后依然有较大的误差。于是美国的汽车厂商不得不花大量时间反复修改和匹配工艺参数，最终的质量却依然不稳定，时常出现每一个工序都在质量控制范围内，但最终的产品质量依然不能达标。

可见,工业制造早已经告诉我们,单个阶段的最优化,并不代表整体最优。业务与开发之间的隔阂，怎么破？如何预防“南辕北辙”？

干系人（Who）

目标定好了，可以通过谁的行为来达成这个目标呢？很显然，需要业务和开发自身去改变行为，其他干系人一起协同，比如Scrum Master。

影响（How）

干系人的行为应如何来改变？如何帮助我们达成目标？

交付物（What）

需要做什么来支持影响的实现，也就是说需要交付什么功能，才能影响干系人去行动，从而实现最初定义的目标。

图中列出的What，都已经包含在了影响地图中，这个deliverable已经是现成的，直接拿来用就可以。

总结

本文采用影响地图的模式，来解释为什么需要影响地图。这个例子只能让大家对影响地图的四个关键字（why，who，how，what）有个基本的了解。严格的讲，图中列的how和what是不完整的。影响地图里很重要的一点就是“永远不要执行完影响地图中的所有What”，因为所有的东西，都是基于假设，只要找出最短路径，然后去快速验证。等验证完了，前面的某些假设，可能已经失效了。所以每验证一次，就要重新评估每个假设，然后开始新一轮验证。

MoMoKo模型，业务敏捷三级跳

全景图

Backlog是Agile和Scrum里一个关键的制品，分为产品和迭代两个层级。

产品级backlog就是项目的代办列表，也叫需求池。项目范围内的所有事项，无论颗粒度如何，都归入产品backlog，经过排序——意味着排名第1的比第5的重要，同样，第5位的比第23位的重要。事项顺序通常是由商业价值驱动，由PO和开发团队一起协商，最终由PO决定。

项目范围通过用户故事的方式来记录，会随着后续的需求探索而变化。产品backlog由PO负责，并持续更新。

产品backlog是迭代backlog的来源。如果说产品backlog代表项目的需求池，那么迭代backlog 就是针对下一个迭代约定的范围，也代表着开发团队的交付承诺。

一旦大家认同并作出了承诺，迭代backlog通常不会再改变，以保证开发团队能够兑现诺言。

开发团队按迭代backlog从上到下的顺序开发（从最重要到不太重要），如果工作提前完成了，就从产品backlog的最上面依次取出额外的代办事项，放到当前的迭代中。

如果事项在迭代结束前没有完成，就放回到产品backlog中，在下一个迭代计划会中重新考虑。

新发现的需求以用户故事的方式加到产品backlog中，在未来的迭代中考虑。

定义“已准备”（DoR） vs 定义“已完成”（DoD）

一个迭代是固定时间的循环，依次把迭代backlog上高优先级的任务变成产品增量。但是，要把事项顺利拉到当前的迭代中，如何定义用户故事“已经准备好”是很重要的——把没有完成或没有细化的用户故事放到迭代中，会在开发阶段产生问题，因为它遵循一个古老的原则：“进去的是垃圾，出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发，他们不太可能产出高质量的代码。

一个“准备好”的backlog事项应该是清晰的，可行的，可测试的：

1. “清晰的”意味着所有的scum团队成员对该条目达成了共识。通过协同编写用户故事，对高优先级事项添加验收标准，有利于需求的澄清。
2. “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。
3. “可行的”意味着根据DoD，该条目能够在一个迭代中完成。否则，条目需要进一步的分解。

简单的讲，DoR定义了一些标准，用户故事在开始估算或者进入迭代前，必须先符合这些标准。

“DoR”关注用户故事级别的特性，“DoD”的关注点则在迭代或者发布层面。本质上，“DoD”代表着迭代或者发布的验收标准。它清楚的列出了为完成产品增量，开发团队必须要达到的要求。

“DoD”是开发团队和PO对每个用户故事需要做什么的协定 - 通常在公司层面统一标准，以保证交付质量一致。

“DoD”通常会说明：

1. 用户故事所处的系统环境（哪个版本的Linux，Android，iOS或者浏览器）？
2. 需要输出什么样的文档（自动生成的javadoc，还是完整的终端用户手册）？
3. 有什么质量要求（用于演示的基本功能，还是一个功能完整，健壮的app）？
4. 有什么安全要求（无安全要求，还是从代码评审，代码扫描到网络安全配置等各方面都要求做安全审查）？
5. 有什么扩展性要求（10个并发，还是10万个并发）？

本质上说，“DoD”是基于验收标准的协议，PO在迭代结束时同它来验收产品增量。

请注意，针对迭代和发布阶段，DoD标准可能会不一样。中间迭代的DoD，比起临近发布的几个迭代，要求不会那么严格。

DoR的一些例子：

• 用户故事是清晰的
• 用户故事是可测试的
• 用户故事是可行的
• 用户故事已定义
• 用户故事验收标准已定义
• 用户故事依赖已明确
• 用户故事已由开发团队做过粒度划分
• Scrum团队已接受UI原型设计
• 指定场景下的性能指标已明确
• 指定场景下的可扩展性指标已明确
• 指定场景下的安全指标已明确
• 验收用户故事的人已明确
• 团队都清楚用户故事所表达的意思

DoD的一些例子：

• 代码已完成（所有代办事项已经完成编码）
• 代码已注释，已提交。版本库当前版本能正常运行
• 结对检视已完成（或者采用结对编程），代码符合开发标准
• 构建没有错误
• 单元测试全部通过
• 部署到测试环境并通过系统测试
• 通过UAT（用户验收测试）并签字确认符合需求。
• 任何编译/部署/配置变化都已实现/记录/沟通。
• 相关文档/图表已完成或已更新
• 任务剩余的小时数已设置为0，任务已关闭

DoR和DoD另外的用法

DoR和DoD的本意是创建一份简明的文档，用于在项目干系人，PO和开发团队间达成一致。但是，随着越来越多的工作被外包或分包， DoR和DoD也更多的用于合同协议和SOW，用以清楚、准确阐述对于需完成工作的期望。

DoR和DoD是很实用的项目范围商议工具，因为它们定义了期望和双方的职责； DoR帮助客户产出良好的用户故事，为开发团队所用， DoD帮助交付伙伴根据整体项目需求产出可工作的产品增量，而不仅仅是特定的用户故事功能。

小结

DoR和DoD就像流水线上的两道关，一个管进，一个管出。我们不像牛那么厉害，吃的是草，挤出的是奶。两道关把好了，质量再不达标，团队就没有借口可找，只能从自身找原因，去持续改善。

工厂参观随想

最近在做工业互联网相关的项目，其中一个MES项目，客户是东阳的。快验收了，要去现场看看项目情况，同时也和客户沟通下验收事项。我因为刚进项目组，不太了解情况，就跟着一起去了。

我们一行4人，自驾前往，大约2小时的车程。到了之后，大家分头行动，我和PM就去车间了解下具体的生产过程。这种大型的流水线工厂，我还是第一次去。我们从原料车间开始，到加工车间，烘拷间，最后到装箱间。相比我们的工作环境，工厂的条件算是比较艰苦。特别是烘烤车间，一进去，明显感到热。要是到了夏天，我不知道能在里面呆多久。

半成品慢慢的从产线上出来，工人把它们装到箱子里，然后运送到下一个环节。我站在一边，看着工人不停的把产品从产线上取下，整理好，依次放到箱子里。节奏不快不慢。我脑子里在想，这就是工人的工作现状吗？每天不断的重复同一个动作，虽然工作强度不大，但真的很不容易。换成我，估计撑不了一天，而他们却能年复一年的做下去。

随后我们又去另一车间，那是个无尘车间，进去得穿上专用的衣服，帽子，戴上鞋套，然后把你全身吹一遍。相比前面的车间，这里的环境好多了，但工人干的活还是差不多，把物料从一台机器，搬到下一台。

一家工厂并不能代表什么，但还是让我对制造业有初步的认识，每道工序的自动化程度比较高，工人把需要的物料准备好，剩下的就交给机器了。旁边的屏幕实时展示机器的生产情况，有问题会自动报警。但是工序之间，流程并没有打通，还是靠人工去切换。工人们就在工序的一头一尾，做连通的工作。流水线生产，我还是没看到。

说起流水线，软件行业也一直在强调部署流水线的概念，推崇持续集成，持续交付。软件实施流水线，跟工厂比起来，从成本上说，几乎可以忽略不计。工厂的设备规格都不一样，很难实现流程对接，可能需要更换所有设备。软件则不一样，有大量免费的工具可以使用。实际上，真正把流水线做起来的软件项目比例也很小。

大部分的软件开发还是跟这个工厂一样，交付物在不同的“车间”之间靠人工流转。不同的是，我们坐在宽敞的写字楼，吹着空调。而工人，在低矮的厂房里，嘈杂的机器声中，浑浊的空气里。这一刻，我感到有点羞愧。

回来的路上，SA听说我是刚接触工业互联网这个行业，对我说，可能你的人生观会因此改变。我猜他的意思是工业在我国还是比较薄弱，信息化改造相比其他行业，难度会更大。但我觉得，软件行业的现状和目前的工业其实差不多。精益，流水线，现场改善等都是很棒的工业思想，当我走进工厂的时候，我脑袋里并没有蹦出这些词（我相信其他大部分工厂也类似）。软件也一样，我们天天在谈论各种思想，方法，实践，真正有多少项目是切实在做的？

自由的乐章之Spotify简介

前言

刚刚完成了IDCF DevOps案例研究第四期的活动，活动的宗旨是借假修真。我们小组借的是“Spotify”的假。一个多月的时间里，和9位小伙伴一起共同学习，共同成长，收获颇丰。 同时也要感谢姚老师的倾力指导。姚老师在每周四晚上会有一档节目，叫“冬哥有话说”，感兴趣的小伙伴可以关注。

在这次的案例研究中，我们对spotify的前世今生，来了一次全方位的探索。为了接地气一点，我们甚至把这次研究的主题命名为“spotify之昨天，今天和明天”。借用赵本山老师同名小品的话：我们这是忆过往，看今朝，望将来。不过，随着学习的深入，我们又有了新的创意，最后将主题改为“自由的乐章-Spotify协奏曲”。

我们按照交响乐的编排方式来组织这次分享，将音乐和Devops融为一体。完整的视频和文章请关注公众号“IDCF助手”和“devopshub”，这里先抛砖引玉，展示第一部分的内容：序曲—Spotify简介。

Spotify发展历程

Spotify是一家正版流媒体音乐服务平台，类似于国内的腾讯音乐，网易云音乐。因为版权等各方面原因，spotify没有进入中国大陆市场，普通用户对它了解比较少。

Spotify的Logo很形象，是一个声波的形状，暗含用心聆听的意思。声田是它的中文名。“Spotify is a music garden”，这句标语稍后在企业文化部分会再做解释。

2006年，创始人Daniel和Martin在瑞典成立了Spotify，成立之初，就决定要做正版音乐。但在和唱片公司谈合作中却碰到了不少麻烦。首先是唱片公司对这种新的模式还不接受， 再者因为没有版权，音乐不能上架，用户无法对产品有直观的感受。后来不得已，Daniel放了一些盗版音乐上去，然后到处给人演示，这才渐渐得到唱片公司的认可。2008年Spotify产品在瑞典、法国、英国和西班牙等欧洲国家上线。

2011年，Spotify进入美国市场，在Sean Parker的撮合下，和facebook达成合作。一周之内，月活跃用户就增加了100多万。这位Sean Parker也是个传奇人物，是facebook的首任总裁，后来成为Spotify董事会成员，有兴趣的小伙伴可以上网了解下。

截止2015年1月，Spotify的注册用户超6000万，付费用户达1500万。付费用户与注册用户比例达到了1:4左右，和国内的音乐APP相比，已经相当高了。Spotify的付费用户比还在持续上升，截止2020年2月，总用户数2.71亿，付费用户1.24亿，比例达到了1:2.2。 也就是说，平均2.2个用户中，就有一个付费用户，这转化率是相当惊人的。

2018年4月3日，对spoity来讲，是个历史性的日子。spotify在纽交所上市，Spotify市值一度接近300亿美元。但由于采用直接上市的模式，不发行新股，纽交所当天场面有点冷清。

到2020年底，Spotify预计MAUs将达到3.28-3.48亿，付费用户总数为1.43-1.53亿。

创始人介绍

Daniel，出身音乐世家，会多种乐器，曾想以音乐为生，后来放弃。 除了音乐外，最大的爱好就是编程，14岁就创办了网站，每月有1.5万美元收入。大学上了2个月就辍学了，靠编程和专利赚了200万美元。在spotify之前，曾创办过三家公司。

金句分享：专注和明确，是普通的和真正的好东西之间的差别所在。

解析：通过对Spotify产品一周的试用，我也是感受到了这点，app的界面说不上漂亮，功能也不多。但体验很好，真的让人专注于音乐本身。我曾经把它比作音乐里的Kindle，朴实无华，功能聚焦。

Martin，硅谷创业先锋，05年推动TradeDoubler上市，获益7000万美元。Martin之前曾找过Daniel开发网站，Daniel有一家公司也是卖给了TradeDoubler。两人都已经实现了财富自由，当时处于迷茫期，不知道下一步干什么。整天在一起玩耍，慢慢发现对方是理想的合作伙伴，决定一起做点事，但绝不是为了钱，而是要做点颠覆。这才有了Spotify。

金句分享：一家公司的价值是解决问题的总和。

解析：当你看到了问题背后的价值，就会积极的去面对它，解决它。不经历风雨，怎能见彩虹。

企业文化

公司的企业文化包括三个部分，使命，愿景，价值观。

使命是创始人骨子里的东西，在公司成立之前就要想好的，我成立这家公司到底是为了什么？要解决什么问题？

使命往往在企业有重大利益决定，或者生死关头时发挥关键作用。所以，任何一家成功的企业，肯定都有使命。

Daniel出身音乐世家，对音乐有着特殊的感情，那个时候，全球音乐产业很不景气，从事音乐事业并不能养活自己，音乐人不得不去做兼职。这就是发生在Daniel身边的事。Daniel当时就想利用科技来改变音乐人的现状。

所以Spotify的使命也是反映了创始人创办公司的初心。

如果说使命是一家公司要解决什么问题，那么愿景就是企业将来要变成什么样子，员工能从中得到什么。

愿景有什么作用呢？《瞬变》的作者把愿景描述为“来自未来的明信片”。 愿景必须为未来描绘一幅图，足以激励鼓舞其他人在过程中一起前进。

从Spotify的愿景可以看出，Spotify并不满足于提供一个音乐平台，而是要通过极致的艺术体验，把人联系在一起，建立美好的世界。Spotify把自己比作一个花园，大家可以想象下，自己置身于花园中，阳光明媚，鸟语花香。小孩子在边上嬉戏打闹，你穿着拖鞋，喝着瓶酒，静静的看着这一切。这是一种怎样的体验！这就是Spotify未来想要给予的。

如果说使命和愿景为公司指明了方向， 价值观就是约法三章，是前进道路上具体操作的方式方法。

价值观是创始人和初创团队一起讨论得出的，并且随着公司发展，会不断完善。比如京东的价值观，从2013年“一个中心，四个基本点”文化价值观：客户为先、诚信、团队、创新、激情；到2018年“一体两翼”文化价值观：正道成功、客户为先、只做第一。再到2019年回归初心再启创业征程，京东价值观正式升级为：“客户为先、诚信、协作、感恩、拼搏、担当”。

价值观不是挂在墙上的，是衡量员工的一个标准，要具备考核性。马云曾经说过，文化不是制定出来的，而是考核出来的。员工业绩好，价值观不行，在公司是无法得到晋升的。反过来，价值观很好，但业绩不行，那也是行不通的。

Spotify的五个核心价值：创新，激情，真诚，协作，好玩，在后面大规模敏捷和devops实践章节中，都会有所体现，留给大家自己去体会。

小结

整个活动持续了5周，每周一个迭代。周三同步进度，周六分享上周成果，同时计划下周任务。利用teams作为协作工具，创建wiki页，做到成果共享，进度可见。

按照事先计划，每周大概投入5小时左右的时间，但实际上这个时间远远不够，Spotify相关的资料非常多，这是我们的优势，但是如何选择研究的点，既要抓住spotify的特色，又不能落入俗套。也让我们头疼。

采用“小步舞曲”的节奏，随着研究的不断深入，大家对Spotify越来越了解，整体的框架也慢慢浮现出来。主题的创意，也是源自对Spotify这种组织架构的感悟，加上Spotify又是一家音乐流媒体公司，所以就有了这种“交响乐+devops”的展现形式。

通过对spotify案例的研究，最大收获是结识了9位优秀的小伙伴，大家从互不相识，到最后协同完成交付。虽然离最佳案例差了一步之遥，但我看到了每个人的成长。ppt不断的迭代完善，100页的ppt远远超出了当初的预期。正式分享之前，我们排练了三次，每一次都能体会到小伙伴们明显的进步。 “借假修真”这个目的算是达到了。

关于Spotify更多精彩内容，请关注DevOpsHub公众号，小伙伴们会陆续分享。

okr：每月和am正式沟通，交流。

床、酒吧、浴室与公交车

标题里的四个场所，大家再熟悉不过了，跟我们的生活息息相关。为什么把它们放在一起讨论？它们之间有什么共性的东西呢？

床（Bed）

爱迪生在实验室的角落里，放了一张床，每当有问题困扰，一时找不出答案时，他就会对团队说，我先去睡会。半个小时后，当他醒来时，往往就有了新的解决思路。

埃里克森国际学院院长，世界顶级教练玛丽莲·阿特金森，临睡前会把当前棘手的的问题都过一遍，然后再把它们抛到脑后，安心睡觉。第二天醒来，这些问题似乎也没那么棘手了。

酒吧（Bar）

这里的Bar，不仅仅指酒吧，也代表咖啡吧，茶吧等。几个小伙伴坐在咖啡吧里，边喝咖啡，边闲聊着各种话题，突然，有人抛出了一个点子，另外人马上会给出自己的解决方案，其他人则在他们的基础上继续发挥，不断完善，最后居然可以形成一套完整的方案。一个伟大的产品，或者一个创业公司，往往就是在这种情况下产生的。

浴室（Bathroom）

日本发明家中松义郎，一生发明的东西可与爱迪生匹敌。他发现只有在水中，才能让自己的思维最活跃，为此，他特意挖了一个3米深的游泳池，还发明了一个可以在水里写字的设备。每天呆在水里，一有创意，马上就记录下来。

当然，最经典的还要属阿基米德，居然在泡澡中发现了浮力。

公交车（Bus）

“曾经有一份真挚的感情摆在我面前，我没有珍惜……”，这段对白大家都耳熟能详了。其实原来设计的台词并不是这样的。周星驰在公交车上想到了这段话，顺嘴说了出来。然后成为了经典。

读到这里，大家不难看出，这四个场所的共同之处就是，都是一个能让人放松的场所。20世纪早期的哲学家Ludwig Wittgenstein通过观察发现，在放松的情况下，人们的思考力，创造力和创新力都得到了提高。他指出了三个让人放松的场所：Bed, Bath, Bus，简称3B’s，如今人们又加了一个Bar，成了4B’s。

你可能会问，我每天睡8小时，天天挤公交上班，怎么没有灵感蹦出来，生活照样一团糟呢？问题的关键在于，你只是依赖显意识在解决问题，当遇到瓶颈时，就会焦虑，烦躁。却忘了潜意识能帮你的大忙。

所以，下次挤公交时，虽然人很多，很吵，记得把该死的问题抛给潜意识，然后看看窗外美丽的小花，冰冷的水泥，匆匆的行人。让自己静下来，潜意识就会给你惊喜。

解决复杂问题，靠的是潜意识，而不是显意识。

。他提出了3B（bed，bath，bus）概念，后来人们又加了一个B（Bar）。

细胞壁太厚无法分裂，融化边界，通透。人要成长，也不能裹得太紧 玛丽莲Marilyn Atkinson， 爱迪生，靠睡觉解决复杂问题。

车库文化，咖啡文化 在闲聊中产生创意，在咖啡馆里，人很放松，就会释放出好的想法。

洗澡产生灵感：亚里士多德在泡澡时发现浮力

复杂问题解决靠潜意思，而不是显意识

乔布斯：旅行中的思考

发明最多的日本人中松义郎

脑钛，又称内咖啡，使人放松。

潜意思和显意识相互交流

情感的力量是理性的24倍

网龙网络公司的文化，组织力量。 员工离职，家人第一个反对。

珊瑚礁旁边为啥鱼特别多？

组织粘性

得到品控手册。 得到例会直播。让用户帮你来做改进

海底捞，设立创意奖，一个点子被采纳，奖励50元。 员工自己想不出来，找顾客发现公司问题。

The early 20th-century philosopher Ludwig Wittgenstein is credited with observing that our thinking, creativity, and ability to generate innovative ideas are all enhanced when we’re relaxed. In conjunction with this theory, he reportedly coined the concept of the “Three Bs”—bed, bath, and bus—to give people guidance on how to operate at peak mental capacity.