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.
| 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. It advocates the use of simple legends and metaphors to express the software architecture, which is always ongoing. In fact, the design in XP is based on team design. Pair Programming and collective ownership of code (collective ownership) are the basis of team design, that is, oral communication. In this way, XP almost does not need documents to express the architecture design. |
|
Avoid ivory tower 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 appear Article 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 technical skills (programming, database design, and 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 from outside the development team to provide developers with relevant technical or business training. This role is called a coach and plays a very important role in software development. It cannot draw an equal sign 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 to involve all developers in the design of the architecture. We call this approach full participation. The full participation ensures that all developers can put forward their own opinions on the architecture design, integrate various opinions, and reach an agreement among 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 people who are important in projects, have more development experience, or have solid theories to form a design group. Of course, if you consider the future strength of the organization, you can also ask some new users to join the design group, or you feel that your development is insufficient, and invite external consulting personnel to intervene, this 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 members of the Design Group will be distributed to various fields of the development team, bring the architecture idea to all developers, and write code to test the architecture, obtain specific feedback, and then all the Members will concentrate on the Design Group to discuss the evolution of the architecture.
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. |
|
Problems in team Design
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. Just like blind people, their opinions all represent part or part of the software, but there is no way to represent the whole of 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. Conflicts of ideas within a certain degree of control are beneficial to the team's decision-making, but if they exceed this level, they mean 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 their technology is questioned, the other party may be challenged by their own authority by holding a discussion attitude, face must be defended in any way. If such a subjective color is applied to communication, the audience of the communication 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. These two roles may be exchanged, and the current suggestion may be the suspect. 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. Unified standards and styles 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 the communication efficiency and reduce the learning curve of developers. 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 need to develop a set of standards (Styles) 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, even though there are uniform 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, they seem quite different because of the differences in the edition, visibility, and details. 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 this article.
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 both parties understand the design model, 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, but the learning curve it requires will also be steep.
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 and functional requirements. Therefore, before designing a team, we must first determine what issues to solve this time, whether it is to discuss the architecture of business logic or technical architecture; whether it is a global architecture, or the architecture of each module.
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, some are good at database design, and 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, no member needs to know what his or her power is. These are clear and the prerequisites for efficient communication are met. After each architecture discussion, everyone knows what they want to do, what they need to ask others to do, and who they should be responsible. 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 includes several aspects, all of which are under the responsibility of those persons. How should we generate and what the entire process should be like? Such an information process includes the three definitions mentioned above. If everyone in the team works hard for the creation of the architecture and designs 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 has clearly defined the software design. 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.
(To be continued)
Author profile:
Lin Xing, Senior Project Manager of the Project Management Group of Chen Xun software studio, has many years of project implementation experience. Chen Xun software studio is committed to the application of advanced software ideas and software technology. Its main research direction is software process ideas, Linux cluster technology, OO technology and software factory model. You can contact him via email iamlinx@21cn.com
