Scrum - real experience in methodology
In this article, I give an overview of the organization of the process of creating software in the team in which I work. My goal is to share the experience of developing and managing a team of developers.
To organize the process of working on the project, we decided to choose the popular Scrum methodology. This is partly a tribute to fashion, partly a large number of publications on the Internet on the topic “Scrum did everything for us!”.
Where does software development usually begin? From the idea: “How wonderful it would be if I had some kind of software that would do something like this. It would be just super! ”The person who will represent this idea in the team is called the Product Owner (PO) or the Product Owner. A Product Owner is one who sees the goal of a product or who thinks that he sees the goal of a product, but what is important is that he can formulate it and begin the process of moving towards achieving it. He forms the goal in the form of a list of his wishes (hotelok). This list is called Product Backlog Items (PBI). It is constantly modified depending on the market situation or on the growing appetite of the Product Owner.
')
Team. According to Scrum, it is believed that the most effective development is achieved if the team itself makes its own decisions on how it will move towards the goal. Therefore, the main requirement for the team - it must be self-organizing and self-governing. Provide one this requirement, and it will be enough for success of the project. Since the requirement is serious, the ScrumMaster role is introduced into the team, which ensures that the Scrum rules are followed.
ProductOwner formulated its goal as a kind of point B, which needs to be achieved by starting at point A. But point B is not a point that can be reached by simply drawing a straight line between it and point A. Actually point B is a neighborhood points, and its radius can vary.
To get to this neighborhood, it is best to develop software in short steps (more precisely, races): sprints. At the end of the sprint, everyone evaluates what happens and corrects the direction of movement. ProductOwner is always aware of the fact that his ideas are correctly understood (and if not, this can be corrected in the next sprint), and calm. The team knows what it does, and is satisfied with its work.
In team sprint lasts 2 weeks. For a week, nothing has time, for a month, everything is forgotten. Therefore, 2 weeks for us is the best option. The first day of the sprint goes to planning. In the early stages, planning took even 2 days. Planning is the process by which a team takes the highest priority from the list of requirements and breaks it down into tasks that allow to achieve results. Each task is estimated in hours. It is desirable that the task does not take more than 4 hours. If a team member says that he will do the task in 5 days, then he has no idea what needs to be done.
The total number of hours in the sprint for each person is calculated from the fact that the sprint lasts 2 weeks or 10 working days. It is 80 hours minus one day to plan. Total 72 hours. But this is a perfect watch. This means that a person is not distracted by anything, does not eat, does not drink, does not get up from his seat, but only works and does not get tired. During planning, the task is evaluated in ideal hours. But not 72 hours is recruited for a person, but 72 hours multiplied by a certain coefficient, which is called the team performance. Usually it is 0.5. Surprisingly, this is some kind of magic number, it is with him that the whole sprint surrenders successfully. Someone from the greats said: “Take the time that the developer called you, multiply it by two and add a little more and get the time for which the programmer will give you the result”. And indeed it is.
In Scrum, there are several recommendations for how the executor evaluates the time for a task. For example, play poker. But we do not sin it. Whatever they say, but if someone started to do some module alone, then he will continue to build it up from sprint to sprint. And only he can estimate how much time he needs to complete the task. The only ones who can prevent him from inflating the time limit are his conscience (remember about self-organization) and ScrumMaster.
There is a list of requirements. But how to check whether this requirement is achieved during development or not? To do this, you need to write tests, which will describe in detail what is considered an achievement of the requirement. Simply speaking, they describe what button to press, and what happens. The team tests write analysts. And these tests should be ready by the time of the start of the next sprint. In our team, analysts and designers work ahead of the development team by 1 sprint.
The main requirement - the tests should be very detailed.
The sprint process begins. His main goal is to ensure that tests for requirements are met by the end of the sprint.
For cohesive movement of the team to the goal Scrum offers to do daily rallies. A rally is when everyone, standing at the blackboard with a marker, deletes what he did yesterday and writes what he is going to do today.
This is a very powerful practice. Thanks to her, everyone knows where the project is going as a whole. In addition, when a person tells what he will do today, he automatically coordinates his actions with other participants. Other participants can immediately offer the best solutions to the problem. And also the task written on the blackboard, and in fact - this is a promise to all its colleagues, very well motivates the performer himself. The only thing ScrumMaster should not forget to announce that the rally began.
Rallies to be held preferably standing and lasting no more than 15 minutes. We start rallies at 9 am.
The long-awaited end of the sprint comes, usually it is Friday at 16:00, and the team gives up the sprint to the Product Owner and everyone who is interested in the product. Everyone reports on the tasks that he performed and talks about what progress he has achieved, and also explains the reasons for which he failed to achieve the goal. The main rule - never postpone the sprint deadline.
Sometimes after the delivery of the sprint, an analysis is made of why something is happening or not happening, and what needs to be done to remedy the situation.
And on Monday, everything repeats again.
We have developed several rules for ourselves, the failure to comply with which led to the failure of the sprint:
• Sprint should be planned in detail, not sparing it forces. If any of the requirements is incomprehensible, then it is necessary to clarify the requirement. If this cannot be done, then there is no need to take the task into the sprint, and send the request for revision.
• Do not, under any circumstances, take on additional tasks that go beyond the sprint. And if they still “imposed”, then coordinate with the Product Owner, that other tasks will be removed from the sprint.
• The number of people in a team should not exceed 5-6 people. When our team grew to 16 people, the rally began to drag on for 2 hours. They entered a fixed performance time for each and stood with a stopwatch. But then the man did not have time to convey his idea, and the rally turned into a formality. Therefore, we are simply divided. First, they were divided into customers and nuclear specialists, and then they began to share according to tasks. Those. Each team makes its own feature, and in this subcommand there are both clients and nuclear specialists. This approach is still used, and for us it is most effective.
Scrum can be a good starting point to start moving. In the course of work, some rules may evolve or fall off as superfluous. This will already be decided by the team, relationships in the team and life itself. But the rules that are formed on the basis of Scrum, will serve as a good springboard for the team to achieve the desired result.
The team I work for is called Unicloud Labs. This is a friendly team of interesting people who really care about their work.
Varikov Andrey VAndrey
Technical Director of Unicloud Labs LLC
If we are interested in what we do - Welcome
To organize the process of working on the project, we decided to choose the popular Scrum methodology. This is partly a tribute to fashion, partly a large number of publications on the Internet on the topic “Scrum did everything for us!”.
What roles are there in scrum
Where does software development usually begin? From the idea: “How wonderful it would be if I had some kind of software that would do something like this. It would be just super! ”The person who will represent this idea in the team is called the Product Owner (PO) or the Product Owner. A Product Owner is one who sees the goal of a product or who thinks that he sees the goal of a product, but what is important is that he can formulate it and begin the process of moving towards achieving it. He forms the goal in the form of a list of his wishes (hotelok). This list is called Product Backlog Items (PBI). It is constantly modified depending on the market situation or on the growing appetite of the Product Owner.
')
Team. According to Scrum, it is believed that the most effective development is achieved if the team itself makes its own decisions on how it will move towards the goal. Therefore, the main requirement for the team - it must be self-organizing and self-governing. Provide one this requirement, and it will be enough for success of the project. Since the requirement is serious, the ScrumMaster role is introduced into the team, which ensures that the Scrum rules are followed.
What is a sprint and why is it needed
ProductOwner formulated its goal as a kind of point B, which needs to be achieved by starting at point A. But point B is not a point that can be reached by simply drawing a straight line between it and point A. Actually point B is a neighborhood points, and its radius can vary.
To get to this neighborhood, it is best to develop software in short steps (more precisely, races): sprints. At the end of the sprint, everyone evaluates what happens and corrects the direction of movement. ProductOwner is always aware of the fact that his ideas are correctly understood (and if not, this can be corrected in the next sprint), and calm. The team knows what it does, and is satisfied with its work.
How is the list of tasks for the sprint
In team sprint lasts 2 weeks. For a week, nothing has time, for a month, everything is forgotten. Therefore, 2 weeks for us is the best option. The first day of the sprint goes to planning. In the early stages, planning took even 2 days. Planning is the process by which a team takes the highest priority from the list of requirements and breaks it down into tasks that allow to achieve results. Each task is estimated in hours. It is desirable that the task does not take more than 4 hours. If a team member says that he will do the task in 5 days, then he has no idea what needs to be done.
The total number of hours in the sprint for each person is calculated from the fact that the sprint lasts 2 weeks or 10 working days. It is 80 hours minus one day to plan. Total 72 hours. But this is a perfect watch. This means that a person is not distracted by anything, does not eat, does not drink, does not get up from his seat, but only works and does not get tired. During planning, the task is evaluated in ideal hours. But not 72 hours is recruited for a person, but 72 hours multiplied by a certain coefficient, which is called the team performance. Usually it is 0.5. Surprisingly, this is some kind of magic number, it is with him that the whole sprint surrenders successfully. Someone from the greats said: “Take the time that the developer called you, multiply it by two and add a little more and get the time for which the programmer will give you the result”. And indeed it is.
In Scrum, there are several recommendations for how the executor evaluates the time for a task. For example, play poker. But we do not sin it. Whatever they say, but if someone started to do some module alone, then he will continue to build it up from sprint to sprint. And only he can estimate how much time he needs to complete the task. The only ones who can prevent him from inflating the time limit are his conscience (remember about self-organization) and ScrumMaster.
How to verify that the ProductOwner requirement is met
There is a list of requirements. But how to check whether this requirement is achieved during development or not? To do this, you need to write tests, which will describe in detail what is considered an achievement of the requirement. Simply speaking, they describe what button to press, and what happens. The team tests write analysts. And these tests should be ready by the time of the start of the next sprint. In our team, analysts and designers work ahead of the development team by 1 sprint.
The main requirement - the tests should be very detailed.
What happens during the sprint
The sprint process begins. His main goal is to ensure that tests for requirements are met by the end of the sprint.
For cohesive movement of the team to the goal Scrum offers to do daily rallies. A rally is when everyone, standing at the blackboard with a marker, deletes what he did yesterday and writes what he is going to do today.
This is a very powerful practice. Thanks to her, everyone knows where the project is going as a whole. In addition, when a person tells what he will do today, he automatically coordinates his actions with other participants. Other participants can immediately offer the best solutions to the problem. And also the task written on the blackboard, and in fact - this is a promise to all its colleagues, very well motivates the performer himself. The only thing ScrumMaster should not forget to announce that the rally began.
Rallies to be held preferably standing and lasting no more than 15 minutes. We start rallies at 9 am.
What happens at the end of the sprint
The long-awaited end of the sprint comes, usually it is Friday at 16:00, and the team gives up the sprint to the Product Owner and everyone who is interested in the product. Everyone reports on the tasks that he performed and talks about what progress he has achieved, and also explains the reasons for which he failed to achieve the goal. The main rule - never postpone the sprint deadline.
Sometimes after the delivery of the sprint, an analysis is made of why something is happening or not happening, and what needs to be done to remedy the situation.
And on Monday, everything repeats again.
Accumulated experience
We have developed several rules for ourselves, the failure to comply with which led to the failure of the sprint:
• Sprint should be planned in detail, not sparing it forces. If any of the requirements is incomprehensible, then it is necessary to clarify the requirement. If this cannot be done, then there is no need to take the task into the sprint, and send the request for revision.
• Do not, under any circumstances, take on additional tasks that go beyond the sprint. And if they still “imposed”, then coordinate with the Product Owner, that other tasks will be removed from the sprint.
• The number of people in a team should not exceed 5-6 people. When our team grew to 16 people, the rally began to drag on for 2 hours. They entered a fixed performance time for each and stood with a stopwatch. But then the man did not have time to convey his idea, and the rally turned into a formality. Therefore, we are simply divided. First, they were divided into customers and nuclear specialists, and then they began to share according to tasks. Those. Each team makes its own feature, and in this subcommand there are both clients and nuclear specialists. This approach is still used, and for us it is most effective.
Conclusion
Scrum can be a good starting point to start moving. In the course of work, some rules may evolve or fall off as superfluous. This will already be decided by the team, relationships in the team and life itself. But the rules that are formed on the basis of Scrum, will serve as a good springboard for the team to achieve the desired result.
Who are we?
The team I work for is called Unicloud Labs. This is a friendly team of interesting people who really care about their work.
Varikov Andrey VAndrey
Technical Director of Unicloud Labs LLC
If we are interested in what we do - Welcome
Source: https://habr.com/ru/post/167059/
All Articles