迭代还是版本，你清楚了吗

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

我是悟空。

我是王宇。

我们三位就是经历了一个小假期，又回到了我们这个节目中，今天我们再看看聊点什么，因为大家经历完小假期应该都回归到工作岗位上了，好像每天都有新的故事发生，悟空今天应该是要有一个事要拿出来聊一聊，对吧？

对的，因为经历了小假期之后，这个工作又开始要卷起来了，卷起来了之后，近期的话就会有一个问题是什么？

是迭代的问题，大家需要去出这一个迭代的日历，但是我们一看说迭代日历就犯难了，可能大家对迭代的概念是什么？大家都比较含糊，大家会觉得两周三周的时间就是迭代了吗？ 然后迭代和这一个版本就是绑定起来的吗？迭代和这个需求是绑定起来的，然后就会有各种各样的问题，然后有的还会去问，就是说我们像五一放假，十一放假，端午节放假这些日子，节假日出来了之后，导致我们这>一个迭代，如果是两周的话，是吧？我们时间不够，没有时间被挪去放假了，我们怎么能够按期的去发版，怎么能按期的完成迭代，对吧？ 然后就出现了很多这样那样的一些困惑，所以今天也是想借着这样的一个机会和两位去聊一聊到底我们是怎么来去看待迭代这个词的，然后大家在团队里面去怎么去使用它的，我们能不能找到一些关键的点，让这些理解变得更容易更顺滑，然后解除一些我们关于迭代的这样的一些迷惑。

说起迭代迭代应该也是大家都很熟悉的一个词了，要不要我们先统一一下概念，迭代是scrum里的 Sprint，对scrum里管它叫sprint，对吗？没有scrum之前我们也有迭代的概念，像瀑布市里面其实也是有interation的概念。

应该不是瀑布里的，应该是Rup里的，它可以选用瀑布的这种交付模式，但是我觉得悟空带来这样的一个话题是非常好的，为什么我要点赞的一点的话，就是说其实我们会发现的话，我们其实都喜欢玩很高级的概念，看见了吗？ 我们规模化对吧？我们百人团队，我们千人团队，但是其实在这些基本的问题和概念上的话，其实我们理解都有出入那，当这样的一个情况发生的话，你会发现你越扩展你扩展的只是混乱而已，或者是扩扩展的只是一些简单的粗暴的概念而已，这样的话其实我觉得是需要思考的。

对我们今天就是聊到了迭代，如果说是把基本概念弄清楚，似乎我们就没有办法在大的组织里面能够去提更一步的提升我们效能对这点来讲的话，菲菲是怎么看的？

团队要做迭代，应该是要做敏捷对吧？ 你们应该是要做敏捷的，好像在现在大家做敏捷都是要建迭代的，刚好我现在所处的团队也有最近也在治理迭代，因为去年是一个大规模敏捷，去年是做双周迭代，听上去是个双周迭代，事实上双周迭代它是没有达到一个交付能力的。

所以今年我们把迭代的时间变长了，但是我们把把一些更多的质量的建设的东西都拉到一个4周的时间里面去做，从2周变4周，但是质量要求更高。所以我们今年也在跟我们的内部的同事们去协商，怎么去定义迭代，我就发现其实为什么刚才我刚开始我说我们要稍微澄清一下迭代的概念，就说现在我们在组织里面做迭代的目的是什么？其实就是这么一件事儿，我的理解包括刚才悟空讲的说你们要建立版本和迭代的关系，需求和迭代关系，长小长假怎么安排，其实目的都还是要统一一个共同的节奏。所以如果说迭代是为了建立节奏的话，我们要基于这个上下文再来看，然后我们再来看说怎么去解决一些常见的基本的问题，说具体一点我整体的观点还是在于迭代它是一个时间盒，对我们还是回到基本的概念，迭代是个时间盒，时间盒就意味着是你确定了一个步长之后，它是2周或者4周或者3周也好，时间过去的就过去了，那么时间合理是可以承载一些事项的，当然时间和到结束的时候是不是有些东西可以出来，这个是向往我们的开发工作出来的东西，往往可能就是一些版本交付，对吧？ 那么这就是一些基本的概念。

