大家好，欢迎光临思维发条，我是马菲菲。

我是悟空。

还是我，王宇

好，我们今天又聚在一起了，今天我们聊点什么呢？就聊一点。敏捷教练圈子里面大家都非常熟悉的一个概念叫Scrum。 Scrum拼写是Scrum，那么其实我们的听众中有一些咱们不是做软件研发的，所以我就觉得我们可能还是有必要稍微来介绍一下到底什么是Scrum吗？这个问题。

先问问悟空，好了，悟空你能用非常简短的语言给大家介绍一下，你理解中的Scrum是什么？

我就选一个这个角度，我就如何跟我妈解释Scrum是什么，我妈还是做财务的，所以他会用金蝶的软件，我跟他解释的时候， Scrum是软件研发过程之中的一个框架，它也相当于这样一个软件，然后你把这个东西装在你电脑上面，它会给你分一些角色，然后有一些流程，然后有一些日子，你到了这个时间，到了这个日子，你这个人就应该往里面去操作一些东西，然后它就会输出你想要的这样一个结果。

那么从基本的角度来讲的话，它是一套框架，能够把你想要的这个东西给输出出来，如果没有了这个软件应用的框架的话，你可能要达到你想要做的这个事儿，你可能有些含糊，逻辑可能有点不那么顺畅，就是我这么去跟我的家人去这么解释的，对于软件研发来说它的基本的作用，那也想听听菲菲是怎么去解释这个的。

Scrum我还真没有跟不在软件研发的人交流过，我通常还是会简单的把它理解成是一个关于新产品研发协作的框架。

当然框架这个词我觉得也是有必要稍微介绍一下框架，我的理解是它相对于我们理解的就是流程来看的，就是流程你可能有先有后有逻辑上的先后，有持续上的一些要求框架，它更多的就是一个结构，就是什么部分哪一块完成什么，哪一块完成什么。

所以我一般跟大家介绍Scrum的话，我会强调它是一个关于新产品的交付或者研发过程的一个协作上的框架，所以它是多角色之间如何协作的，我一般是这么解释。

当然也想听一下王宇的想法，因为王宇毕竟是专家。

好，不是专家，我现在连一个Scrum证都没有了，因为他得每年交钱你知道吗？我突然就想到了我很久以前的话，拿CSP的证前儿的话，Scrum还没这么多级别的时候，我得去考试，全天津市的话，全中国的话若干个考点对吧？

我得答卷子特别好玩，那天拿CSP的证，现在的CSP的话它分成很细致，当然我反正现在无无所谓，因为我啥事没有，我是一个光圈外面的人的话去讲这个东西，所以我也没有什么太大压力。

如果我去给我母亲去讲什么是scrum的话，我觉得 scrum的话，是一有一些细节要求的一套东西，这套东西的话有一些具体的要求，比如你该配备什么样的角色，你在过程上的话有哪些过程要求，对吧？

你怎么去干事情，他有一些要求的一个东西，这套东西的话它可以加快产品的研发速度，尤其是那种面对了不太确定的市场的情况的研发速度，就这个东西跟盖楼不一样，盖楼的话我们需要非常明确，因为盖错的一点毛病很大的对吧？

我们可以，以什么样的一个进行比较，有点像我们做一个可以去探索性的一个东西，比如说现在的这种疫情情况的话，其实它很多不确定这种不确定的话，就使得我们每走每一步的话都需要更加的精确更加的确定，但是我们从一个中期或者长期角度的话，我们有很多不确定的现象，用这种东西就能应对这样的一个情况，就能产生一个相对可控，或者是让各方有选择的一个结果。

这就是我解释。

好，我们大家也都知道说scrum的官方它也在最近两年内刷新过它的 Scrum的一些基本的概念或者叫手册。那么我觉得我们今天可以先来回述一下，我们当初在最早接触Scrum的时候，是一个什么样的情况？上下文，对吧？比如说悟空你最早接触Scrum的时候，你还记得当初你是怎么理解Scrum的吗？

好，我最早接触Scrum的话是学acp的时候，它是作为其中的一个模块，了解这个东西是什么，我当时见到这个东西我觉得我如获至宝，我说天世界上还存在这么好这么有厉害的一种东西，因为当然当时其实思考问题的时候，我并没有一种模式或者模型或者框架型的这种思考方式，我是觉得以前思考的问题非常的零散，然后都是一些单点的东西，这一下子突然给了我一个框架级的东西，他让我就觉得我想得到的想不到的好像都帮我解决了，而且还告诉了我一些清单式的东西，让我可以去做，做安装。

我拿到这个东西就例如像3355，3个角色，3个工件，5个事件，5个价值观的东西，我就特别兴奋，我就希望马上能够去我的团队里面去找到一些映射，例如说我是产品经理，我是对应什么角色，我开发团队我是对应什么角色，这几个工件到底要留下些什么？这个产品代办列表对吧？

以前我们老是排这个需求这么难受，现在这个待办来了，我们就有机会给他排序，有机会可以把历史堆积的这样的一些研发需求给它逐步的给清理掉，然后做到这种高价值的这样的一个状态。而且非常多的事件对应出来的这种会议，站会，计划会议，回顾会议，终于让我很有节奏很有感觉的能够去，每一周能干点啥，能让我这个人体现我的工作价值，所以当时一开始的时候是感觉捡到宝了，这样的一个状态去用。

