Introduction to Software Engineering: A summary of the scrum development framework

As the saying goes, the code of his own writing, 6 months later also is someone else's code ... Review ! Review! Review! The knowledge points involved are as follows:

• Software Engineering Concepts
• Agile development Process Scrum

First, what is software engineering? Please describe it in a sentence.

Software Engineering is a research discipline: it uses an engineering approach (contacting Building engineering ...). )to build and maintain effective, practical, and high-quality software. To put it simply, software engineering has three elements: Process + method + tool, and the software project is the goal , the process is the step , the method and the tool is auxiliary.

Second, then, what is the software process?

Software Process: First of all it is a framework or step, it is a framework for the task required to build high-quality software, that is, a series of steps to form a software product, including intermediate products, resources, roles and processes in the process of the use of methods, tools and other categories.

Iii. What are the common software development processes (development frameworks)? Choose one to do a brief introduction.

1, Waterfall Model: the development process is through the design of a series of stages in the sequence of Waterfall, the process is as follows: What to do first, then see what the user needs, analysis needs after a simple demo (drawing a prototype, sketches, etc.), Then the architecture analysis and design, summed up the design document, then discuss the detailed development details, then the implementation, the final test ...

　　Benefits of the Waterfall model:
– Provides a stage-by-phase checkpoint for the project
– After the current phase is complete, you only need to focus on the next stage
　　Waterfall models have the following drawbacks:

– Very few feedback between stages
– results can only be seen later in the project life cycle
– Track individual project stages with too many mandatory finish dates and milestones
– not adaptable to changes in user requirements

2. Scrum agile approach, scrum is an iterative incremental software development process, often used for agile software development. Scrum in English means a game of football, scrum is developed for managing software development projects, and it can also be used to run software maintenance teams or as a plan management approach.

3, Iconix process, including vision analysis, business modeling, demand analysis, robustness analysis, key design, final design, implementation ...

Iv. What is the agile development process?

　　Agile Development is a human-centered, iterative, progressive development approach. To be more flexible! People-oriented needs as the core! is a gradual adaptation of the process! Agility is an idea ! Agile and Waterfall model comparisons:

So is agile a panacea? No other process is bad? No, we must clarify a few misunderstandings, the misunderstanding of agile development: agile is good, but other methods are not useless. Common software development models that follow agile processes are SCRUM,XP (Extreme programming) ... One of the more popular is scrum.

V. The concept of Scrum

Scrum is a framework, as its name implies, that scrum is a football player with a ball, the meaning of the ball, and the ball need to plan! On the court, at the beginning of each stage of the game, both sides have to lay out, the coach and the captain can refer to the plan. And in the software development company. At the beginning of each iteration of the agile approach, the team leader should plan for this iteration, especially the prioritization of requirements items, the selection of the work of this iteration, the setting of what must be done, and so on. And with the ball has to be flexible strain! On the pitch, the whistle sounded, despite the team's efforts to advance according to the plan, but the field of the instantaneous million, the players can not be in real time in accordance with the instructions of the coach to follow suit, but rely on the quality of training in the form of the attainment of the goal, in the software development company, after each iteration began, the team leader can Instead, it is up to the person who executes it to choose how to do it. Team leaders should do well to coordinate resources, solve difficulties and provide guidance to achieve their goals.

1. The role of Agile development

Product Owner PO, responsible for product requirements refinement, entry, priority ranking, PO directly and the user and other related people interaction. Scrum process manager, Scrum Master, is responsible for maintaining the order of the scrum methodology and for coordinating the resolution of non-technical issues. Finally, team teams, self-organized and relatively flat management method for the project development work.

Scrum Team structure:

Noun Explanation: Each iteration of the sprint cycle process is called Sprint, which runs through a lot of activities ...