对我是比较同意马菲菲的观点。 也就是说当然了时间和这个概念的话，我觉得很多人的话其实不了解什么是时间和我们也不用去去讲这个东西，用白话来讲是什么，迭代的话它就是一个时间的周期，这个时间的周期开始了，比如一个物理的时间点开始了，它就开始了，它结束了它就结束了。 比如的话你不能够控制时间的长度，只要一开始确定了是两周的一个迭代，好它后面的话到了这个时间点，比如零零点零分零秒过了这个点，再完成的需求就是下一个迭代的这样的一种关键概念的话，就是所谓的时间盒，当然了咱们不说时间和概念，咱们就说这样的一个时间的片段，一个单位这样的一个东西的话，我理解就是一个迭代。 迭代的话有哪些的目的？我觉得一方面的话是规范化，我们的一些交付研发的一些事件，比如我们因为它本身的话就是让我们的交付更有节奏感，你会发现的话，如果没有节奏感的话，其实你很多东西都是乱的。 Ad-hoc，什么是ad hoc？ 就是说乱，就是说发现一个东西，你大家就是挽起袖子往上冲，当然了挽起袖子往上冲的话，有可能你的团队的话达到了极端的敏捷的状态，极端的有秩序的状态，你你可能许可能就会达到这种状态，就是发现一个事马上大家一一窝蜂的冲上去，但是在很多团队的话，其实还没达到这样的成熟度，或者是所谓的成熟度，或者是这种协作的叫协作的一致性对吧？

协作的这种潜规则对吧？这种状态没有达到的时候，我们需要有一个概念去让我们交付的团队的话有一种节奏感，我们每个迭代的话我们就可以设定我们每个迭代的话什么时候有站会，什么时候有比如计划会议，有的时候我们需要比如梳理一下需求这些事情的话去放置到我们迭代之中，放置，这样的话团队的一个交付的话就更有节奏感了，这是第一个目的。

第二个目的是什么？它是一个能够预测或者是总结我们完成了多少事事儿的一个一个单位或者是一个尺度，比如我们上个迭代和上迭代的话，一共完成了多少个需求，或者是完成了多少个点的需求。 好，我们就可以看我们池子里的这些需求的话还剩多少，这样的话我们也可以以这样的一个未来能看到多少个迭代，比如我们现在池子里的需求能够够我们3个迭代还是4个迭代，对吧？它迭代也有这个好处，就是可以从一个粗的粒度的话给我们预测我们的大概的交付的完成的大概的情况。 当然了很多人的话，我觉得的话把迭代和版本的概念的话搞混淆了，或者是他把这两个概念当成一个概念了。但是我不太这么认为，因为如果满足我刚才说的这两个目的的话，其实版本和迭代可以解耦的，也恰恰是可能是scrum或者是所谓的这种每个迭代要产生一个潜在可交付软件增量。 当然了潜在软件叫pspi对吧？Potential shipable product increment。这个概念的话，其实也并不是说它必须是一个版本啊，对吧？它可能但是最少的话它一个可发布的东西对吧？但所以的话它但是大家的很多简单粗暴理解的话，他就认为一个迭代就是一个版本，这种简单粗暴的理解的话，当然你说有好处吗？我觉得也有好处，起码逼着大家的话就版本的加快速度了对吧？但是另外一点的话，这种简单粗暴的理解的话，也使迭代的话，这个概念就会有什么？就像刚才悟空说的迭代是不是可以延期对吧？这样的东西出来。 就像说到迭代能不能延期，在我看来就是问一个生物，比如它是不是一个石头的这种感觉，你知道吗？所以我觉得很诧异。

刚才我看王宇想今天就有非常强烈的冲动把我们小小的话题打开，我们刚才设计了好多概念，包括说迭代的自身的一些基本的特性，对吧？ 就是时间段，然后它带来的价值节奏感，我们还引申到了跟版本有关的一些概念里面去，包括潜在可发布的增量，还有我们具体的版本交付，还有就是说迭代延期，所谓的迭代延期的表述，我觉得整体上我刚才有一个很强烈的触动，就是因为我们这个企业的case是站在一个项目经理项目管理的角度来看，迭代这个问题，我最近很深的感受就是以往我们没有迭代，我们先说没有迭代的情况下，传统的项目管理基本上是基于时间节点的，对吧？ 我们可以知道是3月7号要干什么，5月8号要干什么，9月6号要发布，可能一般都是这样的一些时间点管理。 但是事实上时间点管理它要不要这么高的精度，这是一个问题。有可能我们确实需要一个具体的时间节点去给出一个产软件产品的版本来，但是在这里面有很多细碎的过程，很多是事项的，那事项管理的话，版本管理它倾向于呃，项目或者版本管理它倾向于管的是一个结果，并不是管一个过程。

