Now agile development is getting more and more popular, everyone is talking about agile, everyone is learning Scrum and XP...
In order not to lag behind others, I also started to learn Scrum. Today, I mainly use my own understanding of the relevant materials I read recently, and use my own words to describe the various links in Scrum. There are two main purposes, one is to carry out knowledge. To sum up, the other is that the way of telling many learning materials on the Internet makes it difficult for beginners to understand; so I decided to write a blog post about literacy, and at the same time, I tried to share with friends in the park, hoping to help beginners helpful.
What is agile development?
Agile development is a human-centered, iterative, step-by-step development method.
How to understand it? First of all, we must understand that it is not a technology, it is a development method, that is, a software development process, it will guide us to complete the development of the project step by step with the specified links; The driving core is people; it adopts iterative development;
Why is it said to be human-centered?
Most of us have learned the waterfall development model, it is document driven, why? Because in the entire development process of waterfall, a large number of documents need to be written. After the requirement document is written, developers develop according to the document, and everything is based on the document; while agile development only writes the necessary documents, or Write as few documents as possible. Agile development focuses on face-to-face communication between people, so it emphasizes people as the core.
What is iteration?
Iteration refers to decomposing a complex development task with a long development cycle into many tasks that can be completed in small cycles. Such a cycle is an iterative process; at the same time, each iteration can produce or develop a deliverable software. product.
About Scrum and XP
As mentioned earlier, agile is a guiding ideology or development method, but it does not clearly tell us what process to use for development, and Scrum and XP are the specific methods of agile development. You can use Scrum or XP. The difference between Scrum and XP is that Scrum focuses on process, while XP focuses on practice, but in practice, the two are applied together, and here I mainly talk about Scrum.
What is Scrum?
The English meaning of Scrum is a professional term in football, which means the action of "fighting the ball"; name a development process Scrum, I think you can imagine that when your development team is developing a project, everyone is like Scrum. It's going to be exciting to play football as fast as you can, with a lot of fighting spirit, and everyone vying to get it done.
And Scrum is such a development process, using this process, you can see the efficient work of your team.
[Three roles in the Scrum development process]
Product Owner
It is mainly responsible for determining the functions of the product and meeting the required standards, specifying the release date of the software and the content of delivery, and has the power to accept or reject the work results of the development team.
Process Manager (Scrum Master)
Mainly responsible for the smooth implementation and progress of the entire Scrum process in the project, as well as clearing the communication barriers between customers and development work, so that customers can directly drive development.
Development Team (Scrum Team)
Mainly responsible for the development of software products under the Scrum specified process, the number of people is controlled at about 5~10 people, each member may be responsible for different technical aspects, but each member must have strong self-management ability, and at the same time have certain Ability to express; members can work in any way, as long as they can achieve the goals of the Sprint.
Scrum Flowchart
//------------------------
Next, we start to talk about the specific implementation process, but before speaking, I have to explain an English word.
What is a Sprint?
Sprint means a short-distance race, which refers to an iteration, and the cycle of an iteration is 1 month (that is, 4 weeks), that is, we need to complete the development content of an iteration as quickly as possible. , this process we call it Sprint.
How to do Scrum development?
1. We first need to determine a Product Backlog (a list of product requirements in priority order), which is the responsibility of the Product Owner;
2. The Scrum Team estimates and arranges the workload according to the Product Backlog list;
3. With the Product Backlog list, we need to select a Story as the goal of this iteration through the Sprint Planning Meeting. The time period for this goal is 1 to 4 weeks, and then carry out this Story. Refinement to form a Sprint Backlog;
4. The Sprint Backlog is completed by the Scrum Team, and each member is further refined into smaller tasks according to the Sprint Backlog (the workload of each task can be completed within 2 days);
5. During the Sprint Backlog selected at the Scrum Team completion planning meeting, a Daily Scrum Meeting (daily standing meeting) is required. Each meeting is controlled for about 15 minutes. Everyone must speak and face all members. Report what you accomplished yesterday, and promise to all the members what you will accomplish today, and you can also ask questions that cannot be solved. After everyone answers, they have to go to the blackboard to update their Sprint burn down (Sprint burn down) picture);
6. To achieve daily integration, that is, to have a version that can be successfully compiled and demonstrated every day; many people may not have used automated daily integration, in fact, TFS has this function, it can support every time When a member performs the check-in operation, the latest version is automatically obtained on the server, and then compiled in the server. If it passes, the unit test code will be executed immediately. If all pass, the version will be released. At this time, a formal check-in is performed. The input operation is saved to TFS. If there is any failure in the middle, the project manager will be notified by email;
7. When a Story is completed, that is, the Sprint Backlog is completed, which means that a Sprint is completed. At this time, we have to conduct a Srpint Review Meeting (demonstration meeting), also known as a review meeting. Both the product owner and the customer must participate ( It is best that the boss of the company also participates), and each member of the Scrum Team must demonstrate to them the software product they have completed (this meeting is very important and must not be cancelled);
8. The last is the Sprint Retrospective Meeting (retrospective meeting), also known as the summary meeting, which takes turns to speak. Everyone has to speak, summarize and discuss the improvements, and put them into the product requirements of the next round of Sprint;
Here are some scene diagrams of the development process using Scrum:
The image above is an example of a Product Backlog.
The above picture is a daily stand-up meeting. Participants can stand in any posture. The task board must be visible to everyone. When everyone finishes speaking, they must go to the task board to update their burndown chart.
The task viewing version includes the status of unfinished, in-progress, and completed work. Suppose you have completed an unfinished job today, then you should paste the small card from the unfinished area to the completed area.
Everyone's work progress and completion status are open to the public. If a person's work tasks are placed in a certain position for several days, everyone can find out what is wrong with his work progress (the number of members is preferably 5~7 so that each person can use a special color label, and at a glance from the task board, you can see who is progressing fast and who is slow.)
The picture above is not a playing card, it is a planning card, and its role is to prevent the project from being led by someone during the development process.
How is it used? For example, it takes 5 hours for programmer A to develop a function, and programmer B thinks that it only takes half an hour, then they each take the corresponding cards, hide them in their hands, and finally showdown. If the time gap is large, then A and B can discuss AWhy 5 hours...
The 4 Statement Manifesto of Agile Development
Individuals and interactions over processes and tools
Working software is better than comprehensive documentation
Customer collaboration trumps contract negotiation
Responding to change is better than following a plan
Lesson 1: The entire team must understand the purpose and limitations of Scrum.
If the management team sees Scrum as a new management process, this understanding is absolutely wrong and harmful. To properly understand the principles of Scrum implementation, you need to start with an understanding of what it was designed for.
- Adapt to change. A fundamental assumption of Scrum is that external requirements are vague and difficult to understand. Scrum's philosophy on this is: let the customer see the semi-finished product directly, so they know what they want. Many Scrum principles revolve around how to solve this problem: for example, at the end of each Sprint, the Product Owner presents it to the customer, and for example, task refinement generally does not exceed one Sprint. Understand this and understand why Scrum always seems to be changing, because requirements are always changing.
- Iterate quickly. Another fundamental assumption of Scrum is that teams live in a rapidly changing and competitive world. If we can release a new version in a year and a half, and a competitor can release it in half a year, within a few years, we will be left behind by our competitors. Scrum's philosophy for this is that releases are Milestones, and it's better to release 20 features five times at a time than to have five Milestones in-house and release a hundred features in one go. Understand this and understand why Scrum considers release-time hacking to be the norm rather than a failure.
To implement Scrum, the entire team must at least reach a consensus that the above two points are not negotiable. Processes must serve a purpose. If the team believes that increased upfront communication is the best way to clarify requirements, or believes that the feature release must be a one-off in large batches, then use the waterfall development model.
Accordingly, we must understand what Scrum cannot do. My understanding may be sensational, but there are still two points:- Because the release cycle is shortened, the team has no ability to guarantee that every decision made is correct, and a lot of overhead must be spent on trial and error;
- Rapid release actually makes the Scrum team less risk-resistant than the waterfall model team, because one person's departure or sick leave may affect the progress of a single function, which is not conducive to frequent short-term releases.
Scrum's answer to this is: don't try not to make mistakes, but make sure that small mistakes are caught as quickly as possible so they don't turn into big ones. Therefore, there is always some uncertainty in the Scrum process, or the functions are reworked because they do not meet the requirements, or some individual functions must be delayed due to a sudden lack of manpower. If you have to pre-determine the release cycle and ensure that no feature clipping is allowed, go out and turn left to find CMM certification: it can pinpoint the task to what font to use on each dialog box. The preliminary plan is accurate to this granularity, and everything can be controlled. But the problem is, we have to trade in a longer release cycle.
Understand the above, we will not be too entangled in some formal things when implementing, such as Burn down chart, such as Scrum Poker. Need to know that the form serves the purpose, and the form does not necessarily apply to every team, just as the waterfall model is different in every team. It would be foolish to assume it's not Scrum just because team members didn't play poker at the planning meeting. Conversely, some seemingly annoying "processes" are indispensable, such as a 15-minute stand-up a day, and if we understand its important role in communication, we definitely don't think it can be omitted.
As a practical example, in our team we force a Sprint a week. As far as I know, even in many successful projects, this approach is quite aggressive. I didn't understand this at first, but after implementing it for a while, I started to agree because the one-week release cycle gave us no chance to push things back, forcing us to move away from the waterfall model as quickly as possible. This is very important for a team with a long tradition of waterfall development, but not necessarily for others.
Lesson 2: Correctly position the Scrum Master in the team.
Why mention the Scrum Master separately? If it's just reading books and attending training, I believe most people will agree with me that the Scrum Master is probably the most unclear role in the entire development process: not involved in requirements analysis, not involved in code development, or even involved in any personnel issues , with only the vague expression of "removing obstacles". However, when I actually became the Scrum Master, I realized that the responsibilities of this role are very specific. for example:
- Make sure the process is executed correctly. After entering Scrum, many teams still take the old road in various ways, such as lengthening the Sprint cycle intentionally or unintentionally, and distinguishing the planning week, development week and testing week by this, which is actually changing the original three-month waterfall development cycle into a It has become a waterfall cycle of two to four weeks; another example is the reduction of automatic test development tasks to manual testing on the grounds of limited development time. A good Scrum Master should have the ability to detect and prevent this. - By the way, trust me, don't think a two-week waterfall cycle is a viable development plan, and we won't be able to complete the testing task.
- Stop bureaucratic processes. A typical example is one after another of spec/plan review and sign-off emails; another example is to distinguish the so-called Unit Test, BVT and Functional Test: perhaps for a graphical interface program, the two are very different, but for a function Libraries have little or no principle difference. A qualified Scrum Master should stop this tendency. ——But I also have to say that this one I am doing very poorly now and needs to be improved.
- Build cross-knowledge structures. The knowledge model of the entire team should have their own expertise but intersect with each other, and a very important problem in traditional development is the imbalance of knowledge structure, such as testing only testing, development only development. This model may be acceptable for large teams with long release times, but it is fatal for small teams that are short on staff and require rapid releases. A good Scrum Master should be able to influence the team's decisions, ensuring that a task doesn't get bogged down in a "only one person knows the details" situation. - This is often the biggest obstacle in teams that are used to the traditional waterfall development model and needs time to improve.
But because of the above understanding, I basically disagree with most of the statements about the Scrum Master in the Scrum Alliance textbook. First of all, the Scrum Master must undertake part of the development tasks, because it is difficult to imagine that the Scrum Master will really understand the "pain points" of the team without being involved in the front-line development. Secondly, the Scrum Master needs to pay attention to everyone in the team, otherwise the team may hide some problems due to the so-called "self-organization" principle, for example, a person is too specialized in a certain item and neglects to communicate with other members. Of course, there are also departments where the Scrum Master is only responsible for writing reports and pushing things. This is not the practice of any Scrum Master I have worked with, and I can confidently say that such a Scrum Master will not survive in our company.
Scrum Master, you are a person with a human mission! Um! (make a fist)
Finally, post two words I just learned recently:
- 50% percent of our decisions are wrong. Fail fast, learn fast.
- No matter what you want to do, choose what is good for your team.
First of all, let me state that the guy who said the above two sentences is not very popular in our team, but I like these two sentences very much. In my eyes, these two sentences point to all the essence of Scrum.
-----------------------------------------------------------------------------------------------
Our company's development team, the effect of practicing Scrum is very good. Before the project started, we did a Scrum popularization internally, which was very suitable for this problem. I made a slight modification and posted it here, which will definitely help everyone.
1. Role assignment and values
Let's take a look first, the role assignment of a team practicing Scrum▼
The role structure in Scrum is very flat and there are three roles:
1. PO: Product Owner, the person in charge of the product, determines "what everyone is going to do". The PO of an Internet company is generally held by the relevant product manager; if it is a project for a customer, the PO is generally the person in charge of the customer.
2. Scrum Master: The promoter of Scrum, the person who controls the big rhythm.
3. Team: Generally composed of multiple developers, the main force of development.
The three roles have their own responsibilities, but there is no boss-subordinate relationship among the three. This is exactly what differentiates Scrum from traditional development processes:
1. The traditional development process is a centralized system that is decided by leaders;
2. Scurm is a democratic system where everyone is equal. Everyone's abilities are trusted, and they are more autonomous and more efficient.
Scrum's values▼
Second, the three major artifacts
Production Backlog, Sprint Backlog and Burndown Chart are the three artifacts. Introduce them one by one below.