然后同时，当时学的时候也会有非常多的老师在自己的耳边说这个东西，他可能会有僵化的可能，然后会有一些上下文的东西，然后要注意自己去使用的一些方式，但奈何不了自己兴奋激动的心情。听君一席话如听一席话之后也就放到耳边去了，就开始快乐的在团队里面去使用这个东西，使用的时候就发现，站会怎么越开越苦闷，怎么好像大家也不是特别爱讲。

优先级顺序排出来了之后，发现业务部门也不是特别的买账，他觉得他就应该给你塞更多的需求，你凭什么就这么多，你就发车了再来。这个里面他要求这一个团队里面，你要达到自组织的这样的一个状态，对吧？然后我们领导一开始听到就觉得很兴奋，是不是我们做了敏捷之后，我们交付的东西就会非常多，非常快，而且老大可以不用管，不用再去管理团队的一些细节，他可以自己每天或者每周每个月过来检视一下，看看你的周报就行了，让他少操心的一个框架。

所以在做的过程之中也是逐渐的发现了这个里面有非常多的地方用起来，不舒适不适合，然后自己也找不到他到底为什么不适合，因为说明书是这么写的，然后自己用的经验很少，所以就觉得是不是自己因为经验太少了，然后理解不到位，然后就一直持续的在用这种方式去做，直到后面真的发现很多东西是他不work，然后才会想要去做一些改变，当然这个里面的这些故事我们可以留到后面，我们继续来深入的去分享一下，这个是我们早期去学矿的时候的一些感慨，从兴奋感动，然后到迷惑迷茫，然后再到他产生了一些动摇，然后再到它这一个本身2020年也发布了一个一些新的版本，去修补了一些他之前去讲到的一些观点上面的漏洞一些问题。

对，你想听听菲菲在学习实况的过程当中是经历了一个什么样的过程？

好，我也来分享一下啊就，我跟你还不太一样，我这应该是多比你工作了几年，我接触scrum的时候，其实我当时已经在软件行业做了有可能有快10年的工作经验了，从我最早做程序员到后面做需求分析，大概做了10年了，所以接触scrum的时候，最早我的认知软件来了需求就做，对吧？

你每个月用户跟你提需求，你就做一批，或者是用户随时给你提，你就随时给他做，我们最早连版本的概念都不强烈的时候，我们就随时做，随时往上上线就好，做完了就发。

那么scrum被导入到当时我们的企业中和我们的团队中的时候，对我影响最大的是它所体现的形式，有了站会的这种机制和形式了，然后也有了一些说要迭代的交付，可能要更快速的去交付，比如说像两周交付这样的概念，所以我当时本身我现在回想我对scrum的理解，就是个站会再加个看板，我们企业里面一般会结合看板再去使用，所以你就会看到早上起来整个我们那种是一个大平层的工作空间，大概有三四百号人，大家就都一一堆的聚在一些白色的板子面前，然后就开始非常热闹的进行一些探讨，大概这个会从可能开到9:30，早上9:00上班开到9:30，大概大家都开完了，就纷纷回到自己的座位上去开，开始进行一日的工作了，所以scrum最早给我的理解给我的概念，一个开会的形式，然后我们工作的东西都放在墙上，其实就是这样，它就会比较好玩。

我说真的没有觉得scrum对于我们研发这一块有什么深入的一些指导性的指导性的一些什么导入或者是革新，我的感受是很浅的。

当然你让我现在讲，我现在回想起来，我肯定会有一些更深入的理解，比如说我最大的疑问就是。当初企业决定要导入scrum的时候，是否有意识的看到了我有一天我这个软件，我不是一个纯交付型的乙方的这种交付型的一个组织，我最终的变革方向是我要去进行产品的软件产品的集合管理，那么我需要提前的在我的人员和组织中去注入一个关于产品管理的模式，对吧？所以我们回到scrum本身来讲，就scrum它本身是一个产品增量的这么一个管理或者叫产品交付的管理，它的核心是围绕产品去构建组织构建协作方式的，对吧？如果我们老程序员都知道我们最早做程序员的话，我们主要还是交付活动，也就是说你不用问这个东西是从哪来的，你只需要按照这个需求去实现就好了。

最多是这个需求实现的设计涉及到一点点业务本身的一些概念。

所以我其实现在让我回想的话，可能其实我最大的疑问就是企业是有意识的导入的，提前做准备的，那么我们当时在导入的时候，我们自然是不知道我们做这些是为了什么，甚至我们看不到价值是什么，对吧？你开个站会难道就比以前的写代码的模式要更高级了吗？其实不知道的，现在看来可能这一切是有原因的，如果我们往后聊，接下来聊是不是也有机会去打开，我们就打开来看一下这块是是一个什么样的上下文。

当然我想也想听一下王宇的看法了，因为王宇你应该是向企业内导入这一些方法的这么一个角度，可能会跟我们有一些不同的理解。

好，我正在刚才你讲的时候，我也在回想我的一个scrum的历史经验，其实我是从其实我接触敏捷的话，其实是从极限编程开始接触的，那下scrum根本就没有任何的感觉，那下是一个强悍的程序员去写代码面向对象，从这种结构上的话如何解决企业问题，更发力推崇尚的是持续集成，崇尚的是结对编程，对吧？