那么这个里面两我想表达的是这里面是有两个不同颗粒度的管理，一个是点的，另外一个是段的片段的管理，那么我觉得像迭代的概念的引入，对于我们作为项目管理来讲，有一个很好的手段，有一些归于组织，研发团队、小团队自行的活动，就让他们放到迭代里面去管，这样的话他会以一个比较有规律的时间段给出它的真正的节点的时间，对吧？因为我说我再稍微举一个例子，我们最常遇到的比如说排期，排期的话你想要跟开发团队具体的去沟通几月几号给什么东西，其实你会发现这是非常难的。

但如果你跟他讲说我说是这一周行一不行再下一周，如果你是一个比较有有节奏的有时间跨度的去沟通的话，往往是比较容易达成一致的，特别是我们现在常见的敏捷的 Scrum的迭代，现在主流都是建议是做两周，那一个月只有两个可行可以商议的给出的时间节点，这个就是比较好沟通这是咱举一个例子，这样的话回到回到来看说项目管理的角度，我就可以把一些我不用太关注的事情，他的主动权回归到研发团队，自行去去管理他们，按照自己的需要去做管理，我从项目管理角度我就只需要在给定的可选的时间节点上去对齐交附件就可以了。所以我觉得从我的理解来看，迭代的管理自身让我我如果是作为项目经理的话，我会可以从点还是从段上去分别的分头进行去管理，这也就讲的是有些粗细颗粒度不一样的东西，你可以用不同的手段去管。

我觉得这个是一个我认为迭代给出的一个非常好的价值。

那么从这个角度，我们如果说再去探讨说版本怎么搞，节节遇到节假日怎么搞，好多事情就会比较容易有答案了。

所以按照这个说法的话，就是假如下周要放假了，无非我们就是跨到下一个迭代去，那问题就来了，所以应该不叫迭代延期，应该叫做发版延期了怎么办？

是版本是一个交付件，版本它可能真的会延期，但是迭代应该是过一天就是一天，过一个迭代就是一个迭代，它不应该有存在延期的概念，为什么？我们先说说我觉得从哪个角度来看，我们反过来看，如果我们认为迭代可以延期，你会带来什么影响？ 我就可以从这个角度来看。

比如说我们现在三个人个人有，我们如果说1月一年只能见两次面，1月1号见一次面，然后7月1号见一次面，我们为了约定我们在这两个时间节点才能定义的话，那么我们想定义我们的一些动作，我们是不是应该在年初就把我们的节奏商量好，对不对？而不是说本来说好周一要干的事情挪挪到周五，然后随意的去改变这个时间计划，对吗？

所以你看我们用了这么多年的现代的功力，会轻易改吗？你那个闰月你也是什么闰月，你也是每4年才有一次对吧？这些东西全部都是定义好的，当然严谨意义上不是每4年，是每4年以及还有一个什么被备多少整除对吧？

我这个地方是有一些细节的，所以它是有规律的一个东西，有有利于我们去对齐我们的步调，在这种情况下你最不该改的是节奏是不要改的，你要改可以改节奏里面的东西，这就是为什么我们认为迭代不存在在延期的概念，是因为如果你允许它延期的话，那么这就失去标准的尺子了。

对的。

我再多说一点，也就是说其实你会发现的话，我们在管团队的时候的话，其实都是希望的团队的交付过程向着看板的流式管理进行前进。 什么是流式管理？它该发生就发生，该做就做，他不会的话去等待着什么东西，对吧？如果我们把迭代的话，变成一个有开始按钮和结束按钮的这样的一个东西之后的话，你会发现团队都在等待，这也不是我们希望达到的一个敏捷化运作的一个方向，也就是说你会发现的话，当然了这个概念的话，我同时也发现在展会上有这样的一个情况，也就是说我们一旦的话引入了战会的这样的概念，很多团队该沟通的东西的话，他就会拖到站会上沟通，对吧？

但是你会发现的话，我们让团队的更好的沟通，其实站会其实是促进或者是刺激团队的话，更在平常的话就应该沟通的一种手段。对于迭代的话也应该是这样的一个概念，它使得我们的接研发交付的话有这种节奏感，但不会去僵化这种节奏感。

