yarikoptic commented on code in PR #8761:
URL:
https://github.com/apache/incubator-devlake/pull/8761#discussion_r2919759110
##########
grafana/dashboards/DemoHowFastDoWeRespondToCustomerRequirements.json:
##########
@@ -169,7 +169,7 @@
},
"id": 101,
"options": {
- "content": "<div>\n <img border=\"0\"
src=\"/grafana/public/img/lake/logo.png\" style=\"padding-bottom:20px\"
alt=\"Merico\" width=\"40\"></img>\n <h2 style=\"display:inline-block;\">MARI
Guide - Requirement Lead Time</h2>\n</div>\n\nSection |
Description\n:----------------- | :-------------\nMetric Definition | Total
duration of requirements from proposal to delivery. It can be divided by flow
status in the practice domain or project management system to count the time
share of each phase and help locate the links that drag out the requirement
delivery cycle.\nMetric Value | The Requirement Lead Time reflects the rapid
responsiveness of the R&D team. <br> In theory, the faster you can deliver
value to customers, the better, but other aspects such as whether the delivered
value meets customer expectations, requirement throughput, and delivery quality
must be considered together. Fast delivery does not necessarily equate to good
R&D practices.\n\n***\n#### *M (Measure)*\n1.
Count the average or 80th percentile requiremnt lead time for different
times.\n2. Counts the average or 80th percentile requiremnt lead time for
different projects.<br>\n3. Count the length of time that requirements stay in
different practice domains (requirements analysis, design, development,
testing, release) or in different states.\n\n##### *A (Analyze)*\n1. Compare
the requirement delivery speed of different projects to find the fastest and
slowest delivering projects.\n2. Analyze the trend of the average requirement
lead time within each cycle, make a vertical comparison, and locate the key
points such as maximum value, minimum value, continuous up cycle, and
continuous down cycle.\n3. Analyze the trend of the delivery cycle of 80% of
the requirements within each cycle, make a longitudinal comparison, and locate
the key points such as maximum value, minimum value, continuous up cycle, and
continuous down cycle.<br><br><blockquote>\nWhy choose the 80% quantile instead
of usin
g the average?<br>\nThe point of statistics is to make predictions with real
and valid data to support better decisions, while the mean and median cannot
have the role of supporting predictions.<br>\nTypically, the mean and 80%
quantile statistics will appear twice as far apart, and the 80% and 99%
quantile tend to be approximately twice as related.<br>\nTherefore, the 80%
quantile is a good balance point for prediction.\n</blockquote>\n4. Analysis
compares the length of time requirement stays in different practice domains or
different states to identify the most time-consuming links and find the key
bottlenecks that affect overall delivery speed.\n5. Requirement lead time is
correlated with requirement throughput to identify whether the requirement
delivery trend is healthy or not.\n - Healthy trend: requirement lead time is
shortened and requirement throughput is increased.\n - Unhealthy trend:
longer requirement lead time and lower requirement throughput.\n\n\n##### *R
(Revie
w)*\nBased on the analysis results, focus on a few key points and use Ishikawa
diagram (fishbone diagram) or Root Cause Analysis (RCA) to conduct root cause
analysis, research and review. For example, if the requirement delivery cycle
becomes longer in several consecutive statistical cycles, it is necessary to
further investigate the length of stay of requirements in different phases and
find the longest phase for root cause analysis.\n\n1. The requirements phase
takes too long: unclear requirements, frequent changes, overly granular
requirements, requirements priorities not clearly defined, insufficient
resources or experience of requirements analysts or product managers?\n2. The
design phase takes too long: unclear requirement documents, insufficient
resources or experience of R&D leaders or architects?\n3. The development phase
takes too long: unclear design documents, uneven task distribution, high stream
load (parallel tasks), too much technical debt, too many bugs, insufficien
t resources or experience of developers?\n4. The testing phase takes too long:
unclear requirements documentation, poor code quality, few automated tests,
insufficient resources or experience of testers?\n5. The release phase takes
too long: too long build or deployment time, insufficient resources or
experience of operation and maintenance staff?\n\n##### *I (Improve)*\nBased on
the review results, focus on the key root causes, and give targeted improvement
measures in terms of norms, processes, tools and behaviors, etc., with clear
improvement targets, improvement measures, verification cycles and responsible
persons.\n\nThe following are the improvement ideas for reference:\n\n1.
Communicate with customers or business parties to clarify requirements,
reasonably disassemble requirements and define priorities, and invite business
parties, R&D leaders and testing leaders to review requirements.\n2. Invite
product managers, R&D personnel, and test leaders to conduct design reviews.\n
3. Reduce requirement or task granularity, distribute tasks evenly, reduce
flow load, increase unit testing, and solve technical debt and code problems in
time to reduce the number of bugs and rework.\n4. Test left, develop self-test,
code review, increase automated testing, and improve continuous integration
capabilities.\n5. Automate deployment, shorten build time, and improve
continuous delivery.\n6. Reasonable resource allocation and necessary training
for each job holder.\n7. The improvement results should also be quantifiable to
facilitate continuous metrics and tracking of improvement effects.",
Review Comment:
here github fails to highlight requiremnt -> requirement
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
