故事点估算可信吗？

[1000copy]

故事点这个概念，看起来鬼鬼祟祟的。

提到故事点，必然讲到，“不是基于时间的度量（如小时或天数），而是一种相对的估算方法，用来比较不同用户故事的复杂性或工作量”。

谁懂你为什么不用具体时间，而是用相对量？

敏捷联盟不是鼓励勇气和以客户为中心吗？客户真的看到你的故事点，然后如何和他的时间期限比较呢？

我问过一个行业内标杆实践企业的员工，当你估计了一个故事点的点数后，你怎么估计它的时间？

他说，我们项目组约定好，都是一个点就是一天。

这不是障眼法？…干脆一点，你这个月底能不能完成？当你故作专业的时候，客户就只能流氓起来。

我一度以为这个肯特贝克的发明，因为故事点和故事两个概念太接近了。因此我有点怀疑肯特贝克了，然而不是，我查了下，是 Ken Schwaber 和 Mike Cohn 主要再说。好像他们两个都是搞 Scrum 的。

确实，在《极限编程解释》一书中，肯特贝克并没有直接介绍故事点（ Story Points ）这个概念。

你看，敏捷联盟如果剿灭董卓的 18 路诸侯一样，也不是铁板一块。

https://projectmanagercc.github.io

[kingbill]

因为在实际执行的时候，同一个工作量的不同工作可能会用不同的时间。
故事点估算只是估算的工作量，而不是完成工作用的时间，而且是按倍数类比估算
可以先把《 Scrum 精髓》看一遍，再来回看你的这些问题

[tilv37]

实际运行的时候，至少我们这里还是对应到了一个故事点等于 XXX 小时，换汤不换药。[狗头]

[1000copy]

@kingbill 老板或者客户问你啥时候拿得出来？我猜你会这样回答：“我们估计了故事点，点数是 xx 。你去看看《 Scrum 精髓》自己就可以换算为时间了”。

[1000copy]

@tilv37 是的。所以说是障眼法。。。

[kingbill]

@1000copy 我说它不一样，你非要认为它是一样的，可能故事点是啥并不重要了，你就按你想的用就行了……（而且我上面告诉你故事点是啥了）

[1000copy]

@kingbill 所以你的故事点如何换算成时间呢？

[kingbill]

故事点和时间没有严格的对照关系，比如：某团队一次迭代一周，团队一周可做的故事点大概是 12~15point ，那就在 planning 的时候根据优先级等要素选出 12~15point 的 story ，迭代结束的时候看是不是成功了即可，同时这次迭代成功的故事点数又做为以后的故事点评估标准。即：敏捷这个东西看的是 business value ，而不是工作量。只要能在迭代中完成指定的业务目标，工作量的大小不是特别重要（比如，团队这个迭代只完成了 5point ，但也完成了业务目标也可以接受，但在 retro 的时候就需要研究一下 planning 的时候是不是估算有问题什么的）。总之呢，这是一个系统工程，你单独的看某一部分意义不大，所以我推荐你先去把书看一遍，先知道 scrum 是个啥怎么回事，再说里面具体的概念怎么解释

[1000copy]

@kingbill 关于 scrum 我看了 n 本书。反复看过。因为我作为 ScrumMaster 要实操到我带领的几个团队，这几个团队有自己的业务目标和技术特点。我遇到疑问，这些疑问需要搬开或者解决，从而赢得团队的支持。所以不得不多本对照看。并且边做边体会改进。

我看到了敏捷联盟那帮人的天才他们的创造性，也看到了得意洋洋，意气风发，看到他们逃出重围打烂过往的陈腐和破破烂烂的旧框架比如 ISO9002 ，CMMI ，IPD ，RUP 。也看到他们的局限性，他们的固执和偏执。我喜欢这些人，希望成为他们的朋友，但是也防着这些人，因为他们主要是程序员和方法论者，但是缺少并且排斥成熟管理者的经验和智慧。

你讲的内容显然不是你的看法和实践，其实就是转述书上的内容。我质疑的就是这些内容。你则再次拿这些内容回应我的质疑。这就循环论证了。

一个采用 Scrum 方法的团队，不是生活在真空里，不是自己的理论逻辑自洽就会被支持，而必须正面的对待来自利益相关人，团队成员，客户的质疑和反馈。每一个团队创造或者采用某些方法有他的独特上下文约束，独特见解也会有他的局限，这些方法应用到自己就需要去芜存菁。自根据自己的情况做价值和代价分析。


比如我看到很多人采用晨会，但是我认为这个东西的存在的形式大于实质。我因此会限定时间，很快搞完。

比如看板。贴纸条。稍微复杂一点的或者相关性很强的或者需要分解组合多层次的任务就不能这么玩。我看到很多团队的看板都是几个月前的没有更新的东西。还不如直接软件工具上做的效果更好。所以这一块一般我们用软件做。

比如说我看到故事点，好处是这样可以让开发人员压力减轻。明明直接了当的采用时间大家都懂都好交流偏偏搞一搞什么故事点。这样的压力减轻真的没意思，不如直接面对估计的压力，多做几次 WBS 多学业务和技术设计方法，累计估计的准确度来的更好。

对于结对编程和重构也是多次尝试找到一个合适的时间点和时间段。

每一个选择我都尽可能深思熟虑并做价值代价分析并尽可能和团队成员沟通合作，争取大家的意见和支持。并用真实的团队目标的达成来形成正反馈。让每一个人在每一个迭代中看到团队的目标的实现和个人的成长。而不是自说自话自鸣得意。这本身就是敏捷的一种精神。

[1000copy]

所以，我看你说你的那本书说的不少了。不如说说你的实践。你是怎么做的？你的角色是 ScrumMaster 还是团队成员还是利益相关方？没有人质疑你的观点吗？你如何回复他们的质疑？

[kingbill]

我们就是这么做的，几乎没有任何的“本土化改进”，就是按照 scrum 去做的，我是 SM ，前期累一点，偏技术管理，2 、3 个月以后大家习惯迭代的节奏就好很多了，我不明白你为什么看了这么多书还不明白应该怎么做。

在我来看，scrum 是一整套体系，不能断章取义，尽量完整使用一段时间再看是不是有不适合团队的地方。

我们一开始也很难，可能是我运气好，碰到了希望和我们一起用敏捷的 PO ，PO 从不知道怎么写 story ，不知道怎么描述我们需要的 value （她知道业务价值是什么，但不知道我要她写在 story 里的业务价值是什么），有时间还会和我讨论，比如：你真的觉得 PO 应该无时无刻和团队在一起办公吗？然后就是聊，改进、再聊、再改进。

然后就是开发团队，可能因为我就是开发出身，所以感觉这个没什么难度。你从心里尊重他们，他们是有感觉的，不管活有多多都坚持每天整个团队 code review ，就是我每天找出一段有代表性的代码，然后投到投影上，大家一起 review ，畅所欲言，谁都可以说，想到什么说什么（这点也很重要，做为 SM 要让团队成员说话，还要注意大家涌现出来的想法）。然后我再结合大家的意见把我修改的代码拿出来和源代码 diff （这是因为 team 一开始的技术水平确实参差不齐），慢慢地大家写的代码就越来越像一个人写的了。

每天站会，不是形式，不是为了汇报进度，昨天我做了什么，今天我要做什么，我还需要谁的帮助。三个问题都要说，重点在第三个问题，但是要让大家能说出来我需要什么帮助。这就和前面的实践有关联了。比如：SM 不能让大家被 100%占用，甚至 80%也不行，我们一般也就是 50~60%，这样大家才能闲下来，这样才能帮助别人，只有你能去帮助别人了，你才会认为你需要别人帮忙的时候，别人回来帮你。至于前两个问题，又涉及到 planning 的时候的 story 评估，必须是开发团队自己评估，自己认领的 task ，如果是被指派的那大家就对别人干了什么，要干什么不感兴趣了。如果每个 story ，TA 都参与评估了，TA 才有可能会关注这个 story 最后是不是按照我当时的建议去干了……

等等等等吧，我也不是说我们就一点问题都没有，但这些都是一点点涌现出来，然后大家一起面对，一起解决的。

期间大家也会有疑问，你说的这样行不行，这个时候你不能独裁，行不行可以试试啊，试出来了大家就知道行不行了。当然，SM 得扛住压力，能去让团队去试。这个时候去“忽悠”PO 和领导就得看 SM 的本事了

哦，对了，我们的迭代是一周一次，开发提出过太短，要变成两周一次，我们也实验过两周，PO 先扛不住，强烈要求回到一周，而且正好当时也出了一次“事故”，所以我也就借机改回了一周（所以你看 SM 的忽悠本领很重要）

大概就是这样吧，不知道这些实践对你有没有帮助

[1000copy]

@kingbill 先回答你最后一句。你的内容对我没有帮助。

因为你的环境太 easy 。你的实践覆盖不了我的场景。

但是我会回复你，因为你太多槽点。

你的项目三角形，包括范围，成本，时间这三个维度都没有看到任何外部压力。所以你的实践方法对你都是系统内力，缺乏外部影响。系统内力不会产生外部运动。

直接说，与其说你选择了 Scrum ，不如说 Scrum 选择了你。

你的场景下，用 Scrum 可以，用瀑布可以，啥不用一把梭也可以。因为你的方法没有服务的目标。

没有目标，无所谓方法。

所以你的场景估计故事点可以，估计时间也可以。

你的 PO 无可无不可，你的开发无可无不可。因为可没有利益，不可没有损失。我说的损益不单指钱。人家混弄你，你还真以为是因为你会忽悠。

你在忽悠别人，却还跟一句只要你信任他们…


然而，人心莫测世事难料。您的 po 可能换人，你的客户可能变得挑剔，你的老板可能焦虑，环境变了，本来你说什么人家并不在意，现在可能要较真了。

现在回到问题的最初。

你的故事点怎么样换算成时间？

你一直都避开这个问题。其实我可以替你回答，你想说的是，我走的是人民币，不走你的欧元。我不是非要换算不可。


你如果只做内贸，你当然可以自己玩。你想赚人家的钱，你就非要换不可。

就算你不换，你怎么知道你的开发不自己内心里面自己换？他如果换了，你的故事点是不是就变味了？



在一个问题，一个客户找过来，说侬的这个东西我 30 天内要用，侬做的出来？侬说，我的故事点…巴拉巴拉。你猜客户怎么看你？（注意，这里的侬和你，以及后面的侬和你，只是一个及物代词，不特指正在看文字的你。也不特指和我讨论问题的你。

兴致好的，说你不想做我的生意，我找别人去。性格闷的，说今天见到一个 nerd ，算我倒霉。再不好的，麻将过来，你看不起我还是看不起我的钱？

如果你有一套单独的估计时间的方法，还有一套单独的估计故事点的方法，那么为什么要搞两套？钱多烧的？

你以为这些都是假设吗？这些都是真实的场景，你一直避开不谈，只有一种可能，就是因为你根本没有处理过。你的干系人只有 PO ，你的老板看起来离你很远，

你好像接触不到客户。但是你以为你在搞敏捷，其实是敏捷再搞你。你只是一直掉书袋。你的大脑成为别人的跑马场，你还开心的说我提供了场地。

你见不到客户，但是客户会隔着若干层次穿透你。

你待在温暖的花房里，却奇怪的看着外边冰天雪地里穿棉衣的人，你们为啥不穿个小背心清清爽爽啊。

[kingbill]

看了你第一段感觉你就不想用敏捷，非要把敏捷放到瀑布里用（或者连瀑布都没用起来），你非要这样也没办法。
敏捷交付的是价值，不是功能。咱俩现在是两个频道，鸡同鸭讲。
你有你的场景，你判断你不能这么用，那你就不用就好了。

[1000copy]

@kingbill 你拳法乱了。

但是我乐于痛打落水狗，不仅仅是因为落水好打，也尤其因为这个狗乱咬人。

因为我有一个雄心，就是清理网上的垃圾，让正常人可以有立足之地。


就你做的这点马卡龙大小的事情，你敢言必称体系，

就你一个小小的 sm ，你来恩赐大家说话，

就你看过一本书就指导大家如何读书，

就你一个遇到不懂的，就鼓舌如簧的掉书本从而避开正面问题你来说什么敏捷。

就你舔着 ac 之间的大脸想要求我认可你帮助了我。

你连直面问题的勇气都没有，你连承认自己没有做过的诚实都没有。你敏捷啥呀。是你往自己脸上贴金，还是你往敏捷脸上涂 si 。


“腰有十文钱必振衣作响”说得就是你这类。

敏捷的基础是勇气是诚实。你的敏捷没有这些，所以是无源之水 无本之木。

你以为你用了敏捷你就真的敏捷了。一个名词一个形容词没有关系好吗？一个 Java 一个 Javascript 好啊吗。你这个我给你提一个词叫做油腻敏捷。请你不要再羞辱敏捷这个好词。

之前几年有一个叫太极敏捷的，算你的前辈，更加油腻，比你油腻百倍，幸好有识之士把他骂的满地找牙，现在它不出现哦，真的为民除害。大家稍微有点山脚的地，不至于一脚下去慢脚狗屎。他也叫敏捷，他真的就敏捷啦？

你没他那么油腻，但你也污染视听。把你从网路上清理，把你分类放到垃圾桶，甚至变废为宝，从狗屎到肥料，那也是为民除害。


曾经有一个我的手下，技术不错，却不在网上分享。我鼓励他做，他说，网上喷子太多怕被喷。

这样的人不少，他们爱惜羽毛，不愿意和喷子打交道。于是喷子越来越多（这个你有一个贡献，但是也只是一分而已，因为你虽然是油腻但是不是特别臭）好人越来越少（这个我的兄弟有一份贡献）

我看着很多曾经我敬佩的我的前辈，因为不学无术而变的油腻，然后我看到年轻一代也有混吃等死，我知道油腻也可以年轻。

我警告自己，要么老而优雅要么老而油腻。现在我看到你，我知道我的知识经验显然不足，就是年轻而优雅很难年轻而油腻可以很容易。