Agile development practices of "loose Pair Programming"-large teams

Loose Pair programming is a practice of a small team. It runs in the hands of 1 master + 1 ~ On the scale of the three apprentices, when facing a larger scale, a large team model is required. Here we recommend the 139 team model, because it not only makes the loose Pair programming run smoothly, but also solves the problems of big team communication, performance appraisal, and the way out of the master.

139 the overall situation of the team is quite complex. Another series of blog posts will be described here, which only describes content related to "loose Pair programming" to ensure the integrity of this series of blog posts.

Basic Concepts

The 139 team is short for one project manager, three masters, and nine apprentices. Of course, it may not be enough to meet 13 members, nor may each master have three apprentices.

In the first article, we have mentioned three levels of working relationships. Below are some in-depth analyses.

Performance Appraisal

Performance appraisal has always been the biggest headache in the software industry. The new programmers write more junk code than the other programmers. The size of each task varies according to the number of tasks, do you want to evaluate by function? Most people do not count. Do you want to assess by the completion rate of work on time? ...... 139 the team has a general answer: arrange the general salary and bonus ratio at the level of 1-3-9 (detailed analysis in the 139 team series ).

139 the Team believes that performance appraisal is the overall performance of the team first. When it is divided into individuals, it does not depend on how much each person works, but on the role played by the team.

So, do you want a raise? Take the apprentice. However, it is useless to bring a team of useless apprentices. First, you must have team performance to achieve personal performance.

Recruitment

Personnel recruitment is generally conducted at a higher level, and the lowest is the project manager, but the new employee is the master. Therefore, you should ask future masters to be present during recruitment. department managers/project managers can ask Teacher Fu, "is this person an assistant for you? Do you think it is enough ?" I have asked this question recently. The master's voice is very important, because if he doesn't like it, it will be very difficult to cooperate in the following scenarios. If you are recruiting masters, the project manager should have a sense of comparison between the current and current masters, especially the ability to communicate and teach.

The difference between mentoring and mentoring cannot be too large or too small. Too many universities do not understand, white delays the master's efforts; too small to have nothing to learn, but may also lead to conflicts (often half a catty war eight or two, if one is two, it will not be able to fight ). If you understand the above practices of loose Pair programming, you can analyze the actual situation when encountering actual personnel.

Career Planning

What can an apprentice do after learning it? You can work independently. For example, if a new module or business appears, you can independently develop it for this person (with the code reviewer). If you do better, you can become a master and take the apprentice.

What can the master do after learning it? Can be a project manager. For example, if a master has 3 ~ Five apprentices and want to add more members, most of their modules will be split into a sub-project. After the split, the master is the best person for the new project manager.

A previously-visited high-growth company had only 18 people when it went there, and 120 people had been there in a year and a half later. Most of the Business backbone were apprentices of that year, rather than new masters. The original reason is that a business barrier is not just a master to break through, but a mentoring system makes people grow fast. At first, there was no formal mentoring system, but the project manager had guided everyone selflessly and set up conditions for Team growth and later establishment of mentoring system. I have been working for five years since I first went there, and I still don't know that the applied memory is to be deleted (C ++). My current programming skills are basically achieved in this company.

Main programmer team

If you meet a Top Ten masters, there is also a team model that is the main programmer team. Work as a master, work as apprentices and learn. I used it twice and a half and it was very successful. The working style of the main programmer team is more "loose", but it also has its working mode and mentoring system.

The main programmer team is not very comfortable with the Health and potential of the programming team. I personally feel that it is only suitable for some situations.

139 of team content not covered in this article

The incentive mechanism of the self-organizing team, the plan meeting of the large team, every Hitachi meeting of the large team, the cooperation between the large demand team and the development team, and the work style of the team with a strong division of labor, 139 detailed performance appraisal/non-material incentives of the team will be discussed in the 139 team series.

-----------------------------------------------

The 139 team is a large-scale agile team that uses loosely coupled programming. It is applicable to the loose programming process at level 3-9 and the scrum process at the whole level.

The 139 team solved some major team issues such as performance appraisal, recruitment, and career planning, thus paving the way for small teams (mentoring teams) to apply loosely Pair Programming and healthy growth in the future.

This article is the final article of "Agile development loose Pair programming practices". The practices of this series are only applicable to the microenvironments of several developers, for more information about the external large teams, see the "large agile development team: 139 team model" series.

------------------------------------------------

Postscript

Any development method has limitations and merits, and the programming of loose pairs is no exception.

During years of development and consulting, I gradually found that all R & D methods will encounter difficulties, and all R & D methods can be applied in a certain way after deformation. The key issue is that when you encounter difficulties, do not deny the methods because of the difficulties, but actively seek answers to the difficulties. A good motto: It is not a lack of eyes to discover problems, but a lack of hands to solve problems.

Programming with loose pairs is the deformation after difficulties in Agile application development and Pair Programming in the actual environment. Therefore, when programming with application loose pairs is difficult, there is only one solution: continue deformation.

Agile development has been introduced into China for more than 10 years. However, if you ask which company has successfully applied agile development, there is almost no one who can come out and talk about the case well. The reason is nothing more than two:

1. The method is too superstitious. Therefore, if you try to use the method as usual, you will fail to accept the result.

2. If the attempt fails, you can give up easily.

The most overlooked in the whole process is the practitioner's own creativity. In fact, as early as the creation of scrum, Ken pointed out that SCRUM is only a starting point. He suggested that people start with original scrum to maintain a stable process framework, and then play it on their own. However, most people tend to like reading books, Baidu, Google, training courses, and blogs too much in their apps-including here, if they still cannot find them, they will not try to innovate any more, this deviates from the original intention of the founder.