You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@devlake.apache.org by zk...@apache.org on 2022/08/19 14:34:32 UTC
[incubator-devlake-website] branch main updated (088f86ad -> f3af7ffd)
This is an automated email from the ASF dual-hosted git repository.
zky pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
from 088f86ad docs: added 8 metrics
new 862e875d docs: add docs for 21 metrics
new f3af7ffd fix: solve merge conflicts
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
docs/Metrics/AddedLinesOfCode.md | 60 +++++---------------
docs/Metrics/BugAge.md | 50 +++--------------
docs/Metrics/BugCountPer1kLinesOfCode.md | 63 ++++++---------------
docs/Metrics/BuildCount.md | 57 ++++---------------
docs/Metrics/BuildDuration.md | 57 ++++---------------
docs/Metrics/BuildSuccessRate.md | 57 ++++---------------
docs/Metrics/CFR.md | 78 +++++++++++---------------
docs/Metrics/ChangeLeadTime.md | 67 ----------------------
docs/Metrics/CommitAuthorCount.md | 55 ++++--------------
docs/Metrics/CommitCount.md | 70 ++++++++++-------------
docs/Metrics/DeletedLinesOfCode.md | 61 +++++---------------
docs/Metrics/DeployFrequency.md | 70 ++++++++---------------
docs/Metrics/IncidentAge.md | 49 +++-------------
docs/Metrics/IncidentCountPer1kLinesOfCode.md | 64 ++++++---------------
docs/Metrics/LeadTimeForChanges.md | 56 ++++++++++++++++++
docs/Metrics/MTTR.md | 81 ++++++++++++---------------
docs/Metrics/MergeRate.md | 61 ++++++--------------
docs/Metrics/PRCount.md | 39 +++++++++++++
docs/Metrics/RequirementCount.md | 15 ++---
docs/Metrics/RequirementDeliveryRate.md | 39 ++-----------
docs/Metrics/RequirementGranularity.md | 49 +++-------------
docs/Metrics/RequirementLeadTime.md | 49 +++-------------
docs/Metrics/ReviewRounds.md | 67 ----------------------
23 files changed, 383 insertions(+), 931 deletions(-)
delete mode 100644 docs/Metrics/ChangeLeadTime.md
create mode 100644 docs/Metrics/LeadTimeForChanges.md
create mode 100644 docs/Metrics/PRCount.md
delete mode 100644 docs/Metrics/ReviewRounds.md
[incubator-devlake-website] 02/02: fix: solve merge conflicts
Posted by zk...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
zky pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
commit f3af7ffdd29ded4d357f1713698f8a13a9b6518c
Author: Startrekzky <ka...@merico.dev>
AuthorDate: Fri Aug 19 22:24:29 2022 +0800
fix: solve merge conflicts
---
docs/Metrics/{DeploymentFrequency.md => DeployFrequency.md} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/Metrics/DeploymentFrequency.md b/docs/Metrics/DeployFrequency.md
similarity index 100%
rename from docs/Metrics/DeploymentFrequency.md
rename to docs/Metrics/DeployFrequency.md
[incubator-devlake-website] 01/02: docs: add docs for 21 metrics
Posted by zk...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
zky pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
commit 862e875d0fc6ccd864642b72f7259d4e775f4b46
Author: Startrekzky <ka...@merico.dev>
AuthorDate: Fri Aug 19 22:14:58 2022 +0800
docs: add docs for 21 metrics
---
docs/Metrics/AddedLinesOfCode.md | 60 +++++---------------
docs/Metrics/BugAge.md | 50 +++--------------
docs/Metrics/BugCountPer1kLinesOfCode.md | 63 ++++++---------------
docs/Metrics/BuildCount.md | 57 ++++---------------
docs/Metrics/BuildDuration.md | 57 ++++---------------
docs/Metrics/BuildSuccessRate.md | 57 ++++---------------
docs/Metrics/CFR.md | 78 +++++++++++---------------
docs/Metrics/ChangeLeadTime.md | 67 ----------------------
docs/Metrics/CommitAuthorCount.md | 55 ++++--------------
docs/Metrics/CommitCount.md | 70 ++++++++++-------------
docs/Metrics/DeletedLinesOfCode.md | 61 +++++---------------
docs/Metrics/DeployFrequency.md | 67 ----------------------
docs/Metrics/DeploymentFrequency.md | 45 +++++++++++++++
docs/Metrics/IncidentAge.md | 49 +++-------------
docs/Metrics/IncidentCountPer1kLinesOfCode.md | 64 ++++++---------------
docs/Metrics/LeadTimeForChanges.md | 56 ++++++++++++++++++
docs/Metrics/MTTR.md | 81 ++++++++++++---------------
docs/Metrics/MergeRate.md | 61 ++++++--------------
docs/Metrics/PRCount.md | 39 +++++++++++++
docs/Metrics/RequirementCount.md | 15 ++---
docs/Metrics/RequirementDeliveryRate.md | 39 ++-----------
docs/Metrics/RequirementGranularity.md | 49 +++-------------
docs/Metrics/RequirementLeadTime.md | 49 +++-------------
docs/Metrics/ReviewRounds.md | 67 ----------------------
24 files changed, 404 insertions(+), 952 deletions(-)
diff --git a/docs/Metrics/AddedLinesOfCode.md b/docs/Metrics/AddedLinesOfCode.md
index 0644e445..2921ea65 100644
--- a/docs/Metrics/AddedLinesOfCode.md
+++ b/docs/Metrics/AddedLinesOfCode.md
@@ -1,67 +1,33 @@
---
-title: "Added Lines of Code "
+title: "Added Lines of Code"
description: >
- Requirement Count
-sidebar_position: 2
+ Added Lines of Code
+sidebar_position: 7
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The accumulated number of added lines of code.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. identify potential bottlenecks that may affect the output
+2. Encourage the team to implement a development model that matches the business requirements; develop excellent coding habits
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by summing the additions of commits in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
+N/A
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project/team dimension, observe the accumulated change in Added lines to assess the team activity and code growth rate
+2. From version cycle dimension, observe the active time distribution of code changes, and evaluate the effectiveness of project development model.
+3. From the member dimension, observe the trend and stability of code output of each member, and identify the key points that affect code output by comparison.
diff --git a/docs/Metrics/BugAge.md b/docs/Metrics/BugAge.md
index 4ea18675..66cdcbad 100644
--- a/docs/Metrics/BugAge.md
+++ b/docs/Metrics/BugAge.md
@@ -2,23 +2,24 @@
title: "Bug Age"
description: >
Bug Age
-sidebar_position: 2
+sidebar_position: 9
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The amount of time it takes a bug to fix.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Help the team to establish an effective hierarchical response mechanism for bugs. Focus on the resolution of important problems in the backlog.
+2. Improve team's and individual's bug fixing efficiency. Identify good/to-be-improved practices that affect bug age age
## Which dashboard(s) does it exist in
- Jira
- GitHub
+- Weekly Bug Retro
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric equals to `resolution_date` - `created_date` of issues in type "BUG".
<b>Data Sources Required</b>
@@ -26,42 +27,9 @@ This metric relies on issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-bug' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Bugs`.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. Observe the trend of bug age and locate the key reasons.
+2. According to the severity level, type (business, functional classification), affected module, source of bugs, count and observe the length of bug age.
\ No newline at end of file
diff --git a/docs/Metrics/BugCountPer1kLinesOfCode.md b/docs/Metrics/BugCountPer1kLinesOfCode.md
index d9ccc372..0c252e53 100644
--- a/docs/Metrics/BugCountPer1kLinesOfCode.md
+++ b/docs/Metrics/BugCountPer1kLinesOfCode.md
@@ -1,67 +1,40 @@
---
title: "Bug Count per 1k Lines of Code"
description: >
- Requirement Count
-sidebar_position: 2
+ Bug Count per 1k Lines of Code
+sidebar_position: 12
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+Amount of bugs per 1,000 lines of code.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Defect drill-down analysis to inform the development of design and code review strategies and to improve the internal QA process
+2. Assist teams to locate projects/modules with higher defect severity and density, and clean up technical debts
+3. Analyze critical points, identify good/to-be-improved practices that affect defect count or defect rate, to reduce the amount of future defects
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of bugs divided by total accumulated lines of code (additions + deletions) in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on
+- issues collected from Jira, GitHub or TAPD.
+- commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on
+- "Issue type mapping" in Jira, GitHub or TAPD's transformation rules page to let DevLake know what type(s) of issues can be regarded as bugs.
+- "PR-Issue Mapping" in GitHub, GitLab's transformation rules page to let DevLake know the bugs are fixed by which PR/MRs.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project or team dimension, observe the statistics on the total number of defects, the distribution of the number of defects in each severity level/type/owner, the cumulative trend of defects, and the change trend of the defect rate in thousands of lines, etc.
+2. From version cycle dimension, observe the statistics on the cumulative trend of the number of defects/defect rate, which can be used to determine whether the growth rate of defects is slowing down, showing a flat convergence trend, and is an important reference for judging the stability of software version quality
+3. From the time dimension, analyze the trend of the number of test defects, defect rate to locate the key items/key points
+4. Evaluate whether the software quality and test plan are reasonable by referring to CMMI standard values
diff --git a/docs/Metrics/BuildCount.md b/docs/Metrics/BuildCount.md
index 9d9d3d62..50352bbc 100644
--- a/docs/Metrics/BuildCount.md
+++ b/docs/Metrics/BuildCount.md
@@ -1,67 +1,32 @@
---
title: "Build Count"
description: >
- Requirement Count
-sidebar_position: 2
+ Build Count
+sidebar_position: 15
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The number of successful builds.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. As a process indicator, it reflects the value flow efficiency of upstream production and research links
+2. Identify excellent/to-be-improved practices that impact the build, and drive the team to precipitate reusable tools and mechanisms to build infrastructure for fast and high-frequency delivery
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+- Jenkins
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by counting the number of successful CI builds/pipelines/runs in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on CI builds/pipelines/runs collected from Jenkins, GitLab or GitHub.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+N/A
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project dimension, compare the number of builds and success rate by combining the project phase and the complexity of tasks.
+2. From the time dimension, analyze the trend of the number of builds and success rate to see if it has improved over time.
diff --git a/docs/Metrics/BuildDuration.md b/docs/Metrics/BuildDuration.md
index e43d8861..1aa95385 100644
--- a/docs/Metrics/BuildDuration.md
+++ b/docs/Metrics/BuildDuration.md
@@ -1,67 +1,32 @@
---
title: "Build Duration"
description: >
- Requirement Count
-sidebar_position: 2
+ Build Duration
+sidebar_position: 16
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The duration of successful builds.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. As a process indicator, it reflects the value flow efficiency of upstream production and research links
+2. Identify excellent/to-be-improved practices that impact the build, and drive the team to precipitate reusable tools and mechanisms to build infrastructure for fast and high-frequency delivery
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+- Jenkins
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by getting the duration of successful CI builds/pipelines/runs in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on CI builds/pipelines/runs collected from Jenkins, GitLab or GitHub.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+N/A
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project dimension, compare the number of builds and success rate by combining the project phase and the complexity of tasks.
+2. From the time dimension, analyze the trend of the number of builds and success rate to see if it has improved over time.
diff --git a/docs/Metrics/BuildSuccessRate.md b/docs/Metrics/BuildSuccessRate.md
index dbf08eb9..401086d9 100644
--- a/docs/Metrics/BuildSuccessRate.md
+++ b/docs/Metrics/BuildSuccessRate.md
@@ -1,67 +1,32 @@
---
title: "Build Success Rate"
description: >
- Requirement Count
-sidebar_position: 2
+ Build Success Rate
+sidebar_position: 17
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The ratio of successful builds to all builds.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. As a process indicator, it reflects the value flow efficiency of upstream production and research links
+2. Identify excellent/to-be-improved practices that impact the build, and drive the team to precipitate reusable tools and mechanisms to build infrastructure for fast and high-frequency delivery
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+- Jenkins
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of successful builds divided by the total number of builds in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on CI builds/pipelines/runs collected from Jenkins, GitLab or GitHub.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+N/A
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project dimension, compare the number of builds and success rate by combining the project phase and the complexity of tasks.
+2. From the time dimension, analyze the trend of the number of builds and success rate to see if it has improved over time.
diff --git a/docs/Metrics/CFR.md b/docs/Metrics/CFR.md
index 3a800235..d6e34150 100644
--- a/docs/Metrics/CFR.md
+++ b/docs/Metrics/CFR.md
@@ -1,67 +1,53 @@
---
-title: "Change Failure Rate"
+title: "DORA - Change Failure Rate(WIP)"
description: >
- Requirement Count
-sidebar_position: 2
+ DORA - Change Failure Rate
+sidebar_position: 21
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The percentage of changes that were made to a code that then resulted in incidents, rollbacks, or any type of production failure.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+Unlike Deployment Frequency and Lead Time for Changes that measure the throughput, Change Failure Rate measures the stability and quality of software delivery. A low CFR reflects a bad end-user experience as the production failure is relatively high.
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of failures per the number of deployments. For example, if there are five deployments in a day and one causes a failure, that is a 20% change failure rate.
-<b>Data Sources Required</b>
+As you can see, there is not much distinction between performance benchmarks for CFR:
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+| Groups | Benchmarks |
+| -----------------| ----------------|
+| Elite performers | 0%-15% |
+| High performers | 16%-30% |
+| Medium performers| 16%-30% |
+| Low performers | 16%-30% |
-<b>Transformation Rules Required</b>
+<i>Source: 2021 Accelerate State of DevOps, Google</i>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+<b>Data Sources Required</b>
-<b>SQL Queries</b>
+This metric relies on:
+- `Deployments` collected in one of the following ways:
+ - Open APIs of Jenkins, GitLab, GitHub, etc.
+ - Webhook for general CI tools.
+ - Releases and PR/MRs from GitHub, GitLab APIs, etc.
+- `Incidents` collected in one of the following ways:
+ - Issue tracking tools such as Jira, TAPD, GitHub, etc.
+ - Bug or Service Monitoring tools such as PagerDuty, Sentry, etc.
+ - CI pipelines that marked the 'failed' deployments.
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
+<b>Transformation Rules Required</b>
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+This metric relies on:
+- Deployment configuration in Jenkins, GitLab or GitHub transformation rules to let DevLake know what CI builds/jobs can be regarded as `Deployments`.
+- Incident configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Incidents`.
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+- Add unit tests for all new feature
+- "Shift left", start QA early and introduce more automated tests
+- Enforce code review if it's not strictly executed
diff --git a/docs/Metrics/ChangeLeadTime.md b/docs/Metrics/ChangeLeadTime.md
deleted file mode 100644
index 7cdcc740..00000000
--- a/docs/Metrics/ChangeLeadTime.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Change Lead Time"
-description: >
- Requirement Count
-sidebar_position: 2
----
-
-## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
-
-## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
-
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
-
-## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
-
-<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
-
-<b>Transformation Rules Required</b>
-
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
-
-## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
diff --git a/docs/Metrics/CommitAuthorCount.md b/docs/Metrics/CommitAuthorCount.md
index ae84376b..3be4ad20 100644
--- a/docs/Metrics/CommitAuthorCount.md
+++ b/docs/Metrics/CommitAuthorCount.md
@@ -1,67 +1,32 @@
---
title: "Commit Author Count"
description: >
- Requirement Count
-sidebar_position: 2
+ Commit Author Count
+sidebar_position: 14
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The number of commit authors who have committed code.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+Take inventory of project/team R&D resource inputs, assess input-output ratio, and rationalize resource deployment.
+
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by counting the number of commit authors in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
+N/A
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+As a secondary indicator, this helps assess the labor cost of participating in coding.
diff --git a/docs/Metrics/CommitCount.md b/docs/Metrics/CommitCount.md
index e1b1509b..ae85af8d 100644
--- a/docs/Metrics/CommitCount.md
+++ b/docs/Metrics/CommitCount.md
@@ -1,67 +1,55 @@
---
title: "Commit Count"
description: >
- Requirement Count
-sidebar_position: 2
+ Commit Count
+sidebar_position: 6
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The number of commits created.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Identify potential bottlenecks that may affect output
+2. Encourage R&D practices of small step submissions and develop excellent coding habits
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
+- GitHub Release Quality and Contribution Analysis
+- Demo-Is this month more productive than last?
+- Demo-Commit Count by Author
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by counting the number of commits in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+N/A
<b>SQL Queries</b>
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
If you want to see the monthly trend, run the following SQL
```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
+ with _commits as(
+ SELECT
+ DATE_ADD(date(authored_date), INTERVAL -DAY(date(authored_date))+1 DAY) as time,
+ count(*) as commit_count
+ FROM commits
+ WHERE
+ message not like '%Merge%'
+ and $__timeFilter(authored_date)
+ group by 1
+ )
+
+ SELECT
+ date_format(time,'%M %Y') as month,
+ commit_count as "Commit Count"
+ FROM _commits
+ ORDER BY time
```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. Identify the main reasons for the unusual number of commits and the possible impact on the number of commits through comparison
+2. Evaluate whether the number of commits is reasonable in conjunction with more microscopic workload metrics (e.g. lines of code/code equivalents)
diff --git a/docs/Metrics/DeletedLinesOfCode.md b/docs/Metrics/DeletedLinesOfCode.md
index a4f0f611..218ceae0 100644
--- a/docs/Metrics/DeletedLinesOfCode.md
+++ b/docs/Metrics/DeletedLinesOfCode.md
@@ -1,67 +1,32 @@
---
-title: "Deleted Lines of Code "
+title: "Deleted Lines of Code"
description: >
- Requirement Count
-sidebar_position: 2
+ Deleted Lines of Code
+sidebar_position: 8
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The accumulated number of deleted lines of code.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. identify potential bottlenecks that may affect the output
+2. Encourage the team to implement a development model that matches the business requirements; develop excellent coding habits
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by summing the deletions of commits in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+N/A
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project/team dimension, observe the accumulated change in Added lines to assess the team activity and code growth rate
+2. From version cycle dimension, observe the active time distribution of code changes, and evaluate the effectiveness of project development model.
+3. From the member dimension, observe the trend and stability of code output of each member, and identify the key points that affect code output by comparison.
diff --git a/docs/Metrics/DeployFrequency.md b/docs/Metrics/DeployFrequency.md
deleted file mode 100644
index 5f297994..00000000
--- a/docs/Metrics/DeployFrequency.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Deploy Frequency"
-description: >
- Requirement Count
-sidebar_position: 2
----
-
-## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
-
-## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
-
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
-
-## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
-
-<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
-
-<b>Transformation Rules Required</b>
-
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
-
-## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
diff --git a/docs/Metrics/DeploymentFrequency.md b/docs/Metrics/DeploymentFrequency.md
new file mode 100644
index 00000000..13a49bc3
--- /dev/null
+++ b/docs/Metrics/DeploymentFrequency.md
@@ -0,0 +1,45 @@
+---
+title: "DORA - Deployment Frequency(WIP)"
+description: >
+ DORA - Deployment Frequency
+sidebar_position: 18
+---
+
+## What is this metric?
+How often an organization deploys code to production or release it to end users.
+
+## Why is it important?
+Deployment frequency reflects the efficiency of a team's deployment. A team that deploys more frequently can deliver the product faster and users' feature requirements can be met faster.
+
+## Which dashboard(s) does it exist in
+N/A
+
+
+## How is it calculated?
+Deployment frequency is calculated based on the number of deployment days, not the number of deployments, e.g.,daily, weekly, monthly, yearly.
+
+| Groups | Benchmarks |
+| -----------------| -------------------------------------|
+| Elite performers | Multiple times a day |
+| High performers | Once a week to once a month |
+| Medium performers| Once a month to once every six months|
+| Low performers | Less than once every six months |
+
+<i>Source: 2021 Accelerate State of DevOps, Google</i>
+
+
+<b>Data Sources Required</b>
+
+This metric relies on deployments collected in multiple ways:
+- Open APIs of Jenkins, GitLab, GitHub, etc.
+- Webhook for general CI tools.
+- Releases and PR/MRs from GitHub, GitLab APIs, etc.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the deployment configuration in Jenkins, GitLab or GitHub transformation rules to let DevLake know what CI builds/jobs can be regarded as deployments.
+
+## How to improve?
+- Trunk development. Work in small batches and often merge their work into shared trunks.
+- Integrate CI/CD tools for automated deployment
+- Improve automated test coverage
diff --git a/docs/Metrics/IncidentAge.md b/docs/Metrics/IncidentAge.md
index 77c8d170..4cd5e60c 100644
--- a/docs/Metrics/IncidentAge.md
+++ b/docs/Metrics/IncidentAge.md
@@ -2,15 +2,15 @@
title: "Incident Age"
description: >
Incident Age
-sidebar_position: 2
+sidebar_position: 10
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The amount of time it takes a incident to fix.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Help the team to establish an effective hierarchical response mechanism for incidents. Focus on the resolution of important problems in the backlog.
+2. Improve team's and individual's incident fixing efficiency. Identify good/to-be-improved practices that affect incident age
## Which dashboard(s) does it exist in
- Jira
@@ -18,7 +18,7 @@ The number of issues created with the type `REQUIREMENT`.
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric equals to `resolution_date` - `created_date` of issues in type "INCIDENT".
<b>Data Sources Required</b>
@@ -26,42 +26,9 @@ This metric relies on issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-incident' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Incidents`.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. Observe the trend of incident age and locate the key reasons.
+2. According to the severity level, type (business, functional classification), affected module, source of bugs, count and observe the length of incident age.
\ No newline at end of file
diff --git a/docs/Metrics/IncidentCountPer1kLinesOfCode.md b/docs/Metrics/IncidentCountPer1kLinesOfCode.md
index 8d1a4830..9ad92787 100644
--- a/docs/Metrics/IncidentCountPer1kLinesOfCode.md
+++ b/docs/Metrics/IncidentCountPer1kLinesOfCode.md
@@ -1,67 +1,39 @@
---
title: "Incident Count per 1k Lines of Code"
description: >
- Requirement Count
-sidebar_position: 2
+ Incident Count per 1k Lines of Code
+sidebar_position: 13
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+Amount of incidents per 1,000 lines of code.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Defect drill-down analysis to inform the development of design and code review strategies and to improve the internal QA process
+2. Assist teams to locate projects/modules with higher defect severity and density, and clean up technical debts
+3. Analyze critical points, identify good/to-be-improved practices that affect defect count or defect rate, to reduce the amount of future defects
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of incidents divided by total accumulated lines of code (additions + deletions) in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on
+- issues collected from Jira, GitHub or TAPD.
+- commits collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+This metric relies on
+- "Issue type mapping" in Jira, GitHub or TAPD's transformation rules page to let DevLake know what type(s) of issues can be regarded as incidents.
+- "PR-Issue Mapping" in GitHub, GitLab's transformation rules page to let DevLake know the bugs are fixed by which PR/MRs.
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the project or team dimension, observe the statistics on the total number of defects, the distribution of the number of defects in each severity level/type/owner, the cumulative trend of defects, and the change trend of the defect rate in thousands of lines, etc.
+2. From version cycle dimension, observe the statistics on the cumulative trend of the number of defects/defect rate, which can be used to determine whether the growth rate of defects is slowing down, showing a flat convergence trend, and is an important reference for judging the stability of software version quality
+3. From the time dimension, analyze the trend of the number of test defects, defect rate to locate the key items/key points
+4. Evaluate whether the software quality and test plan are reasonable by referring to CMMI standard values
diff --git a/docs/Metrics/LeadTimeForChanges.md b/docs/Metrics/LeadTimeForChanges.md
new file mode 100644
index 00000000..4a5d3957
--- /dev/null
+++ b/docs/Metrics/LeadTimeForChanges.md
@@ -0,0 +1,56 @@
+---
+title: "DORA - Lead Time for Changes(WIP)"
+description: >
+ DORA - Lead Time for Changes
+sidebar_position: 19
+---
+
+## What is this metric?
+The median amount of time for a commit to be deployed into production.
+
+## Why is it important?
+This metric measures the time it takes to commit code to the production environment and reflects the speed of software delivery. A lower average change preparation time means that your team is efficient at coding and deploying your project.
+
+## Which dashboard(s) does it exist in
+N/A
+
+
+## How is it calculated?
+This metric can be calculated in two ways:
+- If a deployment can be linked to PRs, then the lead time for changes of a deployment is the average cycle time of its associated PRs. For instance,
+ - Compared to the previous deployment `deploy-1`, `deploy-2` deployed three new commits `commit-1`, `commit-2` and `commit-3`.
+ - `commit-1` is linked to `pr-1`, `commit-2` is linked to `pr-2` and `pr-3`, `commit-3` is not linked to any PR. Then, `deploy-2` is associated with `pr-1`, `pr-2` and `pr-3`.
+ - `Deploy-2`'s lead time for changes = average cycle time of `pr-1`, `pr-2` and `pr-3`.
+- If a deployment can't be linked to PRs, then the lead time for changes is computed based on its associated commits. For instance,
+ - Compared to the previous deployment `deploy-1`, `deploy-2` deployed three new commits `commit-1`, `commit-2` and `commit-3`.
+ - None of `commit-1`, `commit-2` and `commit-3` is linked to any PR.
+ - Calculate each commit's lead time for changes, which equals to `deploy-2`'s deployed_at - commit's authored_date
+ - `Deploy-2`'s Lead time for changes = average lead time for changes of `commit-1`, `commit-2` and `commit-3`.
+
+Below are the benchmarks for different development teams:
+
+| Groups | Benchmarks |
+| -----------------| -------------------------------------|
+| Elite performers | Less than one hour |
+| High performers | Between one day and one week |
+| Medium performers| Between one month and six months |
+| Low performers | More than six months |
+
+<i>Source: 2021 Accelerate State of DevOps, Google</i>
+
+<b>Data Sources Required</b>
+
+This metric relies on deployments collected in multiple ways:
+- Open APIs of Jenkins, GitLab, GitHub, etc.
+- Webhook for general CI tools.
+- Releases and PR/MRs from GitHub, GitLab APIs, etc.
+
+<b>Transformation Rules Required</b>
+
+This metric relies on the deployment configuration in Jenkins, GitLab or GitHub transformation rules to let DevLake know what CI builds/jobs can be regarded as deployments.
+
+## How to improve?
+- Break requirements into smaller, more manageable deliverables
+- Optimize the code review process
+- "Shift left", start QA early and introduce more automated tests
+- Integrate CI/CD tools to automate the deployment process
diff --git a/docs/Metrics/MTTR.md b/docs/Metrics/MTTR.md
index 5d829dac..a7bcb2dc 100644
--- a/docs/Metrics/MTTR.md
+++ b/docs/Metrics/MTTR.md
@@ -1,67 +1,56 @@
---
-title: "Mean Time to Restore Service"
+title: "DORA - Mean Time to Restore Service"
description: >
- Requirement Count
-sidebar_position: 2
+ DORA - Mean Time to Restore Service
+sidebar_position: 20
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time to restore service after service incidents, rollbacks, or any type of production failure happened.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+This metric is essential to measure the disaster control capability of your team and the robustness of the software.
## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+N/A
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+MTTR = Total [incident age](./IncidentAge.md) (in hours)/number of incidents.
-<b>Data Sources Required</b>
+If you have three incidents that happened in the given data range, one lasting 1 hour, one lasting 2 hours and one lasting 3 hours. Your MTTR will be: (1 + 2 + 3) / 3 = 2 hours.
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+Below are the benchmarks for different development teams:
-<b>Transformation Rules Required</b>
+| Groups | Benchmarks |
+| -----------------| -------------------------------------|
+| Elite performers | Less than one hour |
+| High performers | Less one day |
+| Medium performers| Between one day and one week |
+| Low performers | More than six months |
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+<i>Source: 2021 Accelerate State of DevOps, Google</i>
-<b>SQL Queries</b>
+<b>Data Sources Required</b>
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
+This metric relies on:
+- `Deployments` collected in one of the following ways:
+ - Open APIs of Jenkins, GitLab, GitHub, etc.
+ - Webhook for general CI tools.
+ - Releases and PR/MRs from GitHub, GitLab APIs, etc.
+- `Incidents` collected in one of the following ways:
+ - Issue tracking tools such as Jira, TAPD, GitHub, etc.
+ - Bug or Service Monitoring tools such as PagerDuty, Sentry, etc.
+ - CI pipelines that marked the 'failed' deployments.
+
+<b>Transformation Rules Required</b>
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
+This metric relies on:
+- Deployment configuration in Jenkins, GitLab or GitHub transformation rules to let DevLake know what CI builds/jobs can be regarded as `Deployments`.
+- Incident configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Incidents`.
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+- Use automated tools to quickly report failure
+- Prioritize recovery when a failure happens
+- Establish a go-to action plan to respond to failures immediately
+- Reduce the deployment time for failure-fixing
diff --git a/docs/Metrics/MergeRate.md b/docs/Metrics/MergeRate.md
index 67183e43..c8c27433 100644
--- a/docs/Metrics/MergeRate.md
+++ b/docs/Metrics/MergeRate.md
@@ -1,67 +1,40 @@
---
-title: "Pull Request Pass Rate"
+title: "PR Merge Rate"
description: >
- Requirement Count
-sidebar_position: 2
+ Pull Request Merge Rate
+sidebar_position: 12
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The ratio of PRs/MRs that get merged.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Code review metrics are process indicators to provide quick feedback on developers' code quality
+2. Promote the team to establish a unified coding specification and standardize the code review criteria
+3. Identify modules with low-quality risks in advance, optimize practices, and precipitate into reusable knowledge and tools to avoid technical debt accumulation
## Which dashboard(s) does it exist in
- Jira
- GitHub
+- GitLab
+- Weekly Community Retro
+- Engineering Throughput and Cycle Time
+- Engineering Throughput and Cycle Time - Team View
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of merged PRs divided by the number of all PRs in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PRs/MRs collected from GitHub, GitLab or BitBucket.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+N/A
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. From the developer dimension, we evaluate the code quality of developers by combining the task complexity with the metrics related to the number of review passes and review rounds.
+2. From the reviewer dimension, we observe the reviewer's review style by taking into account the task complexity, the number of passes and the number of review rounds.
+3. From the project/team dimension, we combine the project phase and team task complexity to aggregate the metrics related to the number of review passes and review rounds, and identify the modules with abnormal code review process and possible quality risks.
diff --git a/docs/Metrics/PRCount.md b/docs/Metrics/PRCount.md
new file mode 100644
index 00000000..4521e786
--- /dev/null
+++ b/docs/Metrics/PRCount.md
@@ -0,0 +1,39 @@
+---
+title: "Pull Request Count"
+description: >
+ Pull Request Count
+sidebar_position: 11
+---
+
+## What is this metric?
+The number of pull requests created.
+
+## Why is it important?
+1. Code review metrics are process indicators to provide quick feedback on developers' code quality
+2. Promote the team to establish a unified coding specification and standardize the code review criteria
+3. Identify modules with low-quality risks in advance, optimize practices, and precipitate into reusable knowledge and tools to avoid technical debt accumulation
+
+## Which dashboard(s) does it exist in
+- Jira
+- GitHub
+- GitLab
+- Weekly Community Retro
+- Engineering Throughput and Cycle Time
+- Engineering Throughput and Cycle Time - Team View
+
+
+## How is it calculated?
+This metric is calculated by counting the number of PRs in the given data range.
+
+<b>Data Sources Required</b>
+
+This metric relies on PRs/MRs collected from GitHub, GitLab or BitBucket.
+
+<b>Transformation Rules Required</b>
+
+N/A
+
+## How to improve?
+1. From the developer dimension, we evaluate the code quality of developers by combining the task complexity with the metrics related to the number of review passes and review rounds.
+2. From the reviewer dimension, we observe the reviewer's review style by taking into account the task complexity, the number of passes and the number of review rounds.
+3. From the project/team dimension, we combine the project phase and team task complexity to aggregate the metrics related to the number of review passes and review rounds, and identify the modules with abnormal code review process and possible quality risks.
diff --git a/docs/Metrics/RequirementCount.md b/docs/Metrics/RequirementCount.md
index eb7fd6e9..e9a6bd32 100644
--- a/docs/Metrics/RequirementCount.md
+++ b/docs/Metrics/RequirementCount.md
@@ -6,7 +6,7 @@ sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The number of delivered requirements or features.
## Why is it important?
1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
@@ -18,27 +18,27 @@ The number of issues created with the type `REQUIREMENT`.
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric is calculated by counting the number of delivered issues in type "REQUIREMENT" in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on the issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-requirement' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Requirements`.
<b>SQL Queries</b>
If you want to see a single count, run the following SQL in Grafana
```
select
- count(*) as value
+ count(*) as "Requirement Count"
from issues i
join board_issues bi on i.id = bi.issue_id
where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
+ i.type = 'REQUIREMENT'
+ and i.status = 'DONE'
-- this is the default variable in Grafana
and $__timeFilter(i.created_date)
and bi.board_id in ($board_id)
@@ -55,6 +55,7 @@ If you want to see the monthly trend, run the following SQL
join boards b on bi.board_id = b.id
WHERE
i.type = 'REQUIREMENT'
+ and i.status = 'DONE'
and $__timeFilter(i.created_date)
and bi.board_id in ($board_id)
GROUP by 1
diff --git a/docs/Metrics/RequirementDeliveryRate.md b/docs/Metrics/RequirementDeliveryRate.md
index e5e1467e..eb0a0313 100644
--- a/docs/Metrics/RequirementDeliveryRate.md
+++ b/docs/Metrics/RequirementDeliveryRate.md
@@ -6,7 +6,7 @@ sidebar_position: 3
---
## What is this metric?
-The number of issues in type `requirement/feature`, reflecting the throughput of features delivered.
+The ratio of delivered requirements to all requirements.
## Why is it important?
1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
@@ -18,47 +18,16 @@ The number of issues in type `requirement/feature`, reflecting the throughput of
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The number of delivered requirements divided by the total number of requirements in the given data range.
<b>Data Sources Required</b>
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on the issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-requirement' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Requirements`.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
diff --git a/docs/Metrics/RequirementGranularity.md b/docs/Metrics/RequirementGranularity.md
index 3a7e46d4..03bb9176 100644
--- a/docs/Metrics/RequirementGranularity.md
+++ b/docs/Metrics/RequirementGranularity.md
@@ -2,15 +2,15 @@
title: "Requirement Granularity"
description: >
Requirement Granularity
-sidebar_position: 4
+sidebar_position: 5
---
## What is this metric?
-The number of issues in type `requirement/feature`, reflecting the throughput of features delivered.
+The average number of story points per requirement.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Promote product teams to split requirements carefully, improve requirements quality, help developers understand requirements clearly, deliver efficiently and with high quality, and improve the project management capability of the team.
+2. Establish a data-supported workload estimation model to help R&D teams calibrate their estimation methods and more accurately assess the granularity of requirements, which is useful to achieve better issue planning in project management.
## Which dashboard(s) does it exist in
- Jira
@@ -18,7 +18,7 @@ The number of issues in type `requirement/feature`, reflecting the throughput of
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+The average story points of issues in type "REQUIREMENT" in the given data range.
<b>Data Sources Required</b>
@@ -26,42 +26,9 @@ This metric relies on issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-requirement' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Requirements`.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. Analyze the story points/requirement lead time of requirements to evaluate whether the ticket size, ie. requirement complexity is optimal.
+2. Compare the estimated requirement granularity with the actual situation and evaluate whether the difference is reasonable by combining more microscopic workload metrics (e.g. lines of code/code equivalents)
diff --git a/docs/Metrics/RequirementLeadTime.md b/docs/Metrics/RequirementLeadTime.md
index 37d67982..74061d63 100644
--- a/docs/Metrics/RequirementLeadTime.md
+++ b/docs/Metrics/RequirementLeadTime.md
@@ -6,19 +6,20 @@ sidebar_position: 4
---
## What is this metric?
-The number of issues in type `requirement/feature`, reflecting the throughput of features delivered.
+The amount of time it takes a requirement to deliver.
## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
+1. Analyze key projects and critical points, identify good/to-be-improved practices that affect requirement lead time, and reduce the risk of delays
+2. Focus on the end-to-end velocity of value delivery process; coordinate different parts of R&D to avoid efficiency shafts; make targeted improvements to bottlenecks.
## Which dashboard(s) does it exist in
- Jira
- GitHub
+- Community Experience
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+This metric equals to `resolution_date` - `created_date` of issues in type "REQUIREMENT".
<b>Data Sources Required</b>
@@ -26,42 +27,10 @@ This metric relies on issues collected from Jira, GitHub, or TAPD.
<b>Transformation Rules Required</b>
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
+This metric relies on the 'type-requirement' configuration in Jira, GitHub or TAPD transformation rules to let DevLake know what CI builds/jobs can be regarded as `Requirements`.
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.
+1. Analyze the trend of requirement lead time to observe if it has improved over time.
+2. Analyze and compare the requirement lead time of each project/team to identify key projects with abnormal lead time.
+3. Drill down to analyze a requirement's staying time in different phases of SDLC. Analyze the bottleneck of delivery velocity and improve the workflow.
\ No newline at end of file
diff --git a/docs/Metrics/ReviewRounds.md b/docs/Metrics/ReviewRounds.md
deleted file mode 100644
index 7c3e46bb..00000000
--- a/docs/Metrics/ReviewRounds.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Pull Request Review Rounds"
-description: >
- Requirement Count
-sidebar_position: 2
----
-
-## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
-
-## Why is it important?
-1. Based on historical data, establish a baseline of the delivery capacity of a single iteration to improve the organization and planning of R&D resources.
-2. Evaluate whether the delivery capacity matches the business phase and demand scale. Identify key bottlenecks and reasonably allocate resources.
-
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
-
-
-## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
-
-<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
-
-<b>Transformation Rules Required</b>
-
-This metric relies on the "issue type mapping" in "blueprint-transformation rules" page to let DevLake know what issues can be regarded as `REQUIREMENT`.
-
-<b>SQL Queries</b>
-
-If you want to see a single count, run the following SQL in Grafana
-```
- select
- count(*) as value
- from issues i
- join board_issues bi on i.id = bi.issue_id
- where
- i.type in ($type)
- and i.type = 'REQUIREMENT'
- -- this is the default variable in Grafana
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
-```
-
-If you want to see the monthly trend, run the following SQL
-```
- SELECT
- DATE_ADD(date(i.created_date), INTERVAL -DAYOFMONTH(date(i.created_date))+1 DAY) as time,
- count(distinct case when status != 'DONE' then i.id else null end) as "Number of Open Issues",
- count(distinct case when status = 'DONE' then i.id else null end) as "Number of Delivered Issues"
- FROM issues i
- join board_issues bi on i.id = bi.issue_id
- join boards b on bi.board_id = b.id
- WHERE
- i.type = 'REQUIREMENT'
- and $__timeFilter(i.created_date)
- and bi.board_id in ($board_id)
- GROUP by 1
-```
-
-## How to improve?
-1. Analyze the number of requirements and delivery rate of different time cycles to find the stability and trend of the development process.
-2. Analyze and compare the number of requirements delivered and delivery rate of each project/team, and compare the scale of requirements of different projects.
-3. Based on historical data, establish a baseline of the delivery capacity of a single iteration (optimistic, probable and pessimistic values) to provide a reference for iteration estimation.
-4. Drill down to analyze the number and percentage of requirements in different phases of SDLC. Analyze rationality and identify the requirements stuck in the backlog.