而且极限编程里的话也有概念的话叫interation，就是迭代。

其实也只是从这个角度，我是接触到scrum的相关的概念，到后来的话我加入throughworks，从07年加入throughworks的话，我被告知的话萨多克斯我们自己内部的话去应用，去软件研发的，这里边的话是应用两种东西的合集，一个是scrum，一个是极限编程，但是我们之前在throughworks的时候是弱化scrum的相关词汇的，也就是说我们并不是说ok，我们的迭代的话叫sprint，我们不说sprint，我们就说iteration，我们并不说和daily scrum，the daily scrum去每日站会，我们说的是 standup meeting，对，我们并不是说的是我们有一个计划会议，就比如plan meeting对吧？

我们不说这个词，你们俩猜我们用的是个啥词？

Kick off吗？

Kick off。

也就是说之前用的一个词的话叫kickoff meeting，也就是说我们的迭代踢一脚的会议，也就是说我们每个迭代的话需要踢一脚大家，就会有这样的会议。

当然了现在throughworks，因为我现在的话也有和throughworks一些伙伴的话进行沟通，或者甚至是工作上的配合，现在的话iteration的kickoff meeting的话已经改名了，叫iteration planning，meeting也就是说叫IPM当然了现在的现在的throughworks，整个的一个项目运作方式和我们之前的一个整个的软件研发的运作方式可能还是有不一样的。

但是非常明确的一点的话，是我对scrum的了解或者知道这个词的话，是从throughworks的内部的一些培训的资料，以及我对这些因为好奇对一些东西比较好奇的话，就相关查询，以及后期的社区的一些参与讨论。

因为我是一个我个人认为我是一个社区的比较愿意去惹惹，去愿意沟通，愿意去跟大家分享，也愿意去听到大家分享的这样的一个角色，这也就是在零几年的时候，我也参加了很多这种社区分享，那家社区还并不是很多很少，我坐了火车很远去北京，从天津去北京去参加社区活动。

我的接触scrum的话是以这样的一个接触，但是真正去了解scrum到底是个什么玩意儿，是从我11年离开throughworks到12年的话，是和优普丰的bill的话合作，去专门去培训去讲到底什么是scrum。

我从12年的话到13、14年的话有过一段这段时间的话是非常的intensive的去培训的过程去指导或者培训的过程。因为前的服务的客户很多都是外企，包括思科、赛门铁克、诺基亚，他们的话是使用了这种东西，也就是说我去培训内训以及去指导精力就多了，对这个东西就更加的了解。

大概的上下文，我如果多说一句的话说什么？其实当我真正去讲这个东西的时候，其实我回过头来发现的话，我其实在throughworks自认为我对 scrum这个东西比较了解，其实是有问题的。

其实一些关键点的把持度，当你没有去讲的时候，其实你不知道其中的一些关键点，你只是大概知道这个东西，而且你在用而已，这是我的一个想说的一个我的历史对吧？和我的一个感悟。

好，我们前面大家都讲了讲当初自己是怎么接触scrum的，那么我其实有一个好奇心，咱们今天是为什么一打算要聊一聊scrum了，对吧？其实scrum的话我相信软件研发圈子里大家都是非常了解了，或者说自己认为自己是非常了解的，那么今天为什么我们要聊聊scrum呢？

我觉得很好玩的一点，一方面的话好像每个人都非常清楚知道这个东西到底是什么，就是说但另外一方面的话好像是奠定了很多软件过程方法，包括新产品研发的过程的一些基本的基石，这个东西。

但是好玩的一点是什么呢？这个东西让我想起了很多年之前，我在throughworks的话去做项目，这个项目是什么项目？是一个.net的项目，我们基于office，然后基于office做插件，这种office的插件的话整个过程是非常的痛苦，一方面是office的话本身就已经很强大了，这种强大的话它是，另外一点的话，这个东西它本身的底层的话是不是很稳定的，也就是说它的这种我们需要花很多的时间精力去去解决这底层的一些比如内存泄露相关的这些事情，就造成了我们在往上挪东西的时候，你会发现因为底层并不是很结实，造成了后期的研发过程的话，是非常花了非常大的精力去解决这样的一个问题。

所以同样我觉得scrum的话都好像这个东西不容质疑，对吧？为什么应用起来的话，在我看来很多地方的话有很多非常相对痛苦的一个情况，我觉得的话其实我很好奇，当然了我也是愿意探索到底scrum的有没有这种假设，或者它对应用的话有没有什么东西，就说这种基本假设有没有或者它的一个基础，它这个石头的话它是不是扎的根扎的,比较让我们可以完完全全无忧无虑的话，在它的上面的话跳舞，对吧？

这是我好奇的东西，当然了我没有一个正确答案或者所谓的正确答案。当然我愿意去探讨。

我其实因为我其实有想到就是刚才王宇聊scrum是这个基石，它到底稳不稳定的一个原因，我自己去应用scrum的时候，我一开始会把它当成一个万金油去使用，我觉得就是说软件研发管理只要有一套就够了的这一种，一开始的这一种这种感觉，但是你在用的过程之中，我的观点是他他好像适合的就是需求协作这一块的一个流转，因为你越用你会发现研发人员对更多的形式主义上面的这种会议，或者说是需求上面的一些流转，包括价值方面的一些问题，它并不是特别的关注。

