敏捷圈的100种训练方法：敏捷教练修炼一
敏捷圈的100种训练方法：敏捷教练修炼一团队的工作效率如何衡量？比如说小学数学题，一个皮鞋匠10天造了20双鞋，那他的工作效率就是2双/天。效率是一个工作量除以天数所致，这个数学题已经内卷到幼儿园了，居然无法在管理界里计算团队工作效率。有人说那我用人天来除以天数，你试试？人天/天 = 人，这只能说明在固定时间里用了几个人，无法解释他（们）的工作效率。第二点那有同学就突然横插一杠，工作量不可以用“人天估算”么，非要弄什么故事点么？那我们先说说“人天”到底有什么不好，先说两点：第一点“人天” 能排期么？这个问题困扰管理界多年了，早在2000年左右出的《人月神话》第一章里就对“人天”进行了无情的鞭挞。那时候我自己还是个技术篓子，当然不明白为啥要鞭挞，后来当了项目经理才发觉：“人天”压根不能排期。比如说 10 人天，可以理解为1个人干10天，也可以理解为10个人干1天。那么问题来了，你告诉我这个需求是第10天交付还是第1天交付？
作为敏捷教练，面对一帮技术篓子，最头大的就是要把人天估算的法则拧成故事点估算的相对估算量法则。“人天”多好用啊。一个人，看一下需求，拍个脑袋瓜子，第一次拍砸了没关系，因为下一次还需要拍。这就是估算唯一性的坏处，因为没有别的估算方法可以挑，只有华山一条路，so far so nice。
直到敏捷的估算横空出世，感觉就是和这个世界作对的猴子，上帝随便扔骰子的量子，降临到这个地方感觉和团队尿不到一壶去的敏捷教练。反正对相对估算，不叫好的，不理解的，不想用的，不爱听的，比比皆是。
先简单说一下敏捷的相对估算是什么概念，敏捷用的是故事点为单位的估算方法，是用来估算一个需求（用户故事）的工作量。通常选取一个比较简单的故事，算2个故事点，那么如果一个需求量4倍于这个需求，那么算8个故事点。
不要问我为啥不用其他计量单位，这是创新晓得哇，创新！第一次！就好比人为啥要讲“一个”，猪讲“一头”是一个道理。它是用一个故事点的工作量为基准来估算另一个故事的工作量大小（相对估算），你可能在需求池里看到的需求大小会变成这个样子（pt=Point 故事点），比如按故事1为基准，故事2的工作量就是4个故事点，以此类推。
那有同学就突然横插一杠，工作量不可以用“人天估算”么，非要弄什么故事点么？那我们先说说“人天”到底有什么不好，先说两点：
第一点
“人天” 能排期么？这个问题困扰管理界多年了，早在2000年左右出的《人月神话》第一章里就对“人天”进行了无情的鞭挞。那时候我自己还是个技术篓子，当然不明白为啥要鞭挞，后来当了项目经理才发觉：“人天”压根不能排期。比如说 10 人天，可以理解为1个人干10天，也可以理解为10个人干1天。那么问题来了，你告诉我这个需求是第10天交付还是第1天交付？
第二点
团队的工作效率如何衡量？比如说小学数学题，一个皮鞋匠10天造了20双鞋，那他的工作效率就是2双/天。效率是一个工作量除以天数所致，这个数学题已经内卷到幼儿园了，居然无法在管理界里计算团队工作效率。有人说那我用人天来除以天数，你试试？人天/天 = 人，这只能说明在固定时间里用了几个人，无法解释他（们）的工作效率。
所以你压根不知道你今后面对的团队是什么鬼样是吧，你也根本不知道你以后的需求用“人天”估算后到底其容量怎么样是吧，那你怎么答应客户提出的要求，比如我的需求这个月能排上了么？当然能了，加加班就出来了。这次的需求这个月能做完么？当然能了，加加班就出来了呗。鄙人看起来，加班绝逼是内卷的一种，是人类幸福生活的杀手，是现在社会男女不孕不育的直接因素之一！
顺道说一下什么是内卷，就是你加班了，你没加班费，没有人为你多出来的时间买单，也没有任何价值产生可言。这就是内卷，所以竞争和内卷还是有区别的，竞争是实现人生价值的一种手段，要是竞争到内卷了，就要停止，从其他的路径再入手。
怎么能让团队接受相对估算的方法，怎么能用扑克法来进行估算，怎么能让敏捷的故事点估算变成群众喜闻乐见的一种项目文化娱乐方式呢？
靠培训和训练，还是应着我们伟人的那句话，前途是光明地，道路是曲折地。
第一次培训就遭遇到了滑铁卢，不是说不理解，是根本不想用。大家对于“工作量”这个认知是“人天”，基本上是认同的，要转变成相对估算量，何苦呢，况且我也不需要。就这！
结果和团队干了一架…
要诱导他们使用敏捷的估算量，讲好处是不行的，要让他们了解怎么认知“容量”这个概念是首当其冲的。故事点其实是容量单位，人天其实是速度单位。
于是举了敏捷“向前一小步，文明一大步”的例子：假设我们从这个会议室出发，你们跑到门口要花多少时间，你们估算一下，以分钟计算。
大家开始举牌，有说1分钟的，有说5分钟，还有说1小时的，我和团队说，这就是速度的意思吧，每个人的能力不一样，到目的地的时间估算自然也不一样。
那你们再看看，我们这个会议室出发到公司门口大约多少米，公司在写字楼里，所以距离也可以估算得起来，大家再估算了一下，有写100米的，有写120米的，有写90米，基本上都绕着100米左右打转转。
这就是容量啊，长度就是一种容量，其实“人天”的问题在于人的能力有大小，对一个事物看待的话当然有快慢之说了，不过容量是更“客观”的存在，不管能力大小强弱的各位成员，可能估算容量都差不多。
团队不语，貌似被我的例子制霸了，于是开始扑克估算。
事实上扑克法只停留在我的课程里，之前没怎么打过，所以这一次开始扑克训练我也很激动啊，你们不要笑，有些敏捷老师，其实一听他的课就知道没怎么带过敏捷项目，他们体会不到理论带来的快感，只能照本宣科，纸上谈兵，高级一点的貌似带着VR镜头，就以为已经亲临现场了，盯着某些关键部位就觉得嗨得不得了了。
有关扑克法的估算方法，可以到b站自己去搜索一下，关键字“扑克法”，不要单独输入“扑克”，否则你可能收到的是“德州扑克”或者是“腾讯斗地主”的视频。
而后的实践中用扑克法逐渐变得清晰起来了。我个人对扑克法的好处认知：
认知一
尽早消除分歧，扑克法中有一个非常重要的关注点，拍出最大和最小的估算的都要讲讲为啥。现在发觉这个过程很有必要。有可能拍出大数的同学，不一定是想的多，也可能是压根就不懂！而拍的少的也不一定是有效率，也有可能是他更不懂！所以需要拍出中间数的那些个团队成员倒过来训导一下，使大家达成一致。其实吧，“真的懂”分三层境界：听得懂，做得来，说得出。“说得出”乃最高境界。
认知二
不盲目崇拜专家，估算需要各路人马一起来估算，大家都是专家，大家的意见都要听，专家广听言路，察纳雅言，达成一致，多美。否则一个人绞尽脑汁，容易头发散尽，连女朋友也找不到了。
顺便吐槽一下乙方和甲方砍价的过程，一般乙方团队拿到需求，找一个资深人员（CEO，chief estimation officer首席估算官）负责估算，说是10天就报13天，说5天就报7天，故意往上多报几个百分比。然后等甲方采购上门砍价，双方本着无根据无理由无背景的不学无术的无厘头精神，互砍一阵，表面是砍了一大块，其实留了个全面预算，采购完成了KPI保留了面子，乙方达到利润率留下了底子，耶~，大家“双赢”得很。
不过扑克法有一点必须吐槽，太浪费时间了，虽然不允许一直打牌打下去，不过讨论起来那是玩命得讨论，有时候看他们谈兴正浓，意犹未尽，掐死他们的心都有了。
敏捷最难跨的就是估算这个环节，一旦跨过去，就明显能感觉到团队在预测方面的这些能力：
一、可视化管理
燃尽图知道哇，业界鼎鼎有名的控制进度的图表，长这个样子：
蓝色的属于标准曲线，每天匀速完成多少个故事点，自然就有了这条匀速曲线，也是我们控制进度的基准。
红色线就是实际团队工作完成多少个故事点，之所以是下降是因为燃尽图计算的是还剩余多少个故事点。如果红线贴着蓝线，双股线你中有我，我中有你，你是风儿我是沙，缠缠绵绵到天涯，实在是两条有温暖有情意的一种图形。
也有难看的，给你们看一下，比如下列图形：
这个明显看得出之前不努力，到最后一天加班了，明显的学生拖延症，也不晓得质量怎么样，哎…
还有这种：
哎哟我去，这个一定要放回顾大会好好回顾回顾，每天摸鱼是么，也不晓得啥原因，最后都没完成。
所以可视化管理能帮你做好团队最害pia的一件事情：根本原因分析（回顾大会会在其他章节表述），不过前提是你必须能看得懂燃尽图。
二、了解团队效率
有了故事点估算，自然会有很多指标产生，给大家看看：
这个指标就可以完美得显示出这个团队的绩效，因为敏捷是按一个迭代周期走，所以每个迭代周期（横轴）你就可以记录：
01他们的容量（多少人，2周迭代一共多少理想工作小时）
02计划的故事点（本来开头安排了多少故事点）
03实际完成故事点（实际上产品负责人确认了多少个点）
04变更点数（这是我自己加的戏，团队一直说老是有变更打扰他们，所以我就干脆立了这个指标，你们自己看，到底谁在胡说，一目了然）
05团队速率（通常是实际完成的故事点）
06完成度（实际完成/计划完成）
07团队效率（完成故事点/团队容量，看得出一天他们完成了多少个点）
其实还有额外的指标，比如每个人的计划工作量，按道理来说，同工同酬，如果有些人拿着高薪不干活，这种人就应该就地解决。所以有了这种让人胆寒的指标。
要是对这些数字无感，那么把他们做一个简单的图表：
如果需要团队的绩效改进，最好能追踪团队的速率，如果呈缓慢上升，就说明团队在不停地改进，这个就是学习曲线理论。
三、管理客户需求
回到文中最初的那个问题，客户问，我的需求什么时间可以做好？回答这种问题首先要做好心里建设，如果没有图表，没有数据，那你需要一副处变不惊的厚脸皮，以及一副饱经沧桑的专家的模样：我想大概可能也许是3个月后吧。
此时客户不会掐死你，他们还需要你做交付，但是绝逼不会信你。客户关系为啥那么差，为啥？还不是因为你信口雌黄，天花乱坠，一簧两舌，轻若寡言，最终言而无信导致。
所以需要一个小小公式来建立起客户和你之间的信任，做好客户的干系人管理，也需要故事点管理。
比如针对上述问题，假设客户本身的需求有30个点，而排他前面的大概有100个点有待开发，所以你需要解决掉130个点的需求，才能认为客户的需求达成，那么怎么算时间？
假设我们2周一个迭代，而团队之前迭代中完成的平均速率为30个点，那么客户的完成时间有了没？大约4-5个迭代之后可以完成，也就是8-10周后可以完成客户要求。
我坚信这么一说，客户绝逼不会不信你的推断过程，不过他们会跟你搞为啥前面要等100多个点才能轮到他们… 所以摁下葫芦起了瓢，客户关系不是那么好搞滴…
四、结语
敏捷项目的基于故事点的优点，至此基本都已经罗列：
可视化，可预测化统统因为有了故事点的存在而变得可落地而非纸上谈兵，这是项目管理的一个比较好的实践。
用数据说话，是最有力度的一种表达方式，而这个数据归根到底，离不开故事点的使用，并逐渐扩展到整个敏捷项目的各种管理细节。
目前的团队，已经不太能接受“人天”，比较前一段那种声嘶力竭，誓与“人天”共存亡的呐喊声，都转变成了“真香”的赞扬声。
改变，是不容易的，而跨过去，前面是片天…
文章来源：HPEVIP项目管理老张
