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

我是悟空。

我也是王宇。

又是我们三个，今天我们聊点什么，因为最近我了解到说悟空你好像是在做一些项目是吧？在需求管理这边有一些案例可以跟我们分享一下，是个怎么样的一个情况。

最近也挺好玩，我们在辅导团队的过程之中会落到需求这一块，然后我们也搜集了一下大家对需求这块的一些反馈，然后也非常多的说法，什么需求不清晰的，文档也不太详尽等等，总感觉需求是一个黑盒子，然后想找问题，但是找不到就是来来去去会有那么几句话，所以说我们就有机会就是打开黑盒子去跟团队去看看需求里面到底是有哪一些问题，或者有哪些哪样的一些场景是我们可以去琢磨的。

打开盒子一看，我们就发现需求的估算，拆分颗粒度的一些问题非常的多汁，特别有机会和大家去探讨。但是一探讨就发现什么？发现有一个问题，大家会觉得这个需求的估算是不是为了在压榨我们，大家不太敢去进行这样的一个估算，对吧？是你估算的那么清楚了，是不是最后就是要压榨我们的人，天要管我们的绩效，所以就有非常大的这样的一些恐惧感。

所以我觉得大家其实并没有说是能够了解到估算协作拆分这个里面它究竟为什么要去做，所以我觉得我们今天可以就需求的话题深入的来和大家一起去聊一聊。

对的。需求估算也算是常见的一个操作了，应该也是比较常见的。可能我们以前做瀑布的时候，估算是肯定要估算的，因为接下来你有一个非常长的研发周期不估算， PM的话项目经理他排期都不好排。对，那么其实我们现在要讨论的估算，我理解应该是一个敏捷模式下的需求估算。是这样，悟空背景能不能再补充一下？对的。

就是我们在做敏捷的团队上面的这样的一些导入转型，所以说我们原来的需求可能拆分的颗粒度也比较大，或者说是不太愿意去做跟进一步的这种拆分，就是需求到任务上面。

所以说对估算上面来讲的话，按这个人天小时这样的一个状态，然后时间长的话就发现这一个整个需求实现，然后项目整体把控的进度风险都不太可控，所以我们就想要把这个盒子打开来去看看。

这块这块王宇作为企业的咨询顾问也应该有比较多的经验，不知道有没有什么想法。

悟空的话你的这个问题是啥？他们怕估算的话，当成压榨他们的一种手段，然后就说软件研发的话不应该就这么详细吗？还是怎么着？

好。我们来聊聊。

压榨的这种感觉，我在接触到的这一个团队里面经常会有这样的一个状态，例如说我们去做需求层面的这样的一个相对估算，这样的一个很具体的场景，因为我们可能会用微博那期的数列去让他们感受一下不同的需求，它的大小是怎么样去类比的。

那么有了这样的一个层面上面的估算的话，我们就知道我们自己团队每个迭代也好，或者说是我每个时间周期也好，我们能做的大概的工作有多少吗？对吧？但是大家一听到这件事情就会猛然的有一种警觉感，对我估算出来的话它也不准确，我估算出来的话，我是不是下一轮需求，我可能会要放入更多的这样的一个需求，对吧？是不是我的整个时间如果被透明出来的话，我就要被组织监控，他会不断的让我去加班。

对，所以就产生了非常多种不适应感，这种不适应感让大家就很难的再继续往下去推进估算的这样的一件事情了。

听听上去应该是好几个角度，都好几个角度的担忧，客户好几个角度都混在一起了，至少我听到的有包括说相对估算绝对估算对吧？如果你是采用斐波那契数列这一类的玩法，它是属于相对估算和觉和以前的这种人日、人、天这种绝对估算之间的差异。

如果是讲到产能对吧？团队担心下一个迭代或者版本需要我做更多的事情，这是一个产能角度的可能团队他缺乏安全感，还有这个角度的一个担忧，所以听上去好像是站在团队的角度，对于估算的使用哪一种手段的估算，到底会产生什么效用的有怀疑以及团队担心，自己没有任何底线，守护不住底线，或者说他是作为一个交付团队，他担心作为一个内部乙方也好，他没有安全感了。

我不知道这几个角度，如果我们现在接下来聊的话，我们先聊聊哪个，我们是先聊相对估算绝对估算，还是先聊聊我们的产能隐私安全，你们想先聊哪个？

我觉得的话我们没必要去往前走到这，我觉得的话直接第一个问题要不要估算？估算是为了。

我肯定是估算派的，我先take a site，我估算派的要估算。

就是说整个业内的话，其实是有两种思维的一种或者是模式，或者是对这件事情的一个认识。

