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 10:08:20 UTC
[incubator-devlake-website] branch main updated: docs: added 8 metrics
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
The following commit(s) were added to refs/heads/main by this push:
new 088f86ad docs: added 8 metrics
088f86ad is described below
commit 088f86ad4484db6a6e7dc194634023e2b7e78b1d
Author: yumengwang03 <yu...@merico.dev>
AuthorDate: Fri Aug 19 17:59:35 2022 +0800
docs: added 8 metrics
---
docs/Metrics/CodingTime.md | 57 ++++++++----------------------------------
docs/Metrics/CycleTime.md | 38 ++++++++++++++++++++++++++++
docs/Metrics/DeployTime.md | 51 ++++++-------------------------------
docs/Metrics/PRSize.md | 58 +++++++++---------------------------------
docs/Metrics/PickupTime.md | 57 ++++++++----------------------------------
docs/Metrics/ReviewDepth.md | 59 +++++++++----------------------------------
docs/Metrics/ReviewTime.md | 61 +++++++++++----------------------------------
docs/Metrics/TimeToMerge.md | 61 +++++++++++----------------------------------
8 files changed, 119 insertions(+), 323 deletions(-)
diff --git a/docs/Metrics/CodingTime.md b/docs/Metrics/CodingTime.md
index 0a5d71d7..915eb9a3 100644
--- a/docs/Metrics/CodingTime.md
+++ b/docs/Metrics/CodingTime.md
@@ -1,67 +1,30 @@
---
-title: "Coding Time"
+title: "PR Coding Time"
description: >
- Requirement Count
+ PR Coding Time
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time it takes from the first commit until a PR is issued.
## 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.
+It is recommended that you keep every task on a workable and manageable scale for a reasonably short amount of coding time. The average coding time of most engineering teams is around 3-4 days.
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+## Which dashboard(s) does it exist in?
+- 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".
-
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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.
+Divide coding tasks into workable and manageable pieces.
diff --git a/docs/Metrics/CycleTime.md b/docs/Metrics/CycleTime.md
new file mode 100644
index 00000000..19c9a7e0
--- /dev/null
+++ b/docs/Metrics/CycleTime.md
@@ -0,0 +1,38 @@
+---
+title: "PR Cycle Time"
+description: >
+ PR Cycle Time
+sidebar_position: 2
+---
+
+## What is this metric?
+PR Cycle Time is the sum of PR Coding Time, Pickup TIme, Review Time and Deploy Time. It is the total time from the first commit to when the PR is deployed.
+
+## Why is it important?
+PR Cycle Time indicate the overall speed of the delivery progress in terms of PR.
+
+## Which dashboard(s) does it exist in?
+- Engineering Throughput and Cycle Time
+- Engineering Throughput and Cycle Time - Team View
+
+
+## How is it calculated?
+You can define `deployment` based on your actual practice. For a full list of `deployment`'s definitions that DevLake support, please refer to [Deploy Frequency](/docs/Metrics/DeployFrequency.md).
+
+<b>Data Sources Required</b>
+This metric relies on PR/MRs collected from GitHub or GitLab.
+
+<b>Transformation Rules Required</b>
+N/A
+
+<b>SQL Queries</b>
+
+
+## How to improve?
+1. Divide coding tasks into workable and manageable pieces;
+2. Use DevLake's dashboards to monitor your delivery progress;
+3. Have a habit to check for hanging PRs regularly;
+4. Set up alerts for your communication tools (e.g. Slack, Lark) when new PRs are issued;
+2. Use automated tests for the initial work;
+5. Reduce PR size;
+6. Analyze the causes for long reviews.
\ No newline at end of file
diff --git a/docs/Metrics/DeployTime.md b/docs/Metrics/DeployTime.md
index 0b824b62..94764586 100644
--- a/docs/Metrics/DeployTime.md
+++ b/docs/Metrics/DeployTime.md
@@ -1,67 +1,30 @@
---
title: "PR Deploy Time"
description: >
- Requirement Count
+ PR Deploy Time
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time it takes from when a PR is merged to when it is deployed.
## 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
+## Which dashboard(s) does it exist in?
## How is it calculated?
-This metric is calculated by counting the number of completed issues in type "REQUIREMENT".
+You can define `deployment` based on your actual practice. For a full list of `deployment`'s definitions that DevLake support, please refer to [Deploy Frequency](/docs/Metrics/DeployFrequency.md).
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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.
+
diff --git a/docs/Metrics/PRSize.md b/docs/Metrics/PRSize.md
index 6677bafb..284addfc 100644
--- a/docs/Metrics/PRSize.md
+++ b/docs/Metrics/PRSize.md
@@ -1,67 +1,33 @@
---
-title: "PR/MR Size"
+title: "PR Size"
description: >
- Requirement Count
+ PR Size
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The average code changes (in Lines of Code) of PRs in the selected time range.
## 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.
+Small PRs can reduce risks of introducing new bugs and increase code review quality, as problems may often be hidden in big chuncks of code and difficult to identify.
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+## Which dashboard(s) does it exist in?
+- 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".
+This metric is calculated by counting the total number of code changes (in LOC) divided by the total number of PRs in the selected time range.
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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. Divide coding tasks into workable and manageable pieces;
+1. Encourage developers to submit small PRs and only keep related changes in the same PR.
diff --git a/docs/Metrics/PickupTime.md b/docs/Metrics/PickupTime.md
index fa767dd3..1a37a477 100644
--- a/docs/Metrics/PickupTime.md
+++ b/docs/Metrics/PickupTime.md
@@ -1,67 +1,32 @@
---
title: "PR Pickup Time"
description: >
- Requirement Count
+ PR Pickup Time
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time it takes from when a PR is issued until the first comment is added to that PR.
## 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.
+PR Pickup Time shows how engaged your team is in collaborative work by identifying the delay in picking up PRs.
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+## Which dashboard(s) does it exist in?
+- 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".
-
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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. Use DevLake's dashboard to monitor your delivery progress;
+2. Have a habit to check for hanging PRs regularly;
+3. Set up alerts for your communication tools (e.g. Slack, Lark) when new PRs are issued.
diff --git a/docs/Metrics/ReviewDepth.md b/docs/Metrics/ReviewDepth.md
index 1871a5ab..e9b5e7b2 100644
--- a/docs/Metrics/ReviewDepth.md
+++ b/docs/Metrics/ReviewDepth.md
@@ -1,67 +1,32 @@
---
-title: "Review Depth"
+title: "PR Review Depth"
description: >
- Requirement Count
+ PR Review Depth
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The average number of comments of PRs in the selected time range.
## 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
+PR Review Depth (in Comments per RR) is related to the quality of code review, indicating how thorough your team reviews PRs.
+## Which dashboard(s) does it exist in?
+- 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".
+This metric is calculated by counting the total number of PR comments divided by the total number of PRs in the selected time range.
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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. Encourage multiple reviewers to review a PR;
+2. Review Depth is an indicator for generally how thorough your PRs are reviewed, but it does not mean the deeper the better. In some cases, spending an excessive amount of resources on reviewing PRs is also not recommended.
\ No newline at end of file
diff --git a/docs/Metrics/ReviewTime.md b/docs/Metrics/ReviewTime.md
index c3b0cb06..0769c340 100644
--- a/docs/Metrics/ReviewTime.md
+++ b/docs/Metrics/ReviewTime.md
@@ -1,67 +1,36 @@
---
title: "PR Review Time"
description: >
- Requirement Count
+ PR Review Time
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time it takes to complete a code review of a PR before it gets 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.
+Code review should be conducted almost in real-time and usually take less than two days. Abnormally long PR Review Time may indicate one or more of the following problems:
+1. The PR size is too large that makes it difficult to review.
+2. The team is too busy to review code.
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+## Which dashboard(s) does it exist in?
+- 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".
-
+This metric is the time frame between when the first comment is added to a PR, to when the PR is merged.
<b>Data Sources Required</b>
-
-This metric relies on issues collected from Jira, GitHub, or TAPD.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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. Use DevLake's dashboards to monitor your delivery progress;
+2. Use automated tests for the initial work;
+3. Reduce PR size;
+4. Analyze the causes for long reviews.
\ No newline at end of file
diff --git a/docs/Metrics/TimeToMerge.md b/docs/Metrics/TimeToMerge.md
index b8150e0a..db86f627 100644
--- a/docs/Metrics/TimeToMerge.md
+++ b/docs/Metrics/TimeToMerge.md
@@ -1,67 +1,34 @@
---
-title: "Time To Merge"
+title: "PR Time To Merge"
description: >
- Requirement Count
+ PR Time To Merge
sidebar_position: 2
---
## What is this metric?
-The number of issues created with the type `REQUIREMENT`.
+The time it takes from when a PR is issued to when it is merged. Essentially, PR Time to Merge = PR Pickup Time + PR Review Time.
## 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.
+The delay of reviewing and waiting to review PRs has large impact on delivery speed, while reasonably short PR Time to Merge can indicate frictionless teamwork. Improving on this metric is the key to reduce PR cycle time.
-## Which dashboard(s) does it exist in
-- Jira
-- GitHub
+## Which dashboard(s) does it exist in?
+- GitHub Basic Metrics
+- Bi-weekly Community Retro
## 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.
+This metric relies on PR/MRs collected from GitHub or GitLab.
<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. Use DevLake's dashboards to monitor your delivery progress;
+2. Have a habit to check for hanging PRs regularly;
+3. Set up alerts for your communication tools (e.g. Slack, Lark) when new PRs are issued;
+4. Reduce PR size;
+5. Analyze the causes for long reviews.