Geekly Articles each Day

On thorns and stars on the path to optimizing development processes

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 at least review ...



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


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:


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


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?

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:


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


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


So why exactly Gitflow and such?

  1. 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.
  2. 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 by clicking on a region on the map to call a friend in this region? 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, the “requests” in Jira are usually not registered, because not every developer can refuse to the manager or send him to register his “request ", And it 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).
  3. 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.
  4. 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 the 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:


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:

  1. Small teams. 2-3 developers, designer, tester and manager.
  2. Parallel development (earlier controls were created first, then templates with appearance and application logic).
  3. 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 all of this 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.
  4. Gitflow with develop and master branches, but without feature:


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?




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 the fact that with the guys who are responsible for the 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 came to me, perhaps my most important conclusion:

- Not a process, not technology - the true guarantees of success, but those who create, create, embody the idea in 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.

Source: https://habr.com/ru/post/413025/

More articles:


All Articles