Scrum Agile Development

Using agile to develop one months of events, the basic development model is similar to the one I encountered in this article, briefly copy here ...

Http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html
Games for code farm work: Scrum
http://mp.weixin.qq.com/s?__biz=MjM5NTIyNTUyMQ==&mid=200580964&idx=1&sn= 206ca28b5c8cd05143fe9d065e27ff73&scene=1&srcid=0127uzwburbmbjtlw31iugnu#wechat_redirect

* As the official Scrum guide says, "Scrum is easy to understand, but difficult to master";
1. Scrum is a game rule
1.1 The Chinese version of the official website <scrum Guide, on the cover of its core principles: the rules of the game.
1.2 Rules of the game: people who play games make rules for better entertainment.
Scrum rules: To make people happier, to work more effectively, rather than to constrain everyone.
1.3 In fact, scrum is just a framework,
So when practicing scrum, more rules need to be worked out by team members,
This embodies the idea of the rules of the game------------------the rules of our own rule, which will be unanimously agreed by everyone to work comfortably;
2. Scrum is experience-based
2.1 Scrum emphasizes the importance of experience, but experience needs to be constantly adjusted,
So scrum optimizes predictability by iteratively developing the incremental approach that adjusts the experience of the entire team each time.
2.2 Examples:
When we develop the ape question bank, at the end of each round of scrum, we will review the meeting to summarize the speed at which we are dealing with the backlog every day (what we call daily story points) in the wiki, as shown in.
So when we estimate whether a new round of iterative work can be completed, we can refer to the previous dozens of experience and make more rational judgments.
Daily Stories Point Chart
3. The three pillars of scrum
Transparency, inspection, adjustment
3.1 Transparency: Team members to achieve the full sharing of information in order to have the same understanding of the observed information;
3.2 View: Team members keep checking their status, like regular car inspections, to see the status of the current project.
3.3 Adjustment: Team members find that there is an incident that will affect the progress of the project, to find countermeasures in time
Group IQ is often lower than the individual IQ phenomenon, this is because the information between individuals is often inconsistent, each person's information is one-sided, so the view is a unilateral, and usually the team leader because the information received more comprehensive, so his decision-making considerations will be more thoughtful.
---but scrum also emphasizes that teams need to be "self-organizing", which requires group decision-making rather than leadership.
For better group decision-making, scrum specifically emphasizes the transparency of information so that everyone's information is fully shared,
The view is a way to ensure that information is transparent, that is, to periodically see the state of yourself and the team,
With the transparency of the information, the team members can jointly discover the problems in the project execution, and then find a solution together to achieve the "self-organizing" team.
4. Basic game rules for scrum:
Scrum defines the basic rules of the game, and on top of the rules of the game, the team can develop more detailed rules based on their own experience. But more detailed rules should not violate the underlying rules.
4.1 Role definitions
Product Owner: Product owner is the only person responsible for managing the product backlog, and is also the ultimate responsible person for the product.
In short, if the product is not finished, should buckle the wages of the product owner.
Development team: The development team is responsible for the various professionals who deliver the functionality planned in each round of scrum iterations (probably in the form of a product draft + artwork) to a product that can be released.
The various professionals here include: server-side development, JavaScript front-end development, client development, testers, and more.
The development team is the person who is really playing this scrum game, others (such as product owners are only partially involved)
Scrum Master:scrum Master is similar to the judge in killing games, the game organizer.
Scrum Master is not a team leader, he only does some organizational work,
For a "self-organizing" team, there is really not much to organize, so he is often a part of the development team.

4.2 No sub-team
In the official scrum document, this says:
* * Scrum does not endorse so-called "sub-teams" in the development team, and neither the members of the test nor the business analysis can be classified as "sub-teams". This rule is not an exception.

= = Scrum in defining the role, the emphasis on a whole development team, including the release of the product of all relevant professional and technical personnel, and the development team jointly assume the responsibility of development, only in this way, we can form a community of interests, and work together to make the product well.

It also explains why many big companies don't play scrum well. The team has no common interests, it is difficult to do "self-organizing".

4.3 Emphasis on equality
Scrum only defines the role of the "development team" as a whole, and everyone is equal within the "Development team".
Only in this way can we share information more freely and make joint decisions, otherwise the decision-making power is still in the hands of a small number of people.

In the official scrum document, this is said:
* * Scrum does not recognize the titles of development team members, and they are called developers regardless of the type of work they undertake. This rule is not an exception.

4.4 Game Number Rules
The development team also has a feature that cannot be said, that his size must be small enough, because he emphasized the transparency of information, if the number is too large, the cost of light communication is too big to bear,
So the number of people recommended on official documents is 10 (excluding product owner and scrum Master, unless they are also involved in development).

But in practice, because of the growth of the business, the number of teams is easily more than 10 people.
At this point, it's better to split the team,
For example, we have tried to split the server and client so that each team is within 10 people.
If you grow later, the client may be split into the iOS team and the Android team.

4.5 Game time
Scrum does not have strict rules for each iteration of the round, but it requires less than one months.
For each iteration of the round, scrum calls it a sprint.

As a start-up company, we've been working in the last two years with a sprint once a week.
Once a week the sprint is able to ensure that the adjustments are fast enough and the sprint execution does not encourage demand changes.
So once a week the sprint is able to do, for the more urgent needs change, at the next sprint (next week) can be executed.

The weekly Sprint also has a lot of problems, because it deviates from the topic of this article, so it does not expand the introduction.
Now our project team is also trying to do the sprint 2 weeks at a time.
In short, how long the sprint is determined by the development team based on the specific characteristics of the project, as long as it is not more than one months.

4.6 Game Play Method
Scrum defines 4 events, namely:
A. Planning meetings
B. Daily standing meetings
C. Review meetings
D. Retrospective meeting

4.6.1 Planning Meeting
The planning meeting is mainly through discussion and accomplishes two things: what to do and how to do it.
* about "What to do":
The product owner will give you a list of products to do, and then the team members can select the backlog to be completed for the next sprint based on the expected workload and previous performance.
Features: By the development team members themselves to select to-do items, rather than by the traditional sense of tech leader or product owner to choose.
Benefits: This ensures that the development task is determined by the team members themselves, and that he is more responsible for accomplishing things.
At the same time, as the product owner, it is necessary to tell the development team very clearly the significance and importance of each to-do item so that the development team can make the product selection work.
* about "What to do": After the development team picks up the backlog items to be completed from the to-do list, it needs to evaluate each backlog item to be done.
The job of the assessment is to discuss how to do this, including the technical architecture and the implementation details.
The workload of the work will be clearer only after the discussion is very clear.
PS: After discussing what to do, some agile companies recommend using a "card" approach to evaluate the workload, which we have also done with a set of scrum poker for cards.
The rule of the card is that each person out a card, with the number on the card to indicate the current work workload.
Usually, we will make an agreement on the workload of the number 2 in advance to ensure the same standards.
In order to avoid mutual influence, we first put out the cards to buckle, and then opened.
After that, the highest score and the lowest score of the students to express their views, explain why they estimate this, we discuss,
Such a process can ensure that everyone's information is transparent, that is, without ignoring the technology to achieve the difficulty or details, in the case of full sharing of information, usually the second time when the cards can be agreed.

4.6.2 Daily Standing meeting
A daily stand-up meeting is a way to view.
Usually choose a fixed time (we open 10:10 A.M. every day) to develop team work habits to avoid organizational costs.
Stand-up meetings should be as short as possible, usually within 15 minutes of control, choose to stand in the meeting, but also let everyone have a greater expectation of a quick end.
* Stand-up meetings are primarily for communication, as well as to identify potential problems in standing meetings where team members each have to speak 3 words:
--What did I do yesterday?
--What am I going to do today?
--What problems have I encountered?

Through these 3 sentences to achieve the purpose of effective communication, the issues mentioned in the meeting, usually down to the relevant personnel to solve their own.
Standing meetings are usually able to find out whether the project is progressing smoothly and take appropriate action as early as possible.
Longer sprints can be combined with burndown charts to make it easier to look at how quickly the project is progressing.

4.6.3 Review Meeting
The Sprint review meeting is held at the end of the sprint to check the planned work, which is completed, and which is not completed.
In our practice, we will let our colleagues demonstrate what they have done, and then PM will see if the feature meets the requirements.

4.6.4 Review Conference
A. Retrospective meetings are the process by which the development team examines itself, discovers problems in the team's operations, and customizes the rules of the game.
By reviewing the people, relationships, processes, and tools in the previous sprint, team members can summarize what they do well and do poorly. And then develop an improved program.
B. retrospectives are key to scrum's creation of a "self-organizing" team, which turns team self-improvement into a routine meeting,
In this meeting, the discussion is all about the experience of the game, including good and bad, and eventually everyone in order to play better, will carry forward the good, and strive to avoid bad, to become a self-evolution of the collective.
C. It should be noted that the Review Conference should not be a meeting of the General Assembly, but should be discussed in the spirit of the problem-finding and problem-solving approach.
For example, it is very bad if the retrospective meeting is simply complaining that the product is always changing demand, or complaining that there is not enough time to propose a solution.
D. It is easy to ask questions, and the trouble is to propose a solution. Our boss put forward a way for us to think: "If we do it again, can we do better"? If we find that if we do it again, because of objective principles, we may still not be able to avoid the same problem, then we choose to accept rather than complain.
E. Because there are many times there is no perfect, no problem solution, it is like the software has bugs, if the bug is unavoidable, we choose to find the time to try to repair rather than coding when the time to avoid.

4.7 Frame Diagram
A. Executives: [IG ' zekjutivz]
N. Executives, executives, executive managers, executive directors (executive's plural)
B. team:n team; group
C. stackholders [' steikhouldeo]
N. stakeholders; a stake keeper.
D. Customers
Customer, Customer
E. Users
User

Product Owner: Products owner; Product manager; Product Owner
Product Backlog: Products to-do List
Product Backlog item; Product Backlog Work Items
Sprint Planning: Iteration plan, planning meeting;
Sprint Planning meeting: meetings, iteration plans, iteration planning meetings
Sprint Backlog Sprint Orders
Scrum Master: Agile Admins
Sprint End Date and team deliverable do
1-4 Week Sprint
Burndown/up Charts Burndown Chart--Every Hours
Daily Scrum Meeting Stand-by conference
Sprint Review
Work done by finished
Sprint retrospective Meeting Review Conference; Sprint retrospective meeting; Iterative Retrospective Meeting

Scrum Agile Development