A year and a half of agile development experience shows you how to practice agile.

Previous selections:

• How to treat the programmer 35 career crisis?
• Java full set of learning materials (14W words), took half a year to sort out
• I spent three months writing the GO core manual for you
• Message queuing: From model selection to principle, this article takes you through everything
• Micro service gateway selection, please take my knee!
• How to choose the five registries? Interpret to you from principle!
• Liver ETCD for a month, from Raft principle to practice
• Much more! Much more! Much more! Triple strike!!

Hello everyone, I am Lou Zai! And a lot of blog posts about Agile on the web, I can assure you, this one is one of the best, if you can find something better than mine, please do me a favor, I want to see it

Some of you may say, I can’t even handle the normal project flow, how can I do agile… Don’t worry, these two articles have been arranged for you, and the response is very good. I strongly recommend students who need to bring projects to read them.

• 2 years experience summary, tell you how to do well project management
• The project has been delayed again? Tell you how to do project risk control

When it comes to agile development, you may say, what’s the big deal? I just want to say, it looks like a layman!

Agile development article, I have written before, but that is to deal with the leadership, write very rigid, now I am going to write a new one for you, should be my last one on project management, is it a memorial ~~

What is Agile development

We are used to the waterfall model, which is document-driven and divides the software life cycle into a fixed set of six basic activities, and dictates their top-down, cascading sequence, like water falling down a waterfall.

So what is agile development? Agile development is a human-centered, iterative, step-by-step development method, which can cope with rapid demand changes and take delivering software to customer satisfaction as the ultimate goal. Scrum is one of the standards and processes to achieve agile development.

Scrum

Scrum is one of the standards and processes for implementing agile development. This should be mastered, otherwise the actual practice will be a bit confusing. If you are familiar with Scrum, you can skip this part.

Scrum Main terms

• Product Backlog: The entire project is sliced into many backlogs that form the original work pool of the R&D team;
• User Story: a team’s elaboration and breakdown of a Backlog from a technical perspective that can be developed;
• Task: a Task with a smaller granularity than a User Story;
• Sprint Daily Standup Meeting
• Kanban: a written whiteboard used to show progress of a project, etc.
• Burning Down Chart: A Chart used to manage the progress of a task and the amount of work remaining.

The three roles of Scrum

• Product owner: the demander side, the person who puts forward the requirements, and can make decisions on the functional process and business process.
• Team leader: Responsible for solving team problems and leading projects.
• Project Executive: Development projects generally include front and back end development, UI, QA, etc.

Three artifacts of Scrum

• Product advice form (the Product Backlog) : brainstorming, if the Product owner very clear demand for products, you can omit this step, to develop a principle “tight after loose” first, you must first understand the demand, the demand for the Product owner can call the technical team here for public opinion, the final output a Product proposal form.
• Release Backlog: The product owner filters the Release Backlog and subtracts the core requirements. After determining the requirements, the team leader outputs the technical solution document, which is the same as the traditional waterfall flow. All the documents must be available, and the requirements must be determined by the team leader and the product leader, including business logic, functional process, etc.
• Burning Down Chart: The essence of Scrum is the Burning Down Chart. Through this Chart, you can visualize the time progress of the task, update the remaining time according to the completion level of the task every day, or increase the time (for example, if a technical difficulty is found, team members ask for leave, etc.).

Scrum operational Framework

High energy ahead, this chart is very important!! Once you know how Agile works, there are four stages (requirements review, task breakdown, iterative development, and review) and five meetings (requirements review, planning, daily stand, demonstration, and review).

What? Still can’t read the picture? Let me do it briefly:

• Demand sorting: we started to sort out the demand with the product, put the demand into the demand pool, and then reviewed the need for this iteration through the demand review meeting;
• Task splitting: After the requirement review, we will hold another planning meeting to split the tasks, that is, we will initially evaluate the working hours of each task, and then split the tasks into this iteration according to everyone’s time.
• Iterative development: After the task of this iteration is determined, we will enter into the iterative development and ensure the progress of the project through daily station meetings;
• Summary and review: after the development, a demonstration meeting (review meeting) will be held, and the business side will accept the product. After the completion of the project, a review meeting (reflection meeting) will be held to summarize the project experience.

You might say, well, that’s not easy, so LET me ask you two questions:

1. How do you evaluate the time spent on task splitting without any plan design?
2. The project will be online this Friday, you may not even know the requirements of the next iteration, can you normally hold the next iteration meeting next Monday?

These two questions, if you can answer, prove that you have some ability in project management, the actual combat will tell you the answer.

The project of actual combat

The foundation of agile is not difficult, but when combined with specific practice, there are still many problems. I led my team to go agile, and it took me several months to put this agile process into practice. Now I will take the overseas e-commerce ShareSave project as the prototype to tell you how we put agile into practice.

Demand pool

In order to identify the problems existing in ShareSave, team members brainstormed and presented their ideas through cards, and then voted for selection. The process is as follows:

• Core process: The product leader firstly pasted the whole ShareSave group forming process, including 12 core processes such as group opening, sharing, downloading and payment, into a horizontal straight line with blue cards;
• Description of advantages and disadvantages: The advantages and disadvantages of each of the 12 core processes are explained. The advantages are represented by green cards and the disadvantages are represented by yellow cards.
• Emotional curve: according to the number of cards with advantages and disadvantages and their importance, move the process with more green cards up, and move the process with more yellow cards down to form a fluctuation curve; Represents the user’s mood curve when using the product. The higher it is, the better the experience is; the lower it is, the worse the experience is.
• Process suggestion: For the outstanding problems in the curve, everyone gives their own ideas and improvement suggestions, which are represented by red cards;
• Vote: each team member has 5 votes, denoted by green dots, and pasted on a red card. The red card with the most votes is the better suggestion.

Tips: This is just a way to collect requirements. We can learn from this kind of gameplay, which is very interesting. Of course, we can also skip the requirements collection and let the product and business side determine the requirements.

According to the current “pain points” of ShareSave, the product leader outputs the following product list in combination with the opinions of team members and the operation and competitive product research. It needs to be emphasized that in order to better meet the pace of the entire iteration, the product owner needs to sort out the requirements for at least two iterations to ensure the normal iterative development of the entire project.

Product owner to-do lists of product screening, subtracting refining the core of the demand, the demand for the output products table process, the product owner needs and project director to communicate, can ensure that combing the demand of basic meet an iteration, the project leader also needs a demand for preliminary scheme evaluation, including the core business logic and process function, If the workload of some requirements is heavy, the requirements need to be split and selected. This process will be long and may be repeated several times before the final product requirements table is produced.

Task splitting & Daily iteration

After sorting out the requirements of this iteration, an iteration meeting will be held, which mainly has three main things:

• Decide What requirements To Do in this iteration, i.e., What To Do;
• Divide the requirements into tasks and record the tasks into TB. For each task, the responsible person should be clear, that is, How To Do and Who To Do;
• Schedule tasks and determine if there are human bottlenecks. If there are human bottlenecks, prioritize tasks to include non-urgent tasks in the next iteration.

At the end of the iteration, everyone will write their tasks into cards and post them on the task Kanban board. We have the following three rules:

• The update of task progress in kanban is maintained by team members themselves;
• Update the task progress in kanban in real time through daily station meeting, and publicize the task to students downstream;
• Before RD test, perform smoke self-test (one of DoD), and then test the RD to QA.

Sprint burn out chart is one of the essence of Scrum, through which you can visualize the time progress of a task. If the solid line is below the dotted line, it indicates that the task is ahead of schedule; if the solid line is above the dotted line, it indicates that the task is at risk of delay.

The daily station meeting is the most effective way for the whole team to communicate. The meeting should last no more than 15 minutes and the following 3 questions should be answered:

1. What did you do yesterday?
2. What are you going to do today?
3. Did you run into any difficulties?

Acceptance & Summary

At the end of the iteration and before the formal delivery of the product, the whole team members are required to conduct an iteration review, that is, to demonstrate the product functions, and then the team members will act as users to experience all the functions completed in the iteration and give relevant suggestions.

After the iteration review, we need to conduct an iteration review. In order to avoid too many meetings, our team conducts a review every two iterations, and the review time is generally about 1 hour. The way of review shared this time is “Starfish Review”.

Tips: There are many ways to summarize and review, “starfish review” is a kind of play, you can also baidu more play.

The Starfish Review divides a plane area into 5 quadrants, shaped like starfish, and includes the following 5 aspects:

• Keep it up – activities where the team is doing well and finding value from it;
• Do less — something that has already been done, something that you would rather do less than you would see some gain;
• Do more — something that’s already been done and has been proven to bring greater returns.
• Stop doing — what isn’t generating revenue, or worse, is holding the team back.
• Get started — a brand new idea, or one seen from somewhere else, that can help the team.

Team members take turns speaking manner, to everyone’s ideas by card on the corresponding quadrants, everyone to vote on this little green dot (CARDS), and select the advice of the core (little red dot on the card), and finally by the project director summarize and discuss improvement, given by all solutions of the problem.

How do you control the pace of iteration

If the requirements for the second iteration were to be combed out after the first iteration, it would take at least 3 days to comb out requirements, UI interactions, and solution evaluation before the second iteration could be developed. At present, our iteration cycle is 2 weeks. In order to solve the problem of connecting the two iterations, our team has developed a set of iteration calendars, which are all explored by us:

• On Tuesday of the first week of iteration, the iteration planning meeting was held to split requirements and confirm the schedule;
• On Tuesday of the second week of iteration, the project leader should evaluate the requirements of the next iteration in advance, and then let UI interaction design and RD evaluate the design scheme.
• On Friday of the second week of iteration, the project leader should determine the preliminary plan of the requirements of the next iteration, so as to facilitate the accurate and rapid task splitting and avoid risks in advance when the iteration planning meeting is held.
• For retrospectives, we do retrospectives every two iterations in order to minimize interruptions.

Through this iteration calendar, we can answer the two questions raised at the beginning. We carry out the plan design in the second week, and we can hold the iteration meeting directly on Monday of the third week, so the two iterations can be perfectly connected and the project schedule can be avoided randomly without the plan design.

Agility is a panacea

Agile, if used properly, can improve production and research efficiency, embrace change and rapid iteration, but it is not a panacea. It needs to be in the right place at the right time, and the conditions are a little harsh. Here are some lessons:

• Strong support from the boss: this is the premise of everything. For example, the boss vigorously promoted Agile before, and the whole department was able to carry it out. Later, the boss changed direction, and agile was not carried out.
• Projects can support small iterations: Agile is best for exploration projects, or projects that iterate quickly, such as apps, because requirements are easy to change and tasks are easy to break down. If it is a traditional project, the requirements are set from the beginning and the tasks are difficult to disassemble, you should stick to the waterfall model.
• Team members closed loop: Agile team members need to follow the project, because the iteration pace is fast, no one can work on other projects, otherwise he will become the bottleneck of Agile;
• Team members have the same goals: Because of the rapid pace of iteration, the product, development, testing, and UI must have the same goals, and if any of the students are not aligned, agile can be difficult.

Agility, as I understand it, is more like a sharp blade, which is powerful when used properly! But this blade is not used well by everyone, and it is not needed in every situation. Most of the time, we just need a kitchen knife.

Write in the last

If YOU had to ask me what I miss most about my seven years in the job, IT would be the time I led the ShareSave team doing agile.

We have a very good product manager (junjie), a very careful test little sister (ZhuoLing), a technology has a strong pursuit of H5 front (r), an Android kid sister to have a strong sense of responsibility of the project (YaNan), a great UI designer (kang kang), we are not in order to do projects and projects, I want to do a good job with this product. Sometimes we are all products, sometimes we will help test together, we have the same goal, invincible!

Finally, I would like to attach a photo of all of you to remember the years we have spent together. (Unfortunately, we don’t have an official photo, so please use a photo of our morning meeting.)

It is better to have no books than to have no books. Because of my limited ability, it is hard to avoid omissions and mistakes. If you find bugs or have better suggestions, you are welcome to criticize and correct.