Sprint Planning Meeting: Each iteration is preceded by a sufficient time (4-8 hours or ...). ), Po,sm,team ... All take part in PO from the backlog of product list to find high priority tasks, and the team to discuss how many functions need to complete, PO function decomposition into a small function module, and team to discuss in detail how to complete ... Estimated time.

Backlog (backlog of pending transactions): The Product backlog includes all the content that needs to be delivered, the content is ordered according to the order of the business's demand value, and the growth or decrease of the demand change is more dynamic. The backlog for a given product is the product of an iteration that defines how much work the team accepts, the entire sprint, and the sprint backlog, which covers the final version of the backlog, and the team coordinates the progress of the development. The barrier backlog lists all internal and related issues within the team and hinders project progress, and SM needs to ensure that all the backlog issues are assigned and can be resolved.

Daily Meeting: Open in the morning, the participants stand and open, 10 minutes enough, anyone can participate, SM host, but only the team can do related tasks, each team to ask three questions-what did yesterday? What are you going to do today? What problems have you encountered? Then update the burndown chart .

Sprint Review Meeting: Every sprint at the end of the session, the time normally within 2 hours of control, team show this round of the completion of the task, do not need ppt, show demo! This meeting, customer, PO, management ... Can be involved in order to let the PO determine the progress of the project development and the iteration objectives are consistent.

Sprint review session: After the sprint is over, the time is generally about 1-3 hours or so, po,sm,team to participate in the goal is to summarize, reflect on the newly accepted sprint, improve adaptability. Need to summarize and analyze the successful experience and solve the difficulties.

2, the main features of scrum: rapid development as soon as possible delivery, teamwork to adapt to change.

3, the application of scrum scenario:

• 7 people, +or-2
• smaller will be more suitable
• It's best to sit together
• Customer engagement is not high
• Fast mobile internet projects
• Self -developed products

Vi. specific processes for scrum development methodologies

1. Projects are presented (the background of the project, the project's main target, objectives-vision, business value, segments of the service object) to project owner as the main speaker, Team assist !

　　background of the project : "The Big Data era has come, data is more and more valuable, there is no data to be difficult, there are many areas of data can do a lot of things, such as internet finance." Crawling data from the Internet is an important source of data and is often an essential source. So...... To be able to bring data in a stable, efficient and real-time ... ".

　　 The main service object of the project : Differentiate Customers and users! The customer is the purchaser of the system, and the user is the person who uses it. Bot system service object: a forum-customer

　　The goal of the project (Vision ): Vision is the prospect of longing, is the hope that people continue to strive to achieve the picture! For example, the socialist successor must struggle for life to achieve communism-no class, no oppression, no poverty, no unemployment, everyone happy Communist society! Ford has a car for every family, and Microsoft has a computer for every desktop ... Therefore, it can be thought that the great vision can achieve great cause! Specific to the vision of the software, to find the vision of the software to find the project buyer-the Boss (professional terminology), first find the boss, and then get the boss to buy the system's purpose, PO to do ... We already know that software projects are designed to improve certain aspects of an organization, and that the person who buys the software is, without exception, the most spoken stakeholder in the organization. For example, the financial managers of enterprises need to improve the efficiency of financial work, the leadership of an enterprise needs to occupy the market, lead the opponent, an official needs to show achievements ... the vision of the crawler system is based on the needs of the forum, diversification, Precision rich forum content (here to learn mainly, simulation-oriented, it does not consider copyright, but the actual work must have copyright awareness! ),

　　 The business value of the project ( difficult to analyze, very important ): First answer what is business value? in layman's words, business models are the way in which projects are made to make money. to solve the problem that others are willing to pay for is business value. PO Host Mining Business value, if not dug out ... All right, give up the project!

　　Service Object Segmentation : That is, user Role Modeling , Good user modeling, can ensure that different users can easily access its functions, using the product is also easier to obtain its specific value, usually hosted by project owner, Brainstorm with the power of the team!

• Which users may come to use the product (or visit the website)
• What problems they come up with, or for what purpose

user-Modeled steps, four- step

• List the users as many as possible
• Identify key users--buying decision makers, key consumers
• Categorize, merge secondary users
• Add virtual and extreme users, virtual users--representatives of hypothetical user roles. Mario, for example, is responsible for recruiting jobs at Speedynetworks's HR department, a high-end network component manufacturer. He has been working in the company for 6 years. Mario has a flexible schedule that he works from home every Friday. Mario is very good at computers, and he feels that he is almost a super user for the software products he uses. Mario's wife, Kim, is studying for a PhD at Stanford University's Department of Chemistry. Since Speedynetworks is almost always expanding, Mario is always looking for good engineers. " Extreme users – it's likely that you can write stories that might otherwise be missed."

　　2, the Product Function list definition, the so-called product function list is a demand, or characteristics of the list-the product backlog is the core of scrum, is the origin of all, according to the level of importance of the order , which contains the customer wants things , Described using the terms of the user's customer . The product feature List is primarily written by the products owner, and the team has rights, but ultimately the PO makes a choice.

What is the form of a product feature List-user stories in Stroy form! Because it is difficult to fully describe the needs of our projects in the product definition phase, we need a way to explore the needs-user stories.　　The traditional requirement specification is the result of this phase . PS: Product Feature List format

ID (uniform identifier)	Name (title) – short, descriptive story name	Story (stories) – Story content description	Priority (importance) – Product owner A value that indicates how important this story is	Initial estimate (initial estimate) – Initial estimate of the team, indicating the amount of work required to complete the story compared to other stories	How to Demo (What to Do) – it roughly describes how this story should be demonstrated on a sprint demo	Notes – related information, explanatory notes and references to other materials, etc.

Extra fields (not required)

Track (category) – The approximate classification of the current story
components (component) – typically implemented in an Excel document with a "check box"
Requestor (requestor) – The requester of this requirement
• Bug Tracking ID (bug Tracking ID) – Direct link between story and bug

　　So what's the user story?
User stories are an agile demand-mining approach that focuses not on writing requirements, but on the need to discuss them . The basic narrative format is: "As a ..., can ...", so that ... "." The style and ideas written by the user needs, is the user story. as a webmaster, I hope that through the XX crawler system to crawl XX data, so that my site users can easily get some information , as an online shopping mall buyers, I hope that through the QQ number can log into the mall, in order to buy things ...

　　User Stories Three elements: role, function, customer value , role derived from the results of user role Modeling! function Use subject-predicate narrative principle, verb-phrase principle. For example, for displaying XX data: As a system administrator, I want to display XXX data so that VIP users ... Note: The roles and functions are subject-predicate relationships, and the function itself is a verb-object phrase. We generally write the title of the user story in the form of a function. About customer value, seemingly simple, in fact, it is difficult to write, we first experience; " as a netizen, I hope to have a quick notice to remind me that I have a new news update, so as to save me the time to browse the website for news, so I have more time to do other things." "," as a webmaster, I hope that the crawler system can be effective, fast crawl XXX data, and some column analysis ... To make it easier for me to get xxx information. "

　　User stories are also used to be sold, and the story of not seeing the value is not a user story.

Let the story stay on the business level, Avoid technical stories, Eg: To add an index to the XXXX table, what is its real goal? Of course, to improve the responsiveness of the search for event forms in the backend system, the initial technical description will only exist as an annotation ("adding an index to the event table may solve the problem")

　　The rules of good stories

• Independent (independ) to avoid inter-story interdependence.

– Users can recharge with a visa credit card.
– Users can recharge with a MasterCard credit card.
– The user can recharge with an American Express card.
Thinking: How to eliminate dependency?

Merging stories-users can recharge with credit cards.

Split the story with different dimensions! -Users can recharge with one credit card, and users can recharge with two other credit cards.

• Can be discussed (Negotiable) do not include too much detail

• Value to the user or customer (valuable)
• Estimates (estimatable) generally have the following 3 reasons to cause unpredictable stories

– The developer lacks domain knowledge.
– Lack of technical knowledge from developers.
– The story is too big.
Solution Solutions
–po Lectures/discussions with customers.
– Break down into smaller stories

• Small (Small) just fine, such as: Users can complete a shopping-the big story is not good!

• testable (testable) stories must be testable. Successful testing can prove that the developer has correctly implemented the story. In general, non-testable stories occur on a number of less functional requirements that are related to the software but are not directly related to functionality.

– The user must feel the software is very useful.
– The user never takes a long time to wait for the window to appear. In the case of 95%, the new window will open within 2 seconds.

　　Benefits of User Stories
• User stories emphasize conversational communication rather than written communication.
• User stories can be understood by both PO and developer.
• The size of the user story is suitable for planning.
• User stories for iterative development.

　　3. Product release and Iteration cycle: two common ways

Each iteration releases, mobile internet projects, self-developed products ...

Multiple iteration releases, traditional projects, large projects

　　As mentioned earlier, the Sprint planning meeting will be scheduled before the iteration, but before the sprint planning meeting:

• Ensure the product backlog is orderly, the product backlog must exist, there can only be a product backlog and a product owner, important backlog items have been assessed in terms of importance, PO should understand the meaning of each story!

• Determine the Sprint Schedule meeting schedule
  -13:00–17:00 (10 minutes rest per hour)
  -13:00–13:30. The product owner provides a general overview of the sprint goals and summarizes the product backlog. Time and place to set a presentation
  -13:30–15:00. The team estimates the time and, if necessary, splits the backlog entries. The product owner modifies the importance score when necessary.
  -15:00–16:00. The team chooses the story to be put into the sprint
  -16:00–17:00. Schedule a fixed time and place for daily scrum meetings

• The meeting is attended by product owner, Scrum Master, Scrum team, and the products owner must attend

• ensure quality is not compromised: External Quality is what the system user can perceive. The slow, confusing user interface is inferior in quality, and internal quality generally refers to features that the user does not see, and they have a deep impact on the maintainability of the system. Maintainability includes system design consistency, test coverage, code readability and refactoring, and more.

In a sprint planning meeting

　　

• The goal and length of the sprint is determined by the half-dead target.
• Story telling: Storytelling is about defining the story, deciding which stories to include in spring, using the story index card, which stories need to be copied from the backlog to the sprint, and how many stories are included in the sprint for the team to decide, Not the product owner or someone else
• Estimated time; Estimating Time is the estimation of the story, the unit of the estimate-the story point (idealized person-day), which can be used with the planning Board

Here are some of the techniques we use here:
– Instinctive response
– Yesterday's weather, yesterday's weather (yesterday's weather)--View team history

– Productivity calculations: Estimated using productivity calculations, this technique includes the following steps:

– Reference to actual productivity
– Reach the level of investment
– Yield estimated productivity
– Calculate how many stories can be added without exceeding the estimated productivity.

Actual productivity: Add up the original estimate of all stories completed in the previous sprint and get the actual productivity

"Input Level" (focus factor), the above example is based on the level of input of the team:

18/50=36%

Estimating productivity: Eg: Let's say we have 30 =30x36%=10 in the next sprint, productivity is a story point.

Some other questions: what if there is no historical data? The "default" input used in the new team is typically 70%.

What kind of estimation techniques are we using in the process? In general, we're all combined.

– Review the level of engagement and actual productivity of the last sprint
– Estimating an investment level
– A further "gut reaction" check

How does the product owner affect what stories Sprint has?
Adjust the priority level

Narrow the range

• Task decomposition;What is the difference between "task" and "story"? -- The story is something that can be delivered, the task is not to be delivered

　Spring Planning Meeting: The time and place to set a daily meeting, usually 9:00,9:30 or 10:00, must be a time that everyone can fully accept. Define "Done", the product owner and team need to have a consistent definition of "done",

　　after the sprint planning meeting: The Sprint planning meeting will produce some tangible results.

–sprint Target
– List of team members (and their level of input, if not 100%)
–sprint Backlog (the list of stories included in the sprint)
– Determine a good sprint demo date
– Identify time and place for bowl daily scrum meetings

Let others know about our sprint.
Sprint information page; sprint Target and demo date

• A list of stories that have been approved by the team to add to this sprint
Estimated value of each story in sprint
• Specify the time and place for the daily meeting to fix bowl lines
• Split the story into tasks

　　4. Scrum design process for each sprint

Bad, cause risk, product can not meet customer demand change, bug rate elevation, code quality is worrying

Good:

1. First interface prototype design, PO host, then what is the interface prototype?

Interface prototype refers to the use of tools according to customer needs and the understanding of software analysts, the brain interface quickly reflected on the media. Transform your needs into visual images and human-to-system interactions!

The benefits of interface prototyping: Prototype not only to determine demand, but also to win the hearts of customers-Alan M. Davis and Dean A. Leffingwell, author of "Fast delivery of high-quality software with demand management" (Rational software company/IBM)

The purpose of the interface prototype:
• Early verification of requirements
• Identify factors of uncertainty as early as possible
• Easy Communication
• Provides the basis for subsequent interface design

　　　　The purpose of the interface prototype is to validate the requirements without having to dwell on the details.

If the prototype is not passed, there is no need to go on,

A tool for drawing interface prototypes, white Paper, pencils, erasers, erasers + pencils + White paper, Axure, MS OFFICE, PS, Viso ... Tools are just tools, either way or tools are for our development, production process services, we can not become slaves of the tool. According to the actual and environment to choose the right tool to draw.

2, database design. Here is the main paradigm--"The three paradigms of database

• First Paradigm
– The properties in the relationship R are all inseparable items.
• Second Paradigm
– On a 1N basis, each non-primary property is fully functional dependent code.
• Third Paradigm
– On a 2N basis, each non-primary attribute is neither part dependent nor pass-through code.

From the 1 paradigm to the 2 paradigm
1n | Elimination of partial-size-of-number-of-code for non-primary attribute 2N
• Assume that the course selection relationship table is
–selectcourse (School number, name, age, course name, score, credits)
– The following determinants exist: (School number, course name) → (name, age, score, credits)
– Standardized students: Student (School number, name, age), Course: Course (course name, credits), Elective relationship: Selectcourse (student number, course name, score).

From the 2 paradigm to the 3 paradigm

2n | Elimination of non-principal attribute-to-code transfer of the number of Taipa dependent 3N
• Assume that the student table is
–student (School number, name, age, school, college location, college phone)
– Standardized students: (school number, name, age, School), College: (College, location, telephone).

Understanding of the three paradigms
– Only one value per column
– Each row can be distinguished.
– Each table does not contain non-primary key information that other tables already contain

3. System Design

　5, product implementation (monitoring process), management Sprint Backlog most effective form-hanging on the wall of the task board! Update the taskpad at the daily meeting (or before the meeting starts)

After the first daily meeting, the task Board may become

A few days later, the taskpad might turn out like this.

Also use Burndown chart (burn down chart): A visual representation of the work that needs to be done before the project is completed. Sprint Burndown Chart and Iteration Burndown chart, the Sprint Burndown chart shows the amount of work remaining in the iteration as a story point;

-y: Estimate the remaining story points
–x: Date (except non-working days)
–y/x= Productivity

Schedule rate and actual rate: monitor deviations from actual and planned rates

There is also a cumulative story point graph: Shows the total number of story points completed at the end of each iteration.

The Daily Burndown chart shows the team's progress in a given iteration, and you can use this information to determine whether the planned work can be completed at the end of the iteration.

Introduction to Software Engineering: A summary of the scrum development framework