Workflow automation for a small development team (Part 2)
In the previous publication I described the list of products and their settings that are necessary for the work of our organization.
In this article I will try to describe how we use all this in the daily work of the entire development team.
For 4 years we have developed the following format for the development team:
As a result, the team is about 10-11 people. We have several such teams (cells).
')
The work is mainly in the style of a startup, when there is no specific and detailed statement. Very often, experiments like “let's try this, see what happens” or “you did a great job, but now you have to do it completely differently”.
Over the years, the concept of our work can be described in one phrase - this is a “rapid change of concept”.
It is clear that in such conditions it was impossible to apply various methodologies.
I started as a programmer in this system, then Team lead, well, now PM (DM). Those. I lead, fully participate in the design and sometimes even write. At the time of my programming, I had a wonderful PM (coming from testers) that supported all my ideas on workflow automation. Even more, conceptually this process was invented by her, and I was already able to technically implement it and improve it in some places.
As we previously worked using only Jira and SVN:
After a difficult path of trial and error, after 3 years we came to the next process.
All tasks appear with us either after the meeting with the top management, or wishes from the customer, or we invent something ourselves (or find bugs).
In cases where the task is not monosyllabic, a mini-meeting of the PM, team leader, QA-lead and analyst is assembled. After discussing and inventing what we will develop and how, we usually immediately split it up into logically completed small tasks (no longer than the work of the 1st day of the programmer) and roughly estimate the deadlines for implementation (for plans for top management).
The analyst sits down and thoughtfully presents the statement in Confluence. After that, this statement is coordinated with the PM, and the latter, if necessary, with senior management.
Then, based on this setting, a task is created in Jira.
Often, tasks immediately appear in Jira bypassing the stage with Confluence.
Any task that appears in Jira immediately goes to the “Task Setting” step. At this stage, fill in such data as:
At the stage of setting, the task is with its author and no one else looks at it and does not know about it.
As soon as the author finalizes the formulation of the problem, he pushes it to the next (only possible) step in the workflow - the revision of the formulation.
In the transition to this step, the Jira triggers automatically change the responsible task to the PM.
This step is intended for the PM to re-read the description of the task and make sure that the author understood the formulation correctly and correctly described the task for the programmer. Very often, due to a lack of mutual understanding, the task is being done and is being tested until the very end, and only during the release it is clear that they did not do what was originally required.
Also at this step, the PM decides whether it is necessary to implement this task at all. Or whether it is necessary to implement it in this version.
At this stage, there are two options for workflow: return back to the formulation (refinement of the description) or move it further into the work.
I also often at this step assign a responsible team leader so that he himself identifies the performer.
When choosing this step, I set up a screen in which you need to specify the performer, the “Programmer” field and the planned time.
This step is a programmer's task pool, which must be performed for the version in the order specified in the priority field or in any convenient order, if the priority is the same.
So it turns out that while working on the version, this list is often updated.
Clicking on the “To Work” button, the task goes to the “In Work” state and, thanks to the “Automated Log Work for JIRA” plug-in, the time counter automatically starts and stops and saves the incoming value when the task is transferred to other statuses. In this step, the programmer can:
In order for the FishEye + Crucible + Bitbucket + Jira bundle to work, the programmer must specify the task number (PRJ-343) in the comments when they are working.
We have an agreement in our team that minor edits such as moving the button to the right or coloring the greener green can be immediately thrown onto the assembly. Otherwise - REQUIRED for code revision.
So, we throw the task at the revision of the code, and at the same time we assign the task leader to the task team.
At this step, the team leader in a special section Development in Jira looks at which particular committee was made by the programmer and presses the special button “Code Review”.
After clicking, Crucible automatically opens and creates a review of the specified commit (or several commit).
Timlid can see the file tree which rules the programmer and, accordingly, the diffferents. Can leave a comment on any line of code or general to the revision. Crucible even allows you to specify the degree of criticality of the programmer's passage.
After the agony of studying someone else's guanocode, the timlid either pushes the task to the assembly step or returns to the programmer in anticipation of work.
The programmer in this case in the Development section sees the Code Review and its status. When switching to this Code Review, Crucible opens again, where the programmer can clearly see exactly where he has been working.
When translating to the “Waiting for assembly” step, the team leader selects the tester responsible, which is indicated in the special field, or if it is not filled in, then the QA-lead.
Since we have one common testing server, the build is not suitable as scheduled. You can not substitute the site during its testing.
Therefore, we usually have testers agree, and if no one is against it, they collect a fresh version of the resource for themselves.
They do it with Jenkins. It created three assemblies for each project: an assembly for tests, an assembly for development, an assembly of a database.
The following algorithm is configured in the source build:
The database builds are all the same, only instead of step 3, the following is performed using ssh commands on the server:
3.1. To chop off all connections to a DB.
3.2. Delete DB.
3.3. Restore the database of the previous version.
3.4. Scroll on it all the scripts of the new version.
We collect the database extremely rarely, only when the tester sees scripts in the modified sql files.
At this step there may be tasks that were already in the test, and may be for the first time. If the task was already in the test, then the team already in charge puts the tester who brought the task back to work.
Otherwise, all tasks accumulate in the QA-lead. He looks at the task pool and load of each tester, and determines who assigns the task to the test. Moreover, it immediately determines the tester for paired testing.
From this step, the task can be transferred to almost any workflow step. The tester can:
As with the “In Work” step, at this step, a time counter is automatically started, which logs the time spent on the work.
This step was thought up for several reasons. Many did not understand its expediency, but in the end, after some time, they agreed that it was necessary.
Its essence lies in the fact that there is a main tester on the task, who very deeply and vigorously picks up the task from various aspects and there is a paired tester who superficially examines the task only after the first completed tests. This is very similar to the code revision of programmers.
As a result, we get the fact that not only one tester knows how this or that functionality is arranged. If the task is football 10 times between the programmer and the tester, then a fresh look of the pair tester may notice something missing. And the most important thing is that each tester works in his own way and gets used to using software in a certain way (logs in without using a mouse, upload files with drag-n-drop, use sorting instead of filters, copy texts and paste texts, etc.). It often happens that the same functions can be used in different ways, and the pair tester stumbles upon errors that have been verified by the main one, but a little differently.
If at this step you can usually already assume that the task is almost complete. And very often, when they hurry with the release of a version, it can be formally passed.
After successful testing, the functionality and its implementation have been finally determined. And now tehpis is engaged in this task. Usually, all tasks, except for very minor ones or those that were broken during the work on the version, we mark with “ReadMe”.
The pair tester, if he sees this tag, sends the task to the “ReadMe” step and assigns it to the test list.
Tehpis in a special field describes very briefly the Release notes for this task. Usually this is a user notification of a change in functionality or the correction of an error, or the appearance of new functionality and how to use it.
At the same step, the tech fix corrects or supplements the resource help in Confluence.
After the work done, the task is sent to the final step “Revision functionality”.
When a task goes to this step, the Jira triggers are automatically assigned a responsible PM.
At this step, the PM checks the work of the whole team. Whether what they wanted was realized, exactly as they wanted, whether the description in ReadMe, etc. is normal.
It happens that at this step it turned out that the programmer with the tester decided to do something among themselves and cut off the “unnecessary functionality” or changed it because they thought it was better, and it was this functionality that was required by the top management in that form. Then the task again goes to “Waiting for work”.
The value of this step lies in the fact that a good PM or DM after the release and the customer’s call with the phrase “what have you done?”, Should know exactly how the task was accomplished, as the buttons were called, the message texts, the nuances of the algorithms, and boldly answer the fool himself. But not to be confused and guess, but how did they make that form and what is the button in it zadizeyblen ...
Well, everything is clear here. The task is closed after successfully passed functionality revision.
Or the task at any moment may be unnecessary to anyone, because the transition to this step is possible from any other step.
For convenience, Jira has developed desktops for each project with four gadgets:
With the help of GreenHopper, I set up such a board:
Very handy for reviewing the entire process.
With the release of the version, we unload all the tasks of the version in the form of two columns from Jira: the component and the ReadMe field. So it turns out that ReadMe is grouped by sections.
With the help of “Scroll HTML Exporter” we export the help page to Confluence and all its child pages into a set of html files, which inside look as beautiful as in Confluence and link to each other.
This is the workflow we have been working for several years, sometimes modifying and testing it.
But in general, it is very convenient.
For PM, by the fact that at any moment in time it is clear who exactly and at what step holds the task.
For developers, it's convenient to see only your scope of work.
And, of course, automation at all steps. Those. there is no such person without whom the workflow can stop.
In this article I will try to describe how we use all this in the daily work of the entire development team.
For 4 years we have developed the following format for the development team:
- 1 Project Manager, aka Product Manager, aka Delivery Manager.
- 4-5 programmers
- 1 Team lead
- 3-4 QA
- 1 Analyst
- 1 Techpis (sometimes he is also an analyst in one person).
As a result, the team is about 10-11 people. We have several such teams (cells).
')
The work is mainly in the style of a startup, when there is no specific and detailed statement. Very often, experiments like “let's try this, see what happens” or “you did a great job, but now you have to do it completely differently”.
Over the years, the concept of our work can be described in one phrase - this is a “rapid change of concept”.
It is clear that in such conditions it was impossible to apply various methodologies.
I started as a programmer in this system, then Team lead, well, now PM (DM). Those. I lead, fully participate in the design and sometimes even write. At the time of my programming, I had a wonderful PM (coming from testers) that supported all my ideas on workflow automation. Even more, conceptually this process was invented by her, and I was already able to technically implement it and improve it in some places.
Let's get to the point.
As we previously worked using only Jira and SVN:
- In words, they received a task from the customer or high management.
- PM created a specific task in JIRA.
- The programmer executed, uploaded to SVN and pushed it into JIRA for a test.
- The tester asked the lead to build the build.
- I downloaded the new build and let's test the tasks.
- Bad again on point 3, good - in the "Closed".
- At the end of the version, the techpist described everything that came out.
- Lead gathered everything in a pile and prepared the installer.
- PM packaged and handed over to the customer.
After a difficult path of trial and error, after 3 years we came to the next process.
Formulation of the problem
All tasks appear with us either after the meeting with the top management, or wishes from the customer, or we invent something ourselves (or find bugs).
In cases where the task is not monosyllabic, a mini-meeting of the PM, team leader, QA-lead and analyst is assembled. After discussing and inventing what we will develop and how, we usually immediately split it up into logically completed small tasks (no longer than the work of the 1st day of the programmer) and roughly estimate the deadlines for implementation (for plans for top management).
The analyst sits down and thoughtfully presents the statement in Confluence. After that, this statement is coordinated with the PM, and the latter, if necessary, with senior management.
Then, based on this setting, a task is created in Jira.
Often, tasks immediately appear in Jira bypassing the stage with Confluence.
Any task that appears in Jira immediately goes to the “Task Setting” step. At this stage, fill in such data as:
- type of task (new functionality, change of functionality, error, technical work, documentation)
- version (usually current in development)
- components (for example: admin, interface, main, finance, reporting ...)
- task description
At the stage of setting, the task is with its author and no one else looks at it and does not know about it.
As soon as the author finalizes the formulation of the problem, he pushes it to the next (only possible) step in the workflow - the revision of the formulation.
Production revision
In the transition to this step, the Jira triggers automatically change the responsible task to the PM.
This step is intended for the PM to re-read the description of the task and make sure that the author understood the formulation correctly and correctly described the task for the programmer. Very often, due to a lack of mutual understanding, the task is being done and is being tested until the very end, and only during the release it is clear that they did not do what was originally required.
Also at this step, the PM decides whether it is necessary to implement this task at all. Or whether it is necessary to implement it in this version.
At this stage, there are two options for workflow: return back to the formulation (refinement of the description) or move it further into the work.
I also often at this step assign a responsible team leader so that he himself identifies the performer.
Waiting for work
When choosing this step, I set up a screen in which you need to specify the performer, the “Programmer” field and the planned time.
This step is a programmer's task pool, which must be performed for the version in the order specified in the priority field or in any convenient order, if the priority is the same.
So it turns out that while working on the version, this list is often updated.
In work
Clicking on the “To Work” button, the task goes to the “In Work” state and, thanks to the “Automated Log Work for JIRA” plug-in, the time counter automatically starts and stops and saves the incoming value when the task is transferred to other statuses. In this step, the programmer can:
- Suspend work (waiting for work);
- On code revision;
- On the revision of the production (I did not understand what is required to do or there are technical obstacles to the implementation in just such a production);
- For testing (could not reproduce).
In order for the FishEye + Crucible + Bitbucket + Jira bundle to work, the programmer must specify the task number (PRJ-343) in the comments when they are working.
We have an agreement in our team that minor edits such as moving the button to the right or coloring the greener green can be immediately thrown onto the assembly. Otherwise - REQUIRED for code revision.
So, we throw the task at the revision of the code, and at the same time we assign the task leader to the task team.
Code Revision
At this step, the team leader in a special section Development in Jira looks at which particular committee was made by the programmer and presses the special button “Code Review”.
After clicking, Crucible automatically opens and creates a review of the specified commit (or several commit).
Timlid can see the file tree which rules the programmer and, accordingly, the diffferents. Can leave a comment on any line of code or general to the revision. Crucible even allows you to specify the degree of criticality of the programmer's passage.
After the agony of studying someone else's guanocode, the timlid either pushes the task to the assembly step or returns to the programmer in anticipation of work.
The programmer in this case in the Development section sees the Code Review and its status. When switching to this Code Review, Crucible opens again, where the programmer can clearly see exactly where he has been working.
When translating to the “Waiting for assembly” step, the team leader selects the tester responsible, which is indicated in the special field, or if it is not filled in, then the QA-lead.
Waiting for build
Since we have one common testing server, the build is not suitable as scheduled. You can not substitute the site during its testing.
Therefore, we usually have testers agree, and if no one is against it, they collect a fresh version of the resource for themselves.
They do it with Jenkins. It created three assemblies for each project: an assembly for tests, an assembly for development, an assembly of a database.
The following algorithm is configured in the source build:
- Pull fresh source from git.
- Copy them to FTP.
- Find all the tasks in Jira in the “Waiting for assembly” step and transfer them to the waiting for testing.
- Send letters.
The database builds are all the same, only instead of step 3, the following is performed using ssh commands on the server:
3.1. To chop off all connections to a DB.
3.2. Delete DB.
3.3. Restore the database of the previous version.
3.4. Scroll on it all the scripts of the new version.
We collect the database extremely rarely, only when the tester sees scripts in the modified sql files.
Waiting for testing
At this step there may be tasks that were already in the test, and may be for the first time. If the task was already in the test, then the team already in charge puts the tester who brought the task back to work.
Otherwise, all tasks accumulate in the QA-lead. He looks at the task pool and load of each tester, and determines who assigns the task to the test. Moreover, it immediately determines the tester for paired testing.
Testing
From this step, the task can be transferred to almost any workflow step. The tester can:
- return the task to the statement (so that the PM determines whether it is necessary right now or even to correct it at all, what was found during testing);
- return the pending programmer to work;
- send the description to ReadMe (and assign it to the list);
- push through to pair testing (and assign it to the appropriate tester)
- transfer to the revision of the functionality (the PM will be assigned automatically).
As with the “In Work” step, at this step, a time counter is automatically started, which logs the time spent on the work.
Waiting for pair testing
This step was thought up for several reasons. Many did not understand its expediency, but in the end, after some time, they agreed that it was necessary.
Its essence lies in the fact that there is a main tester on the task, who very deeply and vigorously picks up the task from various aspects and there is a paired tester who superficially examines the task only after the first completed tests. This is very similar to the code revision of programmers.
As a result, we get the fact that not only one tester knows how this or that functionality is arranged. If the task is football 10 times between the programmer and the tester, then a fresh look of the pair tester may notice something missing. And the most important thing is that each tester works in his own way and gets used to using software in a certain way (logs in without using a mouse, upload files with drag-n-drop, use sorting instead of filters, copy texts and paste texts, etc.). It often happens that the same functions can be used in different ways, and the pair tester stumbles upon errors that have been verified by the main one, but a little differently.
Pair testing
If at this step you can usually already assume that the task is almost complete. And very often, when they hurry with the release of a version, it can be formally passed.
Readme
After successful testing, the functionality and its implementation have been finally determined. And now tehpis is engaged in this task. Usually, all tasks, except for very minor ones or those that were broken during the work on the version, we mark with “ReadMe”.
The pair tester, if he sees this tag, sends the task to the “ReadMe” step and assigns it to the test list.
Tehpis in a special field describes very briefly the Release notes for this task. Usually this is a user notification of a change in functionality or the correction of an error, or the appearance of new functionality and how to use it.
At the same step, the tech fix corrects or supplements the resource help in Confluence.
After the work done, the task is sent to the final step “Revision functionality”.
Audit functionality
When a task goes to this step, the Jira triggers are automatically assigned a responsible PM.
At this step, the PM checks the work of the whole team. Whether what they wanted was realized, exactly as they wanted, whether the description in ReadMe, etc. is normal.
It happens that at this step it turned out that the programmer with the tester decided to do something among themselves and cut off the “unnecessary functionality” or changed it because they thought it was better, and it was this functionality that was required by the top management in that form. Then the task again goes to “Waiting for work”.
The value of this step lies in the fact that a good PM or DM after the release and the customer’s call with the phrase “what have you done?”, Should know exactly how the task was accomplished, as the buttons were called, the message texts, the nuances of the algorithms, and boldly answer the fool himself. But not to be confused and guess, but how did they make that form and what is the button in it zadizeyblen ...
Closed
Well, everything is clear here. The task is closed after successfully passed functionality revision.
Or the task at any moment may be unnecessary to anyone, because the transition to this step is possible from any other step.
Desktop
For convenience, Jira has developed desktops for each project with four gadgets:
- My tasks at all steps. This is a list of all workflow steps and with the number of tasks opposite each where I am marked by a programmer or tester. Those. Looking at this gadget, I can immediately see how many of my tasks are currently in testing, development or production. I can understand the approximate amount of my tasks.
- I am responsible. List of tasks that are waiting for my decision. Until I process them, no one else will see them.
- How many tasks on each. List of the entire development team with the number of tasks on each. Used by leads to guide who is more loaded.
- Statistics on the two-dimensional filter. You can see in detail at whom and at what steps how many tasks right now.
With the help of GreenHopper, I set up such a board:
Very handy for reviewing the entire process.
Release Version
With the release of the version, we unload all the tasks of the version in the form of two columns from Jira: the component and the ReadMe field. So it turns out that ReadMe is grouped by sections.
With the help of “Scroll HTML Exporter” we export the help page to Confluence and all its child pages into a set of html files, which inside look as beautiful as in Confluence and link to each other.
Results
This is the workflow we have been working for several years, sometimes modifying and testing it.
But in general, it is very convenient.
For PM, by the fact that at any moment in time it is clear who exactly and at what step holds the task.
For developers, it's convenient to see only your scope of work.
And, of course, automation at all steps. Those. there is no such person without whom the workflow can stop.
Source: https://habr.com/ru/post/270321/
All Articles