Agile Software Development Model-Scrum

Agile Software Development Model-Scrum 1. What is scrum?

Scrum (British rugby competition Team) software development model is a kind of agile development, which has gradually become popular in the past one or two years.

The basic assumption of scrum is:

Developing software is like developing new products. It is impossible to define the final procedure of software products from the very beginning. R & D, creativity, and attempt errors are required in the process, therefore, there is no fixed process to ensure project success. Scrum compares the software development team to an olive team, has a clear highest goal, is familiar with the best model and technology required in the development process, has a high degree of autonomy, and closely communicates and cooperates, resolve various challenges with high elasticity and ensure that every day and every stage is clearly oriented towards the goal.

The SCRUM development process usually takes 30 days (or a shorter period of time) as a stage, starting with the requirement specifications of new products provided by the customer, the development team and the customer select the completed specification at the beginning of each stage. The development team must try its best to deliver the results 30 days later. The team will have a 15-minute meeting every day to check the progress and plan of each member, understand the difficulties encountered and try to eliminate them.

2. Advantages of scrum over traditional development models

A notable feature of the scrum model is its ability to respond to changes as quickly as possible. The following figure uses a traditional software development model (waterfall model, spiral model, or iterative model ). As the complexity of system factors (internal and external factors) increases, the possibility of project success rapidly decreases.

It is a comparison between the scrum model and the traditional model:

Three scrum Models

1) several terms about scrum

Backlog: all tasks that can be predicted, including functional and non-functional tasks.

Sprint: The time cycle of a down generation development. Generally, a maximum of 30 days is used as a cycle. during this period, the development team needs to complete a developed backlog, and the final result is an incremental and deliverable product.

Sprint backlog: the task to be completed within a sprint cycle.

Scrummaster: A team member responsible for supervising the entire scrum process and revising the plan.

Time-box: A meeting time period. For example, the time-box of each daily scrum meeting is 15 minutes.

Sprint Planning Meeting: This is done before each sprint is started. Generally, it is a day (8 hours ). The task required for this meeting is: the product owner and team members break down the backlog into small functional modules and decide how many small functional modules need to be completed in the upcoming sprint, determine the task priority of this product backlog. In addition, the Meeting also needs to discuss in detail how to complete these small functional modules as needed. The workload of these modules is calculated by hour.

Daily scrum meeting: a member of the development team, usually 15 minutes. Each developer needs to report three projects to scrummaster: what has been done today? Have you encountered any obstacles? What will we do soon? Through this meeting, the team members can understand the project progress.

Sprint Review Meeting: after each sprint ends, this team will present the Sprint's work results to the product owner and other related personnel. Generally, this meeting is 4 hours.

Sprint detail spective meeting: Summarize the final sprint. Participants of the meeting are internal personnel developed by the team. Generally, this meeting is three hours.

Ii) implementation of scrum

1) the product's backlog is divided into sprint backlog, which can be completed according to the current human and material resources.
2) Hold the sprint planning meeting, divide the tasks to be completed in the sprint, mark the priority of the tasks and assign them to each member. Note that the task here is calculated by hour instead of by day.
3) In the sprint development cycle, daily scrum meeting needs to be held every day.
4) when the entire sprint cycle ends, the sprint review meeting will be held to present the results to the product owner.
5) The team members finally hold the sprint into spective meeting to summarize the problems and experiences.
6) perform the next sprint following the same steps.

The entire process is shown in:

Nine common misunderstandings in Agile Development

Agility is not a process, but a general term of a kind of process. It has a common feature that conforms to agile values and follows agile principles.

Agile values are as follows:

Individuals and interactions are better than processes and tools

Software that can work is better than comprehensive documents

Customer cooperation is better than contract negotiation

Responding to changes is better than following the plan

12 agile principles derived from values:

1. Our top priority is to satisfy our customers by delivering valuable software as soon as possible and continuously.
2. Even after development, you are welcome to change your requirements. Agile processes use changes to create competitive advantages for customers.
3. Deliver the software that can work on a regular basis. The delivery interval can be from several weeks to several months. The shorter the delivery interval, the better.
4. During the entire project development period, business personnel and developers must work together every day.
5. Build projects around motivated individuals. Provide them with the required environment and support, and trust them to complete their work.
6. In the team, the most effective and efficient way to transmit information is face-to-face conversations.
7. Working software is the primary progress measurement standard.
8. The agile process advocates sustainable development speed. Owners, developers, and users should be able to maintain a long-term and constant development speed.
9. Constantly paying attention to excellent skills and good design will enhance agility.
10. Simplicity-the art that maximizes unfinished work-is fundamental.
11. The best architecture, requirements, and design come from self-organizing teams.
12. at regular intervals, the team will reflect on how to work more effectively and adjust their behaviors accordingly.

The Agile Methods created by 17 masters who established the agile Alliance include extreme programming, scrum, feature-driven development, dynamic system development, adaptive software development, crystal method, and practical programming method. These methods are collectively referred to as agile methods.