而当你想要用这样一套东西就能够去呈现出，大家只要有了这个东西就能变好，不管是管理，还是加班变少，还是说需求的这一个提出更明确，就能够把软件研发所谓的流程问题和它交付的价值问题都解决的，这个时候你就发现它并不是那么的有效了。

这是我今天第一个觉得它存在假设的地方，其实我认为它就是一个需求协作的框架，你如果希望能够把整个组织里面的价值，还有它实现的流程能够彻底的去打通的话，它还需要一些其他的东西，一些工程方面的一些能力去组合进去，他才能够玩得转。

关于scrum的上下文，我觉得我的理解有一个转折点在哪？应该是最近几年有一次参加 Act的培训，应该是伟丹在介绍的时候有提出来跟我们讲了一下scrum的历史，讲了当年的那一篇那篇文章是吧？叫the new product development game是吧？中文叫什么？新的新产品开发游戏是吧？1986年哈佛商业评论的一篇文章，说这个是一个scrum的起源。

然后伟丹当时我记得咱们act的课前是要求说大家提前把这篇文章阅读一遍的，它其实不长，然后那一次让我意识到就是说scrum它的诞生的根源在于说它是一个产品的就是新产品的活动，所以关键在于产品二字。

也就是说我前面咱们再回顾说每个人接触scrum历史的时候，我就讲到说我们当时没有很强烈的产品研发的这么一个概念，我们不需要做产品级的活动，我们一直做的是交付活动，像一个乙方软件团队的交付活动，所以我们当时的体验是不深刻的。

换言之我认为scrum它有一个非常重要的上下文，如果我这个团队要使用scrum的话，我首先这个团队一定是在做产品的研发活动的或者叫产品的交付活动，如果我们不讲软件组织，我们讲一个就是普通的协作型组织，那么它也是要有产品级的活动的，而不是说它是一个外包组织，对吧？订单生产的状态有点像刚才悟空的感觉，为什么悟空强调就是说要做需求管理对吧？

产品我的理解是我跟你所相能附和的一点，就是因为它本身确实是重构了一下这个产品交付活动应该是怎么去运作，所以它里面有好多关键的概念和这个关键活动都是围绕着定义产品目标，对于这个过程增量过程的检视透明，还有要去改进对吧？

是就重新定义我们的下一个目标是什么，学一门知识，我的观点学一门知识，我们要去读它的历史，因为我们在它诞生的上下文里面可以看到他想要去解决什么问题，很显然scrum在我看来就是要解决产品的交付的，这就是为什么好多纯乙方团队，他没有能力决定自己试试做什么产品的时候，他去用scrum，他用的他只能用一些实践，他用起来很怪异对吗？我的站会开起来没有效率，为什么？因为所有参与站会的人没有权利定义自己的产品，他只能讲讲这个代码昨天写的是啥，有没有bug对吧？有没有一些阻碍。

对我先讲这么多，我看王宇。

对我是想要表达的，我一方面的话去去回馈到悟空，也就是说它之所以是框架，并不是说它跟其他的工程实践，它就不需要工程时间恰恰是因为它叫框架，它是一个framework，它是一个skeleton，它是一个脚手架，它恰恰是需要很多东西的补充，所以它关注的这些东西，它并不是说ok不需要工程实践，他肯定需要工程实践，比如csd的话。开发人员的对吧？他也有认证的。但是我们回到这个东西的关注点，其实我想顺着马菲菲的这种话题，因为我们在讨论的话，它是不是有一些基础的假设，然后这种基础假设哪些地方的话，这时候可能是我们忽略在应用它的，就像吃药的话，我们是不是早中晚对吧？吃药之前要干啥对吧？你不能好我们什么情况的话，你都可以吃这药的话，但是你要注意要越猛的药的话，其实它的禁忌的可能就会越多。

我非常坚信或者是认为的话scrum是试剂猛药，为什么是剂猛药？你会发现的话，它会有清晰的什么是错误的的这样的一个评判。比如说你如果3355用了少一个，它就不叫scrum，但这个东西很多，自称是scrum运行的团队，它他不确定这个东西，他也不知道他用了一个时间，他就说自己在玩scrum或者两三个实践，一个另外的话是什么？

这种基本的上下文，比如刚才马菲菲说的，我顺着马菲菲说的这个东西，它是定一个新的产品开发的东西，它得有产品，很多时候的话在团队中发现的话，这种产品概念是比较弱化的，这种弱化的话直接导致了什么？导致了它的每个迭代迭代的目标感和这种迭代的可庆祝性就没有了。

你没有这种迭代的可庆祝性，对吧？我们干活就是一帮人就是淘沟对吧？拉就是我们挖沟对吧？挖完这个沟再挖那个沟，你说他有什么目标吗？他做成什么大事吗？他没有什么感觉。当这种状态的话，你会发现很多涟漪性的这种团队的，比如自管理，包括自组织这种冲劲，这种他为什么要起叫 Sprint？短跑，对吧？他得有冲的感觉，得有大家这种往一个方向的话去努力的感觉，这种感觉完全就不存在。

