在制品与前置时间(又叫交付时间)
来源:互联网 发布:免费名片设计软件下载 编辑:程序博客网 时间:2024/05/01 00:17
转自:http://www.jianshu.com/p/bbc652391e45
在制品与前置时间基本为线性关系,减少在制品数量就能减少前置时间。
利特尔法则(Little’s Law)作为一个非常朴素的原理,为看板方法奠定了一个理论基础,看似简单的公式背后却有其复杂的一面。
一、利特尔法则
利特尔法则的公式是这样的:
平均吞吐率=在制品数量/平均前置时间
举个例子,假设你正在排队买快餐,在你前面有19个人在排队,你是第20个,已知收银窗口每分钟能处理一个人的点餐需求,求解你的等待时间。
如果你已经决定要排队,并且站到了队尾,那么在制品数量就是20(个),平均吞吐率是1(人/分钟)。
从你站到队尾的时候开始,一直到你点完餐,这个时间就是你的“前置时间”。
即使我们没有学习过利特尔法则,也可以轻易地算出来:
1 = 20 / x x = 20(分钟)
因为在一段时间之内,保持工作量饱满的话,我们每天能做多少工作基本是一定的,所以吞吐率基本上不会发生太大变化。
如果这个时候我们想缩短平均前置时间,也就是等待的时间,利特尔法则告诉我们:可以通过减少在制品数量来达成这个目标。
在这个例子中,就是减少排队者的数量。
这也很好理解,10个人的队列和20个人的队列,前者需要等待的时间会更短。 [1]
二、限制在制品的意义
如上面所说,在制品数量和前置时间是成正比的,缩短前置时间的最有效手段就是减少在制品数量。
前置时间的增长会导致交付周期变长,这一点基本毋庸置疑。
前置时间的增长会导致交付的可预测性下降,俗话说“夜长梦多”,长时间停留在某一个阶段会带来一些额外的风险。
如果我们的交付周期比需求变化周期更长,那么会有更多的紧急任务,所以交付周期变长会导致更多的紧急任务。
如果我们管理不好紧急任务的插入,会增大我们的在制品数量。
如果交付团队的可预测性很低的话,那么会影响到IT研发组织和业务部门的信任关系,当业务部门无法预测一个需求提交给研发部门什么时候能交付的时候,那么唯一可行的手段就是一次性把要做的事情全部都压给研发部门,直接增大了研发部门的在制品数量。
同时在制品数量的增长会带来的另外一个后果就是故障发现得很晚,这一点在过去三四十年的软件工程方法论中都得到了验证。
发现的故障需要资源和时间来进行修复,带来的就是在制品数量的上升和前置时间的增长。
- 在制品与前置时间(又叫交付时间)
- 又在字符集上浪费时间
- 今天是不是又在浪费时间了
- 图片根据数据库的时间(开始时间与结束时间)与本地时间相比,在网页上显示。
- 又玩时间一
- 精益看板分析:前置时间
- (原创)尽管少写那么多代码,但省下来的时间又在哪里呢
- 稳压二极管(又叫齐纳二极管)
- 在制品,work in process
- 时间戳与时间
- 时间又过去了一个月
- 时间划过的伤痕叫成长
- 家科技开发时间空间按时交付经济案件是否觉得
- 痤疮(又叫青春痘、粉刺、毛囊炎)
- 螺旋天线(又叫弹簧天线)
- Centos6 安装RepoForge(又叫RPMForge)
- Swift - 获取当前时间的时间戳(时间戳与时间互相转换)
- 前置++与后置++(转载)
- 数据结构4
- Unity事件触发
- String
- 堆排序
- 【计算机网络】TCP/IP协议三次握手与四次握手流程解析
- 在制品与前置时间(又叫交付时间)
- WRF-DA代码编译与安装(一)——依赖库的编译与安装
- Java面试中经常遇到的类执行顺序
- C#调用Python脚本及使用Python的第三方模块
- 3.2编程实现 (1)员工类(Employee)(2)部门主管类(Manager)(3)测试类(Test)
- Android安全开发之ZIP文件目录遍历
- linux下C语言my_memcopy和my_strcpy实现
- vue 请求后台数据
- Course Schedule