How to use usage scenarios for an accurate assessment of the complexity of the work
Each of the programmers and development managers at least once, but fell on the dates, i.e. violated them, strongly or not.
Try to unscrew all your projects back and evaluate the real lateness on them.
It may turn out that the delays simply reach gigantic values.
')
The author of the article saw projects with a delay of 400% and 700%!
There is an opinion that developing programs without being late is impossible in principle.
In general, the reason for this view is clear, because people are not visionaries and cannot see the future.
At the time of the assessment of labor input TK is not always. And even if it is, the factor of uncertainty still continues to play a huge role - after all, people, unfortunately, are not really visionaries, and no matter how detailed the TK is, there are still moments hidden from view.
In addition to the hidden functionality, the qualification and personal programming experience of the evaluator itself also affects the erroneous assessment (it is more difficult for a person without personal programming experience to estimate how long development will take).
Interestingly, the use case scenarios (variants) allow one to estimate the laboriousness of the work fairly accurately.
Practice has shown that it is possible to achieve 20% accuracy (=% error) in the assessment. But lateness of 20% is not 700% at all, right?
How to do it?
The essence of the alternatives!
The beauty of use cases is that they describe not only the main course of events, but also all possible and impossible alternative situations. And alternatives - these are the very pitfalls, because of which errors arise in the assessment of labor intensity.
How to calculate the complexity of using scripts?
Imagine that you need to program such a small window:
The example is not entirely correct, because It is not a business task, but it can be used as an illustration to the calculation of labor intensity. Therefore, please make a discount on the accuracy of the presentation of the script and concentrate on the complexity, okay?
Briefly write the script:
Successful result: the selected document is registered in the property of an object
1. The user enters a search phrase.
2. The system displays a list of suitable documents, in the title of which is the desired phrase . Documents submitted by its name. The list is sorted alphabetically.
3. The user selects one of the documents.
4. The system writes the selected document to the desired object .
2a.The user wants to find documents as of the specified date
1. The system displays a list of suitable documents, limited by date of creation . Execution proceeds according to p.3.
2b. The user wants to find a document in the archive
1. 1. The system displays a list of relevant active and archival documents . Execution proceeds according to p.3.
3a.No document found
1. The system displays the message: "No document found." Execution continues according to claim 1.
Please note that the script is divided into two parts: “Main Successful Script” and “Alternatives”.
And now think, how usually does the assessment of labor intensity? I think you will agree that work is usually assessed only by a successful scenario (as the most obvious one that comes to mind first), but they don’t think about alternatives at all.
This is the essence of the problem - it is in the alternatives that the main complexity is often buried.
Let's go further.
In the example, italic marked the operations that the programmer needs to program.
In alternatives, you can see two operations that are not in the main scenario. Let's think about what these operations are? In essence, these are ordinary SQL queries to the database, but!
They contain additional parameters that are not in the main query. And it may well turn out that debugging requests with these parameters will take 10 times longer than the main request. And that's exactly what happens, right?
Using scripts allows you to pull out all these alternatives (or most of them), and so on. It is several times more accurate to estimate the total laboriousness of the work.
Let's summarize all the information on the script into one table and try to calculate how long the implementation will take:
Creating class infrastructure - 1h
Formation window - 2h
List of documents for a keyword phrase - 1 hour
Displaying the list of documents, taking into account the creation date - 1 hour
Listing of documents with archival records - 1 hour
Writing the selected document to the object properties - 1 hour
Testing 4 * 0.5h = 2h
Total: 9 h
As you can see, the assessment takes into account an additional 2 hours for the implementation of alternatives and another 1 hour for their testing. And if the assessment was carried out only on a successful scenario, then these 3 hours we would not be counted.
And this is almost 50% of the time (6 hours on the main script and 3 hours on alternatives)!
Usage scenarios unambiguously give a very big advantage in the assessment of labor intensity. Use them to gain a competitive advantage over other software developers.
If at the time of the assessment you have not yet written the scenarios, try to at least briefly outline the main alternatives. This is a good improvement.
It happens that the script steps are not small enough. Imagine, for example, that the system should publish any data.
As you understand, under the “publication” can be hidden a whole heap of actions that are difficult to determine immediately.
Such situations are very easy to determine when time is spent in the assessment of labor intensity> 3 hours. This clearly indicates that the person giving the assessment does not know what is hidden inside. And there is a 100% sitting BIG ambush! Tested many times.
In this case, be sure to think over and write down what is hidden inside, otherwise you can get very much on the timing.
Try to unscrew all your projects back and evaluate the real lateness on them.
It may turn out that the delays simply reach gigantic values.
')
The author of the article saw projects with a delay of 400% and 700%!
There is an opinion that developing programs without being late is impossible in principle.
In general, the reason for this view is clear, because people are not visionaries and cannot see the future.
At the time of the assessment of labor input TK is not always. And even if it is, the factor of uncertainty still continues to play a huge role - after all, people, unfortunately, are not really visionaries, and no matter how detailed the TK is, there are still moments hidden from view.
In addition to the hidden functionality, the qualification and personal programming experience of the evaluator itself also affects the erroneous assessment (it is more difficult for a person without personal programming experience to estimate how long development will take).
Interestingly, the use case scenarios (variants) allow one to estimate the laboriousness of the work fairly accurately.
Practice has shown that it is possible to achieve 20% accuracy (=% error) in the assessment. But lateness of 20% is not 700% at all, right?
How to do it?
Where to begin
The essence of the alternatives!
The beauty of use cases is that they describe not only the main course of events, but also all possible and impossible alternative situations. And alternatives - these are the very pitfalls, because of which errors arise in the assessment of labor intensity.
How to calculate the complexity of using scripts?
Imagine that you need to program such a small window:
The example is not entirely correct, because It is not a business task, but it can be used as an illustration to the calculation of labor intensity. Therefore, please make a discount on the accuracy of the presentation of the script and concentrate on the complexity, okay?
Briefly write the script:
“Find Document” usage scenario
Successful result: the selected document is registered in the property of an object
Main successful script
1. The user enters a search phrase.
2. The system displays a list of suitable documents, in the title of which is the desired phrase . Documents submitted by its name. The list is sorted alphabetically.
3. The user selects one of the documents.
4. The system writes the selected document to the desired object .
Alternatives
2a.The user wants to find documents as of the specified date
1. The system displays a list of suitable documents, limited by date of creation . Execution proceeds according to p.3.
2b. The user wants to find a document in the archive
1. 1. The system displays a list of relevant active and archival documents . Execution proceeds according to p.3.
3a.No document found
1. The system displays the message: "No document found." Execution continues according to claim 1.
Please note that the script is divided into two parts: “Main Successful Script” and “Alternatives”.
And now think, how usually does the assessment of labor intensity? I think you will agree that work is usually assessed only by a successful scenario (as the most obvious one that comes to mind first), but they don’t think about alternatives at all.
This is the essence of the problem - it is in the alternatives that the main complexity is often buried.
Let's go further.
In the example, italic marked the operations that the programmer needs to program.
In alternatives, you can see two operations that are not in the main scenario. Let's think about what these operations are? In essence, these are ordinary SQL queries to the database, but!
They contain additional parameters that are not in the main query. And it may well turn out that debugging requests with these parameters will take 10 times longer than the main request. And that's exactly what happens, right?
Using scripts allows you to pull out all these alternatives (or most of them), and so on. It is several times more accurate to estimate the total laboriousness of the work.
How to evaluate the complexity
Let's summarize all the information on the script into one table and try to calculate how long the implementation will take:
Creating class infrastructure - 1h
Formation window - 2h
List of documents for a keyword phrase - 1 hour
Displaying the list of documents, taking into account the creation date - 1 hour
Listing of documents with archival records - 1 hour
Writing the selected document to the object properties - 1 hour
Testing 4 * 0.5h = 2h
Total: 9 h
As you can see, the assessment takes into account an additional 2 hours for the implementation of alternatives and another 1 hour for their testing. And if the assessment was carried out only on a successful scenario, then these 3 hours we would not be counted.
And this is almost 50% of the time (6 hours on the main script and 3 hours on alternatives)!
Results
Usage scenarios unambiguously give a very big advantage in the assessment of labor intensity. Use them to gain a competitive advantage over other software developers.
PSA what if there are no scripts yet?
If at the time of the assessment you have not yet written the scenarios, try to at least briefly outline the main alternatives. This is a good improvement.
PPS Where else is the pig buried
It happens that the script steps are not small enough. Imagine, for example, that the system should publish any data.
As you understand, under the “publication” can be hidden a whole heap of actions that are difficult to determine immediately.
Such situations are very easy to determine when time is spent in the assessment of labor intensity> 3 hours. This clearly indicates that the person giving the assessment does not know what is hidden inside. And there is a 100% sitting BIG ambush! Tested many times.
In this case, be sure to think over and write down what is hidden inside, otherwise you can get very much on the timing.
Source: https://habr.com/ru/post/294780/
All Articles