Panacea Scrum - 2!
This topic, there is a continuation of this topic: habrahabr.ru/blogs/pm/39308
So. Let's continue the story on the subject of Scrum.
Before describing the methodology itself, let's touch on the classification. We often hear: we have XP methodology, and we have Scrum, and we have Agile development. All this has the right to life. But, in my opinion, it is desirable to correctly relate these concepts.
')
XP is a set of principles and approaches that change the traditional attitude to the development of a modern software product.
Agile is the general name for a group of flexible and fairly successful methods of organizing project management. Methods that, as a rule, are based on the principles of XP and involve rapid iterative development, close communication with the customer and, due to close communication of team members, minimization of creating additional entities (artifacts / documents) that were traditionally created during the work on the project. Minimize all that is created in addition to the program code itself.
Scrum is one of the specific Agile techniques. That is, a clear template (framework) of the project management organization. With its own terms and concepts. If you closely follow this pattern, then we can say that you are developing on Scrum.
I often come across a different classification when XP is called the Agile methodology. It is hard to say… In my opinion, XP - postulates the fundamental principles. Other conceptual approaches to development are on a par with XP: Waterfall, Spiral, RUP ... And Agile is already a specific set of techniques that somehow describe the technological aspects of project management. Although ... these are terminological nuances. But keep in mind is necessary - these terms are used with varying degrees of generalization, which sometimes can cause some verbal confusion.
And now directly about Scrum.
To start the organization of the project on Scrum, two important people are introduced to the team. This is a product owner and scrum master.
Product Owner is a person who clearly knows what the customer ultimately needs from a software product. Ideally, it is a customer representative. And not the part of the customer who pays the money, but the part that will use this product directly. In real life, this is not always possible to achieve, therefore this role can be performed by an employee of the company who is responsible for contacting the customer. Calls, drives, speaks on Skype and clarifies, finds out, squeezes out ...
In any case, it is from this person that all wishes (requirements) for the future software product come out. His word here is fundamental and essentially the only thing. This is the law.
Scrum Master is a very special person. It is his task to make sure that the development was constantly accompanied by the spirit of involvement / participation of all team members, and important details were not missed, which should be clarified at scrum meetings. Scrum meeting is the main place where decisions are made on the organization of the project.
And what is important - this person is not a formal head for the team. But it is he who must correctly organize the discussion of the details of the project, “imposing” the appropriate spirit, so that they would NOT be in the form - and now let the head of the transport department report! But all information must be communicated and goals met. I would say that this person can be called a tamada project. :-) Very difficult role.
And now, let's move on to how the development process itself is built. Or rather the management process.
As we remember, in XP, on the principles of which Scrum relies, the development should be structured in such a way that it would go to the goal with iterative turns, on each of which the project takes on a more and more finished look, and from the first turn it begins to breathe. Let the form of just one screensaver.
In Skrama, such a single time run (iteration) is called Sprint (Sprint). On the last day (and hour) of each sprint we must have a working version of the project, which already has something to look at. With each new sprint, we have a more and more meat-overgrowing project. And so, sprint after sprint, race after race, at the exit we get the finished product. Considering that after each race, the project somehow already works and, therefore, we have something to show, then we also have the opportunity to promptly receive feedback from future users and, accordingly, promptly take into account their comments. Slightly more precisely adjusting the future product to the needs of the customer. Moreover, this feedback is not based on the views of the future user about how it will look at the end, but on what he was able to see. What is extremely important in any project. Since, alas, the views of different people can differ very, very much.
There is an obvious question - what should be the duration of the sprint? Good question. Less is better. But - you must have a working project (with new functionality!) After each sprint. Choose the duration of the sprint is an experience and art. But, Scrum says - this duration should be no more than a few weeks. Otherwise, it will not be XP, but a waterfall. :-) One, two, three, or at least four weeks. A longer interval relaxes the customer. Small spacing? So you do not have time to do anything noticeable. Or you can not collect. Such are the sad things.
And now - let's turn to the mechanics of the process. Along the way, we introduce some more new concepts.
It all starts with creating a Product Backlog. I deliberately first use English terms in order not to confuse readers reading texts about scams in the English version. Along the way, unobtrusively, I use a reasonable translation into Russian.
So, the Product Backlog is the complete wish list (stories) of the customer, which forms and maintains the Product Owner (product manager). Linear list. Completed constantly. It can be created in excel. Everything that the customer wants to see in the final product is concentrated there. And all the comments that he makes in the course of work. A-absolutely everything. In order not to forget anything. True, sometimes it reminds: 1. Repair the barn (priority - 20). 2. The construction of communism (priority - 6). But like this. Scrum does not insist that the list be hierarchical, take into account the dependence of points ... and so on. Not. Don't ask me why, but no! Although, according to the mind. Maybe yes.
Canonically, each item should consist of several columns: Number, Name, PRIORITY, a rough estimate of the deadline, an explanation of the item and a column - HOW TO DEMONSTRATE THE PERFORMANCE RESULTS. As you understand, the priority is set by the product manager. The rest is up to the team.
And now - the movement.
At the beginning of each sprint, a meeting is going. The whole team is there (with a grocery manager and a scram master inside). Roughly and habitually speaking - the rally. Production meeting. Long such a rally. Hours for three. And it decides what points (stories) will fall into the implementation of the current race. And formed the second list - Sprint backlog. What gets into the implementation of the current run from the Product backlog. This is clearly a subset of the Product backlog. But this is not enough. The main thing - the goal of the race is fixed. What and how we can show the customer representative at the finish of this sprint. And, most interestingly, an assessment of the timing of development. Public and fun. Making it possible to understand the product manager, what really can be done at this race. And what, really will not succeed. So what is next?
And then - the starting pistol and the race. As you understand, this is a sprint race, not a stayer one. And certainly not a marathon. In the athletics marathon, everything is simple - at least there is clear where to run. In the development of software, the path of the race will be constantly adjusted. And even the end point can change.
And so that everyone would understand that we are still running, and, importantly, we are running together and in the right direction, small meetings are held every day. Under the strict guidance of the Scrum Master. Living such production meetings for half an hour, where everyone enthusiastically tells how much he ran and where he stumbled. They, just, and are called contractions. What translated to English means Scrum. Like men in rugby, in the fight for the ball. Or, like men in American football. In the fight for the same ball. Which, at times, is more impressive, though stupid. And no matter what a person does in the project. He must always feel his elbow! Ideally, all the elbows of all the comrades. These fights are better in the morning. This is not a bunch of people tired at the end of the day. This is after all a party of energetic sprinters who stopped at the twentieth meter of the lane to sip good coffee in good company.
At the end of the distance of each sprint - showing. Showing sprint results. Is always. Ideally, directly to the customer. Well, what's the point of showing yourself what you've already seen a hundred times? Not. Just show someone. Well, on a pinch, the head of the company. Or the head of the personnel department. And a discussion of personal achievements.
So what is next? And all!
Breakthrough - the result! Breakthrough - the result! Tangible result. Tangible for those who look, and not for the developers themselves.
What we have in the bottom line? But:
1. Build a Product Backlog
2. We estimate the complexity of the project and the duration of the sprint
3. Compile Sprint Backlog for the race.
4. Immediately run! (with discussions every day)
5. Show!
6. We supplement the Product Backlog.
7. Compile Sprint Backlog for the race.
8. Immediately run! (with discussions every day)
9. Show!
10. We supplement the Product Backlog.
11. Compile Sprint Backlog for the race.
12. Immediately race! (with discussions every day)
13. Show!
14. Complement the product backlog.
15. …
sixteen. …
17. ... Well, you understand ...
18. We receive a production award for a successfully completed project.
19. Take a vacation (or search for a new job).
In fact, of course - not everything. Scrum is a very team methodology. All these fights, in the process of which a team is formed and work, are very important things. And the scrum master must be a psycho-wizard capable of sophisticated daily battles in such a way as to rally and motivate the team, find out the result of the current day, and tactfully adjust the goals.
Methodology Scrum offers different techniques for a successful outcome. This is a nice room for rally. Great. Light. With soft chairs. And with indoor plants. This and the use of a large amount of paper for stickers that would visually show on the board, how and where we move. Pre razlineev board to the left and right. On less important and more important. This is also a subtle psychological methodology for estimating time (planning poker). The team should work extremely hard, but with the comfort and support of each other.
And yet, Scrum very carefully and distinctly insists on using the conceptual principles of XP. Especially on test-driving development. It is impossible to conduct intensive development and not to write tests. Yes, it's a waste of time. For the first time. Then - saving time. Especially after refactoring. This is a very important principle. Don't underestimate him!
Think beer is over? Nifiga! Just decided to finish it for now.
Now, in the vein of tactful and intelligent comments, we will look as though it would be more correctEH to raise the critical part of the discussion in the third part of the epic. :-)
If she certainly will be.
So. Let's continue the story on the subject of Scrum.
Before describing the methodology itself, let's touch on the classification. We often hear: we have XP methodology, and we have Scrum, and we have Agile development. All this has the right to life. But, in my opinion, it is desirable to correctly relate these concepts.
')
XP is a set of principles and approaches that change the traditional attitude to the development of a modern software product.
Agile is the general name for a group of flexible and fairly successful methods of organizing project management. Methods that, as a rule, are based on the principles of XP and involve rapid iterative development, close communication with the customer and, due to close communication of team members, minimization of creating additional entities (artifacts / documents) that were traditionally created during the work on the project. Minimize all that is created in addition to the program code itself.
Scrum is one of the specific Agile techniques. That is, a clear template (framework) of the project management organization. With its own terms and concepts. If you closely follow this pattern, then we can say that you are developing on Scrum.
I often come across a different classification when XP is called the Agile methodology. It is hard to say… In my opinion, XP - postulates the fundamental principles. Other conceptual approaches to development are on a par with XP: Waterfall, Spiral, RUP ... And Agile is already a specific set of techniques that somehow describe the technological aspects of project management. Although ... these are terminological nuances. But keep in mind is necessary - these terms are used with varying degrees of generalization, which sometimes can cause some verbal confusion.
And now directly about Scrum.
To start the organization of the project on Scrum, two important people are introduced to the team. This is a product owner and scrum master.
Product Owner is a person who clearly knows what the customer ultimately needs from a software product. Ideally, it is a customer representative. And not the part of the customer who pays the money, but the part that will use this product directly. In real life, this is not always possible to achieve, therefore this role can be performed by an employee of the company who is responsible for contacting the customer. Calls, drives, speaks on Skype and clarifies, finds out, squeezes out ...
In any case, it is from this person that all wishes (requirements) for the future software product come out. His word here is fundamental and essentially the only thing. This is the law.
Scrum Master is a very special person. It is his task to make sure that the development was constantly accompanied by the spirit of involvement / participation of all team members, and important details were not missed, which should be clarified at scrum meetings. Scrum meeting is the main place where decisions are made on the organization of the project.
And what is important - this person is not a formal head for the team. But it is he who must correctly organize the discussion of the details of the project, “imposing” the appropriate spirit, so that they would NOT be in the form - and now let the head of the transport department report! But all information must be communicated and goals met. I would say that this person can be called a tamada project. :-) Very difficult role.
And now, let's move on to how the development process itself is built. Or rather the management process.
As we remember, in XP, on the principles of which Scrum relies, the development should be structured in such a way that it would go to the goal with iterative turns, on each of which the project takes on a more and more finished look, and from the first turn it begins to breathe. Let the form of just one screensaver.
In Skrama, such a single time run (iteration) is called Sprint (Sprint). On the last day (and hour) of each sprint we must have a working version of the project, which already has something to look at. With each new sprint, we have a more and more meat-overgrowing project. And so, sprint after sprint, race after race, at the exit we get the finished product. Considering that after each race, the project somehow already works and, therefore, we have something to show, then we also have the opportunity to promptly receive feedback from future users and, accordingly, promptly take into account their comments. Slightly more precisely adjusting the future product to the needs of the customer. Moreover, this feedback is not based on the views of the future user about how it will look at the end, but on what he was able to see. What is extremely important in any project. Since, alas, the views of different people can differ very, very much.
There is an obvious question - what should be the duration of the sprint? Good question. Less is better. But - you must have a working project (with new functionality!) After each sprint. Choose the duration of the sprint is an experience and art. But, Scrum says - this duration should be no more than a few weeks. Otherwise, it will not be XP, but a waterfall. :-) One, two, three, or at least four weeks. A longer interval relaxes the customer. Small spacing? So you do not have time to do anything noticeable. Or you can not collect. Such are the sad things.
And now - let's turn to the mechanics of the process. Along the way, we introduce some more new concepts.
It all starts with creating a Product Backlog. I deliberately first use English terms in order not to confuse readers reading texts about scams in the English version. Along the way, unobtrusively, I use a reasonable translation into Russian.
So, the Product Backlog is the complete wish list (stories) of the customer, which forms and maintains the Product Owner (product manager). Linear list. Completed constantly. It can be created in excel. Everything that the customer wants to see in the final product is concentrated there. And all the comments that he makes in the course of work. A-absolutely everything. In order not to forget anything. True, sometimes it reminds: 1. Repair the barn (priority - 20). 2. The construction of communism (priority - 6). But like this. Scrum does not insist that the list be hierarchical, take into account the dependence of points ... and so on. Not. Don't ask me why, but no! Although, according to the mind. Maybe yes.
Canonically, each item should consist of several columns: Number, Name, PRIORITY, a rough estimate of the deadline, an explanation of the item and a column - HOW TO DEMONSTRATE THE PERFORMANCE RESULTS. As you understand, the priority is set by the product manager. The rest is up to the team.
And now - the movement.
At the beginning of each sprint, a meeting is going. The whole team is there (with a grocery manager and a scram master inside). Roughly and habitually speaking - the rally. Production meeting. Long such a rally. Hours for three. And it decides what points (stories) will fall into the implementation of the current race. And formed the second list - Sprint backlog. What gets into the implementation of the current run from the Product backlog. This is clearly a subset of the Product backlog. But this is not enough. The main thing - the goal of the race is fixed. What and how we can show the customer representative at the finish of this sprint. And, most interestingly, an assessment of the timing of development. Public and fun. Making it possible to understand the product manager, what really can be done at this race. And what, really will not succeed. So what is next?
And then - the starting pistol and the race. As you understand, this is a sprint race, not a stayer one. And certainly not a marathon. In the athletics marathon, everything is simple - at least there is clear where to run. In the development of software, the path of the race will be constantly adjusted. And even the end point can change.
And so that everyone would understand that we are still running, and, importantly, we are running together and in the right direction, small meetings are held every day. Under the strict guidance of the Scrum Master. Living such production meetings for half an hour, where everyone enthusiastically tells how much he ran and where he stumbled. They, just, and are called contractions. What translated to English means Scrum. Like men in rugby, in the fight for the ball. Or, like men in American football. In the fight for the same ball. Which, at times, is more impressive, though stupid. And no matter what a person does in the project. He must always feel his elbow! Ideally, all the elbows of all the comrades. These fights are better in the morning. This is not a bunch of people tired at the end of the day. This is after all a party of energetic sprinters who stopped at the twentieth meter of the lane to sip good coffee in good company.
At the end of the distance of each sprint - showing. Showing sprint results. Is always. Ideally, directly to the customer. Well, what's the point of showing yourself what you've already seen a hundred times? Not. Just show someone. Well, on a pinch, the head of the company. Or the head of the personnel department. And a discussion of personal achievements.
So what is next? And all!
Breakthrough - the result! Breakthrough - the result! Tangible result. Tangible for those who look, and not for the developers themselves.
What we have in the bottom line? But:
1. Build a Product Backlog
2. We estimate the complexity of the project and the duration of the sprint
3. Compile Sprint Backlog for the race.
4. Immediately run! (with discussions every day)
5. Show!
6. We supplement the Product Backlog.
7. Compile Sprint Backlog for the race.
8. Immediately run! (with discussions every day)
9. Show!
10. We supplement the Product Backlog.
11. Compile Sprint Backlog for the race.
12. Immediately race! (with discussions every day)
13. Show!
14. Complement the product backlog.
15. …
sixteen. …
17. ... Well, you understand ...
18. We receive a production award for a successfully completed project.
19. Take a vacation (or search for a new job).
In fact, of course - not everything. Scrum is a very team methodology. All these fights, in the process of which a team is formed and work, are very important things. And the scrum master must be a psycho-wizard capable of sophisticated daily battles in such a way as to rally and motivate the team, find out the result of the current day, and tactfully adjust the goals.
Methodology Scrum offers different techniques for a successful outcome. This is a nice room for rally. Great. Light. With soft chairs. And with indoor plants. This and the use of a large amount of paper for stickers that would visually show on the board, how and where we move. Pre razlineev board to the left and right. On less important and more important. This is also a subtle psychological methodology for estimating time (planning poker). The team should work extremely hard, but with the comfort and support of each other.
And yet, Scrum very carefully and distinctly insists on using the conceptual principles of XP. Especially on test-driving development. It is impossible to conduct intensive development and not to write tests. Yes, it's a waste of time. For the first time. Then - saving time. Especially after refactoring. This is a very important principle. Don't underestimate him!
Think beer is over? Nifiga! Just decided to finish it for now.
Now, in the vein of tactful and intelligent comments, we will look as though it would be more correctEH to raise the critical part of the discussion in the third part of the epic. :-)
If she certainly will be.
Source: https://habr.com/ru/post/39534/
All Articles