From production line to production Island: Understanding design and testing activities in Agile Development

Author: Chen Yong

Source: blog.csdn.net/cheny_com

 

The so-called production line is the responsibility of everyone, working in a linear process. The production line tries to improve efficiency through professional division of labor, but it also leads to the problem: in traditional production lines, intermediate products obtained downstream can continue to work on them without much understanding, for example, half of the cars are assembled and half of the food is processed.

But it is different in software development: people need to have a deep understanding of upstream products to continue their work, and this "depth" eventually leads to the expansion of intermediate products, most of the intermediate products belong to the class "cannot be made without software, and it is useless when software is made. Another serious problem is that each product line needs to solve the problem for each other. For example, if the design group is not designed properly, the development team should consider the design problem for it during development, while the Development Group's quality is not in place, the test group needs to work overtime to help it identify defects. This kind of work rather than assistance is caused by division of labor, which will eventually lead to a fight between various departments.

 

Production islands are quite different. Imagine a person or a small group of people who are not fishermen and hunters in the desert island lost, but all have the responsibility to complete the work, rather than pushing each other. When a problem occurs, the main task is not to find out who is responsible, but how to solve it. This solves the fight problem on the production line. Agile team is a production island team.

Because of the advocacy of the story responsibility system, agile developers have more vertical division of labor, that is, a person needs to cross-demand, design, coding, and testing. We have mentioned in the 139 Team (described in another blog post) and "loosely Pair programming" (described in another blog post, but not yet written, in order to solve the problem that not everyone is competent for the demand/design work, we will arrange a loose pair similar to 1 + 3, that is to say, a master leads three new players to form a group to complete a group of work. The former not only undertakes development tasks, but also helps the latter to complete the demand/design work in the way of joint participation.

So what should we do if everyone is competent, but no one is willing to do it? That is the agile test mentioned in previous blog posts. In "continuous integration/automatic testing", developers who submit code instead of testers are found to discover the defects for others. This changes the testers to discover the defects for others. Furthermore, if developers develop their own testing programs (at least regression functional testing programs), they will help themselves. If one day the entire development team needs to reflect on and act on the defects, rather than the test team accusing the development team of too many defects, the development team accused the design of being ambiguous.

 

Click to download the free agile development textbook: Martian agile development manual