Full-function team of data articles

In the construction of the full functional team and the construction of a full functional team-practice article two articles, my colleague, Hu, has described the need and good practice of building a full-featured team, and since then many people have shared their understanding, or bullish, or pale, in discussions around this topic. There are many teams in ThoughtWorks who have been working on a full-featured team, and in this article I would like to share with you the data I've collected from these teams over the past year, and the more immediate understanding.

Brief review

Fully functional Team

It is not only a software development team made up of versatile members of Multi-skill, but also a team of shared responsibilities by all members. The responsibilities of the team are no longer coupled with the specific personnel, everyone is likely to do and have the ability to do more than a traditional role: for example, at some point, the developer is doing the test, the tester is doing business analysis, the business analyst is doing the deployment, front-end development, back-end development, and database maintenance are treated by developers alike. All people can communicate with their clients and take on project risks that only the traditional project managers are frustrated with.

Questions from the software development industry

In the discussion of the full-featured team, the most intense questioning focused on two aspects of capacity and efficiency:

In terms of efficiency, unless the team is poor, the division of labor is inevitable: team members frequently change the work function, it means to do something is not particularly skilled, whether this reduces efficiency? For example, the high repetition of the test work, although the introduction of simple, but a traditional developers also need some time accumulation of experience, in order to replace the full-time QA, to achieve rapid and efficient testing; Should I find someone to do the deployment?

From a capacity perspective, the division of labor seems to be necessary: Let the business analyst understand whether the code implementation is necessary, will not be too pushy? Developers have strong code and business reading capabilities, but do they also have the same level of test-case design capabilities? Even the versatile team has a limited skill depth.

With such a problem, we have proven in practice over the past year the viability of a fully functional team and have benefited greatly from the development of team members and the sustainability of projects.

How do we do that?

For efficiency issues

The usual consideration of the efficiency originates from the industrialized production, and the repetitive work after division of labor can improve the proficiency of labor and thus improve the production efficiency. However, knowledge work is not a screw on the assembly line, its core problem is effect (effectiveness) rather than efficiency (efficient) 1. Generally speaking, the fastest typing is not necessarily a good programmer, 100 lines of code is not necessarily more valuable than a line of code. So what's really important for a valuable software developer is to know what to do, why, and how to do it correctly.

In a fully functional team, we let members do different roles, that is, to break the barriers to knowledge, let everyone stand in different ways to see our software, transfer knowledge, expand cognition; When you look back at what you've done, the knowledge from other roles will help us do the right thing in a more correct way. At the same time, the benefit of developing generalist team members is that it is helpful to adjust the number of people who do something or to schedule a replacement for the team.

We do this:

We do not divide jobs for front-end development, back-end development, and operational dimensions, requiring all developers to be exposed to all levels of code and environment. With a comprehensive understanding, no one "because they did not dare to touch," so the next step is to improve their ability to do things better.

We rotate every two weeks to be a member of the test work. To be a tester, he will test the capabilities of the development and regression test components, which helps him understand the overall behavior of the system, and he brought his own development experience, not only in the external functional level test, but also in-depth code mining, more than a professional tester to find potential defects.

Our business analyst plans to schedule a regression test for each deployment and scheduling before deployment, and the functionality of the deployment should be very clear; they have to prepare comprehensive acceptance criteria for each feature to be developed, and even write acceptance test descriptions (Given/when/then) 2, which is a very readable user story, Because acceptance tests can be directly communicated to customers or developers.

We do not have a fixed user interface with the client to communicate, all the rotating testers need to show the completion of the function to confirm acceptance, all the people are obligated to ask customers the difficult needs, all the people take turns to do iterative reports or review meetings.

Information on all projects is shared within the team, and pair programming is rotated 2 or 3 days, reducing the contextual blind spot of team members, making it easy for everyone to locate and handle problems correctly.

Addressing capacity issues

The fear of ability is understandable: no one can be quite sure of the things they do, or even the first time they do, to be independent; everyone's technical ability is limited, and the shift of responsibilities means the challenge comes. However, this is a team, no one alone, and will not arrange for members to do things.

The full functional team is focused on the ability issues of team members and the sustainability of the project. Training a member to become a new responsibility is a stretch of his ability, as long as the method is proper, the team will be a few months after the harvest of a number of Multi-skill versatile members. And this growth is not at the expense of temporary project progress, the project and personnel growth does not stand in opposition.

We do this:

After the responsibility and individual to the coupling, refining a number of responsibilities, such as business analysis, testing, front-end development, database maintenance, deployment and so on.

We identify leaders, called coaches, for each responsibility. A coach is an expert in a certain role, such as a Test manager, who is the most capable and known person in the test, and who is the one who has to coach the test skills to Marian to help him adapt to the new role.

When a new person grows up, the coach tracks the progress of his work and only reaches out to help in complex situations, such as some emergency response. Coaches are also responsible for the first time in response to customer questions, they are the customer and development team on a certain aspect of the work of the interface, customers know want to track the progress of a work, as long as contact him.

The coach of a certain duty is also often a "newcomer" to other duties, he also needs to be helped, and he needs to be equally competent in his new duties.

From the sustainable progress of the project, the fully functional team can easily overcome the personnel short board, and maintain a high team cohesion. Because the team is a versatile member, and we maintain very frequent communication and information sharing, it is easy for individuals to do things even if they are replacing each other's positions.

In my team, there are a lot of things that other non-functional teams can't imagine:

Without a dedicated tester and deployer, everyone has the ability to develop, test, and deploy to a product environment, even if it is only half a year of college graduates to join the team, can choose this burden alone. The project's deficiencies and delivery schedules remain on average, without the lack of professional expertise resulting from the absence of a "full-time" staff.

Never obstruct a job because of someone's sudden leave of absence. This is thanks to the full information sharing and pairing work of the versatile members every day, and anyone who has taken a leave of absence will be able to replace him immediately.

It is easier to remove members from a project than to cause a project to be in distress because of the departure of the key person. Four months ago, when the woman who was doing business analysis and project manager suddenly learned that the pregnancy needed a vacation, we only made a simple handover, completed the personnel changes, and maintained a smooth project delivery capacity; Now this responsibility has already been successfully handed over to another member.