Process Implementation - Step-by-Step

    I want to share my experience in developing and introducing IT processes in a project. Why do we need processes? They meet many different goals, but in our case, the main goal was to differentiate responsibilities.

    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, motivation decreases, the image deteriorates, and in general - those who work the most get the most kicks. And recognition is received by managers, sales, and others ...

    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 performs calculations according to all estimates of all students in the country. Every year in September, the operating cycle begins, which should work like clockwork, without errors and delays. Since January, planning begins to change the system, and the operating cycle, meanwhile, continues.

    I am not an expert in the processes, so all of the following is based on personal experience. However, the experience is very positive - the number of defects with which the system entered the UAT was 0, and, for the first time in 3 years, the UAT started at the time and passed with sign-off.

    Step one - where are the problems?

    The first step in developing a process is to establish what is wrong now and how to avoid it.
    With this question, I pestered everyone - programmers, testers, analysts, managers and passers-by on the streets . It turned out that bad - that's all. Non-tested code comes into 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 databases are constantly overflowing, and much more.

    The conclusion of this stage was the fact that an accurate distribution of responsibility is needed. For example:
    - When the programmer implements the code, he is responsible for its unit testing, and for the fact that the implementation will not ruin anything
    - When the tester says that everything works - the responsibility for this decision is already on him
    - When the analyst confirms that the system is suitable for UAT - it is responsible for the functionality
    , etc.

    Step Two - Identify Processes

    Next, I identified the processes that I will describe. Since the system has already been developed, we needed a process for a “change” (change request) and a bug (defect).

    Each process has initial conditions (precondition), steps (steps) and final condition (post-condition). Process steps can be either a simple step, or branching, or another process. Each process and step will have its own inputs and outputs.

    In the “Change” process, the initial condition was “change and the business specification approved by the client”. This is a guarantee that a change is needed and the specification is in accordance with the requirements of the client. That the client then will not say that we did not at all what he requested, as has often happened before. Below is a complete diagram of the “Change” process and a description of its main sub-processes.

    image

    The first step in “changing” is the specification. It is prepared by the programmer responsible for the change, and it must guarantee him that his understanding of the requirement is correct. When the analyst confirms the specification, it is a green light to begin direct development. If, according to the analyst, 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 user requirements increases. It used to happen often that the requirements are “understandable,” and the programmer, without noticing it, makes assumptions that do not meet the expectations of the analyst and client. And now we know what and how we will do it.

    The next step is programming, which ends with a unit test. All objects are stored in SVN, comments are required when adding, places of code change are commented at least by version number, etc. A recommendation was also introduced on the use of SVN - when a new branch is created, when it merges with the main branch, and so on.

    After him - the 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 being directly introduced into a living system, the programmer must obtain formal permission from the analyst so that the change does not violate the “operating cycle”. The analyst must make sure that the code is correct - sometimes just standing behind the back of a programmer demonstrating functionality, or looking at the data output. Once implementation is allowed, responsibility for influencing the system on analytics.

    I will not detail the testing and defect processes - probably, everyone has them, and it is always very similar. In my case, the emphasis was on the division of responsibilities, permission to implement.

    Step Three - Process Implementation

    This is the hardest part. Here it is necessary to convince everyone and everyone that these processes are a silver bullet. Because if at least one does not follow them - all in vain!
    I made presentations. First to the top authorities. There are no problems. Then - to analysts who constantly ask tricky questions and have to edit, again and again. Then the programmers, with whom it is even worse, have to prove that the specification is needed, and it is very short, and there is more sense in release notes than there are costs.
    After everyone is convinced, it is urgent to move on to action. I prepared document templates, created libraries in sharepoint, so that everyone could immediately understand which square is on the diagram in which menu of the site.
    Earned!

    Step Four - Improvements

    As you use the process, new ideas appear on 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!

    Conclusions

    A little bureaucracy has made the necessary changes over these 9 months. Each team member feels relatively safe because more verification and confirmation points have appeared. On the other hand, everyone feels responsible for his work, because he knows that its quality will be checked, checked soon, and therefore tries harder. In addition, working in an organized team, where everyone knows what he needs and what does not, increases motivation.

    I hope someone will benefit from my experience, and I will be happy to answer your questions!

    Also popular now: