Shulou(Shulou.com)06/03 Report--

Introduction:

For the agile development team, team management is also essential. The team I lead is divided into two parts, one is the development team and the other is the test team. The development team, I generally feel at ease, because after all, it has been running for more than a year, the documentation is sufficient, and there are many technical materials or ready-made code to refer to. The test team has just been set up, because the original test team was placed on the onshore side, but now their test team has been disbanded, so we have set up a test team here. Share some of my experience in managing the team here.

Implementation method:

In fact, I am not a full-time team manager, because I am a pure technical person, I do not even have a PMP. I have done a column, I have worked as a cloud computing consultant, I am a member of the company's architecture group, but as a manager, I really lack experience. In spite of this, I have been a Leader in the company for 3 years and have taken over 4-5 project teams, large and small, so although there is no experience sharing, at least I can talk about some experience. Because our team is the best team in our company (the evidence is that there is an @ sign in front of our team, if you have seen the soldier assault, you will know the old A, pretty much), so the configuration of the team is very high. More than half of them are senior engineers.

(1) most senior engineers have a characteristic that they think more than they do, and spend more time writing documents / emails than writing code. Our team is no exception, because after all, in my eyes, senior engineers have to do more macro design than simple coding. But work has to be done, so how to make everyone motivated to do their assignment? This is my first challenge. What I do is: try to arrange some challenging jobs for them, because most programmers are "proud". If he feels that a job has hardly improved his ability, then it may not be motivated enough to do it. I'm no exception. So the way to deal with smart people is to challenge him. For example, although many of our needs are given by customers in the United States, many requirements, if you just implement it, or elegantly implement it, or not only achieve it, but also consider the future reusability and maintainability, then the cost of this implementation is completely different. So, for a senior engineer, you try to give him some abnormal needs, so that he has the motivation to do it well.

(2) Intermediate engineers are different. because they are not very experienced, many functions may not be very familiar to them, so it is very difficult for them to do the work on their hands directly, but with a serious attitude, there is no problem for them to finish the work on hand within the specified time. So for them, encouraging them and giving them enough confidence is the most important thing. Because anyone, including myself, has come step by step from junior, intermediate and senior engineers, they have incomparably strong potential. Everyone has a lot of potential, and how to guide this potential is what your manager needs to do. For me, first of all, I should believe in their ability as much as possible, and absolutely say that a certain task can never be completed. Second, do not arrange to replace some tasks, maybe I will do it for 2 hours myself, but it will take 2 days for others to do it, even so, I can't do it, because once I help them, I will make them feel dependent. Anyway, I can't get help, which is bad for their growth. I have always believed in a truth: in fact, the closer you are to the end of a difficult problem, the greater your technical improvement, just like a soldier crossing the river, the more you enter the royal city, the stronger your combat effectiveness, and when you completely conquer it, what you gain is the whole process, the whole knowledge system rather than an isolated knowledge, in other words, you receive not a few pawn, but an established army. I myself am like this. I remember that I just graduated from college six years ago (in fact, I have been an intern when I was a student for several years). I have a habit that I will never ask others easily if I have a question, even if I have to study it for a few weeks. I don't relax, and then slowly, I am very confident in my personal problem-solving ability, because I used to study problems very slowly, and then I often exercise in this area. It became a fast solutioner, so much so that I have been bragging to my team that as long as I am given a debugger, I can solve almost any problem. Of course this is exaggerated, but at least it is very good for personal growth. I remember that in the first year of my graduation from junior engineer to senior engineer, I was very proud at that time.

. Now I also share these experiences with the members of the team. There is a man on our team. When I worked with me in another project group 2 years ago, he was still at the junior level. I have been influencing him with the right experience. He has also become very good at thinking and solving problems independently, especially like doing Redd work. Now, he has worked for less than 3 years, and his level is also the level of a quasi-senior engineer.

What is mentioned above is how to treat team members differently, and another topic below is that for teams, there must be time for knowledge share,code review,summary and other systems to improve team capabilities.

Generally speaking, people are reluctant to look at other people's code, because it is always more difficult to read other people's code than to read their own code, but as a programmer, the consciousness and ability to read other people's code is necessary, because very often, don't reinvent the wheel, you spend more time learning, researching, and reusing other people's code, such as open source frameworks, or legacy project code. Or take over the work of another person, etc. Be sure to read the code, because reading code is not like reading a novel, it is a process of secondary construction, a program master, like an architect, when reading code, you can inadvertently draw logic and structure on paper. You can even see the defects in the other party's writing code, which is also an improvement for your own quality.

Code Review is also important because many problems are exposed in Code Review.

Knowledge Share is also a symbol of a mature team, we follow the practice of eBay, there are often technical salons in eBay, we all go to share some recent research results, because a person's time and energy is limited, it is impossible to dabble in all aspects, and sharing knowledge and technology can improve everyone's level as quickly as possible, thus taking the "elite route". I like to take the elite route very much. Because a small group of elite troops will be much more powerful than a group of old, weak, sick and disabled. Our team has some knowledge share every week, most of which are related to the project, such as some very thorny Bug Fixing, such as the implementation of some functions, or we can also talk about some latest technologies, and so on. Our team has improved rapidly. As I told the team, now our team has 5 senior engineers. I hope everyone will be senior engineer or above in a year's time. That's what I look forward to.

Summary:

(1) for senior engineers, arrange more challenging tasks to stimulate enthusiasm.

(2) for non-senior engineers, give more encouragement, confidence and correct guidance in methods.

(3) Code Review and Knowledge Share are essential practices for building a mature and positive team.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.