Paul CC Photos
Being engaged in the development of IaaS-provider, we in
1cloud know firsthand how important it is to competently organize the workflow of the whole team. Recently, we published
material in which we discussed 13 things that developers and testers should not say, and in another post they
touched upon the corporate culture of organizations.
')
Today we would like to go back into the organization of the company's processes and talk about how to optimize the development of services.
Jeff Morris, project management at LucasArts, once
said that in the development of applications, the main criterion for success is daily work. Successful athletes did not immediately begin to win gold medals at the Olympics, they regularly practiced and ate properly under the guidance of their coach.
In the case of the development of services - all the same. You, as a manager, must become the coach who will lead your team to success. It is necessary to properly organize the processes of developing services to improve the outcome of any project. It will also save the development team from burnout, reduce staff turnover and strengthen team spirit.
Here are some tips for managers on how to organize the development of applications and services.

Only sprint, only hardcore
Development should be carried out gradually and iteratively, therefore it is necessary to draw up a strict schedule. The figure below shows an example of such a schedule for a two-week sprint.

A scheduled work day is essentially a standard day when everyone is working on their current tasks.
You, as a manager, should intelligently distribute the workload among employees to keep the team in good shape. Crush large tasks into smaller ones so that programmers do not suffer under their “weight”. As the marketer Cheryl Andrus
says , "even a small success can quickly cheer the team." Every time a developer completes another small task, he is energized and he has a second wind.
Distributing tasks, consider the individual characteristics of each team member. Not all people work at the same speed, each with its own strengths and weaknesses. Also, at the end of the second week, it is worthwhile to reserve a couple of days to complete the remaining tasks and resolve unexpected difficulties.
In addition, it is necessary to allocate one day to conduct the scheduling, when it is necessary to evaluate the progress made by your wards for each task, and to schedule the stages of work for the next sprint.

We run more intensely
In order for all the tasks scheduled for the sprint to be completed on time, you need to regularly check how the work moves. In the Scrum methodology, it is recommended to spend 15 minutes every morning talking to the development team. During this time, each team member tells briefly what tasks he performed yesterday and how much time he needed to finish the remaining ones. You, as a coach, should listen to your team and give valuable attitudes.
If you are afraid that such meetings will drag on, try to hold mitaps while standing. It is proved that it will take them three times less time. Moreover, the sooner the meeting ends, the more power will be left to the development team.
A good technique would be to write tasks on multi-colored cards and hang them on the board. Each color is assigned its own status, for example:
- Blocked - the task cannot be started (there were technical problems or the task associated with it was not completed).
- Not started - you can proceed to the task.
- In the work - on the task is working.
- Check - the developer completed the task and handed it over to the older one for review.
- Completed - the problem is solved.
This will allow team members to see in which direction they are moving, and independently assess the load.

We prioritize
Setting priorities is a guarantee that the project will not “fall” at the end of the race. An interesting classification of the tasks
proposed by the Drupal project:
- Critical task: It is necessary to complete as soon as possible, because perhaps it prevents someone from continuing to work. The postponement of such tasks can lead to a sharp decline in productivity, greatly impair the user experience and the quality of documentation.
- Important task: While it is not completed, it is undesirable to launch a new version of the product. One typical example of an important task is code refactoring. Refactoring can improve not only the readability of the code, but also its performance, which will have a positive effect on the attitude of customers - we mentioned this in one of our previous posts .
- Medium-sized task: A release can be carried out without its completion, but the quality of the program may suffer. An example of such a task is testing a small piece of working code.
- Not an important task: It is performed “for beauty”, as it does not affect the functionality of the application. For example, the correction of typos in the comments to the code.
There are many ways to prioritize tasks. Above is just one of them. More information can be found on the links (
here ,
here and
here ).

We support breathing
Prioritization is also important in identifying program errors. It is difficult to track and “clean up” absolutely all the bugs, and for this reason it is reasonable to focus your attention on the most “deadly” ones.
- Critical bugs regularly destroy the system and undermine the work of the whole team - they need to be tackled immediately.
- In second place are serious bugs that prevent team members from continuing to work, reduce productivity, or do not adequately assess a particular service function.
- On the third - less serious bugs, indicating obvious problems or inaccuracies in the program, but not affecting the workflow.
- Not serious bugs are unlikely to be noticed by the user, but if you found them you can fix if you wish. Bringing beauty is always nice.
To track bugs, you can create your own database in which all information about errors found will be stored. Arrange the columns in decreasing order of importance and take care of creating filters. So it will be easier to navigate.
As for specially developed bug trackers, here are a couple of recommendations. There is a bug tracker
Jira , often used by large teams. For teams of several people,
Pivotal Tracker ,
Trello and
Github tracker are suitable.
Bugzilla from the Mozilla Foundation,
Mantis BT ,
Redmine and minimalist
Trac are distributed free of
charge .
Those who like to write with a marker can mark all the bugs on the white board or stick stickers of the type of cards from the second paragraph.
Often, managers are allegedly trying not to overload the team with information and don’t “put into work” all found bugs right away. It would be more sensible, however, to report them as soon as possible. So, each developer will clearly understand how many mistakes he has to correct, and will be able to plan his work day more precisely. So, not sharing this data with a team means at least disrespecting its members.

Focus on technology
Configure your team to create quality software. However, to check this quality, it is necessary to regularly test the service. A few tips on this topic were
given by Quora discussion participants.
Additionally, it is worth noting that sometimes you need to conduct testing with the participation of the entire development team. At least once a week, everyone should “play around” with his application, feel it. However, it is
not worthwhile to completely give testing to developers.
Thus, in order for you, as a manager, to lead your team to victory, you need to intelligently distribute the workload among team members, be able to set priorities (including when fixing bugs) and ensure the transparency of the tasks performed, so that each developer understands what the project is at .
PS We have prepared links to practical manuals in case you have time for the weekend to get acquainted with our IaaS-provider
1cloud and test its capabilities: