Build a full-featured team

Introduction
Developers of the team are immersed in "perfection" in their imagination"ProgramTesters are confused and click the button to find out what the function is. The designer creates an endless stair, and even worse, the customer falls in love with the design; team leaders are everywhere to fight the fire. There are indications that we have to break the barriers of division of labor and build a full-featured team-a team that most people can do most jobs.

During a chat, my girlfriend's mother talked about the fact that the intern doctor had to take a one-year shift to study separately. I questioned: "For doctors who are dedicated to heart disease treatment, didn't he waste a year on irrelevant learning? ", Her mother smiled and said, "If you don't do this, how are you sure the patient has a heart disease ?". I don't know why, but I suddenly see such a scene? The tester asked, "Is this a defect (not an operating system/browser restriction )?".

Adam and pin factory
Adam Smith introduced the benefits of social division of labor when describing specialized production at the pin factory in 1973: improving proficiency, reducing overhead during task switching, and facilitating machine application. It seems that we can naturally push and export repeated designs, Recode, and repeated tests can increase the technical proficiency of corresponding employees, improve efficiency, and thus improve the profitability of enterprises.

However, the constant changes in the market make repeated production dream absent, and switching tasks become more and more frequent. IT companies are not pin factories. After all, there are two differences between knowledge workers and physical workers in the process of changing labor subjects. One is the difference between local optimization and overall optimization, second, the difference between doing the right thing and doing the right thing.

There is a mathematical problem. Assume that each developer can complete a function every day. The tester can test two functions every day. The team consists of three developers and one tester, how many functions can be tested in a week?

The first response of most people is 5 (day) X2 (function/day) = 10. The following table will tell you that the tester has no measurable function on Monday due to load imbalance, in fact, the team cannot deliver 10 functions within a week.

Monday, Tuesday, Wednesday, Friday, total
Developer 3 function 3 function 3 function 3 function 3 function 15 Function
Tester 0 function 2 function 2 function 2 function 2 function 8 Function
(Table 1)

Let's change the conditions. Suppose there are 4 developers in the team and the developers can participate in the test. What will happen?

Monday, Tuesday, Wednesday, Friday, total
Developers 4 functions 4 functions 3 functions 2 Functions 0 functions 13 Functions
Tester 0 Function 0 function 2 function 4 function 8 function 14 Function
(Table 2)

We were able to deliver at, with a 60% increase in output. If we leave only three all-powerful people:

Monday, Tuesday, Wednesday, Friday, total
Developer 3 function 3 function 3 function 1 function 0 function 10 Function
Tester 0 Function 0 Function 0 function 4 function 6 function 10 Function
(Table 3)

Two more features are delivered than the combination of three developers and one tester!

Of course, we have reason to question the assumption in question 2: "developers can be qualified as testers ". Or continue to discuss data changes in iteration 2. My answer to this question is:
First, I can see from my observations that the reason why developers do not perform the testing is not that the capabilities are not allowed, but that the testing work is simple, repetitive, and boring and unwilling to do it. Objectively, developers are more expensive and difficult to cultivate. Such a "waste" is not allowed at the organizational level ".

The bias towards testing has objectively led to the selection of testing engineers as a profession by a large number of people who do not have the technical skills, while the lack of skills leads to a simple repetition of testing work. To a large extent, testers are unable to determine what is right (to do the right thing), so they are more inclined to operate in accordance with the script (to do the right thing ).

Second, my focus is not on delivery at or. I hope this example will inspire everyone to think about balanced production.

The demand and implementation of software can be refined, but it is not a pin after all. The demand and implementation are often associated and dependent. In other words, the increase of local efficiency cannot be directly converted to the increase of overall efficiency. The optimization of overall efficiency often relies on balanced production (see table 3), that is, eliminating the production peaks (over-production) and troughs (insufficient production), to avoid the task from being too tight, productivity waste during loose hours (full-time testers at Monday hours), working overtime and shoddy work.

I tend to think that Adam Smith's assumption about the division of labor is: stable demand and simple production. Are these assumptions still true for the IT field?

Wrapper of the screw
It is not difficult to find that the superstitious division of labor and individual efficiency have profoundly influenced the IT field. The clues of division of labor have been revealed during recruitment. Even for graduates with little difference, employers will test their skills based on different standards (Java ,.. net, PHP, etc.), and assign them different titles, such as front-end engineers, backend engineers, test engineers, and support engineers, you may even be responsible for the maintenance of a document within a visible career.