这种节奏感的话就像你念的一个咒一样，或者是你走路的话是两条腿走路，但突然的话有的时候的话，你三条腿走路，有的时候画两条腿，你会发现的话，你完完全全掌握不了这种节奏，但如果说你一直就是两条腿走路，你按照自己的节奏你会发现的话，你也能应对变化，对吧？

比如路上的话，有些时候的话需要倒一下步，你就用两条腿倒一下步对吧？

这样的话就会使得我们进入一个我们有规则，但又不会被规则所限制的状态，所以我们才用这个东西，但是我见过很多的这种所谓的敏捷团队，它其实把迭代其实或者是很多的工具都作为了像传统的管理工具，它成为一种防守性工具，他成为管控团队的一种手段了。

虽然说是团队的话，可能在某些能力上有所欠缺，但是一旦这种东西一旦使用了，其实就变成了限制团队的一个枷锁。

其实我想说那是不是可以这么来理解啊我们一个团队，我可能从启动的这个时候，我要去找到适合我这个团队的这样的一个节奏，我可能去设定了两周的一个迭代，当然我也可能希望这两周能把这个版本发出来，然后很具体的到了这第一次我玩尝尝试这么做之后，发现我的版本发不出来，也许我们会面对一个调整，可能是把这个时间横跨两个迭代的一个时间和也许我是4周发一次这样的一个版本，然后发现在这4周之后，我们的质量，我们的这一个需求的这样的一个移交，它都是能够去做闭环的。 所以我们随着一两轮的这样一个测试，我们找到了我们团队自己的一个节奏，然后把这个节奏给固定下来。这样来说的话，这样是不是一个相当于说一个小的团队它的形态对的。

这个地方我觉得也是一个讲到了我认为迭代的关键点，就是说为什么要建立迭代你？既然我们认为迭代时间盒，那么你已经有大自然给你的时间盒了，周也对吧？ 比如周一个自然周是一个时间和一个自然月也是个时间盒，其实我们可以看到在没有刻意的引入迭代这个概念，2~4周或者scrum现在的标准是2~3周的概念之前，大家依然在用一些自然的时间和去做一件事做事务管理，那么为什么现在大家又特意的去强调，我觉得这是迭代的另外一个意义，就是说如果你限制一个时间和是比如说是两周或者是一周的话，那么你势必要把你的工作项拆解2~1周，你才能适配进去，对吧？

所以迭代的另外一个概念是要求大家强制你去拆解，你要确保工作量要小，拆解的概念不是也并不是敏捷带来的，对吗？我们PMP里面我们也讲对不对，你wbs不就是工作项拆解吗？你当然拆解它可能更多的是基于逻辑上的，只是说在敏捷中更强调你的潜在的交付件，你的小的这一批增量或者你的每个阶段你要有目标，小的目标小的成果，只有工件够小，你才可能流动起来，所以我觉得这是一个敏不是迭代带来的另外一个关键的一个呃，潜在要求我们要去做的一件事情。

你可以简单粗暴的话去用这种迭代放太大的需求的话，对吧？就挤出来的一个一种东西，但其实你也可以去考量它的这种前置交付时间，就等于是一段时间的话，你从开始做到做完了的一个时间长短，这样的话也可以给团队的话设成一个基线。 当然了回到悟空的问题，其实一开始的迭代的话，其实你可以拍脑袋去形成，比如的话你觉得你的团队的话形成一个什么样的节奏比较好？

我之前的一个思路的话，一开始是逼迫团队用一个更小的单位去做迭代的，比如我之前支持过100以上的一个团队，我强制说一个星期一个迭代，基本上的话这是团队连滚带爬对吧？连滚带爬的话受不了，说不行，我们一个星期太短了，我说好咱就调整两个星期两个星期所有人都会很高兴，对吧？

但是如果说你一开始就说两个星期，很多人就会说两个星期不行，两个星期待我受不了对吧？你就说怎么办？我们变成4个星期对吧？或者3个星期对吧？我之前是这样弄的，对呵呵我？

