Agile Software Development Practice-team Management

Introduced:

For the Agile development team, team management is also essential, I led the team divided into 2 parts, one is the development team, one is the Test team. Development team, I am generally more comfortable, because after all, has been running for more than 1 years, sufficient documentation, and technical aspects of a lot of information or ready-made code can be referenced, the test team is just set up not long, because the original Test team on the onshore side, but now their Test team dissolved, So we set up a Test team here. Here I share some experience with my management team.

Implementation mode:

In fact, I am not a full-time team manager, because I am a purely technical person, I do not even have a PMP. I used to do columns, I have been a cloud computing consultant, I am a member of the company's architecture group, but do management, I really lack of experience, however, I have been in the company for 3 years leader and took over 4-5 project team, so although there is no experience to share, at least can say some experience. Because our team is the best team of our company (the evidence is that our team has a @ logo, see soldiers assault all know old a bar, almost this meaning), so the team configuration is very high, more than half of the people are senior engineers.

(1) General engineer Most have a characteristic, is to think more than do, write documents/mail time more than write code. Our team is no exception, because after all, in my eyes, senior engineer more to do macro design, rather than simple coding work. But there is always work to be done, so how to make everyone have the initiative to do their assignment? This is the first challenge for me. My practice is: as far as possible to arrange some challenging life to them, because the programmer is most of the more "proud", if he felt that some of the work of his ability is almost no promotion, then it may not be enough enthusiasm to do this job, I am 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 across the United States, but a lot of demand, if you just implement it, or it is elegant to implement it, or not only to implement it, but also to consider the future of reusability and maintainability, then the implementation cost is completely different. So, for senior engineer, you try to put some abnormal demand to him, so he has the power to do this thing.

(2) Intermediate engineers are not the same, they because experience is not very rich, many features may not be very familiar to them, so they are very difficult to do the direct second killer on the job, but in a serious attitude, they in the specified time to complete the work of the hand is no problem. So it is most important for them to encourage them and give them confidence. Because anyone, including myself, is from the primary, intermediate, senior engineer step by step, so they have a very strong potential. Everyone has the potential to guide the potential that is what your manager is going to do. For me, first of all to believe that their ability, absolutely say that a certain task and so definitely not complete such words. Second, do not Baladati, some tasks, maybe I personally shot 2 hours, but others to do 2 days, even so, I can not do it, because once I help them, they will be able to rely on the sense of dependence, anyway, to help them, so for their growth is unfavorable. I have always believed in a truth: in fact, in the study of a difficult time, the closer to the end, your technical upgrading, like the soldiers across the river, the more you reach the king, the more you fight, and you completely conquer it, you reap the whole process, is the whole knowledge system rather than an isolated knowledge, In other words, you receive not a few strokes, but a formed army. I am also like this, remember I was 6 years ago just graduated from college (in fact, I have been a student internship for several years), I have a habit, it is not easy to ask other people, even if this problem I want to study for a few weeks, also do not relax, then slowly, I am very confident of my personal ability to solve problems, Because the previous research problems are slow and slow, and then often this exercise, become a fast solutioner, so far I have been and my team people boast: just give me a debugger, I can solve almost all problems. Of course it's exaggerated, but at least it's good for personal growth. I remember the first year I graduated from college, I went straight from junior engineer to engineer level, and I was proud.

。 And now I am. These experiences are shared with members of the team. Our team has a personal, 2 years ago and I was in another project team work, he is still the primary level, I have been using the right experience to influence him, he also became very good at independent thinking and solve problems, especially like to do R&d, now, he has not been working for 3 years, level is also quasi-senior engineer standard.

The above is how differentiated treatment of team members, there is also a topic, for the team, must have the time knowledge share,code review,summary, such as the system to enhance team ability.

Generally speaking, people are not very willing to look at other people's code, because reading someone else's code is a lot harder than reading your own code, but as a programmer, the awareness and ability to read other people's code must be there, because many times, don't invent the wheel, you spend more time learning, researching, reusing other people's Code, such as open source framework, or legacy project code, or take over another person's work and so on. Must bite the bullet to read the code, because reading code is not like reading novels, he is two of the construction process, a program master, like architects, when reading code, you can inadvertently draw on the paper logic, structure. Can even see the other side of the code to write the defect, so for their own quality is also a promotion.

Code review is also important because many of the problems are exposed in the code review.

Knowledge share is also a symbol of a mature team, we follow the practice of ebay, there are often technical salons on ebay, everyone to share the next few recent research results, because a person's time and energy is limited, not all aspects of the study, and the sharing of knowledge technology can be the fastest to let everyone's level to upgrade, thus walking is the "elite line", I very much like to take the elite route, because a small number of good soldiers than a group of elderly and infirm to give more power. Our team will have some knowledge share every week, mostly related to the project, such as some very tricky bug fixing, such as the implementation of some features, or can talk about some of the latest technology, etc., our team level up very quickly, I originally and the team said, Now our team has 5 senior engineers, I hope that 1 years after everyone is a senior engineer level. That's what I was looking for.

Summarize:

(1) For senior engineers, more arrangements to write a challenging task to inspire enthusiasm

(2) for non-senior engineer, give encouragement, confidence and method to guide correctly.

(3) Code Review, knowledge share is an essential practice for building a mature, positive team.

This article from the "Cohesion of parallel Lines" blog, please be sure to retain this source http://supercharles888.blog.51cto.com/609344/1261962