Process implementation - step by step instructions
I want to share the experience of developing and introducing ah-ti processes in the project. Why do we need processes? They meet many different goals, but in our case the main goal was the division of responsibility.
Many programmers will agree that when they find a bug in an already running system, the blame falls on them. And who else? After all, they allowed him! As a result, the motivation decreases, the image deteriorates, and in general - those who work the most get the most kicks. And the recognition is received by managers, sales and other ...
About 9 months ago I was asked to introduce processes into one project. The project is very large and strategic for the organization - the system collects, processes and calculates all the estimates of all students in the country. Every September, an operating cycle begins, which should work like a clock, without errors and delays. In January, planning for system change begins, and the operational cycle continues in the meantime.
I am not an expert in the processes, so everything that was told is based on personal experience. However, the experience is very positive - the number of defects with which the system entered UAT was equal to 0, and, for the first time in 3 years, UAT started during and passed with the sign-off.
')
Step one - where are the problems?
The first step in developing the process is to establish what is bad now and how to avoid it.
With this question, I pestered everyone - programmers, testers, analysts, managersand pedestrians on the streets . It turned out that bad - everything. Untested code comes to the system when it is not necessary, that it is impossible to track the history of changes, that it is not clear who is responsible for what, that the bases are constantly overflowing, and much more.
The conclusion of this stage was the fact that you need an exact distribution of responsibility. For example:
- When a programmer injects code, he is responsible for his unit testing, and for the fact that the implementation will not spoil anything
- When the tester says that everything works - the responsibility for this decision is already on it
- When an analyst confirms that the system is suitable for UAT - he is responsible for the functionality
Etc.
Step Two - Identify Processes
Then I defined the processes that I will describe. Since the system is already developed, we needed a process for “change” (change request) and a bug (defect).
Each process has initial conditions (precondition), steps (steps) and final condition (post-condition). A process step can be either a simple step, or a fork, or another process. Each process and step will have its inputs and outputs.
In the “Change” process, the initial condition was “change and business specification approved by the client”. This is a guarantee that the change is necessary, and the specification meets the requirement of the client. That the client will not then say that we did not do what he asked for, as it often happened before. Below is a complete diagram of the “Change” process and a description of its main sub-processes.
The first step in "change" is the specification. She is trained by the programmer who is responsible for the change, and she must guarantee him that his understanding of the requirement is correct. When the analyst confirms the specification, it is the green light to begin direct development. If the analyst thinks the specification is incomplete or incorrect, it is sent to the programmer for editing. As a result, the programmer’s motivation and confidence that he will satisfy the user requirements increases. Previously, it often happened that the requirements are “understandable and so,” and the programmer, without even noticing it, makes assumptions that do not meet the expectations of the analyst and the client. And now we know what and how we will do.
The next step is programming, which ends with a unit test. All objects are stored in SVN, when adding comments are required, the places where the code changes are commented on at least the version number, etc. Also, a recommendation was introduced on the use of SVN - when a new branch is created, when it merges with the main one, and so on.
After it - introduction. As an artifact, Release Notes comes out of it, which will contain the entire list of changed objects, testing tips, and so on. Before direct introduction into the living system, the programmer must obtain formal permission from the analyst so that the change does not violate the “operational cycle”. The analyst must make sure that the code is correct - sometimes just standing behind the programmer, demonstrating functionality, or viewing the data output. Once the implementation is allowed, the responsibility for the impact on the system on the analytics.
I will not detail the testing and defect processes - probably everyone has them, and it is always very similar. In my case, emphasis was placed on the division of responsibility, permission to implement.
Step three - process implementation
This is the most difficult. Here it is necessary to convince one and all that these processes are a silver bullet. Because if at least one will not follow them - all for nothing!
I did a presentation. First to the top management. There is no problem. Then - to analysts who constantly ask tricky questions and have to rule again and again. Then programmers, with whom it is even worse, have to prove that the specification is needed, and it is quite short, and there is more sense from release notes than costs.
Once everyone is convinced, it is urgent to proceed to action. I prepared document templates, created libraries in sharepoint, so that everyone could immediately understand which square in the diagram is in which menu of the site.
Earned!
Step Four - Improvements
As the process is used, new ideas emerge, how to optimize it, where to add it. The process document is a living document and it is necessary to inspire colleagues to make changes - it is important that the process suits everyone and is suitable for their purpose!
findings
A little bureaucracy made the necessary changes over the 9 months. Each team member feels relatively safe because there are more verification and confirmation points. On the other hand, everyone feels responsible for his work, because he knows that its quality will be checked, verified soon, and therefore he tries harder. In addition, work in an organized team, where everyone knows what he should and what does not increase motivation.
I hope someone will benefit from my experience, and I will be happy to answer your questions!
Many programmers will agree that when they find a bug in an already running system, the blame falls on them. And who else? After all, they allowed him! As a result, the motivation decreases, the image deteriorates, and in general - those who work the most get the most kicks. And the recognition is received by managers, sales and other ...
About 9 months ago I was asked to introduce processes into one project. The project is very large and strategic for the organization - the system collects, processes and calculates all the estimates of all students in the country. Every September, an operating cycle begins, which should work like a clock, without errors and delays. In January, planning for system change begins, and the operational cycle continues in the meantime.
I am not an expert in the processes, so everything that was told is based on personal experience. However, the experience is very positive - the number of defects with which the system entered UAT was equal to 0, and, for the first time in 3 years, UAT started during and passed with the sign-off.
')
Step one - where are the problems?
The first step in developing the process is to establish what is bad now and how to avoid it.
With this question, I pestered everyone - programmers, testers, analysts, managers
The conclusion of this stage was the fact that you need an exact distribution of responsibility. For example:
- When a programmer injects code, he is responsible for his unit testing, and for the fact that the implementation will not spoil anything
- When the tester says that everything works - the responsibility for this decision is already on it
- When an analyst confirms that the system is suitable for UAT - he is responsible for the functionality
Etc.
Step Two - Identify Processes
Then I defined the processes that I will describe. Since the system is already developed, we needed a process for “change” (change request) and a bug (defect).
Each process has initial conditions (precondition), steps (steps) and final condition (post-condition). A process step can be either a simple step, or a fork, or another process. Each process and step will have its inputs and outputs.
In the “Change” process, the initial condition was “change and business specification approved by the client”. This is a guarantee that the change is necessary, and the specification meets the requirement of the client. That the client will not then say that we did not do what he asked for, as it often happened before. Below is a complete diagram of the “Change” process and a description of its main sub-processes.
The first step in "change" is the specification. She is trained by the programmer who is responsible for the change, and she must guarantee him that his understanding of the requirement is correct. When the analyst confirms the specification, it is the green light to begin direct development. If the analyst thinks the specification is incomplete or incorrect, it is sent to the programmer for editing. As a result, the programmer’s motivation and confidence that he will satisfy the user requirements increases. Previously, it often happened that the requirements are “understandable and so,” and the programmer, without even noticing it, makes assumptions that do not meet the expectations of the analyst and the client. And now we know what and how we will do.
The next step is programming, which ends with a unit test. All objects are stored in SVN, when adding comments are required, the places where the code changes are commented on at least the version number, etc. Also, a recommendation was introduced on the use of SVN - when a new branch is created, when it merges with the main one, and so on.
After it - introduction. As an artifact, Release Notes comes out of it, which will contain the entire list of changed objects, testing tips, and so on. Before direct introduction into the living system, the programmer must obtain formal permission from the analyst so that the change does not violate the “operational cycle”. The analyst must make sure that the code is correct - sometimes just standing behind the programmer, demonstrating functionality, or viewing the data output. Once the implementation is allowed, the responsibility for the impact on the system on the analytics.
I will not detail the testing and defect processes - probably everyone has them, and it is always very similar. In my case, emphasis was placed on the division of responsibility, permission to implement.
Step three - process implementation
This is the most difficult. Here it is necessary to convince one and all that these processes are a silver bullet. Because if at least one will not follow them - all for nothing!
I did a presentation. First to the top management. There is no problem. Then - to analysts who constantly ask tricky questions and have to rule again and again. Then programmers, with whom it is even worse, have to prove that the specification is needed, and it is quite short, and there is more sense from release notes than costs.
Once everyone is convinced, it is urgent to proceed to action. I prepared document templates, created libraries in sharepoint, so that everyone could immediately understand which square in the diagram is in which menu of the site.
Earned!
Step Four - Improvements
As the process is used, new ideas emerge, how to optimize it, where to add it. The process document is a living document and it is necessary to inspire colleagues to make changes - it is important that the process suits everyone and is suitable for their purpose!
findings
A little bureaucracy made the necessary changes over the 9 months. Each team member feels relatively safe because there are more verification and confirmation points. On the other hand, everyone feels responsible for his work, because he knows that its quality will be checked, verified soon, and therefore he tries harder. In addition, work in an organized team, where everyone knows what he should and what does not increase motivation.
I hope someone will benefit from my experience, and I will be happy to answer your questions!
Source: https://habr.com/ru/post/99189/
All Articles