我在这个地方就特别想稍微扩展一下，我们不要讲不要太说软件研发，我们就反思我们自身的工作。我现在觉得可能很多职场里的新人，大家都会遇到一个问题就是，年终总结的时候对吧？你准备要晋升了，要发奖金了，要做年终回顾了，你去想一想全年干了什么，你会发现有的时候是不太容易总结出来的，这个不太容易总结出来，有一个很重要的点，就是你的有没有很好的去对自己的全年的工作进行拆解，去进行阶段的目标定义。

也就是说我们做敏捷教练的话，我们也会强调说团队你要阶段性的去做一些庆祝，你要庆祝的东西得是你提前定好的小目标，对吧？你不能一口吃个大胖子，然后一一步迈得太大对吗？

所以我觉得这一点上就是说从携带的小步快跑的思路上来看，我们做自身的工作管理的时候，也要去沿用这个价值观，我们看一看一周之内干点什么，不要把一件事想得太大了，这个太大里面它有好多复杂度很高的东西你是很难控制的，有可能你会做一些价值不高的事情，因为因为你不长很长，你说一个月干什么，你会倾向于看一个大饼干一个很大的事情，结果到月底发现都没出来。

但是如果说你说一周干点什么，你会更容易聚焦，就是眼前马上能产生价值的事儿，而且你是马上可以出成果的事儿，这个部分是要先干，所以这个是我觉得迭代作为时间和来讲，作为控制我们的优先级，控制我们的颗粒度，保证我们是渐进式的去逼近我们想要的价值来看，不管是研做研发，也还是做日常事务管理也好，它都是特别的有价值，对吧？

所以迭代怎么不会延期，但是你的价值有可能确实是要延期的，有可能做做着做不完。

我想问你们俩一个问题，你觉得你们俩能浪费时间吗？

太会了，我都不用想。

你觉得你会浪费时间。

王宇桑又在下套，我觉得不会因为时间不属于自己，你浪不浪费他都会溜走。

你看，对吧？

马菲菲的观点是觉得时间能浪费，是因为觉得时间是自己的，悟空觉得的话时间不能浪费，因为时间就是时间，对吧？迭代的概念恰恰是强化了我们对于这个时间的疼痛感，因为我们不能够浪费时间，我们只能浪费自己的生命。迭代的概念的话，强化了这种疼痛感，使得我们能够更容易的进行思考和反思或者是调整，这就是迭代给我们的价值。

当然了你就觉得这是什么？无数的时间我可以用，对吧？你这辈子是无数的时间可以用，你拥有好几辈子生命对吧？你这辈子你是不是珍惜了对不对？我们就是说如果我们这个人的这一辈子为一个迭代的话，我们是不是也该思考思考对吧？

我觉得这个角度真的好好震撼，我们在团队里面现在其实也在讲迭代你要庆祝什么吗？

就是说你做的这个东西到底你是已经被这个任务还有你的业务方绑架了，然后你每天都只是在没有灵魂的交付这个东西，还是说做完这个东西我会一下一次我会比这一次感到更自豪，我会觉得我又创造了更多的一个价值，所以说这样子的话不至于我的生命被虚度，了现在很长的一段时间里面都在去讨论。我做这个东西是不是浪费的，我做这个东西是返工的，浪费时间浪费就浪费，大家陷入了一种纠结里面，就有一个小的故事，我最后在这一小段里面，上次和一个产品同学聊天，我说你能不能找到就是说我们咱们这个迭代，我们能够庆祝的东西是什么？然后它愣了有30秒左右的一个时间，后来他说他好像好久都找不到自己为什么要去做这个东西的意义了，但是写我们就达成了一个小共识去写一个卡片，就是写这个东西它到底是不是值得庆祝的，然后他的眉头稍微有一些舒展，那就找到他做产品的意义在哪里。

对的，菲菲怎么想？

我觉得王宇桑刚才给的故事还是挺震撼人的，我就是忍不住发出了一个幸福充满幸福感的微笑，主要点是在于说比较让我比较感动的一点是在于说，如果说人生是这一辈子，你是一个迭代这句话对吧？然后我觉得我一下想到说我们也经常讲说我们小的时候读书老师就说一年之计在于春是吧？

一日之计在于晨，我们现在其实我们在沿用这些概念对吧？我们一个迭代之际在于迭代的需求梳理会是吗？对，就是说在需求梳理会上，你会去定义接下来的一一，段时间我们打算要庆祝什么，对吧？我们要庆祝什么，我们定下来，然后结合悟空的小故事，我觉得这件事会让大家有更多的手段去让我们这个过程变得更加有意图的去做。

