Skip to content
Info Soft Office

Software Development Project Management

Info Soft Office

Software Development Project Management

February 25, 2022December 28, 2022

Technical tasks in software project

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.

Tags

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.

Task type

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.

Code review

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.

Bug fixes

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.

Soft best software development company in usabest software development coursescontract for software developmentcosts of software developmentelearning development softwarejava software development servicesplanning in software developmentsoftware developmentsoftware development bookssoftware development companies londonsoftware development courses listsoftware development engineeringsoftware development industrysoftware development kpisoftware development managmentsoftware development with servicessystem development softwaretools software developmentwebsite software developmentwhat is software development process

Post navigation

Previous post
Next post

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Schedule milestones of software development
  • Communication and documentation when creating software
  • Support stage in software development
  • Software development project management
  • Unity software development

Recent Comments

No comments to show.

Archives

  • December 2022
  • October 2022
  • August 2022
  • July 2022
  • May 2022
  • March 2022
  • February 2022
  • November 2021
  • September 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021

Categories

  • Soft

Software Development Project Management Services

  • Github
  • Monday
  • SumatoSoft
  • ClickUp
  • Wrike
©2023 Info Soft Office | WordPress Theme by SuperbThemes