On thorns and stars on the path to optimizing development processes

From the sandbox

Dreams Dreams

On cold autumn evenings, we and the developers of 3D visualization gathered in the kitchen ... drank coffee ... and thought about it ... about the development reference organization.

- I have friends on agile working: sprints, story points, all things ...
- Yes, we would have at least a review ...

The fact is that in those days, we were not very smooth about this. For example, storing projects in git was very unusual:

there were several repositories and some piece of the project was stored in each;
some repositories were shared, some related only to some projects, some only to one;
to get a working copy, you had to download the contents of all repositories and put them in certain folders.

Since we work with 3D graphics and then used the concept of “controls + templates (layout of elements on the screen, transition logic)”, then, to be more specific, things were as follows:

when working on controls, commits went to the repository with basic controls and, possibly, to the repository with resources (if the already used three-dimensional models would need to be used elsewhere);
when working with both controls and templates (for example, if you had to replace the background in the application with the background under the help panel), you had to upload pictures to the repository with resources, and edit the layout in the repository with templates. If the background was made a skin (single style), then 3 repositories could be involved.

With this approach, reviewing the code was a cost-effective luxury:

development was carried out in a single branch;
changes for one task affected several repositories and it was very problematic to track which commits belong to which task.

As a result, due to the inability to “learn from mistakes”, share experiences, and analyze each other’s code during the review, developers could not improve their skills quickly enough. And to develop applications “quickly” was necessary. And in order to maintain the development speed at an acceptable level, on each new project, people were engaged in tasks that were similar to their tasks in previous projects. Those. if someone had previously worked with a 3D map, he had again and again got tasks related to maps, or if someone once developed the “schedule” component, he was doomed to graphics. And this has its own logic, because the task is implemented more quickly by someone who has encountered similar or identical ones. The result was that the developers specialize in specific things and are not interchangeable.

As for development methodologies and a clear workflow, they also were not used for a number of reasons. Starting from the fact that for this it was necessary to allocate a significant amount of time to think through all the concepts and development processes, ending with the fact that there was simply no one to bring it. Neither I, as a recently arrived employee, nor the guys had the authority to reorganize. And it remained only to grumble and dream.

"Where there is a dream, there is always a chance"

Of course, for me, as a person who is not indifferent to my work, it was the goal of changing the situation. Otherwise, what is the point of my activity if I cannot in any way positively influence the existing processes and provide such working conditions for people in which they could open up their abilities and improve? The development of those who create the application, who embodies the idea, projected on paper, to life - is the development of projects and the company as a whole.

A good chance to implement this goal was appruv to develop a new visualization module of our platform. This project was not like the others, because It was not the development of an application on a platform, but the implementation of a part of the platform itself. Therefore, here we were not tied to the strange concept of storing and working with projects in a variety of git repositories, which seemed to me a wonderful opportunity to introduce a review code. By the way, what happened with us And one fine winter morning I attacked the project architect with a proposal to introduce Gitflow. At first he took my idea contradictory, but there were reasons for this: some standard model does not always fit. However, in the process of communication, the most suitable option for this project was invented, which we now successfully use.

Our modified Gitflow is the following scheme:

there is a main branch (we called it master, but you can give any name so as not to be confused);
there is a sprint in Jira, formed from backlog tasks, which are united by one micro goal;
the developer takes the task from the list of open sprints in progress and creates a feature branch from the master, specifying the task code (for example, PLAYER-55) in the name of its feature branch;
as soon as the work on the task is completed, the developer sends his work for review: through Gitlab, creates a merge request to master and transfers the task to Jira to Review with the link to the merge request specified in the comments;
if the review is completed and all discussions are closed, the task in Jira is closed, the feature branch is held in the master and deleted;
if there are comments after the review, in Jira the task is rediscovered from Review and passes the algorithm from the beginning, with the exception that the feature branch has already been created.

When all tasks are closed, we enter the release stage:

From the master, the release branch is denoted, which is called two digits, for example, release-3.0, where 3 is the version number of the project, and 0 is the number of the release branch (respectively, the next release branch will be called release-3.1, etc. );
further testing of the release candidate (usually the development of small demos);
if during testing no defects are detected, then the release candidate is ready for production: the last commit in the release branch is marked with a production tag consisting of 3 digits (for example, prod-3.0.0, where 3 is the version number of the project, 0 - release-branch number, 0 - production version number), then the release-branch is held in the master and is not deleted, unlike the classic Gitflow;
if the defects are still detected, they are registered in Jira as a Bug, and then the process of fixing the bug is similar to working with a task in the feature branch (it is only denied from release, not from master) and when all bugs are closed, we put down a production tag, the version is displayed in the prod and the release branch is retained in the master without being deleted.