一派的话认为需要估算，一派的话说不需要估算的，当然了不管需要估算还是不需要估算，其实他都要弄清楚一个问题是我池子里的这些需求大概什么时候能做完？

你会说如果我不估算的话，我怎么就能够知道这一堆需求什么时候能做完呢？

其实它是通过了计算整个的一个这些需求的，像流动效率前置时间，通过这些历史数据的比对，他就能够对他自己的一个交付的能力形成一些预判，通过这些预判，他把整个的交付的研发系统的话当成一个系统，这样的话其实他能够得到一些信息，通过这些信息他就能够做出一些判断，这是不需要估算派的。

当然了说是不需要估算的话，其实也是不需要开发人员的一个估算，但是其实它还在持续着测量的系统，这一派的一个思路是这样的。

另外一派的思路的话是需要估算，当然了咱不说一些杂七杂八的这种派，因为很多人的话其实是相信有估算或者是觉得有估算，其实他对估算的认为认识的话还并不是很到位。

其实的话我也是非常清晰的站在需要估算这一派的，当然了需要估算是一个倾向，当然了如果说有一个团队的话，他现实情况就估算就没什么太大意义，比如的是一个完完全全创新的团队，对吧？我们走一步看一步，我们只能看两个星期的东西，我为什么要估算我池子里的需求都没这么多，我也不知道我要做到什么程度，对吧？这样的话不管是需要估算派还是不需要估算派，对于这样的团队其实都没太大意义。

当然了它经过它的一个历史分析的话，它的一些利他们的数据可能会对未来的一些系统预测做出一些铺垫，这是这个的。

但是对于是不是需要团队估算的话，有些项目就不一样，我现在说一下，我为什么认为需要估算，就是估算用来干什么，当然了这个东西也是我的一个倾向，我也不确定其他人，甚至我都不确定马菲菲和悟空的话是不是跟我的想法是一样的，也就是说估算的目的是什么呢？

你可以理解，你可以想象一下我们软件开发的一个过程的话，其实是在一个不确定的大陆上开车，在这种不确定东西，你可以想象是在一个夜晚，如果说我把所有的需求弄得非常清晰了，就如同我把这片大陆的每一寸的道路都完完全全能看清楚了，我在开车，那这种东西是不靠谱的，这是一种不建议走的路，因为你会花太多的成本去把你的需求弄清楚，当然了你如果花了很多精力把你的需求弄清楚之后，你会发现你的需求又变了，对吧？

这不是废话对吧？你是折腾半天对吧？但是有另外一种思路是什么呢？咱们就走对吧？咱们就敏捷开发，咱们就想怎么干怎么干嘛对吧？敏捷快变对吧？好，那就如同你根本就不是开车，你就像什么，你就像关在一个漆黑的屋子里，一点光都没有，你大步的向前走，你不觉得你的头会磕的满身是包吗？不光你的头会磕上包对吧？你的胳膊你的大腿你都磕的到处都是淤青，对吧？你肯定在这样的一个环境的话，你肯定要伸出手来摸一摸，这种摸一摸的过程的话，恰恰就是我们在混乱系统混乱状态下，我们手中的一个武器或者是我们的一种应对措施。

我认为需要估算的话，恰恰就是我们要伸出一只手去感受一下我们的这样的一个未知的领域。

当然了未知领域可能很粗，但是它可能需要我们去感知，这取决于我们能够承受风险的承受能力，以及我们这件事搞砸之后的一个consequence，它的结果对吧？如果说这件事的话你就随便摔，反正咱就皮实，你就估它干啥，就别估你就你就跑对吧？摔得七荤八素接着走。

但是如果说我们做这个东西是需要认真的去审视，是一个相对比较大的系统，需要很多人的协作和配合。如果在这种情况下的话，你的这种估算就要往这个方向发力，就是什么让我们知道一些坑有多深，这些坑的话风险到底大不大，并且我们通过好多人的视角，尝试把这样的一个情况去摸的差不多。

所以的话我完完全全不认为估算能作为考核，而且的话你用估算成为一种考核的话，是一个反模式，我认为他让一个程序员的话过分保守的面对估算，但是你要知道精确和估算这两个词就不应该在一起，精确的它就不可能是估算，它就不可能是精确。

这种估算仅仅是我们开车在黑暗的过程中的一个远光灯而已，你觉得远光灯能看到多少东西吗？不一定，但是我们一定要打出远光灯，这是我的观点。

但是对于到底需不需要打出远光灯，得看到我们路是哪个路，车是什么样的车，我们的旅程是什么样的旅程，这才是敏捷而并不是说干活不靠谱，也就是说敏捷坚决不是干活不靠谱的一个代名词，我们得根据情况去弄估算或不估算或者怎么估算，咱得商量很多东西。

当然了我是站在我跟马菲菲是一派的，我们是不是就偏偏向估算派的。行，我就说这么多。

你们俩我突然间猛然地意识到这个问题，其实它在定位层面出现了一些分歧，我们一开始讲估算的时候，我们脑子里面到底冒出来的是什么？我就想以前在团队里面做做研发的时候，业务部门或者说我们的上游老大会经常说什么，这个需求大概需要做多久，需求不难，应该很容易做。

他在向你要的是什么？他在向你要的是一个承诺，或者是一个相对精确的承诺，以帮助他更好的去预判你这个软件研发的周期和它去联动业务的时候要交付的这样的一个预期是什么。但是做这件事的时候，他要的是估算吗？我现在的感觉是他要的其实不是在要估算，我们是把估算和承诺精准的承诺这两件事情搞混在一起了。我认为我们现在谈的估算更像是团队对内部对自己的一个能力，对协作上面的一种可视。

对，就像我要我生病了，我得先去医院，就是有个检查单，我得做B超，或者说我得化验验血，我得知道我的能力边界在哪里，我得对这个东西有预期，真正向客户或者向别人去做承诺，让别人能够看到的时候是什么，我们拆分成任务的一些阶段，我们去去看到这个东西大概需要多久，这个可能是我认为别人想要的东西。

所以我认为是在做敏捷估算的时候，我们是在原来的基础之上，我们加入了一些应该叫做近光灯，还有远光灯互相交替的这样的一些部分，让我们更清楚的了解自己的能力的状态。对的，这是我刚才的想法。

这个承诺我说一下承诺就是不可能他的承诺不能是百%，他只是可能是85%或者75%，你75%或者85%可以根据你的一个过往的历史数据来弄，他为什么很多公司特别在乎这样的承诺，是因为他们系统的耦合度太大了，也就是说如果你这个团队不给出一个非常明确的承诺的话，你让其他团队怎么干，你就说我可能上线这个功能，你上线这个功能跟其他的功能它就是耦合的，你说怎么办？

其他团队是做还是不做这个东西，对吧？

这是问题的所真正的问题所在，它不在于估算，而是在于耦合，那恰恰是因为耦合的一个存在，所以我们对于交付的一个进度或排期就非常的在乎，而并不是在乎估算，估算只是它因为我们在乎排期，在乎这种倒逼的计划，所以我们才重视这种估算。

对。这是一个原因。

除我估计另外的原因有可能是领导实在没事干了吧，想考核团队觉得像要卷一下对吧？

我来表达一下我的观点说我肯定是估算派的，基于刚才前面两位也讲了好多，其实是我觉得这个问题以我们就可以认真看一下，在我们聊估算的时候，我们到底在聊什么，还是我们的老句式，估算你至少看它至少有三个信息，一个就是潜在的什么是一件事，什么时候开始什么时候结束，中间的时间跨度一般光估算就是这些信息对吧？

那么这些信息我们在软件工程里面，我们看看它到底用来支撑什么，我觉得至少几个点。其实前面王宇嗓也讲了好多，一个是你作为改进的话，你可以看一下如何改进软件工作，流在制品是怎么去流动的，包括lead time，它有一些其他的手段可以去度量，是不是非要用估算，这是一件事情，这是第一个点。

第二点就是说刚才大家我们都在聊的，你可能是一个排期级的管理对吗？我要知道它如果启动话大概什么时候能结束，所以一旦你拿估算的数据就可以去支持我们做排期了。特别是在王宇讲到了，我们在一些复杂系统中，各个功能之间是有依赖关系的，所以如果你不知道的，不知道这个事什么时候启动，什么时候能结束，你是没有办法进行大规模的管理的，它就可能会导致软软件整体的失败。

这个就属于这种工作量工期工期角度的管理，它里面一包含着软件设计中的一些依赖关系的识别，包含着一些集成类的测试活动的一些去计划，这个就属于项目管理或者软件产品研发管理过程的东西。

我觉得我还要补充一点，是咱们刚才没有特别去讲到的，估算在我看来我强烈支持他的就是回到估算活动本身，它就是用来支撑软件设计的。

这里我想讲什么，刚才王宇也提到了，说精确估算是一个矛盾的词，精确就不应该是估算出来的，要估算你就不是精确的对吧？很抱歉的说我现在所处的组织，我们还就真有精估，而且精确估算作为一个字段坐在了我们的工具里面去需要大家去填写，但是我觉得这个事他跟王宇讲的一点都不矛盾，我们事实上在企业里做的精估是什么？它指的是在软件分层设计的过程中，在最即将启动开发前的最后一次估算。

