Specify English metric terms

Author: basicthinker

docs/metrics-dict/elements-of-metric.md

@@ -65,6 +65,16 @@ sidebar_position: 1
 
 联系[思码逸](https://www.merico.cn)企业服务，获得完整信息。
 
+## 中英文词汇对照表 {#glossary}
+
+| 中文 | 英文 | 缩写 |
+| --- | --- | --- |
+| 缺陷关闭时间 | bug close time | BCT |
+| 事务前置时间 | issue lead time | ILT |
+| 需求交付时长 | requirement delivery time | RDT |
+| 需求交付速率 | requirement delivery velocity | RDV |
+| 需求吞吐量 | requirement throughput | RT |
+
 ## 参考阅读
 
 汇集和精选跟该指标相关的网络资源或文献。

docs/metrics-dict/requirement-delivery-cycle.md renamed to docs/metrics-dict/requirement-delivery-time.md

@@ -1,22 +1,22 @@
 ---
-sidebar_label: '需求交付周期'
+sidebar_label: '需求交付时长'
 ---
 
-# 需求交付周期
+# 需求交付时长
 
 ## 概念
 
 ### 定义
 
-需求交付周期是需求从创建到交付的总时长。可按照需求在实践域或项目管理系统中流转的状态划分，统计各个状态阶段的时间占比，帮助定位拖长需求交付周期的阶段。如果需求的颗粒度不统一，可以统计需求的功能点、故事点、代码当量等进行校准。其中功能点是常用于估算软件规模的单位，有国家标准作为依据，适用于小颗粒需求或小规模专业性强的团队，或航天、军工、政务等行业。为了校准需求的实际颗粒度，可以采用每个需求交付后对应的代码当量作为一个统计指标，来观察各个需求颗粒度的分布。如果它们的代码当量符合正态分布，则需求交付周期的结果可作为观察交付速率的有效参考，否则应重点排查代码当量过大或过小的需求，首先统一需求颗粒度，再采用需求交付周期指标。
+需求交付时长是需求从创建到交付的总时长。可按照需求在实践域或项目管理系统中流转的状态划分，统计各个状态阶段的时间占比，帮助定位拖长需求交付时长的阶段。如果需求的颗粒度不统一，可以统计需求的功能点、故事点、代码当量等进行校准。其中功能点是常用于估算软件规模的单位，有国家标准作为依据，适用于小颗粒需求或小规模专业性强的团队，或航天、军工、政务等行业。为了校准需求的实际颗粒度，可以采用每个需求交付后对应的代码当量作为一个统计指标，来观察各个需求颗粒度的分布。如果它们的代码当量符合正态分布，则需求交付时长的结果可作为观察交付速率的有效参考，否则应重点排查代码当量过大或过小的需求，首先统一需求颗粒度，再采用需求交付时长指标。
 
-例如，下图展示了几个月份中，需求交付周期的均值和低80%分位值。
+例如，下图展示了几个月份中，需求交付时长的均值和低80%分位值。
 
 ![image](https://user-images.githubusercontent.com/592493/147876210-e897227e-4119-441c-b58e-edb7abaf6346.png)
 
 ### 价值
 
-需求交付周期反映研发团队的快速响应能力。理论上，向客户交付价值的速度越快越好，但必须综合考虑交付价值是否满足顾客期望、需求吞吐率和交付质量等其他方面。快速交付不一定等同于优秀的研发实践。
+需求交付时长反映研发团队的快速响应能力。理论上，向客户交付价值的速度越快越好，但必须综合考虑交付价值是否满足顾客期望、需求吞吐率和交付质量等其他方面。快速交付不一定等同于优秀的研发实践。
 
 ## 应用
 
@@ -32,9 +32,9 @@ sidebar_label: '需求交付周期'
 
 #### 计算方法
 
-对于某个需求，需求交付周期 = 需求发布时间 - 需求创建时间。可以按照需求在各个状态中停留的时长，将需求交付周期细分为多个组成部分。可以只统计指定范围内的需求，计算它们的交付周期。
+对于某个需求，需求交付时长 = 需求发布时间 - 需求创建时间。可以按照需求在各个状态中停留的时长，将需求交付时长细分为多个组成部分。可以只统计指定范围内的需求，计算它们的交付周期。
 
-* 统计项目维度需求交付周期。
+* 统计项目维度需求交付时长。
 * 统计周期内平均或 80% 的需求的交付周期。
 
 ![](img/xu-qiu-jiao-fu-zhou-qi-1.png)
@@ -47,7 +47,7 @@ sidebar_label: '需求交付周期'
 ### 分析（Analyze）
 
 * 对比不同项目的需求交付速度，找到交付最快和最慢的项目。
-* 分析各个周期内平均需求交付周期的变化趋势，进行纵向对比，定位最大值、最小值、连续上升周期、连续下降周期等关键点。
+* 分析各个周期内平均需求交付时长的变化趋势，进行纵向对比，定位最大值、最小值、连续上升周期、连续下降周期等关键点。
 *   分析各个周期内80%的需求的交付周期的变化趋势，进行纵向对比，定位最大值、最小值、连续上升周期、连续下降周期等关键点。
 
     :::info
@@ -56,13 +56,13 @@ sidebar_label: '需求交付周期'
     通常情况下，均值和80%分位数的统计结果会出现两倍的差距，80%分位数和99%分位数也往往是约两倍关系。
     因此，80%分位数是一个很好的预测平衡点。
 * 分析对比需求在不同实践域或不同状态的停留时长，识别耗时最长的环节，找到影响整体交付速度的关键瓶颈。
-* 需求交付周期与需求吞吐量关联分析，辨别需求交付趋势是否健康。
-  * 健康趋势：需求交付周期缩短并且需求吞吐量增加。
-  * 不健康趋势：需求交付周期延长并且需求吞吐量降低。
+* 需求交付时长与需求吞吐量关联分析，辨别需求交付趋势是否健康。
+  * 健康趋势：需求交付时长缩短并且需求吞吐量增加。
+  * 不健康趋势：需求交付时长延长并且需求吞吐量降低。
 
 ### 回顾（Review）
 
-基于分析结果，聚焦少数关键点，采用石川图（鱼骨图）或根因分析法（RCA），进行根本原因的分析、调研和回顾。例如：连续几个统计周期，需求交付周期变长，需要进一步调研需求在不同阶段的停留时长，找到耗时最长的阶段进行根因分析：
+基于分析结果，聚焦少数关键点，采用石川图（鱼骨图）或根因分析法（RCA），进行根本原因的分析、调研和回顾。例如：连续几个统计周期，需求交付时长变长，需要进一步调研需求在不同阶段的停留时长，找到耗时最长的阶段进行根因分析：
 
 * 需求阶段耗时过长：需求不明确、变更频繁、[需求颗粒度](https://www.openmari.dev/)过大、需求优先级没有定义清楚、需求分析师或产品经理的资源或经验不足？
 * 设计阶段耗时过长：需求文档不清晰、研发负责人或架构师的资源或经验不足？