反而的话这种对团队的这种要求，比如站会，比如开若干个会，就变成了大家的这种怎么说管理手段就管就变成一种管理手段，就你得执行。

当然了在it圈子很多人的话，在这种管理手段上面的话是缺失的，所以的话他们觉得这个东西的话就是立竿见影，确实有用，是他因为之前他就没什么管理手段，你知道吗？所以去用这个东西它就有很大的效果，这个绝对是没问题的，但是有一些东西，比如说这种推崇这种比较正确的状态，比如说迭代里边的话不能改需求这件事，对吧？

有些这种原则的话就和我们的上下文的话就有一些别扭。

当然了咱并不是说别扭，不是不就不对，因为别扭的话可以让我们思考，对吧？就像scrum，有些人说了你应用scrum的话，你并不一定能得到什么，但是你会思考，会产生更多的思考，我觉得这也很对，但如果是非常片面的僵化去坚持这些原则，反而我个人认为的话是敏捷性的丧失。

我觉得就回到马菲菲的刚才说的第一点是scrum，其实它有一个很强大的假设是什么？是产品，你整个需要做产品，这是第一个假设。第二个假设的话是什么？说这些时间你必须严格执行，严格执行，没有商量的这种执行，这样的话我觉得它是第二个我脑子里觉得它的一个极大的假设。

听王宇刚才讲的时候，他说吃药我就想到了这种抗生素，有的时候你发烧的时候你吃个抗生素确实是立竿见影的这样的一个效果，但你要是吃多了，你就会有这种耐药性，想到我们这个团队里面最早怎么去应用，可能最早最早我去做这个软件研发是15年那个时候创业的时候那时候去做，当然我们是做自己的产品，但我发现这个理念是什么？

我们要做自己做产品，实际上我们做的还是一个交付的工作，为什么？虽然我们有客户，但我们就是想把我们的工作让我们的内部的leader满意就好了，我们也不亲近我们的客户，不不怎么看他们真实的需求是什么，所以其实蛮局限的，进而就产生了。

这个做完了这个事情，你也觉得没有人去用，做完了这个事情也觉得没有什么好值得去庆祝的这样的一个一个状态，自然而然它也就慢了，但是现在我们谈慢更多的是看到它更多涟漪性的就是说，你团队因为缺少了各方各面的这种问题，所以你这一种、成就感、获得感你也就变少了。

悟空我有一个问题想问问你，因为你刚才讲到说你15年接触scrum，你们自己是个创业团队，然后你也是一些关键角色我。我比较好奇的是你能介绍一下说你们当初是怎么想到要选择使用scrum的？因为你们自己有产品，那么你们肯定是选了这个模式的就这个地方能不能介绍一下，我还挺好奇的。。

可能我刚才没有太讲清楚，我最开始15年刚开始创业的时候，其实没有scrum的概念，对，我们自己只是把它当成一个软件研发，当成一个产品在做，但是完全没有建立这样的一个概念，所以前两年做得非常的痛苦，到第三年之后我们已经受不了这种发布和交付的这样的一个节奏了，所以才开始在网上去看就是到底有什么好的方法。

因为你在创业的过程之中，就是说你遇到了问题，你总觉得学一些新东西是非常的费劲的，然后它不好安装或者说不好理解的时候，你就没有办法花很多时间去学，所以产生这个变化的速度也非常的慢，到第三年我们看到这个东西的时候开始跟团队去聊，说其实有这一个scrum的方法或者敏捷的方法，敏捷开发的思路，在这个地方我们团队是不是要学习一下这个东西，往这方面发劲，然后就发现团队对这个东西丝毫不感兴趣，只有你自己。

你说因为当时的痛点是说大家加班多，还是说你们当时作为初创团队，你们觉得自己的产品没办法拿到产品的，结果是哪个地方让你决定了你们要去用scrum？

你讲这几个方面都有，第一个就是我们的发布周期非常的长，因为我们就算做完了，第一个质量和质量问题非常多，第二个老板总是希望他的用户体验能够更好，但更好到什么程度，没有人能够定义这个更好，就是我永远不希望我拿到给客户面前，这个东西是一个不完美的东西，它只要一开始不完美的这个东西就是一个完蛋的东西，所以周期非常长，能发也不发。

第二个东西，做的这一个时间、周期也很磨人完全没有这种仪式，例如说该什么时候要去开这个会议，该什么时候要去发这个版本，该什么时候去检视，没有，不断的滚动需求过来，不断的滚动的去做发布，所以正是因为这样的一系列的一些痛点，导致我们就是想寻求一些看得见摸得着的这样的一个框架去做一些启动。

王宇你看像悟空他们这种企业的情况，当年的情况其实是非常适合做scrum的，对吗？

它又是一个产品团队，它又是可以自己决定自己产品方向的，然后我理解应该初创团队应该也规模也不会特别大，对吧对应该是非常符合我们说的所谓的安装一个模式，安装一个scrum进去。

其实的话这个scrum其实是在你这场景挺好的，虽然说你们挺疼痛的，但是你看你每个迭代没有可庆祝的东西，这不是值得思考的东西吗？对吧？这是那嗯。

如果你们一个劲的往下跑下去的话，这种假设你以为的一些东西得不到验证，这其实是更危险的一种情况，对吧？