换言之说，人生你不走到最后关头，你不去反思这件事是不是可以频繁的去做，是不是更有意图的更有觉察的去做。

我们做敏捷教练，我们试图为组织创造一些觉察的机会，那么迭代应该就是一个这个角度你是可以去失利的，你创造一些觉察机会给到组织，也是需要有一些去做的对吧？对的。

我想突然我想说什么，就是说马菲菲说的组织或者团队需要有一些觉察去做这事儿，是这样的，所以的话我们有的时候需要创造一些你让团队疼痛，但是又不是那么疼痛的一些概念或者是点或者是做法，让团队的话逐渐形成这种更强的这种自我意识和这种演进的这样的一个规则。

这些基本的点就像我们今天的话聊迭代，我就觉得非常赞，因为这个东西就是非常简单的小问题，最终小问题的话我觉得才是很重要的。比如马菲菲刚才之前的话讲过有句话，那叫什么？叫。

对越小的问题有讨论的价值。

这样的东西的话才是我们追求更小的原子性正确的一种趋势。

当我们在很小的问题上进行纠结讨论思考的时候，你会发现它扩展起来的话，速度其实是很可以很快的，但是恰恰就是我们在很具体很小的这些问题上，没有一些非常的深入的思考，就造成了我们需要借助很多这种法器。

比如这种法器的话，就像我一般很想说喜欢说的话，我们要把我们的能量，因为我们hold不住很多能量，所以我们要把能量注射到这种很多法器里边，然后我们就拿着这些法器去到处打怪物或者是去做事情搞事情。

对，但其实的话你要知道它的归根结底是你hold不住这些能量，他才会这样，所以我们在追求这种法器，而且的话你在挥舞这些法器的时候的话，你就觉得我很厉害，是你厉害还是这些法器厉害，你就不知道了，你觉得自己身上闪闪发光，你觉得自己是在发光吗？对吧？

有的时候这种错觉有的时候反正我是不停在思考这种东西，所以我也非常喜欢去讨论非常具体的一些问题，所以当团队我讲很多有的时候需要给团队进行培训，其实我并不是很共鸣，我其实不太喜欢干培训的这种事情的，但是只要团队说我们这有具体问题，然后我就就按耐不住我兴奋的表情，我就说来咱们去搞一搞具体问题，对吧？这种东西就是我的一种趋势。

其实我听到王宇桑讲具体问题的时候，还有一点觉察是什么？我们可能今天我们是在聊迭代，我们可能很多时候是在一些问题的定性上面，我们其实分不出来什么是我们具体的一些问题，我们有一些可能是概念没有搞懂，有一些可能是我们的一些抱怨，或者说有一些是更复杂的一些结构层的东西，但我们会把它混淆在一起，然后通过一些情绪的方式把它给表达出来去塞给别人，希望别人能够去帮我们解决，我不知道是不是这个样子，如果是这种状态的话，我们很可能就没有办法有效的去解决，反而是当你清楚了你自己的问题在什么地方能够问出很精确的问题的时候，你把这个东西你其实是想过的，其实和别人再配合起来的话，它的效率会更高，对的。

这个东西的话我想说什么？

你刚才说的话对理论的理解是不是正确或者是什么，我告诉你你根本理解不错，你知道吗？

你任何东西你理解的就是你理解的，而且我们每个人脑子里的东西都不一样，比如我学的冥想的特音，只要老师告诉我们，我们就不允许说出去这个东西我脑子里的特音和你脑子里特音就是俩东西，但这个不影响我们去用这个概念去做事情，对吧？我们如果协作的话，我们如果有交付软件发布时间，我们纠结一下发布的时间点，我们倒逼一下需求，对吧？就这样，这是第一点。

第二点的话就是说这种责任的受害者的心态，我觉得的话一旦你有受害者心态的话，你就变成了你就等着别人做事，或者你觉得这个东西别人做就得了对吧？这个事的话跟我没什么关系，对吧？这种心态的话也需要调整，只要心态一调整，你会发现所有的概念的话都是你利用的武器，而且别人脑中的概念的话，也是你可以发力的东西。

你刚才说的这个东西又让我想起一件事儿，有的时候我说很多东西会让别人迷惑，并不会让别人清醒或者是清晰，我觉得这可能有的时候是我故意的，你知道吗？因为一旦你迷惑了，你会发现你其实就是走向自由了，对吧？或者是你就开始接受你就开始思考这东西到底怎么回事对吧？到底哪个是对的对吧？到底软件开发对吧？