In case the bugs are detected in the production, there is also an agreement:

work on such bugs is also conducted in the release-branch of this version of the sale, if the edits are critical, they are marked as hot fix and are carried out directly in the release-branch with team names;
otherwise, work on such bugs is similar to work on bugs found in the release candidate.

So why exactly Gitflow and such?

Entering a feature branch is a way to introduce a review, which allows you to share experiences, improve the overall skill level of the team, and, most importantly, as a result, avoid low-quality code that does not have a common style, is hard to read, and full of bugs.
I think many people are familiar with the situation when the project is evaluated according to the TOR and specifications, a budget has been allocated for it, you implement the functionality according to the requirements in the documentation, but then someone from the authorities will spawn and you hear: “Oh, and let's add a couple of unicorns here, the customer will like it ”,“ Can you make it possible to call a friend in this region by clicking on a region on the map? It will be a bomb, proceed ”,“ We need to add a legend ”,“ Now the legend needs to be removed, and the signatures too ”,“ Removing signatures was superfluous, return ”. And all this is “free without registration and SMS”. And then, when calculating the actual costs, it turns out that it took a lot of pain to develop with such a small number of tasks (after all, “requests” in Jira are usually not registered, because not every developer can refuse a boss or send him to register his “request”, and this can be understood). Entering the rule for naming individual branches with the Jira code and impossibility to hold branches in master without reference to Jira, excludes the presence of unregistered works and conflicts that may arise if the developer "starts downloading rights", demanding to issue a "request" as a task in Jira, and also allows you to have a clear idea of how much work was actually done (the tasks in Jira are confirmed by the code associated with them, the code written is connected to the registered task).
Connecting Gitflow with Jira in terms of updating task statuses helps to avoid a situation where several people do the same task. In the case of updating the statuses according to their Gitflow stage, everyone will see that such and such tasks are already in progress or on the review, respectively, they already have feature lines in which code is written, and there is no need to take them. You can also clearly see who does what and what work can affect each other, which of the guys should contact more often and agree on a particular implementation so that when the merger doesn’t have to resolve their code conflicts for a long time.
Since we are developing a platform for creating applications, it is worth considering that someone's finished products will depend on our policy of supporting old versions of the platform and the introduction of new ones. There are situations when someone from the users of the platform, for whatever reason, will use the latest version of the platform and find a bug related to the operation of the platform. If we delete the release branches, we will not be able to help our users in such a situation, especially if the functions that they use in their version are removed or modified in the new implementation of the platform. Accordingly, the preservation of release-branches allows you to provide support to users who do not work with the latest version of the platform.

What about Agile?

As you have probably already noticed, we began to slowly approach the agile scrum principles of development, starting with splitting tasks into sprints by micro-goals. Next were introduced Planning Poker, Story Points, team speed analysis, retrospective. Participation in Planning Poker and assigning Story Points to tasks allow the team to have a more holistic view of the project, its architecture, what we are striving for and what should be the result. People get the opportunity to think systematically, and not just within their tasks. This has a positive effect on their development as professionals, and on the project itself:

new useful features are offered, because it becomes clearer to developers what and where can be improved as a whole;
more often errors and flaws are found that could become clearly visible only at the time of operation of the platform.

Due to the availability of data on the number of completed tasks in the sprint and the corresponding Story Points, it is possible to analyze the speed of the development team in order to carry out more competent planning and assessment of the dates.

However, there is also some disappointment in our project in this regard: the composition of the team changes very often, because some developers are periodically taken to urgent projects, replacing them with freed ones from tasks. Because of this, the speed estimate is reset to zero each time. It is almost impossible to count in such conditions. The only solution that was invented was to collect data on each composition of 3-4 sprints, and then try to identify the average value.

“And let's take a quick run” or 3 full demo applications per month

Of course, application development has not been canceled. Especially if they are necessary for reaching the global goals of the company. Especially if very urgently needed. And recently, the need for high-speed implementation of demo applications for shows has greatly increased.

Of course, having worked in the new paradigm, I did not want to go back to the old conversations. Then we decided to use parts of the new visualization module (as a complete system, it was not yet fully prepared for those tasks), taking the principles of its development as a guide.
Since so far not all developers were in the workflow theme, and adapting the guys to the new development device was a big risk in terms of the terms of our burning demos, we tried to find some kind of a middle ground between the past and, I hope, the future. As a result, here's what happened with the partial use of the principles of the new visualization module on demos:

Small teams. 2-3 developers, designer, tester and manager.
Parallel development (earlier controls were created first, then templates with appearance and application logic).
Using tasks like Story in Jira. There were no clear specifications and TK, so I collected all the available information on the expected behavior and appearance of the application and designed it all in Story. They were then tested, which caused a positive reaction from the testers, because all the information was collected in one place, but it was broken down into functional parts, which made the verification easier. And the team as a whole did not have to read a bunch of official text in order to correctly understand and accomplish the task. Also, unlike Vord documents with specifications, Story was updated more quickly, people received descriptions with new specifications more quickly and, accordingly, started to implement them more quickly.
Gitflow with develop and master branches, but without feature:

all development was carried out in the develop-branch, but in order to exclude the presence of unregistered tasks, each commit must have been marked with a task code from Jira, within the framework of which it was carried out;
when all the tasks planned for the release were cut off, a new build was going: the team led the develop-branch revision code and, if everything was ok, the changes were retained in master with assignment of the tag with build number. If in the process of review there were gross errors and irregularities, the code was sent for editing and only after they were made and re-checked was held in master.
The builds were numbered in two digits, for example, 0.1 is always the number of the first test build, where 0 indicates the production version, 1 is the build number. And so, in the number of each next test build, the last digit increased, until the tester and the manager conclude that the build is ready for output in production. Accordingly, if such was the fourth test build (0.4), then it became the first production build (1.0) and the corresponding tag was put in the master branch. If defects are detected in production, and the production build was sent for editing, then the number of all subsequent builds also increases the second digit (1.1, 1.2, etc.).

Thus, during the month we implemented 3 full-fledged demo applications, which received positive feedback and continue to be useful. Previously, we could not implement such functionality so quickly and with so many people in the team.

In my humble opinion

What do I personally think about this?

That organization of processes really influences the result and that listening to world development practices, invented by the developers themselves and oriented towards them, is not just “stylish, fashionable, youth”, but necessary (after putting the demos, for the first time in several years of practice, we continued to do the rest projects, and did not sit until the night for another 2 weeks after the surrender, ruling the heaps of shameful defects found by the customer.
The level of chaos, misunderstanding and stress on projects with a clear workflow is lower (people are better equipped with relevant information, they know where to get it if necessary).
Proper use of project organization tools affects the development of the projects themselves and their participants (thanks to the optimization of development in Gitlab, Jira, the introduction of the principles of agile scrum, the opportunity to exchange experience in a team, pumping teamwork skills, the transfer of junior team building skills began and middle developers).

Here's the secret

Despite the above conclusions, and something else became obvious to me:

- Not everyone is ready for what they dream.

Sometimes, when we observe something from the outside, it seems to us that this is something good, useful, necessary for success, correct and reference. But it is worth the dream to become a reality, as we understand: "This is not what I imagined." So in the work: it seems that here give you such conditions in which “normal companies” work, and you will flourish. But alas. And it happens that you, sparing no effort, try to give people what they dreamed about as a pledge of success, and the miracle does not happen: the work is still not done well enough, and you realize that you may have accepted someone’s typical words of kitchen talk support for real aspirations and dreams.

So in the process of introducing new rules and principles, we faced not only positive feedback and results, but also a negative perception of what is happening. Someone working with Jira and Gitlab seemed to be too much fussing, and it was extremely difficult to change this perception, until people were faced with a problematic situation that occurred due to ignoring the generally accepted workflow. Some tasks were still performed carelessly, descriptions in Story and task setting were not taken into account or were perceived as “personal requests” and were not executed, despite being registered in Jira with a clear statement. In general, builds with poor-quality or inappropriate implementation were still born, and some bugs were rediscovered from build to build. Although the final result was positive in all demos, I still thought about that with the guys who are responsible in their work, for whom it is important to give the highest possible result, we managed not only to implement the necessary functionality, but also to introduce new features, optimize the application and “add ryushechek”. And with teams where someone could afford to be lazy or was less interested in achieving the highest quality result, we implemented only the basic functionality and a couple of small features according to the additional requirement of the customer after delivery.

It was then that, perhaps, my most important conclusion came to me:

“Not a process, not technology — the true keys to success, but those who create, create, embody the idea into reality — people and their attitude to their work. A musician who puts his heart into his work will affect the listeners, playing even the cheapest and most inconvenient instrument. Give him a Stradivarius - he will drive the audience crazy. And there are those who even Stradivari, even the latest development of advanced manufacturers of tools provide - it will all sound unimportant.

You can provide people with comfortable conditions and top technologies, but in the end get an unsatisfactory result of their activities, because "it will come down anyway." And it is possible with the presence of not the most successful, and sometimes even hindering the competent implementation of technologies, to get a decent result, because those who sought it - can not afford to hand over unfinished or poorly done work. And it is very important for such team members to discern, support, it is to them to be able to listen and create favorable conditions for their activities.

Technology and process organization do have an impact on the result and are very important, but the main key to success is in talented, responsible and development-oriented people.

Tags: