9 metrics that may be relevant for modern software development teams /OTUS Blog. Online education /geek magazine
A translation of the article was prepared in advance of the start of the course. Team Lead ???r3r3355. .
As I noted in article
"Why metrics don't matter in software development unless you pair them with business goals" , The choice of metrics needs to be carefully thought out to give answers to the questions that poses. Business This is the critical point: measurements should be designed to answer business questions, and these questions will never sound like “How many thousands of lines of code do we have in the project right now?”
This article continues the theme begun in the previous one. First we’ll talk about specific metrics that each team should use, or at least plans to use, in order to significantly improve performance . Please note that the title of this article begins with “9 metrics that MAY matter ” because it is important how these metrics add value to the business. How you use them is up to you. We conclude the article with a story about how to meaningfully combine these metrics with each other, as well as formulate and test a hypothesis about the value of a business. quality. software which in the later stages of development (or subsequent stages of the life cycle) is often overlooked. Security analysis tools can be used during the assembly process along with more specialized assessment methods and stress tests. Security requirements are consistent with common sense, but the development team should always remember them, as well as the metrics that come from them.
The full range of security methods and related metrics is beyond the scope of this article, but, as with agile process metrics and production metrics, there are several very specific metrics that will go a long way towards satisfying the needs of your customers.
Incidents at the endpoints of 3-3-3195. - the number of endpoints (mobile devices, workstations, etc.) on which the virus was detected for a certain time.
[i] MTTR (Mean Time Between Failures) - in terms of security - this is the time between the detection of a system security violation and the deployment and operation of the security tool. As with MTTR, which we talked about in production metrics, the security issue should be monitored for specific time intervals. If the MTTR value decreases over time, then developers work more efficiently and better understand security problems, find errors and fix them.
For both of these metrics, decreasing the value of an indicator over time means that you are moving in the right direction. Fewer incidents at endpoints speak for themselves. As the value of MTTR decreases, developers work more efficiently and better understand security problems, find errors and fix them.
You will find more ways to apply security metrics in software development in articles 3–3–3200. Application Security for Agile Projects
and Security Threat Models: An Agile Introduction .
Note on source code metrics
To date, connecting the source scanner to the assembly pipeline and getting a bunch of objective metrics is quite easy. There are empirical averages, suggested ranges, and logical arguments in favor of the relative importance of these indicators. However, in practice, these tools are more useful for ensuring compliance with a certain style of writing code, highlighting certain antipatterns and identifying anomalies and patterns.
Do not get stuck in numbers. I will give an example so that you understand what I am driving at.
Suppose you find in a class a method with an absurd NPATH difficulty score of 52 million. That is, 52 million test cases will be required to test each variant of the method. You can refactor the code and get a simpler structure, but before you do this, think about how this will affect the business logic. Most likely, this old scary code works quite well (despite the fact that it may not be fully covered by tests). It will be valuable to show this antipattern to your team so that they don’t do it anymore, since the fix of this method as a whole will not change any worthwhile business metrics.
Best of all, if the team agrees with the level of requirements and rules which their code answers, but keep in mind that studying anomalies and worrying about the appearance of any patterns can be time-consuming.
Putting it all together: Success is a universal metric
The main advantage of using automated tools for tracking and measuring quality indicators and analyzing user behavior lies in the fact that they free up time to work on really important indicators - indicators of success.
How to use metrics to succeed
A business has goals. In order to hide questions, for example: "What does success look like?" or “How will the product affect customer behavior?” Correctly formulated questions are fraught with metrics.
In other words, metrics should only be used to answer the questions posed, to test hypotheses formulated regarding a specific business goal. These questions should be answered as long as the answers lead to positive changes.
Do not all projects have a certain set of invariant goals, questions and hypotheses, and therefore metrics?
Yes, but only from a business perspective. Business level metrics, such as user engagement, closing ratio, revenue generation, etc., provide feedback on how the business affects the real world. Software changes that will affect the business will also affect these metrics.
At a finer level of resolution, each function and User Story can have their own success rate - it is preferable that it be unique and be directly related to the value that is delivered to the client. Closing 9 out of 10 stories for a sprint for functions that remain undeliverable is not a success, but a defeat. Delivering stories that customers don’t need and don’t use is not a success, but a waste of time and effort. Creating stories that make the user a little happier is success. Creating a story that hasn’t improved user experience is also a success, because now you know that this business hypothesis does not work, and you can free up resources to search for other ideas.
How to formulate the value hypothesis
The value hypothesis is a statement about what, in your opinion, will happen as a result of adding a certain function. The relationship between software, the desired result and metrics forms a value hypothesis for a function (or system, history, update, etc.). The hypothesis should express the expected change in the target metric over a certain period of time, as well as the concept of its effectiveness. You will need to talk with the team and the Product Owner to at least find out what exactly this function or story can create or improve in relation to the business in order to formulate a value hypothesis regarding it. You may have to ask the question “why” several times (as a child) to get rid of unspoken assumptions, so be patient. Once you understand what business value should be, you can start asking questions that will lead you to metrics that answer them.
For example, a “technical” story about increasing the speed of placing an order in an online store may have the idea that speeding up sales will lead to an increase in their number. But why do we think so? How many people leave shopping baskets during the checkout process? If you come to a consensus (backed up by your assumptions with data), then value hypothesis it may sound like this: “We believe that accelerating the process of placing an order will lead to a decrease in the rate of“ rejection of a basket ”. In turn, this will lead to increased sales and improved user experience. ”
You probably expect users to like the speedordering process, but it would not be superfluous to ask if they noticed it at all. The abandonment rate of the basket and sale can be measured for a certain time before the introduction of the new process and after. If the cart abandonment rate drops and sales increase (taking into account statistical fluctuations), then the evidence confirms the hypothesis, and you may wonder if a further increase in the speed of checkout is justified. If not, then let this metric recede into the background (or exclude it altogether so as not to distract), and turn your attention to the following hypothesis. If the cart abandonment ratio is reduced and sales remain unchanged, take longer measurements or try rethinking the alleged relationship between cart abandonment and sales. In other words, use metrics that bring meaningful improvements in order to learn.
In some cases, the hypothesis is erroneous, and we discard the metrics (and roll back to the old version of the software) after a few days. In other cases, the hypothesis may be true, so we continue to improve performance in this area for many years.
Six heuristics for the effective use ofmetrics.
We saw how subjective metrics made a greater contribution to business success than the good old objective quality indicators. The acquired knowledge and training opportunities prevail over the efforts necessary to search and measure relevant business performance indicators. Business conditions and opportunities are constantly changing, so instead of deriving a fragile formula that could be followed, I will give six rules of thumb, or heuristics, that will help maintain focus and flexibility. Let them help you on your journey to quality software and success!
Metrics will not tell you the whole story, but the team will tell (I take off my hat to Todd Dekapula );
Comparing snowflakes is a waste of time.
You can measure almost everything, but you can not pay attention to everything.
Business success metrics help improve software, not the other way around.
Each function adds value, whether you measure it or not.
Measure only those indicators that matter at a given moment.
Build work processes on a remote site: practical recommendations
Why don't you have to become a team leader?
Why do my colleagues /employees behave like @% §?
Burn, but not burn - burn to shine
Learn more about the course.
It may be interesting