# Acceleration4X. Principle number 0/1. Variable environment
So, we want to speed up development 4 times. No, we do not want, we have already accelerated. Do you want to.
Silver bullet, accelerating 4 times, no. There is a whole clip of bullets of different caliber, type, lethal force and applicability in a particular situation.
I'll just tell you how we did it. What solutions have found, chips, approaches, philosophy. Whether you need it or not - decide for yourself. We do not impose. We just got into trouble with questions by mail and at conferences, so we decided to tell centrally, in the most appropriate place for this - Habré. Immediately developers experience sharing? All the questions will give links.
We do not pretend to the highest truth and the full disclosure of the topic, we are not going to argue with anyone, we have passed this way. Do you want to - pass too
')
If you agree - under cat.
The entire list of material that I want to present is divided into two parts - approaches and solutions.
Approaches are basic principles, applying which you can find solutions. Using approaches, solutions can be implemented. Approaches + solutions give 4X.
Approaches, or basic principles, I assigned the number zero. There are three principles of zero, today - about the first, namely about the environment, which should change.
Everything, enough to beat around the bush, everyone understood everything, drove to the point.
The main thing that needs to be done to speed up 4X is to create a variable environment in your team. I’ll say right away - if you don’t have a team, you’re alone, then consider yourself a team. Some of the principles will be inapplicable to you, some - on the contrary, will be more effective.
People often ask - what if we have a remote team? And this is what we need. We also had a remote team. But we sometimes meet. Classic Scrum says that it is necessary to meet every day, but we do not have classic Scram, but "German". Well, it was necessary to somehow call our fork.
If you are not meeting a team, then consider yourself a loner +, because Some teamwork methods are applicable for you - there is Skype, for example.
Variable environment is the absence of formal, approved work algorithms. Only temporary, which sometimes live one day, sometimes one hour.
Programmers, unfortunately, love to work on the standard. They need everything to be clear - here you take the task, right here you add the result, these are the tests that have to be worked out, that guy will go and show.
Probably love because they themselves are engaged in the creation of algorithms.
Now you need to switch programmers to another mode - debugging. Only you need to debug not the code, but the work of the team.
Everybody knows what debugging is - compile, run, see whether it works or not. If it does not work, we make corrections. If any piece of code is working, ok, leave it. But we understand that it can stop working if something changes to it, or requirements in the following code, or an object model - it does not matter.
It is important that in the debug mode everyone understands that this is temporary. The goal is to create an algorithm, but working and tested, instead of any.
This should be clearly and honestly explained to the team. If you write code that, as you know for sure, you cannot debug, then you will do this for a very long time and still make mistakes. If it seems to you a far-fetched situation of “writing code that cannot be debugged,” then you are probably very young. Nowadays, we wrote such a code on exams at the institute - on paper, and only once.
In fact, you create the rules, the algorithm. You saw how the rules or business processes create warlocks - well, all sorts of business intelligence, quality management systems, 1C franchisees, etc.? What is their mistake?
The fact that they are not programmers. So, they do not understand what debugging is and why it is needed. They write snapshot - a snapshot of reality "as is", which becomes obsolete in a minute. And they, in general, don't give a shit if it will work or not.
But we are not warlocks, and not govnodery, we will debug our team. It is so simple that it is hard to believe - you will agree, it sounds like a truism that everyone knows?
And figushki. You know that you need to debug, and the rest do not know. The rest of them want to write the Big Document, in which everything should be taken into account, coordinated and endorsed this document, and forget about it forever.
Well, and to hell with them, we have our full business.
So, the command needs to be debugged. To make this possible, the team will have to talk and enlist their support. Simply put, you need to access the debugger - the F12 button - and the source code.
If you do not have access to the button and code, you can forget about acceleration. So most do - throw changes at the zero stage, because they do not understand the importance of a changeable environment.
In practice, this means that all existing rules are declared temporary, and can be changed, deleted or new ones added at any time. And everyone should take it. No excuses, such as "we did not agree so" or "this is not in my job description."
If the scrum master decided that from this moment we are not answering phone calls, it means that we do not answer phone calls. No one, no one, ever. Until a new instruction arrives.
The team must become a performance environment - flexible, adaptive, not opposing. The chrome debugger doesn't mind the code you debug in? And imagine if you objected? How would your work speed change?
You wrote a piece, started it, saw the error, fixed it in the source, started it again, and Chrome tells you - “uh, nah, we didn’t agree, I won’t restart debugging every minute, come on business process, not more than once hour, and generally agree with Sergey Brin ". Rave? Rave.
And in life, when debugging human systems, this is what happens. You are not allowed to debug. They say - write the code (rules, business process), send, we read, ask questions, clarify, etc. Both external and internal people speak.
Ok external - full of bureaucrats everywhere. But the internal resist.
Imagine how the debugging speed will change if you declare a variable in the code, assign a value to it, start the debugger, go to this line and see that the value has not been assigned. Why? You open the console, and there it says: “it was not possible to assign the value to the variable qty1, because it does not want.”
This is how systems of people with whom you do not agree. This is how a team behaves, which was not explained that it is now a team, not a team.
There is a good example that demonstrates this behavior - the film The Man Who Changed Everything . It literally happens there. The initiator of the change tells the person - from this day do it. That mane waves, leaves, and does not. Since he does not do it, he does not do two, then he is kicked out.
Because the initiator of the changes needs debugging. It is necessary to make changes and see if there is any benefit from them or not. And this process - to make, look, evaluate - should go very quickly. As in debugger.
About the fact who should make changes and how it should be done, let's talk in the following publications.
Happy New Year, everyone!
Silver bullet, accelerating 4 times, no. There is a whole clip of bullets of different caliber, type, lethal force and applicability in a particular situation.
I'll just tell you how we did it. What solutions have found, chips, approaches, philosophy. Whether you need it or not - decide for yourself. We do not impose. We just got into trouble with questions by mail and at conferences, so we decided to tell centrally, in the most appropriate place for this - Habré. Immediately developers experience sharing? All the questions will give links.
We do not pretend to the highest truth and the full disclosure of the topic, we are not going to argue with anyone, we have passed this way. Do you want to - pass too
')
If you agree - under cat.
The entire list of material that I want to present is divided into two parts - approaches and solutions.
Approaches are basic principles, applying which you can find solutions. Using approaches, solutions can be implemented. Approaches + solutions give 4X.
Approaches, or basic principles, I assigned the number zero. There are three principles of zero, today - about the first, namely about the environment, which should change.
Everything, enough to beat around the bush, everyone understood everything, drove to the point.
The main thing that needs to be done to speed up 4X is to create a variable environment in your team. I’ll say right away - if you don’t have a team, you’re alone, then consider yourself a team. Some of the principles will be inapplicable to you, some - on the contrary, will be more effective.
People often ask - what if we have a remote team? And this is what we need. We also had a remote team. But we sometimes meet. Classic Scrum says that it is necessary to meet every day, but we do not have classic Scram, but "German". Well, it was necessary to somehow call our fork.
If you are not meeting a team, then consider yourself a loner +, because Some teamwork methods are applicable for you - there is Skype, for example.
Variable environment is the absence of formal, approved work algorithms. Only temporary, which sometimes live one day, sometimes one hour.
Programmers, unfortunately, love to work on the standard. They need everything to be clear - here you take the task, right here you add the result, these are the tests that have to be worked out, that guy will go and show.
Probably love because they themselves are engaged in the creation of algorithms.
Now you need to switch programmers to another mode - debugging. Only you need to debug not the code, but the work of the team.
Everybody knows what debugging is - compile, run, see whether it works or not. If it does not work, we make corrections. If any piece of code is working, ok, leave it. But we understand that it can stop working if something changes to it, or requirements in the following code, or an object model - it does not matter.
It is important that in the debug mode everyone understands that this is temporary. The goal is to create an algorithm, but working and tested, instead of any.
This should be clearly and honestly explained to the team. If you write code that, as you know for sure, you cannot debug, then you will do this for a very long time and still make mistakes. If it seems to you a far-fetched situation of “writing code that cannot be debugged,” then you are probably very young. Nowadays, we wrote such a code on exams at the institute - on paper, and only once.
In fact, you create the rules, the algorithm. You saw how the rules or business processes create warlocks - well, all sorts of business intelligence, quality management systems, 1C franchisees, etc.? What is their mistake?
The fact that they are not programmers. So, they do not understand what debugging is and why it is needed. They write snapshot - a snapshot of reality "as is", which becomes obsolete in a minute. And they, in general, don't give a shit if it will work or not.
But we are not warlocks, and not govnodery, we will debug our team. It is so simple that it is hard to believe - you will agree, it sounds like a truism that everyone knows?
And figushki. You know that you need to debug, and the rest do not know. The rest of them want to write the Big Document, in which everything should be taken into account, coordinated and endorsed this document, and forget about it forever.
Well, and to hell with them, we have our full business.
So, the command needs to be debugged. To make this possible, the team will have to talk and enlist their support. Simply put, you need to access the debugger - the F12 button - and the source code.
If you do not have access to the button and code, you can forget about acceleration. So most do - throw changes at the zero stage, because they do not understand the importance of a changeable environment.
In practice, this means that all existing rules are declared temporary, and can be changed, deleted or new ones added at any time. And everyone should take it. No excuses, such as "we did not agree so" or "this is not in my job description."
If the scrum master decided that from this moment we are not answering phone calls, it means that we do not answer phone calls. No one, no one, ever. Until a new instruction arrives.
The team must become a performance environment - flexible, adaptive, not opposing. The chrome debugger doesn't mind the code you debug in? And imagine if you objected? How would your work speed change?
You wrote a piece, started it, saw the error, fixed it in the source, started it again, and Chrome tells you - “uh, nah, we didn’t agree, I won’t restart debugging every minute, come on business process, not more than once hour, and generally agree with Sergey Brin ". Rave? Rave.
And in life, when debugging human systems, this is what happens. You are not allowed to debug. They say - write the code (rules, business process), send, we read, ask questions, clarify, etc. Both external and internal people speak.
Ok external - full of bureaucrats everywhere. But the internal resist.
Imagine how the debugging speed will change if you declare a variable in the code, assign a value to it, start the debugger, go to this line and see that the value has not been assigned. Why? You open the console, and there it says: “it was not possible to assign the value to the variable qty1, because it does not want.”
This is how systems of people with whom you do not agree. This is how a team behaves, which was not explained that it is now a team, not a team.
There is a good example that demonstrates this behavior - the film The Man Who Changed Everything . It literally happens there. The initiator of the change tells the person - from this day do it. That mane waves, leaves, and does not. Since he does not do it, he does not do two, then he is kicked out.
Because the initiator of the changes needs debugging. It is necessary to make changes and see if there is any benefit from them or not. And this process - to make, look, evaluate - should go very quickly. As in debugger.
About the fact who should make changes and how it should be done, let's talk in the following publications.
Happy New Year, everyone!
Source: https://habr.com/ru/post/345830/
All Articles