Agile development handouts-how to build an agile team

PPT download link: http://pan.baidu.com/s/1bncprTd

Agile development sharing handout-modified version

Page 1: Personal Information

I will not introduce myself. My basic information is on the first page of the PPT. On July 15, July 26, that is, last Saturday, I attended a one-day training session on Agile development. We applied for this training because the training is suitable for the audience who wish to develop towards project management in addition to senior leadership, project managers, and product managers. "I don't want to be a project manager or a project supervisor." I didn't want to be a real cow, So I attended the training. But this time I was forced by Ting Jie (joke! Hey !). Although the time is not long, there are still some valuable ideas and work methods, so it may take some time for you. I will share some of the content with you today! Another part of the sharing will be made next week.

 

Page 1: Sharing background

22d> 7.0 h> 1.0 h

Agile development and design involves a lot of content. According to the instructor's plan, all the courses will be completed for 22 days (the training courses for professionals will be 9 days, including: excellent demand analysts, excellent software designers, and excellent system analysts are trained for three days each. The courses trained by the project manager are also nine days, including project management, project quality and project evaluation, and middle-level management leadership training, including: middle-level leadership training and performance appraisal every two days ). During the 22-day course, this guy only talked about the course for one day (seven hours, the planner finished the course for six hours, because the content was too long and delayed for another hour ). I have not mentioned much about it, and the content I mentioned is not very detailed. I can't digest it for a short time. Now I have a limited time to share it with you. It will not exceed 1 hour. Therefore, we can only talk about part of the content: How to build an agile team.

 

Page 1: share title

How to build an agile team

 

Page 1: Content outline

These four points are our learning goals on the day of training. Today I will share with you the second part: How to build an agile team is how to build an agile team. In terms of agile nature and project management, I will also talk about "Learning agile requirement analysis and practical skills", which will be shared with you one day next week. First, we understand the essence of agility. The word agile is very popular. We often hear it, and agile has been used by many companies, not only in Software Project R & D, but also in the military, retail industry, school management and so on. What kind of team is agile team? What kind of team is agile? Next we will understand the essence of agility from two aspects.

 

Page 1: agility

1. Core Foundation of agility

2. agile features

The first is the core foundation of agility, and the second is the characteristics of agility.

 

Page 1: Core Basics

We are on the same ship.

Just as the foundation is the basis for building a house, what is the agile "base? All versions are available on the Internet. In plain words, we are on the same ship ". This sentence has two meanings: one is that all members of the project team are on the same ship, and the other is that all employees and companies are on the same ship. It sounds very simple, just a few words, but no company can do it completely, especially the second one. To achieve these two things, we need to build on the powerful material basis, otherwise it will be difficult. Therefore, we often see that the project supervisor is always the most anxious in a project, because the whole project team has the greatest benefit. Once a project has an accident, the boss will definitely find the project supervisor, no one in the team will be found. So the project owner should help those who are on the same ship with you and those who are in a hurry with you. The stronger the base, the higher the building, and the higher the project team can stand. The direct result is that everyone in the team is making progress. Now let's think: Are we on the same ship? We will not discuss it here. It is only for your consideration. Next, let's take a look at the agile features:

 

Page 1: agility

1. All persons are responsible for the success of the project.

2. directly driven by the needs of all people.

3. All people need to work in different fields.

4. Continuous delivery and iteration.

5. Make small strides and make continuous improvements.

6. Effective and simple.

Here is a simple introduction. 1. Everyone is responsible for the success of the project, not only the project manager is in a hurry, busy. 2. All people work directly and demand-driven, not technically-driven. Because once the requirement is determined, it should not be modified. Therefore, the confirmation of requirements is very important, and it is necessary to communicate with people who directly develop products. 3. All people need to work in different fields. Design and R & D, art and design, testing and R & D can work across different fields. 4. Continuous delivery and iteration. 5. small steps forward and continuous improvement. 6. Effectiveness and simplicity are the most direct features of agile development. Agility aims to be "simple and efficient", and ultimately to make profits.

 

Page 1:

How to build an agile team?

 

Page 1: team concept

Design, artist, R & D, testing, implementation, etc.

Since it is sharing, I want to have a small interaction with you. Let me ask Liu, a simple question: Pick a project you are working on and tell me how many people are there now? (You will definitely say one person or two people, and Yong ye .) This is not correct. Apart from R & D personnel, we should first include the project owner, design, artist, test, implementation, and so on. Only the persons associated with the project are counted as project team members. This is a conceptual mistake that many of us often make. If you ask the R & D personnel about the number of people in your project team, he will only say the number of R & D personnel and will not include the testers. You ask the tester, there are several persons in your project team, and the tester will only include the R & D personnel and discard himself. Well, next we will introduce the two classic team architectures and export the characteristics of Excellent Teams.

 

Page 1: Classic team Architecture

Scrum team Architecture

MSF team Architecture

The first is the architecture of the scrum team. Have you ever heard of it? Okay, no! (Good. You don't know many people !) Many people now equate scrum with agility. The second is the MSF team architecture. This team architecture, Tao Ge told you last Friday that Microsoft solution framework and Microsoft solution framework will be briefly introduced later. Let's first talk about the scrum team framework.

 

Page 2: scrum team architecture-founder

In such a classic team model, we must at least know who the Founder is. Scrum was proposed by two Americans: JS and Ks. Both of them are legendary. JS again, buddy is about 60 this year. At first, he was a pilot and participated in the US-Vietnam War, with more than 100 flights. After 11 years of military career, he received a PhD from the Colorado Medical College. He has served as CEO and CTO of 11 software companies. KS is also very good, this buddy is just ten years older than JS, born in 45 years. At the beginning, I started as a merchant account manager. To put it bluntly, I managed to ship goods to the merchant account at sea. After more than 40 years of software development, I developed system software for the IBM mainframe and created my own business. Scrum proposed by the two during an IBM Project Partnership. Next I will understand the main roles of this team.

 

Pages 12th and 13: scrum team architecture-Role

There are three roles: 1. It is the product owner Po, that is, productowner. 2. It is the scrum supervisor SM, that is, the scrum master, which is not another "SM ". 3. It is a development team. The main responsibility of Po is to provide a vision for the product and determine the scope and priority. It is very important to provide a vision. Most of the time, only the project manager and supervisor can know the vision of the project. How good the project is, but other members of the team do not know it. This is also one of the reasons that sometimes only one project manager is worried about the project. Like this picture, only the person standing can see the beautiful scenery in front of the scene, and the person sitting there can't see it at all. Even if the horn sounds louder, it's up to you! If the speaker said, "Everyone is drawing hard! All the beaches in front are bikini girls !" Think about the effect. Haha!

 

Page 1: scrum team Summary

Each member plays a unique and irreplaceable role in project success.

Different members may have different experiences and abilities, but they all have the opportunity to become one-on-one masters.

Members can be the directors of successful projects.

This gives members sufficient room for growth.

This architecture should be open-minded, encouraging progress, and making people happy.

 

Page 1: MSF team Architecture

The MSF team talked about Tao GE last Friday. Here I will briefly introduce it. The MSF team is centered on communication. The relationship among team members is: mutual dependency, mutual collaboration, and equality. Everyone is indispensable for the success of projects or products.

 

Page 1: Core Ideas of the MSF team

Everyone in the project team is equally important,

The project team is composed of professionals,

Each member plays a leading role in his/her own professional field,

Each member is responsible for the final success of the project.

 

Page 1: What should a good team have

All members are equally important, and each member is a master,

Persons with high capabilities are more responsible for promoting the improvement of project team members,

Learning, summary, and progress.

We mentioned above in the previous two points that we will not explain too much here. Third: Learning and summarization are processes, and progress is the result. How to Learn? How to summarize? It makes people feel confused. Let me share with you some of my experiences.

 

Page 1: A learning Summary

1) every Friday, the R & D department shares technology or experience.

2) Check the code of the android team in stages

3) stick to writing Technical blogs

The first two points are my experiences in my first company and my first company. The third point is what I have been doing since I joined my work. Referring to the relationship between "Emergency and importance" mentioned by Tao GE last Friday, learning and summarizing are "important but not urgent. Is learning important? Of course it is important. Is it urgent? Of course it is not urgent. Over time, it will turn into an "urgent and important" thing. Therefore, we often lament that books are used with less hate! Of course, you also have your own learning methods.

 

Page 1: What do you think of "mistakes "?

Software development is a creative and creative task, and it is impossible to make no mistakes. Do you agree? In fact, the same applies to other departments. Confucius said: "If people are not sages, what can they do ?"

 

Page 1: What do you think of "mistakes "?

But we need to know the cause of the mistake. There are two types of mistakes: Advanced errors and low-level errors. Are you making mistakes because of low difficulty or repetitive work, or because of difficult work? If it is the former, it is to make low-level mistakes. Leaders should criticize and improve it more. If it is the latter, we should encourage "Making Mistakes ", making mistakes in difficult work is the fastest way to progress. Encouraging "Making Mistakes" is actually encouraging progress.

 

Page 21st: "mistakes!

Failure is not the mother of success. Summary is the mother of success!

The essence of agility and the creation of agile teams are shared here. Next, let's talk about project estimation, planning, and tracking.

 

Page 1:

Project estimation, planning, and tracking

The entire project process should be: Estimation --> plan --> tracking --> delivery

 

Page 1: Project Estimation

Let's take a look at the rough estimation: (show the picture) a few people discuss it, take an average value, it's almost OK. This is even better. Sometimes the leaders rush to tell you about the functions and the requirements are not completely clear, so you can estimate the project time. The estimated time is short. The leader said, "you have to finish it on time." If you don't finish it, you will die. Even if you work overtime, you will barely finish it, if something goes wrong, you will also die. After a long time you estimate, the leader will say, "it takes so long to develop such a function! ", The leaders mistakenly think that we have no confidence or ability. How can we make an estimation?

 

Page 1: Project Estimation

Let's take a look at the detailed project estimation. The project should at least be estimated from these four aspects: Demand refinement (determination), software design, code implementation, defect repair, and testing. The estimation made in this way is relatively reliable. It should be a good estimation method.

 

Page 1: Project Plan

Schedule projects by function module, take time as the node, and specify the owner of the corresponding function module.

 

Page 1: project tracking

Project tracking should have a table: What todo will do, what doing is doing, what done has done, and filished passed the test.

 

Page 1: content review

Review the content.

 

Page 6: 6-minute short video sharing

Directly put the video, and the effect should be good.

 

Page 7: Thank you!

Have a good weekend!