迭代这些概念到底是怎么回事，所以我觉得的话螺旋式上升的话，就是你从清醒到迷惑再到清醒或者是明白对吧？这样的来回的摇摆的一个过程，如果你觉得很多东西你一直是很清楚的，我觉得你根本就没太螺旋式上升，你知道吗？

刚才讲到一个点，我也是特别有感受，我觉得刚才有一点就是王宇想提到第一点，这个理解没有什么对错之分，因为理解就是理解。

我最大的感受是在于什么？是因为我们自己我们都在做一些敏捷教练的工作，敏捷导入你会发现纯讲概念的话，这种培训类的工作该有就要有问题是说培训为什么大家都觉得培训不解决问题，或者说你听的时候你觉得都明白，然后跃跃欲试，但是干起来的时候有很多偏差，甚至可能解决不了问题，或者觉得这玩意不好用不好使对吧？

我觉得最大的一点在于说真正要发现一个东西到底能不能解决问题，一定要回到具体的上下文，比比如说我们开篇在讲说一个很细的细节，就是迭代遇到节假日到底要怎么安排，这就是个非常细节的东西，这就是我们最近遇到的东西。

因为我可以讲这个故事大家一下子都明白了，我所在的团队我们本身也要做工具的，然后我们的用户就过来提问了，说你这个工具上你看我现在要改迭代，这个迭代我要按做全年计划，你看如果接下来我们打算是国庆节我们是不排的，你这个能不能工具给我做成，是我把国庆节的迭代一改，后面的迭代跨拉全都自动的向后挪挪一个迭代是吧？

挪顺序排下去，你看这个需求是不是听上去就是非常容易理解非常合理。但是也我们要是做点软件开发，你都知道在工具上，但就好多细节都要问清楚，否则这个功能是做不出来。的啊我举这个例子是想讲说好多很细节的概念，在具体的上下文里面都会产生大家对于迭代理解的一个偏差。

那么我的观点也非常简单，如果说迭代前面我们也讲了迭代遇到节假日该不该跳过，我的答案就是我觉得迭代就不应该跳过，因为我们认为迭代就是时间和最大的一个点，就是你反过来想你跳过或者不跳过，影响是什么啊，我们都约好了，你全年就是每两周一个迭代，你就跳过大家都不排就不用就好了。

所以也不会影响什么？这个点就是说我们做培训的时候可能会讲说你是2~4或者3~4周一个迭代，这就是你一个迭代，你这个迭代开始之前要做计划，结束之后你要做回顾，那么培训可能很少会打开来讲说迭代存在的意义是什么？如果你真的知道迭代存在意义是什么，迭代该不该跳过，迭代要不要延期，这些东西其实你都是已经是有答案的，对吧？就像我们前面讲的，我们可能很快的就能建立共识，我们都一致的认为ok迭代应该该跳就跳，没有反正过去了，那个时间已经发生了，你就让它过去就好了。

然后我们也会认为说你时间和怎么可能会有延期，你可能版本你的交付物，你可能没有能在一个具体的给定的一个计划里面去发生，但是你依然是晚一个节奏再出现的，对吧？

所以迭代本身也是没有延期概念的。对，我觉得这就是要回到一个很具体的细节去讨论事情，它本身才会有价值。对。

这种迭代的概念的话，很多敏捷的概念的话，它都是用一个它给我感觉是一种杠杆的手段，而且的话它尽可能的简单的使得这种杠杆的话有效这样的一个但是如果说我们会发现的话，很多工具或者是很多的手段，很多具体的一些管理规则的话，都是走向越来越复杂的方向。

我认为这是我们需要思考的东西，也就是说这种东西的不停的做加法，你会发现的话它就越来越复杂，这种复杂的话就和杠杆就是两个方向的东西，这是我的观点。

这个地方我也想抛一个问题出来，我其实已在过去的一段时间，其实有几年了，我都在尝试跟我一些朋友就去沟通交流，我的个人观点是说，我认为我们应该尽量少的去进行目标管理，更多的去进行一些过程，就是发生什么事情是我们要去做计划的，但是那个目标我是觉得不应该对目标做定的，或者是你不应该对目标做太明确的定义，为什么讲到这一点？还是回到迭代来看，我认为迭代或者这些年做敏捷，让我更加的意识到你去管理一个时间区间内，你要做什么事情，远远比你管理到某一个具体的节点，你要达成什么目标来的更会有价值。

