Agile thinking: Methodology in Architecture Design (4)-team Design

Introduction:Team design is an important practice in Agile Methodology. The team we are talking about here is not a plural person. A group of people is a group and cannot form a team. To become a team, you have to do a lot of work.

The reason why we consider architecture design on a team basis is that software development is not a personal task, especially architecture design. A single individual's thinking cannot be considered properly, and his or her knowledge cannot cover all subjects. Effective teams can make up for these shortcomings.

Context

Who is responsible for architecture design?

Problem

In our impression, we always think that architecture design is the exclusive work of those so-called architecture designers. They often have rich design experience and related skills, and they do not need to writeCodeIn this way, we can design a perfect theoretical architecture with exquisite legends.

Question 1: theoretically designed architecture that is almost perfect lacksProgramIn practice, such problems often occur.

Question 2: the designer's design architecture is subjective and often ignores the customer's needs, resulting in the architecture being unable to meet the requirements.

Question 3: The implemented programmer is in conflict with the architecture or fails to implement the architecture because he does not understand the architecture.

Problem 4: the architect's design architecture is based on a large amount of experience. The architecture designed cannot reflect the current software requirements.

Solution

The theoretical basis of team design is group decision-making. Compared with personal decision-making, the biggest benefit of group decision-making is that its conclusions are more complete. Although group decision-making has its advantages, its disadvantages are also obvious: Extra communication costs, low decision-making efficiency, unclear responsibilities, and so on. However, if group decisions can be properly organized, they can play a major advantage in architecture design.

Avoid ivory tower Architecture Design

Example 1: In XP, we basically cannot see the architectural design. It does not mean that teams using XP technology do not need architecture design. XP does not have a special design period.
Some simple legends and metaphorical ways to express the software architecture, and this architecture design is carried out all the time. In fact, the design in XP adopts the team design method, pair
Programming and collective ownership of code (collective)
Ownership) is the basis of team design, that is, oral communication. In this way, XP almost does not need documents to express the architecture design.

For software, architecture design is a crucial task. It is very dangerous to give such a job to someone. Even if he is smart, he may miss some details. The strength of an effective team is greatly greater than that of an individual. Therefore, the achievements of the team are superior in terms of stability and consideration compared with those of the individual.

Scott W. Ambler provides the concept of ivory tower architecture in his book:

An ivory tower architecture is one that is often developed by an impact ect or
Specified tural team in relative isolation to the day-to-day development
Activities of your project team (s ).

In China's software development industry, ivory tower architecture designers are also emerging. These architects are not involved in actual programming. His job is to create a beautiful architecture model for the project, which is theoretically perfect.

Excellent Architects can make full use of existing frameworks to reduce software investment and enhance software stability. None of these are wrong, but the problem is "too late ". Ivory Tower architects often appearArticle
Start to point out the problems. Architecture design is not very complex, but it requires developers to have relevant skills, experience, and a certain understanding of the problem domain. Developers often have related technologies.
Skills (programming, database design, modeling), and understanding of problem domains can help users and industry experts. Therefore, in theory, it is entirely possible to implement a team-based architecture design.

In the above ivory tower architecture definition, we can see that architects are isolated from daily development work. This architecture has great limitations. In reality, we will also find another role,
He is from outside the development team and provides developers with relevant technical or business training. This role is called a coach and plays a very important role in software development. It cannot be painted with an ivory tower architect.
.

Select your design team.

The software architecture is important throughout the software lifecycle. That is to say, all the people in the software development team need to deal with the architecture. Therefore, the best way to organize a team is for all developers.
All participate in the design of the architecture. We call this method full participation. The full participation ensures that all developers can put forward their own opinions on the architecture design and integrate various opinions to reach the goal of all developers.
. This method is especially suitable for small teams.

There are still many teams that are not suitable for full participation for various reasons. Therefore, it is also a good way to organize excellent developers to form a design group. Generally, we choose
It is important to have more development experience or people with solid theories to form a design group. Of course, if you consider the future strength of the organization, you can also let some new users join the design group, or you feel like you
Insufficient development power. inviting external consulting power to intervene depends entirely on the specific situation.

The design group is different from the Ivory Tower architecture designer we mentioned earlier. The architecture designed by the design group can only be called the original architecture. It requires constant feedback and improvement. Therefore, in architecture implementation, the design group
Members will be distributed to various fields of the development team, bring the architecture idea to all developers, write code to test the architecture, and obtain specific feedback, then all the Members will go to the design group to discuss the architecture
Evolution.

Problems in team Design

Example 2: Agile Methods focus heavily on team communication. Communication is a very interesting topic. It takes a lot of time to talk about it. Here we will just give a simple discussion of possible communication problems in architecture design. Let's assume that a discussion situation comes from a real life:

Project Director Xu hui, designer Li Hao, and designer Luo yiming are discussing a new software architecture.

"Li Hao, what do you think about this software database connection part? "Xu hui asked.

Li Hao thought, "I think solution a is good... "" Solution a must have a problem! This software is different from the previous one. "Luo yiming interrupted Li Hao's speech.

"What do you know! How long have you been in the company? solution a has been proven for a long time! "Li Hao was a little annoyed when his speech was interrupted. It was not long before Luo yiming entered the company, but he was always playing against him in some cases.

"How long have I been in the company? What is the relationship between the error of solution! "

In such an atmosphere, the results of the meeting can be imagined.

In the process of team design, we will encounter various problems, the first of which is the cost of communication. In architecture design, the demand has not been fully understood, and the software design idea is still in the initial state.
In this case, each member of the team has a unique view of the software, which may be the same and mutually exclusive. Like blind people, their opinions all represent part of the software or
But there is no way to represent all the software.

In the Agile Methodology, every process is quickly and constantly improved. The same is true for architecture design. We cannot spend more time on one architecture design. Team decisions tend to be discussed and weighed for a long time.

The problem in example 2 occurs in architecture design. The discussion of pure technology is easy to rise and is called a quarrel. There is almost no way to avoid this situation. Team-based decisions will inevitably conflict with ideas. Control certain
Conflicts of ideas within a certain degree are beneficial to the team's decision-making, but if they exceed this level, it means they are out of control and need to be adjusted by the team leader. More importantly, we need to pay attention to the communication skills:

Team communication

Communication is a very important issue when the team designs the architecture. The above situations often occur in software organizations, because technicians naturally think that their technology is better than others
If your technology is under question, the other party may have a discussion attitude, but it is no different from the challenge of its own authority. face must be defended in any way. However, if communication is subject to such a subjective color
The audience of the information will subconsciously reject the information. On the contrary, he will find vulnerabilities in the other party's discourse and prepare to fight back. Therefore, we need to cultivate a good communication atmosphere.

In actual observation, I found that there are two roles in team communication. One is the author who can often make suggestions. The other is the Q & A, who give a negative view of the suggestion. The two roles are
If they can be exchanged, the current suggestion may be the suspect just now. The speaker's speech can strike down the enthusiasm of the suggestion maker. In a brainstorming meeting, it is best for everyone to assume the role of the suggestion,
This requires that the participants of the Communication meeting be able to master this point, give positive comments on the suggestions, and encourage everyone to make new suggestions.

Good communication is helpful to the development of architecture design. A team with the same ability can design an excellent architecture through good communication. If a team with a good member lacks communication, the design may eventually fail. Many examples can be found in reality.

Standard and Style

We always use various standards and styles without knowing them. In team design, we can consider using unified standards and styles to improve decision-making efficiency. The unified standards and style are not
Formed overnight. Because everyone has their own different habits and experiences, it is mandatory to require developers to use uniform standards (Styles), which may lead to dissatisfaction of developers. Therefore, you must pay attention to the skills in operations.
Important standards (Styles) for architectural design include the following categories:

• Interface Design
• Process Design
• Modeling specifications
• Code Specification
• Persistence Layer Design
• Test Data

In my experience, some organizations do not pay attention to standard (style) accumulation at ordinary times. I think this accumulation is a skill, but it is exactly these tips, it can effectively improve communication efficiency and reduce developers'
Member learning curve. Imagine that if the code written by everyone in a team is of different standards and styles, it would be much more difficult to understand. Of course, we do not have to develop a set of standards by ourselves
In reality, there are a lot of materials that can be directly borrowed. The best standard is the UML language. We can download the latest standard from the official UML website. common coding standards are everywhere. However
However, there are unified standards. If the style is not uniform, it will also lead to barriers to communication. For example, although the displayed class charts represent the same class, the differences in version type, visibility, and details indicate
There is a big difference. Among other standards, this difference is also common. Therefore, we should use the same style after using the unified standard. Scott
W. Ambler has set up a website to discuss issues related to the UML modeling style. Interested readers can read more.

Figure 4.
Two Style Class Diagrams
 

On the basis of a unified style, the term is further used. Both parties know special terms, which can represent a large amount of information. An example of the best term is the pattern name of the design pattern. If communication
Both parties understand the design model, so one party only needs to say that this part of the design can use the factory model, and the other party can understand it, without having to explain the design ideas in detail. This communication method is the most efficient,
It also requires steep learning curves.

Team Design

To maximize the efficiency of team design, you can consider the following four aspects:

1. Define goals

It is meaningless to hold a general architecture discussion meeting, and there will be no results for a meeting without clear themes. In the requirement-based model, we talk about architectures with non-functional requirements.
Architecture with functional requirements. Therefore, before designing a team, we must first determine what issues to solve this time, whether to discuss the architecture of business logic, technical architecture, global architecture, or model.
Block architecture.

2. clear division of labor

One important reason why we pay attention to the team is that different members have different areas of expertise. Some members may be good at business logic modeling, some are good at prototype design, and some are good at data
Data library design, some are good at web programming. Can you imagine that a software has no interface? (Some software may be like this.) Can you imagine that a software has only a database, but no processing logic? Therefore,
The architecture design needs to comprehensively consider all aspects and make full use of the advantages of members. This requires that all members of the team be clear about their division of labor.

3. Clarify responsibilities and rights

In addition to clarifying the division of labor, each Member must be aware of their responsibilities. Without responsibility, the division of labor will not have any effect. Each member needs to specify what he/she wants to do. Of course, relative to the responsibility,
No member still needs to know what his or her power is. These are clear and the prerequisites for efficient communication are met. Every time the architecture is discussed, everyone knows what they want to do and what they need.
People are responsible for what they do. If these questions cannot be answered, the discussion will be wasted.

4. Clarify the communication methods

The communication method may be a little inappropriate here. to clearly express the meaning, you can consider the word "information flow. A complete architecture consists of several aspects: who are responsible and how to generate it,
What is the entire process? Such an information process includes the three definitions mentioned above. If everyone in the team can work hard for the creation of the architecture and design the architecture smoothly
This process is perfect. If you find that some of them do not know what to do, this is a problem with the process. The perfect process also has an additional by-product. After the architecture is created, the team
The software design is already very clear. Because we advocate as many developers as possible to participate in architecture design.

Not just Architecture

As mentioned above, a lot of content has already been removed from the architecture design. That is to say, many principles and techniques can be used in other activities of software development. Which activities can use these methods? You can consider this issue based on your actual situation. Note that the key to getting started is the current low efficiency.