那么这里隐含着有两个角度的含义，第一个角度是我们大家都认可，你不应该在非常早期进行估算，因为这时候有些需求你是决定不做的，这个时候你去做非常细密度的投入大量的工作量去估算，你都会产生浪费，这是我们的共识对吧？所以我们都认可，我们应该随着整个需求排期的这种渐进明细的思路，在即将启动的时候去进行估算才是合理的。

当然我们的企业情况比较复杂，所以我们会把最后一次估算叫做精估，它指的是代替了说前面需求决策早期的那些粗略的拍拍脑袋想一想，大概8个月这种代替了这种估算。

那么第二个点就是说为什么我认为要支持估算，而且这种所谓的精估在你软件即将启动研发之前，我们认为说软件研发影响最大的影响是你的设计在实现过程中产生偏差。

我们抛开说由于需求变更导致的软件实现的偏差，单就软件研发自身的活动来看的话，那么你肯定是希望说越复杂的系统，越复杂的越庞大的组织，你越需要设计活动要提前启动，因为我们希望coding 包括你后面的一些流水线构建，什么测试那些我们就不讲了。

我们纯以广义的coding来看，你希望这个活动越快越好，对不对？一个真正的大师是前面想四五天，最后一天花20分钟把代码写出来，然后上流水线是吧？这是我们认为软件大师的操作水平。

所以说经估如果说或者说我们说详细的估算活动，在软件即将启动前，最晚时间启动的时候，你去做它有什么意义？很显然在组织协作里面，你是需要知道大家很认真的想过这个东西该怎么设计，而不是说希望这个软件写了三五天之后，发现我的设计失败了，我要推倒重来，这个影响面就比较广，我觉得大家都能理解，如果我们有一些听众朋友也来自一些大型的金融软件的这种公司，金融软件复杂度也非常高，你你不可能随便就启动一个工作，随便就废掉一个活动不做对吧？

所以我觉得从这几个角度来看，我也是坚决的站在要做估算的，只是说我们现在很多情况下，遇到的问题是大家对于估算怎么做和估算服务于什么这个事儿理解好像是不是特别的清楚，导致这里面有些误解，比如说我觉得最常见的误解，站在项目管理，站在产品管理管理者的角度，他是希望你通过估算给他反馈具体的排期时间的，刚才悟空也有举了这个例子，但是作为开发角度，他对估算的理解应该可能是基于软件设计自身的，所以这里面有很复杂的上下文，不同的上下文决定了我们应该采用什么样的估算手段，包括在什么时间进行估算，还有就是我们估算真正的结果是服务于什么。

对，我先大概说这些，我不知道对回应到悟空最早提我们节目开头讲的上下文来看，有没有一些新的想法。

我觉得是有回应到的。

因为这个里面的话它包含了不同的视角，就是像你刚才所说的产品，它就是想要一个大概的一个周期能不能做，然后整个项目的进展它是否是可控的，而开发他一听到估算这个词，可能第一时间他理解的不是说我要怎么去协作，他理解的就是这个事情已经到了要做的一个程度了，所以我就得给你详细的去做估算。

但我觉得我们现在的软件协作的过程，它变成了一个开发，并不一定要那么早的进入详细的设计的这样一个阶段，但是他得对这个软件设计得有一个大致的理解，而产品也没有那么早去做出要把它拉入排序的这样的一个决策，但是双方的信息把它给它拉通了。

当然在这个过程中测试可能也要参与进来。

那么当大家更早的能够参与进来去做这样的一个估算的时候，我们对项目整体的进度把控，包括设计中的风险，还有产品的决策，我们首先在信息层面上，我觉得我们就拉通了一致，所以这是我认为做估算活动它的一个必要性。

你刚才讲到测试参与进来，我这里我还稍微想跑个题，我觉得测试不但是参与进来要看产品复杂度，有的时候测试它本身也要进行自己部分工作的估算的。

换句话说，我觉得我更想讲的是咱们就不说研发，咱们说任何活动你是不是都要对你的接下来的工作到底做成做到哪儿算 Ok，然后要花多少时间，要投入哪些关键点是什么去进行估算，我觉得我们可以跳出来软件研发角度来看，哪怕我们今天像我们三个人决定录一期节目，我们也是要去进行大概的估算的相关活动，它的难点在哪里？是不是这个地方需要更多的时间？

我们是不是应该缩小范围，确保我们的所有内容是来在一个小时40分钟这么一个一个时间段里面去完成对吧？

