敏捷-故事点估算基准、基准的选择相关讨论 -- 敏捷家微信群讨论纪要-2020-05-12

[muerjie]

问：各位敏捷家人，你们有没有想听哪个公司，或者团队的案例分享？

• 想听京东、平安、网易、银行类讲讲具体技术实践的落地
• 小米MIUI开发团队、携程
• 京东、网易、ThoughtWorks
• 想听听美团的
• 京东、阿里巴巴、腾讯、网易、滴滴、字节跳动
• 字节+1

问：有没有“翻车”案例的介绍啊？

• 有那么多不能翻车的，为啥还去干那翻车的活儿
• 我做过手机的，1500万行代码～同时辅导一个项目上的两个团队，一个成功，一个失败，这个项目一共有20个团队
• 现在行业水平与十年前出来讲的水平差不多
• 试点和人强相关～推广则和公司管理强相关～不要过于挣扎

问：怎么算失败？ 就是公司回归到没实施敏捷辅导之前的状态？

• 就是落地后的不良反应吧
• 哪有失败的，就是没达到预定的目标，先要定目标，才有失败。定目标才是最难的～
• 先有成功的度量标准，才有失败。没有成功的度量标准，就可以安心混日子，一直立于“不败之地”，全靠后期PPT的虚荣指标瞎扯

问：对于故事点估算基准，有没有易操作的经验分享？

• 一周一周的，就别用故事点了。2个月以上的，值得做一次，《持续交付2.0》附录B中有相关的内容
• 要衡量效能，总得有个客观的量，在这方面，点数没啥用，故事点也是一个粗的不能再粗的主观数据
• 不求他准，而是大家认可容易操作，这看的是趋势
• 趋势也没啥用……，你看点数，我就可以把点数估计很大，我自己带团队，tw的产品团队，单周迭代，每周交付的点数没啥规律
• 这是个管理手段，如果一线管理不认可不监督那就没辙
• 我们只看完成了多少真实的需求，估算大约3个月才做一次，当时是3个月发布一个版本，十几年前了。不要神化敏捷……根本没有那么神的～
• 现在不是神话，只是找一个方式衡量“量”
• 如果按照 吞吐量，通常会遇到另一个问题，就是需求颗粒度 大小不均匀。导致干系人对 需求交付数量的不认可，对效能数据产生质疑。
• 按个数差距太大
• 吞吐量 + 需求颗粒度相对均匀，最终数据持续增长 是可以的。DevOps里面是这样做的。
• 但是实际落地也会遇到问题，就是需求颗粒度相对均匀这一点，所以对量的衡量就没辙
• 需要对需求颗粒度有较为清晰的标准，并且执行到位。吞吐量 才有价值。
• 颗粒度有是量，比如不超过2天开发
• 敏捷的度量方式是 速率 也就是：点数 + 固定迭代周期（但是点数估算，要能够做到 团队估算 并且基点对齐）；DevOps的方式是吞吐量， 但是要做到 需求个数 + 相对均匀的需求颗粒度（否则度量数据很漂亮 但是没人信服）
• 每一种方式 都有利有弊 关键看你怎么选择 以及能否做到扬长避短。另外，度量尽可能简单 、注意成本 ， 不要本末倒置 搞得太复杂就不太好了

问：基准怎么选？

• 很多团队在时间过程中，1个基准点对齐 1个理想人天（不具体到人）；但是你可以根据你们的实际情况来选择，没有绝对的标准
• 我的想法是：还是和时间相关，一人天为1，是团队小组决定。不是一个人，尽量消除差异，另外这个过程也是更了解需求技术实现的过程
• 举个例子： 如果你们公司的需求拆分都很到位，基本颗粒度都比较均匀 ，完全可以使用“吞吐量” 来衡量。省去了点数估算的成本（但是也失去了点数估算带来的一些好处）。如果你们公司需求颗粒度不均，更加适合敏捷点数估算的方式，而且优点更多。
• 怎么算均匀？你们衡量均匀怎么衡量？
• 《持续交付2.0》上写了，少于3天。书上都有答案，还有案例
• 另外，颗粒度均匀要和产品需求的特点吻合，选择适合自己团队和产品特性的需求颗粒度范围和迭代周期 。
• 所以还是回到了估算，没用点数，2013年以后就不用了，很多是花架子
• 这个基准会用于团队间横向对比么？要横向对比更难，虽然横向意义不大，但是总有领导要求
• 对于都是短期需求，没啥长期计划的，就是人天，挺好
• 都是人来估，客观性始终是问题，这个不过不重要。现在是想找一个标准大家都能轻易的理解，和它做比较。一个需求可能有客户端，前端，后端
• 互联网企业会好些，整个团队按产品管理，业务和技术都在一起，沟通紧密，没有太多量化衡量速率的要求，以实现业务价值为主，毕竟技术的工资也要看业绩奖金～业务和技术分离的企业，总是更多的管理成本，比如需要估的很准
• 我们是互联网教育，两周一迭代，也有单周的，小瀑布。小周期，看人天