Technical tasks reflect the programmer’s view of the work related to the implementation of a particular requirement or a particular group of requirements. They are elements of an action plan and are expressed in technical terms, or at least in the vocabulary of a programmer.
EXAMPLES OF technical tasks:
Develop a class that does… or is responsible for…
Write a function that…
Improve the search algorithm…
Technical tasks are easier to assess, and the resulting assessment is more accurate. It is also possible to form a work flow from them, and it is easier to take into account and resolve the dependencies between them.
However, they are more difficult to verify. Often the result of a technical task is not visible to the end user. In order for it to be noticeable, it may be necessary to perform a series of technical tasks.
Simultaneous use of technical and user tasks is justified when the team consists of more than 6 people. In this case, the time and time spent are estimated by technical tasks, and the result is estimated by user tasks. However, this approach requires a dedicated full-time manager, whose responsibilities include the distribution of both technical and user tasks among team members and the establishment of correspondence between user and technical tasks.
In our case, the team is not that big. Therefore, we use only custom tasks, because they can easily be checked by a QA engineer. We discuss all the technical details and approaches to implementation in words. Similarly, we sort out dependencies between different user tasks, if there are any.
When entering a task into JIRA, we mark it with labels. Tags allow you to configure various filters, as well as collect and analyze statistics.
As labels, we use:
The ID of the milestone
It makes it easy to find all the tasks related to a particular milestone.
This is either a feature task (in English – feature), or a criterion.
ID of the component or part of the program to which the task belongs
Filtering by this criterion subsequently makes it easy to assess the complexity of a particular part of the program.
Before sending the written code to the shared repository, you need to go through the review procedure. At first, the code review is done by more experienced developers. But newcomers should also be involved in reviewing other people’s changes as early as possible. This will allow them to familiarize themselves with the application code and better understand the style adopted in the team.
The most common errors that are found during the code review procedure are the following:
Errors due to carelessness
The most striking example is the initialization of a compound variable. In sloppily written code, the initialization of such a variable (or parts of such a variable) may be scattered throughout the file. The initialization code should still be grouped correctly. Mistakes due to carelessness are acceptable for beginners. But they must be eradicated quickly. It is desirable that a beginner, after a couple of reviews, does not make such mistakes anymore.
Mistakes due to inattention
The most common mistake is forgetting to add the newly created file to the change list. Such mistakes are acceptable, but should be extremely rare.
Errors in names
A whole gamut of errors is possible here: the name of a class or function does not reflect its (or her) essence, a too long name, an incomprehensible name, and others. At first, such errors will occur frequently. But with experience, there should be fewer and fewer of them.
Errors in the distribution of functions by modules and classes
The most characteristic manifestation of such an error is when a small change affects many files at once. Beginners learn not to make such mistakes for a long time. This requires painstaking and patient work on the part of experienced developers and a leading programmer.
Application testing takes place in parallel with development. To do this, the department has a QA engineer who is only engaged in testing the tools being developed.
Every morning, the QA engineer takes the updated source code from the version control system and builds it himself. This is part of his duties. Thus, the QA engineer always works with the updated version and does not ask the programmer to build another build for him. The programmer is involved only if some error occurred during the build or during startup.
As the tasks are completed, the QA engineer looks at how they are completed. If he finds a bug, he immediately starts it in the bug control system. Our rule is to carry out all found bugs through the bug tracker. Even if a programmer discovers a bug, he does not rush to fix it immediately, but asks the QA engineer to repeat it and, if it reproduces, then start it in the bug control system. Why is this important?
Firstly, because an independent party appears in the person of a QA engineer who will be able to check that the bug has been fixed.
Secondly, because the bug registered in the bug tracker gets into the statistics, which can then be analyzed for the most common errors or the most “bad” subsystems.
When registering a bug in the bug control system, it is recommended to use tags. The most important of them are:
The ID of the milestone
ID of the subsystem of the program in which the bug manifests itself
Such tags allow you to analyze bug statistics properly.