所以从敏捷来看，如果我们说敏捷这种小步快跑的思路，是需要你每一个迭代的给定时间内一定要有产品价值输出的话，从这个角度来看的话嗯，我知道有些人会认为反正你就是一周或者两周出点东西不用估算放进来做就行了，但是事实上我觉得你只是说你可能没有做显性化的，你没有落在一些工具纸面上的具体人日级的估算，但你事实上你都要考虑，不管是产品经理就是PO或者是Scrum Master，还是真正的开发人员来讲，它事实上都要考虑，如果如果要出货是下周五，那么下周五之前我能做什么？

难道不是估算吗？这个也是一种估算，对吧？

所以我觉得有的时候这个问题，这就是我估算派，嘛我估算派我肯定是觉得不管你显性隐性，你事实上已经在做了，只是说我们不要太僵化，对吧有？我们有一些各种的手段去做估算，做到什么时候做成什么样子，我看到王宇应该是有一些想要互动的。

精估刚才回应马菲菲的精估这个东西的话，一般的话我也是在我带的团队的话，也就是在进入迭代马上开发的时候，让他们去再估算一遍或者拆分，就像所谓的 sprint backlog的一个估算成小时的数字，这是可以的。

因为的话其实这种估算的话是反逼着嗯也各角色的话，把设计重新其实估算就是设计，你如果给不出估算的话，你设计也不靠谱，我们做东西的话是不需要设计，很大部分的一个结论的话是需要的，对吧？我们不是蛮干，但是这个时候的话，我觉得我突然想说另外一个东西是这些自大的程序员。当然了这个话题我个人认为跟估算相关，但有不那么相关，是因为之前的话我觉得我就是一个非常牛的程序员，我写代码的话要高于一般的程序员的代码对吧？

但是这个事的话你知道在什么时间点的话，我被打脸了，在我结对写程序之后，因为你会发现的话，当我把我的盒子打开，把我的思路打开，把我的让别人看到我的写的东西的时候。完全透明出来之后，我发现有几个东西，第一个我跟不上别人的思路，我发现的话我的思路和别人的思路在碰撞，在打仗，也就是说别人走的话，按照别人的走路的话，我的思路根本就跟不上。另外一种思路的话，我们看代码的话，我看代码的节奏和别人看代码节奏也是不一样的，经过了长时间的结对编程的训练之后，我发现我看代码的速度可以和之前的话提高一个数量级，我抓问题的关键点可以提高一个数量级，我对编程的任务的专注度可以提高一个数量级，这个数量级的话坚决不是一倍两倍三倍这个概念，这坚决不是一个数量级的概念。

如果是这样来讲的话，我回过头来看我之前我的一个编程的状态，我个人觉得我根本就没有到位，我只是自己觉得我自己厉害了。这样的一种过程的话，其实我们通过这种估算也是强制的让大家进行讨论。你是我推行阶段编程的话，可能大家实在太太困难太大了，对吧？我不想把我的一切的东西，这个场兄若怀的告诉别人对不对？对吧？我觉得我没面子有可能对吧？或者是我要守护这点我的自尊对吧？

我个人认为的话，我们为了共同的目标打开这个盒子，让这个过程透明起来，或者说我们用不同的眼睛去看我们的交付过程难道不是更好的吗？对吧？你非得守护着自己那点专业，所谓的专业操守，这又有多大的意义？

你守护完了之后你就有专业操守了吗？咱们拿出代码咱们聊一聊，对吧？你把你的代码拿出来，我把我的代码拿出来，咱们一块说一说，这些东西的讨论我觉得才是更有意义的，所以很多程序员不愿意把自己的盒子打开，我觉得就该拿鞭子抽。

什么这个东西，你们这样的思路是拖整个中国软件行业的后腿，你知道吗？

我意识到王宇在讲的故事说有的时候可能我也有这种感受，有的时候你会感到软件的工程师他们会比较介意你问他工作量，我觉得这是另外一面，这是估算中的难点，让程序员他很谨慎的一个性格，他才会干这个工作对吧？

他对自己的专业他是他是有信念感的，当你跟他协商说你可不可以大概给一个可能的对吧？

或者是要求你必须要给出精准的人日级的估算的话，他们通常还是会比较犹豫的，在我过往的需求管理还有排期管理工作中，这就几乎每一个工程师他们都有这种困惑，我也非常尊敬这一点，我觉得这是本身对自己工作的一个专业度。

然后它就是有一定的矛盾，我们如果是站在软件管理，站在项目管理或者站在产品管理的角度，你可以理解为 pm项目经理对吧？PO大PO们，大家肯定是希望说有一个大概的时间计划的，我觉得这本身它天然的就是矛盾的。在这里我就觉得说作为工程师，他们还是要意识到说当你是做一个协作的时候，对吧？当你做协作的时候，你要考虑到你给出的时间计划，它对于其他人来讲非常有价值的。

