Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
分布式架构
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
人工智能
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
更多话题
为何在敏捷开发中使用斐波那契数? - Reddit
22-03-26
banq
最近,我的团队决定为我们的冲刺尝试斐波那契(Fibonacci,简称fib )点。
在这之前,我们用点来表示时间(1点=1天),并且通常有一个我们称之为置信度的第二个值(在估计的准确性方面)。低置信度意味着它可能会有很大的变化。高置信度是为你以前做过很多次的事情保留的。
我觉得在大多数情况下,这样做效果很好;我们知道每个冲刺的最高分是9天(天数,1个会议日),而且一般会给低信心的票据提供额外时间。但我们的争论大师喜欢斐波那契(简称fib ),我们对任何事情都有兴趣。
但我无法理解为什么斐波那契是有用的。
据我所知,估算编程任务的时间是很难的,也是不准确的,而fib是故意抽象的,这样你就不会太执着于你的 "4天3小时2分钟 "的时间估算。所以fib有一种刻度,0/1/2/3/5/8/13,每个任务都比上一个任务大得多......而这个大小代表了开发的 "努力"(但不是时间?什么是努力?)。
但我不明白finb如何具体地比任何其他有序的描述符更好,就像T恤衫尺寸(小号、中号、大号、XL)或其他编造的订单(shot, short, tall, grande, venti... berry, cherry, apple, watermelon)。
我读了一点书,承认fib是为了记下相对值,比如3比2多50%,5比3多66%......这样你就不能在估计时过于细化。
最让我感兴趣的是速度的概念。我的理解是,你使用你的团队完成的故事/项目点,把它们加起来,这就是你的速度。像这样做几个冲刺,现在你就有了一个平均数,就可以朝这个方向计划了...... 但这对我来说没有任何意义。
如果fib系统的目的是故意抽象和不准确的,你就不能只是把数字加起来,并期望围绕它进行计划。
在我没有受过训练的耳朵里,这听起来像是 "上一次冲刺我们做了3个小号和一个大号,所以这次冲刺我们可以做两个中号和两个大号"。
fib系统甚至有一个零级任务。一个人在一个冲刺阶段能做多少个零级任务?10? 100?
Reddit网友回答:
1. 问题是,你对这个旨在成为 "风中的拇指 "的系统的精确度要求太高了。
有几点意见:
如果你有一个 "X点=Y天 "的标尺,你还不如直接用天来估计。
为什么不在冲刺阶段尝试一下,看看会发生什么?你的问题可能都有答案了。
使用Fib的最初动机之一只是为了避免关于5分故事和6分故事之间的争论。既然我们知道这些测量方法并不精确,那么任何类似的争论都是在浪费时间。
速度只是作为一个非常粗糙的、"风中的拇指 "的预测工具。如果你真的把需要任何信心的承诺完全建立在速度上,那你就活该了。
如果你只根据故事点的估计和速度来制定你的冲刺计划,你就做错了。
我的经验是,一个 "0 "点的故事/任务会被认为是 "微不足道 "的,就冲刺计划而言,不值得浪费时间去讨论。如果你发现自己在冲刺阶段有100个0分的任务,请给我打电话,让我知道。不要再担心那些永远不会发生的可笑的情况了。
2. 在一个团队中估计任务会产生讨论。通过这样的讨论,你可以对困难有一个深入的了解。这也有助于项目经理/产品负责人了解什么是需要时间的。
当以天为单位定义故事点时,不同的开发人员、产品负责人或利益相关者之间可能总是有冲突。例如:你需要1小时来完成这个子任务?我可以在30分钟内完成它。
3. 试图在估算中达到精确是没有用的。斐波那契是故意模糊的。
而且不要再试图通过时间来估计,没有必要。
或者继续做下去。不管怎么样。
敏捷工程方法
项目管理
产品经理
LeanStartup