In fact, everyone can start from agile declarations and principles, identify problems, find some solutions, and form their own processes. I think the software environment in China is so complicated and the autonomy of programmers is so strong. agile methods should be first proposed in China, only people in China have a standard-only, normative, and Supreme psychological mindset. Even if they find a good solution, they feel that they are not standardized. They have not formed a theory in depth and cannot improve their height. They have always followed the devil's ass, I think this is also one of the immature performances of the foreign software industry!

2. agility is just a Software Process

If you only understand agile implementation from the perspective of the software process, the effect will not be very good. Compared with the previous software engineering, agility is the biggest innovation in improving the role of people to process first, as stated in the first article "individuals and interactions win over processes and tools" in the agile declaration.

People-related problems are no longer covered by the process. They are now at the level of enterprise management, including corporate values and culture. This is also the biggest obstacle for agile implementation in China:

1. Think of the customer as a partner rather than an opponent, think about the problem from the customer's perspective, and fully communicate with the customer, rather than shirking responsibility for the problem. The goal is to let the software realize the value of the customer, rather than simply making money.
2. mobilize people's initiative to give motivation rather than pressure.
3. Be practical, not standardized. Let developers understand and implement, experience the benefits of agility, rather than blindly and mechanically implementing specifications.

There is no absolute authority, and everyone has merits.

3. iteration is agile, and up is agile.

Seeing that so many people put up into agility, I began to wonder if I was wrong. But in my impression:

Up is a heavy process. Although iteration is introduced, its principles and values are different from those of agile. Agile focuses on feedback, the iteration cycle is as short as possible, and the customer's participation is important. Through the customer's participation, continuous feedback is obtained and adjustments are made to keep the entire project in the correct direction. At the same time, it also gives the customer a chance to feel and think about it, because for most customers, the goal is clear (not to rule out that some customers are not clear), but how to do it, I didn't have any idea at the beginning. I only knew it when I saw specific things. "Oh, we could have done this. I want to adjust it here ".

4. agility is completely revolutionary

Agility, especially XP, makes people feel refreshed. I feel that all the previous software engineering theories and design methods can be abandoned, overturned, and started from scratch. With this kind of idea, it is wrong to implement agility. agility is not "a sun dasheng exists in the Stone", and the previous software process also has the shadows of agility, it just does not rise to the heights of values and principles like agility, such as rapid prototyping. Agility is the improvement of existing software process methods. It discards the inefficient appearance of traditional software engineering. In the past, many skills were very practical in the software process. Agile implementation should be based on existing software processes, starting from agile declarations and principles, and using agile methods to improve the process.

5. agility is anti-document

The document is just a means to achieve the goal. If this means is inefficient, it is a different means. But I completely abandoned the document. How can I solve the communication problem? Isn't it even more inefficient to say that every communication is completely done by hand, and to say that you are repeating the same idea with different people.

It should be clear that the essence of the document is to make knowledge explicit. There is a lot of knowledge to be communicated in a project. There are two types of knowledge: explicit and implicit. The traditional concept is to make tacit knowledge explicit, that is, to document, as much as possible, the cost is ignored (especially the cost of updating synchronization documents ).

Therefore, when implementing agility, You need to specify the knowledge that must be explicit in the team, which can be communicated through documents. Which of the following knowledge can be implicitly used to achieve optimal communication efficiency.

The document is not the purpose, but effective communication is the purpose.

6. agile for agility

"Well, we can be agile if we are so agile." Many people may have this idea. I forgot where I used to see my master's interview records:

Q: "Our current process is very good. I don't know how to use agile improvement ?"

A: "Since it is good, don't use agility ".

You must have a clear goal in everything you do. Although agile is good, it depends on whether you need it or not. Can you solve your current headache? If not, don't bother yourself.

7. agility is the antonym of CMM

In some discussions, many people regard CMM as the antonym of agility. I think this is not very suitable. CMM is only a standard for measuring software maturity, not a process, and agile is not a concept. If I want to find an antonym for agility, I think traditional waterfall development should be more appropriate.

In addition, I believe that if CMM continues to become popular, companies should be able to pass CMM certification through agile improvement processes.

8. agility is free and unrestricted

Agility emphasizes self-organizing teams, giving full play to people's initiative and replacing stress with motivation. This gives people the illusion of absolute freedom. However, it should be clear that everyone should pay attention to a balance, and both sides of the person. The negative side and the positive side coexist at the same time. Absolute freedom will indulge the negative side of the person. Agility is not absolutely free and unrestricted. As a manager, it has a responsibility to guide team members to suppress the negative side with their own positive side and not to allow free-riding in the team; otherwise, the overall morale of the team will be compromised. If it is ineffective, you can only exclude it from the team. Is this punishment binding?

9. Redo is refactoring.

Redo is not equal to refactoring. In many cases, these two concepts are mixed. However, in agility, a feature of refactoring must be controllable. When a large adjustment is made to the system structure, the controllability will be poor without the help of the test driver. This cannot be called refactoring.