虽然最终有价值，真正有价值是你出来的那段可运作的可工作的软件，但事实上这个时间计划本身也是有一定价值的，所以这个事还是觉得还是要搞。

还有说有一些管理者他基于对团队的保护，他会倾向于不希望暴露我的容量这一类的信息，这种情况最常见的就是甲乙方这种模式对吧？

我们如果做过甲方呃，当过甲方面向乙方的时候，乙方到底能干什么干干成什么样，其实你心里没底的，所以很希望乙方给出精准的估算，还有排期计划清单都要给清楚，需求清单时间计划给清楚，而乙方本身肯定希望越不透明越好，因为这是一个合同，如果我承诺的东西越具体，我就越有可能去打偏了，这个本身是由软件它的复杂度造成的，对吧？

我们在敏捷这个知识体系里面领域里面，大家也知道上下文软件它不像一般的这种土木类的工程，你是可以肉眼可见的制造质量和进度的，对吧？软件你就是很难，有的时候你不测你都不知道，或者是集成的时候出问题，所以软件本身有这个复杂度，所以这里从这个角度我觉得也能理解一些软件这一边的管理者，他会倾向于不对外暴露自己的一些估算的信息，或者是倾向于笼统的去给，这里面我觉得至少有两点可以做，第一点就是说我们要怎么去建立安全感，哪怕你是个甲乙方对吗？

甲乙方的协作如果没有安全感，这个项目在开出这个味道也是有问题的，有可能是导致失败的。

所以安全感雇主和交付对象的安全感是一定要有的，不管你是内部的加一方还是外部的加一方，这是第一个角度要做的对吧？第二个角度要做的，我觉得大家要提高的就是怎么去估算，就是估算要奔着真正的价值方向去做，而不是要把它做的僵化变成一个人日变成一个考核，特别是没有办法对人进行考核，对吗？

我们很难讲说一个工作做8天，这段代码一个程序员写8天，它就是一个有价值的程序员写两行，俩小时做完了就是没价值的，对吗？这个软件它也不是这个规律。

所以我觉得听到这儿的话，我就是有感而发这一点我也能理解说他对于估算比较排斥。

作为估算派的话，我就像建议不估算的一派喊话，好看看悟空有什么感慨吗？

有一些感慨的话确实是这个样子的，我们原来在早期可能做一些甲乙方的一些工作的交付的时候，就是签固定价合同，希望需求更早的时候就能够明确下来，希望自己做的工作就不要在过程中产生变更，因为变更就意味着浪费，意味着反攻什么之类的这样的一个状态，我感觉这个意识好像十几年下来，因为我是一12年14年左右的话去就开始从事软件研发这一块，我发现十几年过去了，这个意识好像还是植根于大家的这样的一个心底。

我自己曾经去尝试过做这样子的一些小小的尝试，例如说跟我的雇主可能就不签这种固定价的合同，用这种敏捷敏捷合同是或者说敏就是敏捷交付，我可能会更少的一开始给他做一些交付，让他先明确自己要做的这个事情大概是不是有价值的，就不需要他花那么多的银子钞票。对，然后在这个过程中去找到适合自己的一些方向。从我的一些经验里面来看的话，这样子的话实际上你的交付时间可能比你签固定价的时间还短。

第二个这一个甲方的这样的一个满意度可能还更高一些，同时你交付出去的东西，你自己的感觉的成就感也可能会更高一些，但是可能愿意和你去做这样探索的客户会偏少一些。你回到企业的场景里面的话，得些实践得有亲身感受，然后才能去慢慢校准过来的一种思维方式，通过讲的话还是会觉得有一些含糊，对。

还是得去做，就是说还是需要打个样，所以都需要有经验的人的话去带着大家，尤其是对软件交付的过程的话，有一些思考的人去带着大家去做事儿，我很认同这种事情，所以的话现在也带着很多的团队在做这块事，但是我也很惊讶的发现，很多事的话，其实之前的这种培训或者是什么讲的，其实一些关键点没讲到位。

说到这我觉得有一点我们还是要聊清楚，因为我们今天大很多内容都是聚焦于工程过程中，从软件设计角度它是需要去估算的这里，但是它没有说清楚在敏捷模式下，敏捷模式下要不要估算，敏捷模式 Square有没有再要求估算，包括我知道我们很早很早以前王宇在给我们做咨询顾问教练的时候，曾您带着我玩相对估算，当时我好多年前当时还是挺打开新世界大门的，有那种t-shirt size是吧？就是SML，XL是吧？

然后也有动物的，什么老鼠大象对吧？这还有当然飞波纳气竖立，那么我觉得这一点我们还是有必要聊一聊，避免大家以为我们在这老聊软件设计，你要你也不能证明说我相对估算我要怎么玩。王宇这个地方你要不要给大家再补充一下？

