I see scrum (2)

4. team collaboration

When talking about team collaboration, the most common thing we hear is the team responsibility system. In a small team, it is easy to form an external team Responsibility System (because of the collective sense of honor), which is also one of the reasons why scrum encourages small teams. However, in a team, it is not easy for everyone to implement team responsibility.

It seems easy to find the counterexamples. In a project with sub-features to people, there are bugs in the product, and almost always programmers say, well, this is not developed by me. You need to find a certain person. In another project, business analysts go beyond the best practices of the industry and ignore the comments of programmers. They must display all locations on the map at one time, rather than delaying batch loading, as a result, this function was reworked several times, and programmers complained.

To implement team responsibility within a team, the most important thing is to encourage everyone to participate in everything on the team. Participation is not always done. At least you must understand it. I don't know a module from start to end. I don't know any decision about this module. Is it possible to assume responsibility for this module? It's like a lot of big slogans posted at the door of the factory: the factory is my home, and I am a master, just a blank talk. In order to participate extensively, we need to implement collective code ownership; in order to participate extensively, we need to switch pair objects frequently; in order to participate extensively; we need business analysts, programmers, and testers to sit together to analyze and discuss stories. Of course, another benefit of doing so is to avoid the waste of knowledge transfer. To participate extensively, we intentionally weaken the role of experts and share knowledge in our team. To participate extensively, we set up an exciting project prospect.

Is that enough? Not enough. In the Microsoft Project survival rule, the Demand Class of software is divided into five parts, from bottom to top: survival requirements, the pressure of the project is not canceled, and the working conditions are reasonable; security requirements, meet your personal commitment to time and functions, do not arrange tasks that cannot be completed; sense of belonging and love, sound team motivation; self-esteem, team productivity, trust in project importance; self-realization, continuous development.

With regard to self-esteem, we emphasize that it is difficult to operate on people that are not right. One example is that when a design violates the design principles, the programmer is directly criticized and held irresponsible, leading to the departure of the programmer. Another example is that at the review meeting, a programmer criticized himself for not wanting to rebuild but to catch up with the progress. When it comes to a person and a thing, you need to understand the characteristics of each person in the team, and periodic private communication is the responsibility of each iteration manager. People themselves are ignored by setting a large principle. An extreme example is that some people have a point of view that agile cannot be fully attributed to the human problem, But he obviously ignores one point. agile is originally intended to solve human problems, A solution to human problems cannot be implemented because of human problems, which is not an irony.

5. full-featured team

Scrum advocates a full-featured team. One idea is that a team that pursues excellence requires everyone to do everything without accepting the division of labor. From my personal point of view, I do not agree with this point of view. My point of view is that a team pursuing excellence has to focus on their own things and think about everything at the same time. That is to say, I agree with the division of labor. Why is the division of labor professional. Just as a roadside clinic deals with all kinds of diseases, experts only exist in specific fields.

A counterexample is that when a project encounters a serious performance problem, developers use selenium for performance testing, which takes several months, many of which are used to build the environment, the final effect is not big. This requires the professional skills of testers.

Another counterexample is that after a special tester is introduced in the later stage of a project, bugs are continuously discovered. One feature is that the edit box is displayed on the list page, when the list contains 20 data pages that need to be rolled, the edit box does not scroll. As a result, the last few data pages cannot see the edit box, And the programmer has not found this bug, however, testers almost immediately discovered the problem. In this case, the tester needs to think differently.

So, why should we emphasize the full-featured team and other people's perspectives?

The first and most important thing is to avoid waste. Software development is a mental activity. There is a work handover between business analysis, development, and testing. This kind of handover actually shows the transfer of knowledge, and the transfer of knowledge makes the division of labor blurred. Business analysis analyzes problems from the perspective of customers, programmers analyze problems from the technical perspective, and testers analyze problems from the perspective of customer use (ease of use, various boundaries, finally, the implementation of the story must be the result of coordination between the three. Therefore, everyone needs to think from the perspective of others. The sooner informal communication is established, the better, the less rework. In the above example, as business analysts did not notice the technical constraints, programmers did not stick to their own opinions (in fact, there is no more in-depth thinking ), as a result, the implementation of the map is repeatedly tossed and wasted.

The rest are incidental. For example, a tester is very interested in writing code due to extensive participation in the Team's sense of responsibility, and when the tester occasionally is not enough and the programmer temporarily replaces it to balance production. For balanced production, what I want to say is that occasionally there is no problem, but if a Team frequently needs programmers to perform the testing on their behalf, the problem is obviously that there are not enough testers, the right solution should be to add testers instead of requiring programmers to test.