其实我个人觉得的话scrum去逼迫你，去每每个迭代的话去思考这些东西，我觉得也是一种好事，对吧？另外一点的话就是说当你们觉得这种东西就像scrum这种要求，比如站会你觉得可能一天开的话也没什么意义，对吧？我做的也并不是很快对吧？那两天开一下对吧？这样反而的话其实大家这种节奏感又慢下来了，对吧？从另外一个角度上讲的话，我们是不是真正的去高效的利用了我们的时间，对吧？去去投入到一些东西。

所以在这一点的话，我觉得虽然我们还是挺积极的，对，只是你们在当时的话，在这种很别扭很有很多东西不能改变的前提下，你们选择了这个东西吗？对吧？我觉得是这样的，你们一一旦要选择了scrum，你们的这种革命的心态一定要有，如果是你一方面选择了scrum的，但是又不想保有这种革命的心态，对吧？冲击旧模式对吧？要深刻思考，我觉得你没把scrum用到位是吧？

我又想说了，因为分几个阶段，最早15~18年那个时候去用scrum的时候，真没什么革命的心态，或者说那时候也不叫用，那个时候只是在找救命的稻草，这个稻草他讲得清楚，它不含糊，他明白的就告诉你该怎么做，按我们那种教练喜欢讲的层次，就关注这个东西是什么怎么做就好了那种状态，就特别容易抓住。

当然我也认同王宇去讲的，讲为什么说革命心态的丧失，因为后面我在第二次去使用它，也把一些基础也学会了之后，我们去应用大概用了有两年左右的一个时间，他很快速的帮我们完成了这个产品的迭代的发布交付改善过程，但随之而来就更多的问题就出来了，它走向了僵化，每一个流程你都必须得去走，这个会你得开站会，有没有事儿能不能同步，他们原来可能更好的一些方案，他们原来就是通过文档的方式去做协作，你非得让他在那个地方开卡就很别扭，对吧？

原来这个需求这有一个班车的这样的一个概念，上车了你就不允许再改了，然后你要等到下一站再给你再给你改，或者说是迭代完成不了了，不允许中止，必须强行的把它给做完，然后有一些东西就在这个框架里面就找不到答案，就感觉自己这个时候如果说我如果改了这个东西，它是不是就不是scrum了，然后也没有人能够去回答你那个时候，所以我觉得我在18年那个时候做的时候是我蛮迷茫的，用这个框架的的阶段，我自己不太敢去修订里面的一些内容。

你说到这儿我就比较有感受，很显然我们在安装或者使用scrum的时候，它各个角色它在自己的管理或者是它的痛点解决上，scrum是可以比较好的去解决问题的，刚才悟空其实讲了好几个点，我觉得都是这样子的对吧？

比如说一些问题的检视，大家能看到进度对吧？

作为项目管理或者管理者，他能看到大家热火朝天的在干活了，这些都是一些微观体验，对于我们在企业里我们是大型企业，当时导入scrum的话，我们的所比如比比较能够感受到的就是说实在的燃尽图，因为你能看到问题嗯，故事被拆了，拆了之后你就可以看到燃尽了，所以这些微观的体验事实上是决定了scrum怎么样的被大家接纳的。

我估计不是所有的人在当初做scrum的时候，都能够感受到它作为产品的这种增量管理它带来的价值，但是你作为某一个具体决策，作为测试作为开发。作为项目经理，你是可以在自己的角度上有所感受的，我觉得这个是让scrum可以比较在国内来看，或者它是得到普及的一个很重要的因素，对吧？但是有一个问题就是我们今天其实曾经尝试探讨一下scrum的上下文，什么情况下你该适合使用scrum，我觉得更多的是从一个软件研发的角度，或者从一个产品交付角度，他不是那么显而易见的能够被看到的，对吗？

我举一个例子来说，可能我们当时做在某某金融公司软件大型软件公司做的时候，导入scrum的最大的一个变化就是曾经测试团队是一个独立部门，它是独立于多个软件研发部门的这些部门都是百人团队，然后做了敏捷以后，做了scrum之后，测试部门就被拆散了，测试人员就全部都进入了软件研发团队，软件研发团队的管理者，他是管理一个既包含开发又包含测试的一个团队，在组织上是一个很重大的变革，它其实会影响到整个企业上千人，应该也是个七八千人的软件公司，这个上千人的团队怎么就去构建他的能力，所以它的变它带来的组织上的变革也是非常深远的，但是我们作为其中的一个交付团队，我们是很难理解你导入这个方法背后他真正的意图是什么，以至于我在咱们开篇在讲的时候，我就有一个疑惑，我可能下来要再找找我们以前的老同事们问一问，当初要导入他目的是要做什么？

就是要做变革，本来就是要动这些组织和人员，然后我找到了一个好的软件研发的框架，刚好借机做了组织调整，因为可能我现在看，当时是七八年前做那件事，我认为整个软件是基于说咨询顾问给出的一些企业发展方向，试图打散软件研发团队，让软件和业务相结合到然后我们一步一步走到今天，是希望构建一个科技驱动的或者技术赋能的一个软件形态，也就是现在最流行的什么数字化变革对吗？

我们可能七八年前10年前就在尝试做这件事情，至少先把软件团队先重构掉，对吧？所以现在我觉得站在企业角度看，他可能有另外一一层意图，这个意图是跟我们所讲的，scrum安装这种它的上下文是有密切关系的。

对，这一点我就比较想听听王宇的意见，因为王宇你是在做咨询顾问的，从你的视角来看，你是不是接受，比如说是不是接受甲方老板们的订单，他其实潜在的意图他就是要对资源进行整合，或者是说这种我们作为虾兵蟹将，我们在组织里我们倒是没有办法看到这一层背后的原因。

对，我觉得的话scrum这种东西的话，或者是一个顾问拿到这个东西的话，会有一种莫名的自信感，这种自信的话就觉得他能够去解决一些问题，然后用他这个东西就能得到一些结果，这种自信的或者是很盲目的这种状态的话，其实我个人认为敏捷的某种特性。

因为如果说你不盲目什么玩意你都想得很细致的话，这东西本身的话世界就是变化的很剧烈，对吧？你如果没有这种盲目的状态，不愿意去冲进，或者是把这个测试部门就像你说的咱们揉到开发，你如果敢都不敢对吧？我觉得这也是有问题的，对吧？这是第一点。

我想说的就是说这种盲目有的时候也是好事，再说企业的话，你说测试人员都挪过去了，其实该怎么干活还是怎么干活，你知道吗？也没什么变化，但是恰恰这种盲目的状态去让你的去勇于去做一些事情，我觉得是挺好的。

但是要注意的话，这种东西有可能会僵化，我们的思考就等于是你看我用了这个东西，用了这个东西的话，我们就敏捷了，就敏捷就10分了，对吧？我们就不需要再去思考了，这是有问题的，你知道吗？恰恰是很多企业应用这个东西的一个问题，最大的一个问题。

因为敏捷就是不停的思考，而且有行动的勇气，但是scrum的应用的话，你有行动的勇气，但是你怎么能够证明有思考的这种能力，对吧？他有的时候就没有对吧？所以我在做敏捷的导入的时候的话，会强制着所有的人的话都开始这样的一个思考过程，所以但是我回过头来看，有的时候强调这些名词反而使得我们远离了思考，就觉得这个东西你看见了吗？这个东西就这意思，所以我们用这个东西，但如果说我们在企业中创造了一些概念，创造了出一些名词，你会发现企业的这种转型之路走得会更快一些。

你虽然说可能应用某种标准的打法的话，可能这一步子迈得比较大，但是在我的经验之中没有使用这些名词，或者是企业自己创造这种名词，他在自己的转型之路上走的会更更有条不紊。

对听王宇讲我也是有一些思考的，是因为做到后面，比如说最近做的一个项目里面，我才开始慢慢能够了解王宇讲的一些东西，他到底在思考什么的角度，他其实在思考这一个企业你未来生长的限制的这样的一个角度，最开始我用的时候我确实就是行动做一些形式敏捷也好，或者说是安装这样子的敏捷的这样的一个框架，然后也频繁的高频的去使用这些名词，一开始觉得这名词很叼，然后说起来里面的信息量很大，你们要跟我去同步，你们也要理解这些名词啊，敏捷迭代计划会议是吧？

要把这些东西搞明白，这样子我们因为上下文或者说名词对齐的，我们做事情就能更高效。后来我越做我越发现这个里面是有冲突的，而且因为前面是使用这种方式去做的，在我想要去做一些改造或者是改善一些适用于企业自己的东西的时候，它就会错失一些窗口的机会。

怎么说你前面跟大家反复的去强调这些词，然后这些词的话他一开始成就了你，让你很快能把这个东西安装进去，但后面如果当大家腻了，例如说你每天开站会，这个已经不是一个新奇好玩的事了，你每周回顾这个事情，已经不是一个让他觉得更有新意的一个东西了，他会反过来反噬你的，他会觉得你来来去去就是这么回事儿，你来来去去讲的就是这么些东西，这些东西虽然最早我们也说了不是我们想要的东西，但你既然这么强调，那就听你的，现在听你的，现在遇到这种情况我们解决不了，对吧？

那你咋办？然后再把这个问题反馈给你，你会发现你没有办法了，我最新的时候在试的时候就发现我就开始大量的减少这样的一些相关的词汇，更多的用团队它原生，生长出来的一些词汇去使用，反而他的这一个团队能够，他的天花板可能会更高一些，他不会受制于这个东西，因为换句话说是教练你自己受限制，你有这个过程就够了，对于团队来讲，你如果能用更高的维度和视角去计划它，有一个长期的计划，对团队来讲它的空间会更多。

对的，所以我想强调的是什么？大型组织的转型非常忌讳朝令夕改，你做了一些事儿，你突然说大家做别往那方向跑了，那方向不对对吧？这个东西让我们的受伤的是什么？是我们组织的执行力，大型组织最关键的就是执行力，所以我们不轻易说我们做的不对，对吧？我们一切都对，但是我们需要很慎重，所以我们就要回过头来看看这些关键点是不是我们永恒都会存在的关键点，而且它不会限制我们团队的这样的实施。

所以我在团队制作实施敏捷的过程中的话，我绝对会非常的慎重。

