The more overtime the more trouble _ how to jump out of the programmer's vicious circle? _ Programmer

Click to have a surprise

How to make every cute engineer less overtime, not overtime. Alibaba technical expert Zhang Guanan, in the quality assurance system construction, the continuous integration domain, the Agile practice domain and the research and development efficiency domain has the rich experience and the experiences. Today, Guan Nan will use the Ali research and development team's actual case, vividly demonstrates how to use the data to drive the research and development efficiency enhancement.



This article is my use cloud effect public cloud measurement function, plus agile part of the method guidance, practice in a division dozens of people team precipitation results, hope to give you some reference meaning. I will cover a variety of key representations of data, but detailed data, including data from a specific research and development team, also needs to be accessed by the cloud-effective public cloud Metrics feature page.

Data presentation

To give you the data first, I began to enter the team in April. Focus on this team's March data:




Problem analysis

The above picture is easy to see, the team's obvious feature is: March completed the demand number significantly increased, and the team load is heavy. Quality is not high-defect number, reopen rate and online publishing success rate. The average length of demand is exceptionally long. Sudden increase in fault.

So we have the data exposed to these issues, and team of front-line research and development personnel, PD, TL to communicate, analyze the meaning behind the numbers. We soon reached a consensus found that the main problem of the team is: the demand deliver traditional waterfall model, 1 to 2 months to complete a particularly large demand, and finally, and the user expectations of a large deviation, data representation is a small number of previous requirements, March suddenly completed a lot and a long time demand. We work overtime, heavy load, the introduction of more defects, PD and users are not satisfied with the changes will increase the workload, such a vicious circle. The importance of the defect is not high, management is not standardized, the priority division is not clear, or even residual important defects, remain in the bug list unresolved and flow to the line to cause trouble.

The above three points formed a vicious circle, the result is more and more, more and more wrong, the more wrong, change, change more.

Solution Landing and data operation

After discovering the problem, the targeted solution and landing on the relatively easy, we give the team's solution is: requirements refinement: Split into the smallest deliverable, try to avoid a need to do for 1 months, to find PD and user acceptance. Embrace the user at any time: iterative output, delivery is acceptance, so that the accuracy to the minimum, the error is minimal when correcting. Focus on quality management and operations: transparent data, encourage the team to fix bugs as soon as possible, and have strict bug resolution rate standards before the line. Make every effort to guarantee the success rate of online publishing.

At the same time, we perform regular data operations and analyze data, including quality and efficiency, to ensure that we can identify problems and correct deviations at the first time. So in 3 months time, I focused on the following data. On the interpretation and analysis of these data, the content is more in-depth, I only do a simple general introduction: The requirements of the throughput: the team specified time period to complete the number of requirements, can generally reflect the team's output trend. The average time required to complete: the average time from the creation to the final state, the more times the demand delivery granularity of the more efficient. Number of new defects: the number of defects assigned to the team in the statistical time period, the combination of stock defects and the average length of the defects, the quality of the team products and the efficiency of the defect resolution. Average resolution length of defects: the average time length from creation to resolution, and the efficiency of resolving defects. Online release success rate: The number of successful online publishing and the total number of times, the higher the quality of the product on the line higher. Reopen rate of defects: the ratio of the number of defects being reopen to the number of defects, the higher the value, the worse the quality of repairing defects, the reopen rate is an important index to characterize the quality of products.

Results Analysis and summary

We go back to the 6 charts above and a bug resolution timeline below, we enter at the end of March, focusing on data starting from April: The team's load is controlled, the number of requirements has been reduced, and the following 3 months have been maintained in a relatively stable state. After the requirement refinement split, the delivery time is reduced, and the team delivers the demand at a faster rate. The number of defects decreased, the rate of reopen decreased, the success rate of online publishing increased, and quality was improving. The average resolution time of defects increases significantly, the team delivers faster, faster feedback issues, and faster resolution of problems.

Overall, is the need to deliver fast, get feedback quickly, correct error/defect cost is low, the defect is also slowly convergent, the quality is also improved, defect repair is also fast, this is a virtuous circle, summed up the total is: efficiency increased, quality assurance. Team people work harder too.

How to further improve.

According to the number of requirements and the average time to complete the data show that the team still has room for growth, for the requirements of the delivery granularity and speed, or slightly fluctuations, in order to quickly know whether we do is the user needs, the rapid, iterative delivery needs, lest the user want a car, we gave him 4 wheels.
So whether you can completely solve the needs of the team's delivery and user expectations of the problem, or need to go one step further, the demand continues to refine, improve delivery rate. See agile, quick iterations, fast delivery, quick feedback, just for faster and more accurate.

Summarize

Data is attractive, research and development data are the same, we use it for two purposes: one is to ensure quality, and the other is to ensure the rate of delivery. In the course of walking, we used the new function of cloud effect measurement, combined with some ideas of agile, and cooperated with the traditional test method to help the research team.
Maybe some people will question the need to use such a cold figure to measure our lovely programmer brother. My answer is: this is not a measure. Data is just a means to help us to diagnose the team in a practical and effective way. Learn to use it and harness it. So we only need to: focus on the data, read the data. Key issues focus on solving, priority resolution, a period of time to focus on only one or a few problems. Believe that the team's ability to drive, combined with the management and motivation of TL, develop a good team building power.

Welcome to the Exchange discussion

The development team is dealing with the most daily needs, defects, code, release, application, testing, and so on, which is closely related to our research and development staff data, cloud effect is now the development of the market, team space, staff effectiveness, quality distribution and other dimensions of data integration into the data platform, The follow-up will be tailored to meet the development team's demand for research and development data. The use of this tool can help us to clearly understand the status of the team, exposing problems, to find improvement measures to improve team efficiency and product quality.
I am an agile enthusiast, in depth research and development team to do testing and quality management, but also to learn and learn from the agile part of the idea to the landing. My feeling is that getting the most out of it, such as stations, Kanban, fast iterative delivery requirements, and data support, is a means to help the team deliver high quality products faster and more accurately.
Finally, I posted a few data shows of a research and development team that I cut on the metric, this team is our recently contacted team, through the data we to this team's speculation is: the team in the quality needs enhancement, in the defect management needs to strengthen. First of all, the number of team defects is rising monthly, which is the trend of poor quality.



Another defect resolution time is not accelerated, which will lead to more and more defects flow to the line, visible team to eliminate the failure of January, followed by a few months of failure. And the team's online publishing success rate continues to decline, the development of online code to control the degree of low. So finding the reasons behind these data representations and working on them is the most urgent thing the team has to do in the near future.
Develop good research and development habits, and maintain efficient team cooperation, should be the pursuit of each research and development students to persevere.

Click to have a surprise