首先的话不要去打扑克，打扑克的话是我见过，首先这个东西的话更是一个教学的教具，现实的过程中的话，我只说我从经验上没见过任何一个在现实中的软件团队，除非是那些压力不大的，我在深圳这边的所有团队的话都没有使用负荷估算，这是我的经验，太费时间了，而且他给出了很大的一些数字，根本就没有使用。

你说你给出这100 100个点120 200个点，你说那有什么用对吧？无穷还有一个无穷的标志，这不扯吗？你无穷的话就不估算不就得了吗？所以你用这东西干什么，那个东西更像是教具不要用，我们更倾向于用的什么什么方式，要么就我之前在ThoughtWorks的话，就是石头剪刀布出12358对吧？就估算就得了，这是一种方式，但这种方式的话，我们现在用估算2.0的方式相互排序，先按照大家认可的工作量大小排序，排序完了之后我们认为哪个是一倍的工作量，哪个是两倍的工作量，这个方式也更快一点。

当然了对于scrum或者对于标准的敏捷过程来讲，从来都没有说必须要估算的，这件事情我个人觉得只是它需要落地，落地的话它就需要有这个东西。

而且我认为各位在告诉你们的一个非常小抄级别的东西就是说任何一个需求一来就要估算，这样的话才能从沙子需求到板砖需求，这样的话我们进到我们池子里的需求才是差不多的需求，你别好进来的需求到底坑多深谁都不知道对吧？这是我的经验。

好，我插句话，因为前面讲讲到一些点，可能有可能大家不知道我做背景补充，第一个是打扑克的估算法，指的是一套玩法，那是真真正正有一套扑克的扑克，长得就跟我们玩的扑克一样，只是上面是有一些数字对吧？有一些给定的数字，12345也有无穷大。好像我记得那套扑克里还有什么咖啡一些logo图，所以刚才王宇讲的打扑克的估算话，指的是一个团队拿着那一套扑克互相出数据，出数字，你觉得3天我觉得5天对不起大家再补一下，如果有兴趣了解，大家可以去上网搜一下。

然后还讲到了一个什么？相对估算是吧？用飞波纳7数列或者是用12358这种给定的数字去估算，这也是估算法。然后最后我们刚才你也讲到了说敏捷好像我也记得敏捷没有特别强调的，强调我们要去要去做估算，我这里我有一个发散点，想你在讲的时候，我突然间有一个感受，就是敏捷他为啥不强调，因为他敏捷并没有强调包括Scrum具体说Scrum好吧？

Scrum并没有强调软件工程过程的交付细节，所以它指的是一个产品级的管理，其实咱们前面几期讲gram。我也是这个观点，你对一个产品进行管理的话，你肯定要采用一些成本可控的估算模式，否则的话他就进入研发过程了，也就是说你不要做两遍，我看王宇有什么补充。

我都我突然有点断弦，就是说到这样的一个估算的话，再告诉大家还有一种估算的话叫power of 2的数列，也就是12 4 8 10 16、32这样的一个数列。当然了和123512358的这样的一个斐波那契数列是不一样的，数列的话更陡峭，这是但是估算到后来的话，我又开始使用了这种T恤size，什么ml sxsxl一般的话可能有一个事情的话，开发人员的话很容易把这个数字联想成人天，或者是乘以一个神奇的系数成为一个天数。

我在指导具体团队的时候，我不care这个东西，我也不说这个是人天，我不说这个数字，一是一人天还是二，我就说它是一，所以的话做工具的时候你一定非常的注意，就除了到这种金箍的时候，可能会出现小时人天的数字之外，在这种粗略的这种板砖级的这样的一个需求的估算的时候，就点数就给他一个数字就行，这是我的给的一些信息，对对到最后的话 t shirt size的话，我们更倾向于用T恤衫子，因为 t shirt size的话大家就不没有一些直接的应对关系了，到底一还是对应二还是三，就让做事回到做事儿。

我觉得还可以再补充一点东西就是说，我们其实讲了很多个层次的估算的，这些估算的话，我感觉它最后可能会对应一些对应一些生成出来的统计图表，例如说我们就是伸指头这种12358这种对于需求管理过程的估算，它可能生成的可能是对于我们需求进入来的这种容量，我们可能会是一张表，对吧？

然后他可能知道我们燃进就是燃下图，对我们烧了多烧了多少，烧了多少需求，或者说我们这个需求的容量是多少。另外一个的话就是我们做了这一个详细估算，金箍之后就是我们具体团队里面工时上面的一些统计，不知道两位在两位在这个点上面去看来的话，它是不是其实是分了不同的仕途的？

我的感受上是大家可能在提到估算，因为用词不够精准的一个情况之下，容易把这样的一些试图去做混淆。

直接给一个反馈，燃尽图不要用。为什么给这个反馈很多？

其实我有的话的话，我直接就告诉你答案，就不要用这东西，你也不用问为什么，因为我得需要飞，就是说给你补充太多的信息了，有的时候你不要以为的话，培训的时候就告诉我们有燃尽图的话就燃尽，但是很多关键点你可能根本就不知道，比如他燃尽的是什么，比如二位可能都经过Scrum的培训，对不对？

我问它迭代中的燃进的话燃的是什么玩意儿？当然了我就不让大家去想了，我直接告诉答案了，它燃的应该是对任务的重新估算，还剩下的小时数的重新估算，但是有多少团队的话会重新估算，这是第一点。

第二点它可以燃的是任务的数量，这是课程的标准的答案，但是有多少个参加过索朗培训的人根本就不知道这东西。如果这样的话为什么要大家用燃尽图，所以很多东西只是培训上的一种教学点杀时间用的时间杀而已，所以我有的时候就特别有点义愤填膺。

好你稳定一下。

我事实上我也受培训学Scrum那么多年，我们在团队里很少实践燃尽，如果说他项目级的还是会有一些燃尽的，我们作为小团队的管理者就会把这个东西把它给保护起来，团队内就不再去做燃尽了，团队对外我们还是会给的。

所以我觉得也就是说刚才王宇也强调了燃进的有的时候你是要去进行进度管理，从这个角度你看看就从趋势上来看，这个项目级的交付有没有风险，或者是产品大规模产品级交付有没有风险，对吧？所以我觉得要分段，然后刚才其实悟空大概提了一点点，然后一点点问题，或者说一个探讨的细节时间有限，我们也很难打开，我觉得我们可以在礼物环节做一个关闭。

我觉得我整体上基于悟空最后的问题，我的想法是这样的，当我们谈估算或者说我们今天重点在谈需求管理中的一些跟工时工作量跟计划有关的一些事情的话，我观点就是估算还是一个很细颗粒度的手段，然后做它有很多方式可以去做，前面我们也讲到很多工具和技巧，那么最重要的是要关注你要在什么阶段，用什么目的去回看你采用哪种估算的手段，但至少我觉得是有两大块的，第一块就是需求管理角度的估算，一定要注意渐进明细，不要投入太多的，工作量。

这个地方我们常见的就是相对估算法里面的这些东西，如果将来有时间我也很希望想要跟大家探讨，就是我们在大规模软件，我现在在服务的是大规模软件团队，它在需求管理阶段是怎么通过限制需求的颗粒度再结合估算去进行在进行管理的，这是指的纯需求管理的角度。

第二个角度就是工程过程的估算，工程过程的估算，我的观点也是说我们认为估算是一个支持设计的，或者是判断设计活动到底有没有达到一定的质量标准的一个探针一样的这样的手段，所以工程过程的估算可以更多的使用。

人、日、人、天他的活动对象应该更多的就是我们研发团队的具体的工程师们，包括测试的工程师们，我觉得我整体上来讲，我还是倾向于一分为二的来看，我就先送礼物先讲那么多。

接下来悟空来说一说。

我们今天整个去聊了一下估算它就是缘起，缘起其实我认为还是一开始去讲的，源自于研发和产品的协作的过程之中，大家其实一开始没什么概念，会把一些承诺精细的这一个、绩效、人、天和需求风险管理的这些估算混在一混为一谈了，所以我们今天想要给大家送的一个礼物的话，第一个就是要把拆分开来，你要把它区分成这一个需求管理的过程和工程管理的这样一个过程，然后在需求的上面对于使用估算这个技术不要有太大的心理障碍，我们只是为了快速的能让它产生一些流动，或者我们能快速的知道它里面有哪些风险，这个东西它并不是面向绩效去服务的，它是面向我们自己内部的协作去服务的。

而到了这一个真正的研发过程的时候，我们在采取一些估算的方式，其实是对于软件设计它的这一个详尽程度来去做剖析的，我认为的话今天想要去送给大家礼物和区分的，也就是这两个观念。

行，我的礼物的话是不管什么工程什么需求，不管怎么分，你别扯就别弄什么分，想用就用，不想用就算对吧？想听谁的就听谁的，但是干出屎事来的话别怨别人就行了，好吧？就这样。好。

好，王宇的意思是it's depends要结合上下文，大家不要僵化。

对，但是你事了的话，你的责任在你就得了，好吧？

今天就愉快的结束了，我们欢迎大家转评赞，下次节目时间再见。好。 王宇 47:07 拜拜。