所以在这样的一个大上线上下文之中的话，我们就要思考我们是不是要引入一些关键概念，引入这些概念会不会对我们的未来造成一些消极的影响，对吧？

这些是我们需要思考的。

突然间又特别的有感慨了，我发现了我自己理解这个事情的心智模式是因为我一直创业工作经历也比较的动荡，它对于我来讲的话，我可能在玩一个无限游戏，这一个阶段对于我来讲就是说我可能僵化了，对吧？企业也没做下去，对他来讲也没有什么所谓的后遗症的一些问题，你也跟他老死不相往来了，基本上，然后到下一个阶段的时候去突破自己去做一些改变，然后和一个企业去进行一些成长。

但是反而你在咨询顾问的视角里面来讲的话，你的企业其实都已经存在的时间非常久了，5年10年甚至往20年上面去奔，你一旦去做出这样的一些东西，它对企业的影响是非常巨大的，你如何给它埋下了这样的一些锚或者一些种子它生长出来，对，就真的会有影响，所以我今天是终于感慨到视角关注的差异带来的变化。对的。看菲菲刚才想讲菲菲来。

是我觉得有一个关键点，就是大型组织里面做敏捷的一个关键点，它跟小型团队我们今天其实就有探讨过，像悟空这种小型创业型团队，他在做scrum的时候他想要的是什么？

他想要的可能是产品集合的管理，大型团队做scrum的话，他可能意不在此，说真的我现在体会是我们当时是意不在此的，可能更多的还是期望说资源整合，然后加速发布，然后做一些透明化，因为scrum对于透明化的要求是能细化到团队的，这比以前的纯粹的这种PMP软件项目管理的来看的话，它的细化的深度是要更深的，而且它是可操作的，还是可以10人小团队去操作的，这种透明化，我觉得这个是倒是大型组织采用敏捷中它有一些非常具体的痛点，所以我觉得可能今天时间也是比较有限，我们大概是探讨了说小型团队导入，还有大型团队他在scrum中的诉求是什么，然后我们也尝试探索了一下scrum它要安装在一些组织不同的组织中，他要的上下文是什么，如果我们有机会，我们再可以再做一些相关方向的探索，然后我觉得最后是咱们一贯都是送礼物时间，我就先说，我觉得我比较想讲的是我们第一次去探讨一个我们自己领域里的常见的概念，我最想跟大家分享的是，我觉得我们学东西还是要回到一个事物的历史过程，它是怎么诞生的。

所以在导入scrum中，我觉得我们要去关注说scrum它被定义出来本身是用来解决的是新产品的一个交付的活动，它就是一个game，英文原文，所以我觉得这个点是我们做敏捷教练来看，或者我们在组织里做敏捷转型来看，我们一定要深刻的意识到scrum本质上到底是什么，另外就是要清醒地意识到你要用它，你打算你想用它解决什么问题，那么你到底是要变革的改变它是吧？还是说你要取用其中的一些优秀实践或者是怎么样，我觉得这一点是我们做敏捷教练我们需要去特别关注的，这是我最后想要送给大家的一个我的想法。

然后也看看，要不然悟空也送礼物来。

我要送一些礼物的话，像我们今天其实做了很多对scrum的一些假设，例如说你其实做这个产品的时候，你可以去这么去做，然后例如说你在早期没有什么方向的时候，你可以按照这样的框架去做，然后你可能在做scrum的应用的时候，因为你原来没有使用这样的一些管理的辅助的能力。所以它开始会有一些很大的改善。还有的像框架会聚焦于一些需求管理上面的一些协作，但同时它也需要一些工程方面，或者说是更多领域方面的一些插件能够加入进去，打造出一个适合你自己公司生态的状态。

那么很重要的就是在这个里面我们做了非常多的假设，它是有很多上下文的，那么你要清楚自己的状态，还有自己组织的状态适不适合用它，而不要盲目的就是把它当成一个一劳永逸的方式去使用，那么它在未来很有可能会去限制到你组织的一个天花板。

好，这个是我想分享的，也想听王宇是想给大家来分享一些什么样的礼物。

如果可能但是很多企业的话，其实利用scrum其实是统一名词概念的一个用用法，就是如果一些企业去应用scrum的话，它其实节省了一些培训的的时间去统一思路的时间，并且达到了某种管理的这种强度的这种能力，对吧？你们有这样的一个知识对吧？你就可以去做这种事儿，他们就可以去弱化管理的一种发力程度，但是在我的经验里来看的话，这种省事的这种做法的话，它有一些的副作用。

对，这种副作用的话其实是我需要很长时间给他掰过来的，所以我还是觉得各位的话去慎重慎重，再慎重去做这些东西，虽然说敏捷有一种力量的话，就是让你犯傻，在犯傻之后，你要感受场域和整个组织的变化，感受之后再次的犯傻，这样的话我们才能够走向一个正常的循环，而并不是你一味的犯傻，你就真的犯傻，好吧？就是这些。

节目也差不多了，我们还是要说如果有朋友对我们的节目感兴趣，欢迎点赞转发，然后留言跟我们互动，或者想要来参与我们这个节目，也可以跟我们私信啊，然后可以来我们节目里面去聊聊你的这些观点痛点看法，当我们的嘉宾对的。

那就这样，下次再见，好拜拜。