我举一个例子，比如说我们大家这这，大家现在生活好了，都想聊聊减肥，好多人都有小目标，我能不能年底的时候或者我能不能3个月以后清10斤，这是一个常见的目标，你会发现这种目标不起作用的，我觉得与其定义3个月后轻10斤，不如定义每个星期去一次健身房或者去跑两次步是吧？因为我觉得活动是比较容易去做管理的，但是目标是很难做管理的，这就是为什么我觉得我可能是做敏捷这些年，让我更多的把重点放在了一个过程的计划里面，我觉得我们现在做迭代，其实很多也是倾向于是做过程上，我们在迭代里面要做什么事情，要交付哪一些story是吧？

这个都是偏过程的，这个目标的东西就是沉归于尘土归土，有些东西目标的东西，说实在的有可能你怕你部分的达到，它依然是work的，对吧？

所以我们不要去大而全的定义一个目标，有的时候会跑偏，我的感受我同意。

就是说我很快的我想突然有感觉是什么，就是敏捷的话很多顾问或者教练的话，它是依赖上下文的，说这个东西得看情况对吧？

然后但而且的话很容易往务虚的方向走了，但是务虚的状态或者是根据上下文依赖上下文的，不代表说上下文这个团队的东西不能形成很具体的和低维度的手段。

所以我们一定要思考，就像回到就是敏捷的这种状态，更像是一种进攻的状态，你如果连自己的很多东西的话都做不到。

是其实这个东西就后面的东西你就别谈了，就像你今天的话都这星期都去不了一次健身房，你说你减肥健身的话，那这个事就不靠谱，我们看的点的话就是你的这一星期对吧？

而且是很低维度的这种手段这种东西的话，这也就是为什么很多之前的传统的行业的咨询顾问，或者是这种这种瀑布软件研发的这种以前的老顾问的话，在敏捷状态下不太好使了，或者是大家不太买账了。

就是因为他的话，他必须不光能说，而且要能够落地，而且要能落得非常具体，你刚单独说的很多高大上的名词或者是过程理论的东西渐渐就没用了，或者是效果就差了。

对这就是我我要说的时间也差不了太多了是吧？咱该到送礼物的时候，好，每个人说说送啥礼物，今天聊聊了半天，先从悟空开始。

今天给大家送些礼物的话，建立还是回到我今天的初始的问题，怎么去做我们迭代日历，首先你可以给团队快速的去拍一个基线，然后能够去根据实际的情况去快速去做一些调整，但同时也可以去让团队有一些成长的空间在里面。

第二个的话就是我们做迭代既要有长远的这样的一个目标，但同时也得脚踏实地的去看到基本的一些纪律性的问题，因为像更低维度的一些手段，它其实有的时候是通用的，就像我们今天聊了很多问题，他都是在聊一些基本的概念，反而我们能把这些基本的概念能够聊清楚，可能我们就用更容易撬动更大的这样的一些价值。

对的。

好我也送礼物，我就送点具体的，我觉得因为迭代这个问题，经常我遇到的一般是像这种项目管理或者是团队管理这两个角色，会经常关注关心的啊，我觉得如果你是项目管理者，你是一个要结果的人，我的建议就是你对迭代的思路，你就理解为迭代，就是成为到哪，什么时候你该要拿到什么东西，从这个角度去理解，如果你是一个团队管理者啊或者你是个smart master，那么你就考虑迭代是你的庆祝的一个手段，就是你要让去团队改进团队庆祝点什么，更多的关注于把团队的能力建设起来，不要把迭代当成一个交付件的管理手段。

养兵千日用在一时是吧？Scrum master更多的去做一些利用迭代做一些养兵的手段，这个是我觉得我今天比较想要送的具体的小礼物。

好，接下来王宇桑。

我送的礼物的话就是说用迭代的方式的话去思考一下，就是说你做的这些事儿，对吧？之前的话有一个词的话叫做日日新苟日新，对吧？就等是每天的话还是要就不一样一些，对吧？这样才好。行就这些。

好，我们今天时间就到这了，欢迎大家转评赞。

好。拜拜。