Optimization of overall efficiency requires the IT team to eliminate technical barriers, cultivate multiple teams, and elastically adjust tasks based on planned changes to achieve a balance between roles and processes. For IT enterprises, changes must begin from recruitment. Finding people with enthusiasm for learning, learning ability, and learning habits has become a top priority. Do employees have certain skills?AlgorithmThe language or tool should be downgraded from the entrance criteria to a proof of its learning ability and enthusiasm (not the only one.

Optimization of overall efficiency requires that employees must continue to learn and grow. Interest is undoubtedly a catalyst for growth. However, meaningless work is constantly killing people's interests. Dan? Herry wrote in the weird behavior:

Workers are separated from their own production activities, labor targets, and production processes. This makes work a non-spontaneous activity. Therefore, workers cannot recognize or appreciate the meaning of labor, but lack the meaning, professionals may feel as if they were playing the role of Charlie Chaplin in the modern age movie, and everything was controlled by the gear of the factory. They would not have the desire to work wholeheartedly.

If an employee needs to grow, it is necessary to help the employee realize the full picture of the work. Role rotation is a good solution. In the project, roles are exchanged and there are no restrictions on Role pair work. The knowledge transfer between different roles and modules is enhanced to break technical barriers and help employees understand projects and train their skills from different perspectives, this increases the team's ability to balance production.

In my opinion, the biggest obstacle to role rotation is the widespread lack of programming capabilities, and most of the testing and demand analysis work (given the position of most teams, the demand analyst is actually speaking too much, the more accurate name is the requirement organizer), iterative management, simple customer communication, and low learning curve. Any member can quickly master the key points of work under the guidance of the master, however, programming is an exception. Even for newcomers with good foundations, under the guidance of experienced mentors, it may take about two months to write decent unit tests and object-oriented programs. Under the division of labor system, developers using other roles to rotate are almost endless.

It is strange that the IT field places so much emphasis on abstract and logic analysis capabilities that can prove the endless stream of modeling languages, models, domain models, and architectures. However, an activity that best trains abstract and analytical capabilities is only carried out selectively. Does this mean that we believe that IT projects can be unavailable to most people (and cannot) when consensus is reached, how can it be smoothly launched and successfully delivered? In my opinion, writing a program is not only a skill, but also a way of thinking. It also undertakes the purpose of constructing a common experience zone among IT team members to improve the communication efficiency.

One experience worth learning from other industries is to first cultivate the basic quality and then enter the field to cultivate professional quality. In other words, to avoid premature division of labor, all new people start their career from programming, at the institutional level of the company, every new employee can experience all roles within his/her capacity. After having a certain basic quality, after the employees have a full understanding of the work content and their own interests, they can enter the field to develop their professional skills according to their personal wishes, interest will become the internal motivation for the growth of employees, and good basic qualities will enable employees to display their ideas in their professional positions.

At the same time, the company should encourage employees to work across borders. The author of applying selenium and Ruby for domain-oriented web testing is a developer with excellent capabilities, he has been conducting tests for a long time. When others complain that automated interface testing is difficult to maintain, his excellent abstract and analysis capabilities have helped him extract the test mode, identify defects, find an elegant and efficient way of working, and give birth to this excellentArticle.

Dan iResearch said in my heart.

Integration of knowledge and industry

In the past nine months, we have conducted initial practices for building a full-featured team. Before sharing specific practices, I hope the following summary data will help you gain some background knowledge.

The project deals with futures trading and uses the C # and ASP. net mvc technology stacks. The team consists of eight developers and two testers (one of them joins the project in the middle of the Project). Four of them are graduates and three have working experience, however, only one developer has just joined thoughtworks. NET development experience.

The following figure shows the burnout of all 35 weeks. The black solid line represents the scope of the project, the green solid line represents the development completion speed, and the blue solid line represents the test completion speed. Each week is an iteration.

In most of the regions of this figure, blue and green overlap or are very close, which means that the functions completed by the team for each iteration are exactly aligned with the processing capability of the tester. On the one hand, this is due to the efficiency improvement of the automated testing framework implemented by testers themselves. On the other hand, the participation of developers in testing also balances the development and testing speed.

Let's take a part of the development process and observe the speed of each iteration. In the following figure, the horizontal axis represents the iterations, and the vertical axis represents the number of Function Points completed by each iteration.