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 <[email protected]>
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.
