1、响应速度
“兵之情主速，乘人之不及”。——《孙子兵法》【九地篇第十一】
Merriam Webster字典对交付周期（Lead Time）的定义是“一个流程或项目启动到其结果显现所需的时间”。•版本发布 •特性发布 •用户故事平均周期 •缺陷生命周期
1.1 响应时间的系统因素
1.1.1 WIP（Work In Progress-半成品）
一个主要的精益流（lean flow）原则是利特尔法则（Little's law），利特尔法则由麻省理工大学斯隆商学院（MITSloan School of Management）教授John Little，于1961年所提出与证明的。利特尔法则指出，缩短交付周期有两种方式：降低半成品数量，提高交付速率。
利特尔法则：
生产周期=半成品/产能（cycle time=work in progress/throughput）
1.1.2 系统资源利用率
研究表明，资源利用率越高，工作单元在队列中的等待机会和时间就会越长，交付周期就成指数级增长。
•很多人要同时应付多个任务，任务间上下文的切换会占用相当的额外时间。
•关键资源，特别是具备掌握特定技能和领域知识的人，还有特定的设备，经常积压着长长的工作队列，成为瓶颈。
1.1.3 需求的差异性
当工作单元的大小差异很大，工作量不一致的时候，要解决这个问题就要在系统中增加缓冲，也就是在每个工作环节中增加队列。
当每个工作单元的大小比较均衡，完成时间可以预期，我们在缓冲队列里保留较少的工作单元就能够维持系统顺畅地运作。这意味着工作单元在队列里等待的机会和时间会大幅降低。
当重要的需求是以一个波浪的方式进入到我们的开发队列，我们要么将系统规模（容量）和交付速率维持在一个较低的水平，以提高资源的利用率，这就会降低对市场的响应速度，要么我们就提高系统规模（容量），使其能够应对波峰的冲击，这样我们就要确保冗余的产能和容量。
在一个稳定系统内，我们应该通过减少半成品，减少和缩短在各个环节的队列，来缩短响应周期。而在一个动态、变化很快、变化幅度很大的系统里，我们应该通过减小需求的大小，来平滑系统的输入，提高系统处理的效率。
1.2 价值流图分析（VSM）
价值流图（VSM-Value Stream Mapping）作为分析和设计物流和信息流的技术，经常被运用在优化“流”的改进活动当中
我们按图索骥，很容易追踪到影响市场响应速度的几个问题：团队或角色负载过大带来的瓶颈、需求理解错误带来的返工、工作环节间的等待、开发和验证之间的反馈时间长，还有重复的手工回归，等等
1.3 累积流图（Cum ulative Flow Diagram）
累积流图（Cumulative Flow Diagram）早期出现在排队理论里，用来呈现在一段时间范围内，处于不同工作环节或阶段的工作队列的大小。我们通常把软件开发的工作队列称为backlog，队列中每个工作单元的生命周期一般会包含分析、开发、验证等不同的阶段和状态。开发团队通过记录工作单元状态变化的各个时间点，并基于这些信息绘制累计流量图。
一个颜色的水平长度代表了某个工作单元在一个处理环节停留的时间，一个颜色的纵向长度则代表了在该环境上正在被处理或等待的工作量大小.
1.4 库存类指标
在一个团队内，库存积累的主要原因是流程各环节当中存在的瓶颈，工作单元在某个待处理环节需要等待很长时间。在大规模产品开发当中，库存积累的原因更多是来自团队间、模块间存在的依赖或是技术能力的障碍，也可能是各功能组织之间存在的瓶颈所致，特性无法及时进入更接近发布的下一个环节。
2. 工作量估算
2.1 基于算法模型的估算技术
基于算法模型的估算通常试图通过一个公式，把影响软件规模的因素，以参数化的形式纳入到计算范围之中。软件度量的一个里程碑式的作品是Barry W . Boehm 在1981发表的“Software Engineering Economics”[注释]，其中描述了对后来影响极大的一款软件度量模型“构造性成本模型”（Constructive Cost Model-COCOMO）。
2.2 基于专家判断的估算技术
敏捷开发团队在评估故事的相对大小和复杂度的时候，常推荐的Wideband Delphi方法就是一种专家评估技术。强调参与者之间的交流和沟通。它依赖专家的经验、直觉，以及专家间的相互磋商，因此有相当大的主观性，有时候会带来较大的偏差。
2.3 度量单位
业界现在常用的工作量度量单位有三大类：人天(Man Day)、代码行数（SLOC）和功能点（Function Point）。
3. 交付速率
“不是所有的工作角色都需要达到一种顺流状态才能具有生产力，但是对于一个涉及策划、设计、开发、写作或类似工作的人而言，顺流是必不可少的。”
——Tom DeMarco ＆Timothy Lister，《人件》
3.1 度量交付速率
速率的度量其实有两个方面，一个是速率本身的大小；另一个是速率的可靠性，可以由团队交付节奏的稳定性来体现。
1. 速率：迭代开发模型中直接的交付速率指标是迭代速率（Velocity）——团队在一个迭代中完成的用户故事点数。
2. 节奏:指标是代码合入频率和构建频率。只有成功通过自动构建里的各项验证活动的代码，才能被计入速率的统计。
3.2 提高系统效率
3.2.1 提高个体的交付能力
经验证明，系统中的个体——软件开发中的团队成员，他们的能力、诉求和动机对这个生产或是创造的过程会产生极大的影响.
3.2.2 优化系统的结构
优化系统的结构，也就是通过优化团队的组织、流程和工作方式，在不改变规模的情况下，扩大系统的吞吐速率。
快速解决瓶颈需要高度可视化的流程，及时暴露管道中的阻塞，并积极采取措施。通过看板和统计数据来观察在不同工作环节等待的用户故事是一个识别瓶颈的有效手段，我们通常关注的是在待分析、待开发、待测试状态的用户故事数或是工作量.
3.2.3 减少浪费
•重复手工劳动：对于生命周期较长的产品，随着响应市场需求的加速，有些活动在开发过程中多次重复。
•规模、复杂度带来的不直接增加价值的活动：随着交付规模的扩大，不管是管理上还是开发上，都有些不直接增加价值的活动，其耗费时间呈快速上升的趋势。
• 任务切换或中断
