Panacea Scrum? Let's talk together where it is useful to us
I will begin simply - I will explain what Scrum is and why it is needed, so that those people who have not yet come across it could read with interest this note and understand what it really is.
So, Scrum, this is the popular (fashionable, if you will) methodology of running software projects today. In other words, how to manage the development team so that the software project ends successfully. What and how to document, how, with whom and how often to discuss the details of the project, how to set tasks for people and how to control the result. All this falls under the term “software project management methodology.”
Do you understand? Fine! And now... I honestly say that I myself do not know what scram is. But I know that all developers love him very much. Why? Well, probably because scrum is an extremely informal approach to development, with a minimum of documentation and a lot of communication. Have you often seen developers who like to write separate documentation on their own code? I rarely.
')
Remember this old joke - the leadership of a certain institute decided to conduct an experiment: to invite students to take exams themselves from their fellow students (instead of teachers). And what do you think? The experiment fully justified itself - only good and excellent grades are in the students' records!
Let's return to the scrum. Scrum is one of the popular Agile class methodologies. And, following the principles of XP (Extreme Programming). Here I would like to clearly explain what XP, Agile and Scrum are. Well, of course, since I myself understand it (yes, you don’t get scared much, I read a certain number of primers out of politeness, and those who read more, I know, will definitely correct me tactfully).
So - XP.
When the universe arose, and people just started writing computer programs, they treated it very simply. About how to create an aircraft. Things are trivial. Take off, not take off ... but where will he go. Well, if ebn ... does not take off in the sense, well, it means that they made a mistake somewhere in the calculations. It happens. It is simple to do it in the sense of doing everything consistently. That is, experienced, usually gray-haired men sit down (as I am about), and carefully plan everything in advance. Sometimes, foolishly, the barely sat down, but they usually got worse after all. Yes. And these men are planning work on the principle: the man said - the man did! And the man said simply, today we squeeze out of these fucking customers all that they know about IT (and fulya, they need it!). Tomorrow, our analysts carefully IT fix in the specifications, and then, our most analytical analysts offer the best approaches to do everything as MI needs in the best possible way. Strictly and then, architects come out of the sea and select the most suitable architecture. And, well, now everything is clear. Boys coders fly, they quickly dictate everything to ... yes, it doesn't matter what. And at the exit we get a candy.
What is the peculiarity of this approach? And that everything is done strictly consistently. As in the army: lifting, charging, breakfast, building on the parade ground ... That is, we slowly ... slowly descend the mountain and carefully move ... I wanted to say that the project strictly and irrevocably follows the finish line as water falls from the cliff. The approach is called a waterfall. Everything is planned, everything is predetermined, deadlines are prearranged to the nearest hour. All is good, but ... There were arrogant and daring customers who for some reason did not want to call the result candy. Taste they, you see, did not like. Damn it with him as they called it (not for dinner be mentioned), but they did not want to pay either. That is not very good.
In general, this nonsense, apparently, began to repeat with enviable regularity. For many years, we, the developers, suffered this, but then the end came. About ten years ago, the wisest of us, plucked up courage and made a different decision, and postulated other principles.
These principles are:
- We do not give the descent to the customer! We immediately take a short pause to make the right decomposition of objects, design interfaces to software modules, plug them in three weeks, and then roll out the first visual forms.
- We hold the customer by the tail and show him these forms at least once a week. The customer begins to realize what and how he really wanted and how he is really comfortable. He is not afraid of anything. He begins to think!
- We do not steam with the careful name of the variables and code methods. We expel the code quickly. We even sit down next to other people not to read Habr while I code
- We understand that we will pile up a lot of badly working code. Therefore, the smartest of us initially write tests to verify that it would check that all this works as the customer would like. And we always check every bunch (crossed out), our work with these tests (test driven development)
- We, in our hearts, understand that the code should look good. Therefore, we periodically clean it. Without changing its essence and not redesigning. By clever - we do refactoring. So that in the end we don’t mess around, we’ll be testing all changes.
That is, from the first day we are fully involved in the race with the customer in order to get feedback from him as quickly as possible. At first, just forms, then calculations went, then the script ... The customer squeaks, but he is always at hand ... (tail alone) He will not say that he was waiting for something new and interesting. He already ofigel from our pressure.
What's the Difference? And the difference is that we do not simply coordinate with the customer how the wooden product will look like at the exit. Not. Although this too. Step by step, we remove the chips, even if not processing the product with sandpaper, but we persistently put it under the nose of the customer with enviable regularity, so that he would penetrate and not say later that this carved horseradish looks completely different than he imagined it in his dreams.
We consistently strengthen our project with a spiral, keeping it in working condition and quietly, at night, we replace our stubs with real code. Pre running our tests.
Yes. This is XP. A set of technical principles on how to make development sensitive to external requirements. This is not a management methodology, but it is only a set of useful technical approaches.
Roughly speaking, instead of removing the chemical pencil, draw a line and start, turning away, chop it with an ax, you organize the work in such a way that you can tactfully drive a plane, showing each slice of chips to the customer and take all his comments into account. Let him look and drag.
As the beer is over, the sequel will follow later. :-)
So, Scrum, this is the popular (fashionable, if you will) methodology of running software projects today. In other words, how to manage the development team so that the software project ends successfully. What and how to document, how, with whom and how often to discuss the details of the project, how to set tasks for people and how to control the result. All this falls under the term “software project management methodology.”
Do you understand? Fine! And now... I honestly say that I myself do not know what scram is. But I know that all developers love him very much. Why? Well, probably because scrum is an extremely informal approach to development, with a minimum of documentation and a lot of communication. Have you often seen developers who like to write separate documentation on their own code? I rarely.
')
Remember this old joke - the leadership of a certain institute decided to conduct an experiment: to invite students to take exams themselves from their fellow students (instead of teachers). And what do you think? The experiment fully justified itself - only good and excellent grades are in the students' records!
Let's return to the scrum. Scrum is one of the popular Agile class methodologies. And, following the principles of XP (Extreme Programming). Here I would like to clearly explain what XP, Agile and Scrum are. Well, of course, since I myself understand it (yes, you don’t get scared much, I read a certain number of primers out of politeness, and those who read more, I know, will definitely correct me tactfully).
So - XP.
When the universe arose, and people just started writing computer programs, they treated it very simply. About how to create an aircraft. Things are trivial. Take off, not take off ... but where will he go. Well, if ebn ... does not take off in the sense, well, it means that they made a mistake somewhere in the calculations. It happens. It is simple to do it in the sense of doing everything consistently. That is, experienced, usually gray-haired men sit down (as I am about), and carefully plan everything in advance. Sometimes, foolishly, the barely sat down, but they usually got worse after all. Yes. And these men are planning work on the principle: the man said - the man did! And the man said simply, today we squeeze out of these fucking customers all that they know about IT (and fulya, they need it!). Tomorrow, our analysts carefully IT fix in the specifications, and then, our most analytical analysts offer the best approaches to do everything as MI needs in the best possible way. Strictly and then, architects come out of the sea and select the most suitable architecture. And, well, now everything is clear. Boys coders fly, they quickly dictate everything to ... yes, it doesn't matter what. And at the exit we get a candy.
What is the peculiarity of this approach? And that everything is done strictly consistently. As in the army: lifting, charging, breakfast, building on the parade ground ... That is, we slowly ... slowly descend the mountain and carefully move ... I wanted to say that the project strictly and irrevocably follows the finish line as water falls from the cliff. The approach is called a waterfall. Everything is planned, everything is predetermined, deadlines are prearranged to the nearest hour. All is good, but ... There were arrogant and daring customers who for some reason did not want to call the result candy. Taste they, you see, did not like. Damn it with him as they called it (not for dinner be mentioned), but they did not want to pay either. That is not very good.
In general, this nonsense, apparently, began to repeat with enviable regularity. For many years, we, the developers, suffered this, but then the end came. About ten years ago, the wisest of us, plucked up courage and made a different decision, and postulated other principles.
These principles are:
- We do not give the descent to the customer! We immediately take a short pause to make the right decomposition of objects, design interfaces to software modules, plug them in three weeks, and then roll out the first visual forms.
- We hold the customer by the tail and show him these forms at least once a week. The customer begins to realize what and how he really wanted and how he is really comfortable. He is not afraid of anything. He begins to think!
- We do not steam with the careful name of the variables and code methods. We expel the code quickly. We even sit down next to other people not to read Habr while I code
- We understand that we will pile up a lot of badly working code. Therefore, the smartest of us initially write tests to verify that it would check that all this works as the customer would like. And we always check every bunch (crossed out), our work with these tests (test driven development)
- We, in our hearts, understand that the code should look good. Therefore, we periodically clean it. Without changing its essence and not redesigning. By clever - we do refactoring. So that in the end we don’t mess around, we’ll be testing all changes.
That is, from the first day we are fully involved in the race with the customer in order to get feedback from him as quickly as possible. At first, just forms, then calculations went, then the script ... The customer squeaks, but he is always at hand ... (tail alone) He will not say that he was waiting for something new and interesting. He already ofigel from our pressure.
What's the Difference? And the difference is that we do not simply coordinate with the customer how the wooden product will look like at the exit. Not. Although this too. Step by step, we remove the chips, even if not processing the product with sandpaper, but we persistently put it under the nose of the customer with enviable regularity, so that he would penetrate and not say later that this carved horseradish looks completely different than he imagined it in his dreams.
We consistently strengthen our project with a spiral, keeping it in working condition and quietly, at night, we replace our stubs with real code. Pre running our tests.
Yes. This is XP. A set of technical principles on how to make development sensitive to external requirements. This is not a management methodology, but it is only a set of useful technical approaches.
Roughly speaking, instead of removing the chemical pencil, draw a line and start, turning away, chop it with an ax, you organize the work in such a way that you can tactfully drive a plane, showing each slice of chips to the customer and take all his comments into account. Let him look and drag.
As the beer is over, the sequel will follow later. :-)
Source: https://habr.com/ru/post/39308/
All Articles