Fourth, team design
Team design is a very important practice in agile methodology. The team we said here refers to people who are not a plural. A group of people is a group of people and there is no way to form a team. To be a team, there are a lot of work to do.
We consider considering the team-based design because software development itself is not a personal thing, and the architecture design is even more. Some people think about it is not exempted from being owed, and single individual's knowledge is not possible to cover all disciplines. The organizational effective team can make up for these shortcomings.
Context
Who is responsible for the design of the architecture?
Problem
In our impression, it is always considered that the architecture design is the exclusive work of the so-called architect designer. They often have rich design experience and related skills. They don't need to write code, they can design theoretically perfect architecture, equipped with exquisite Legend.
Question 1: Theoretically designed a lack of proof of the lack of procedures in theoretically, often there is such a problem in practical applications.
Question 2: Designer design architecture has a lot of subjectivity, often ignoring customer needs, causing architectures that cannot meet demand.
Question 3: The implementation of the programmer has an emotion of this architecture, or because of the failure of the architecture achievement because it does not understand the architecture.
Question 4: Architect design architecture is mainly based on its own large experience, and the design of the design cannot be realistic reflecting the current software needs.
Solution
Theoretical basis for team design is group decision. Compared with personal decisions, the biggest benefit of group decisions is to be more complete. Although group decisions have their advantages, their disadvantages are also very obvious: there is an additional communication cost, low decision efficiency, and not clear responsibility, and so on. But if group decisions can organize properly, it is possible to play a big advantage in architecture design.
Avoid architecture design of ivory tower
For software, architecture design is a crucial job. Such a job is very dangerous. Even if this person is smart, he may miss some details. The strength of the organizational effective team is much larger than personal power, so the results of the team's results are more winning more than the level of stability and thinking.
Scott W. Ambler gives the concept of ivory Tower Architecture in its work:
An Ivory Tower Architecture IS ONE THATE OFTEN Developed by An Architect OR Architectural Team in Relative Isology To The Day-to-Day Development Activities of Your Project Team (s).
China's current software development industry has gradually emerged as an ivory tower architect designer. These architects do not participate in actual procedures, his job is to make a beautiful architecture model for projects, which is theoretically quite perfect.
Example 1: In XP, we basically see the shadow of architecture design. It is not to say that the Team using XP technology does not require architecture design. XP does not have a dedicated design period, which advocates the use of some simple ideas, metaphorical ways to express software architecture, and this architecture design is not in time. In fact, the design in XP is the way team design, the group of string, Collective Ownership, and the Collective Ownership, are the foundation of the team design, which is based on the oral communication mode. By adopting such a way, XP does not require documentation to express architectural design.
Excellent architects can fully utilize existing frames, reduce software investment, and enhance software stability. These are not wrong, but the problem is "I'm still too". Ivory Tower Architects often have those issues that have begun to pointed out. The architecture design is not very complex work, but it requires developers to have relevant skills, experience, and have a certain understanding of the problem domain. Developers often have relevant technical skills (programming, database design, modeling), and understanding of the problem domain can be helped from users and industry experts. Therefore, in theory, we have to achieve teaming of architecture design is completely possible. In the ivory tower architecture definition, we see architects and daily development work isolated. Such an architecture has a large limit. In reality, we will also find another role that from the outside of the development team, providing developers with relevant technical or business training. This role is called the coach, which is a very important role in software development, and cannot draw an equal sign between ivory tower architect designers.
Choose your design team.
Software architecture is important in the whole process of software life cycle, that is, all people in the software development team need to deal with the architecture. Therefore, the best team organization is the design of all developers involved in the architecture, and we call this way for all members. The participation of all the participation guarantees that all developers can make their own opinions on architecture design, and consistently reached all developers. This approach is especially suitable for some small teams.
There will be a lot of teams that are not suitable for use in all-in-one. Then, organize excellent developers' formation groups are also better ways. Generally, we have chosen those who have more important in the project, more developed experience, or those with solid atrial to form a design group. Of course, if you take into account the training of subsequent power, you can also let some newcomers join the design group, or you feel that your own development power is insufficient, inviting external consultation power to intervene, which is completely dependent on the specific situation.
The design group is different from the ivory tower architecture designer we mentioned before. The architecture designed in the design group can only be called the original architecture, which is a constant feedback and improvement. Therefore, in architectural implementation, members of the design group will be distributed to various fields of the development team, bring the architecture to all developers, write code to verify the architecture, and obtain specific feedback, then all members are also concentrated The evolution of the architecture in the design group.
Problems in team design
In the process of team design, we will encounter a variety of problems, and the first rush is the issue of communication costs. When architecture design, demand has not been fully understood, and software design ideas are still in a germination. In this case, each member of the team has unique insights for software, which may be the same, some are mutually exclusive. Just like blind, their views represent part of the software or on the one hand, but there is no way to represent all software.
In agile methodology, each of our processes is running quickly and is constantly improving. The architecture design is also the same, we can't spend more time in an architecture design. Team decisions always tend to discuss and trade.
The problems in Example 2 occurred in the architecture design, and the discussion of pure technology was easy to rise. There is almost no way to avoid this situation. Team-type decision will inevitably have a conflict of concepts. Conflicts to control a certain degree of concepts are beneficial to the team's decision-making, but if this extent means that it is out of control, it is necessary to adjust the team leader. More importantly, we need to pay attention to communication skills:
Team communication
When the team is architecture design, communication is a very important question. The above situation often occurs in software organizations, because the technicians naturally think that their technology is better than others, if their own technology is questioned, then afraid The other party is a discussion attitude, which is also challenged by the authority of their own, and the face is to defend anyway. And communication If you bring such a subjective color, then the audience of communication information will receive information on the decline of the potential. Instead, he will find the vulnerability in the other party and prepare for counterattack. Therefore, we must pay attention to cultivating a good communication atmosphere. In actual observations, I found two roles in team communication, one is a suggestion, and they can often make suggestions. One is a question, and they are advised to propose a negative view. These two roles are possible to interchange, and now the suggestion may be the question of just now. The questioner's statement is to hit the enthusiasm of the suggestion, and in a glimpse conference, it is best to play the role of suggestions, which requires the host of the meeting to master this, It is recommended to give affirmative evaluation and encourage everyone to put forward new suggestions.
Example 2: Agility method is very concerned that the team's communication. Communication is a very interesting topic that will spend a lot of time, we are just a simple discussion for communication issues that may exist in architectural design. We assume a discussion situation here, this situation comes from a true life:
Xu Hui, the designer Li Hao, the designer Li Hao, and the designer Roever is discussing a new software architecture.
"Li Hao do you think this software database connection section should consider?" Xu Hui asked.
Li Hao wants to think, "I think the plan is a good ..." "Solution A must have problems! This software is different from the last time." Luo Yiming interrupted Li Hao's statement.
"What do you know! How long have you been to the company, the program A is a long-lasting certificate!" The speech was interrupted, Li Hao was a little annoyed, and Luo Yi Ming did not have long, but in some things, I always sang a reverse call.
"How long does I enter the company and what is the relationship between the mistakes of the program A!"
In such an atmosphere, the results of the meeting can be imagined.
Good communication helps architecture design work. A member of a member is flat, you can design a good architecture by good communication, and a team with an excellent member, if there is a lack of communication, it will eventually connect. There are a lot of this example in reality.
Standard and style
We always use a variety of standards and styles in unknowing. In the team design, in order to improve the efficiency of decision-making, we can consider using unified standards and styles. The unified standards and styles are not formed on the evening. Because everyone has their own different habits and experiences, mandatory requirements developers use a unified standard (style) that can easily cause the developer's dissatisfaction. Therefore, you need to pay attention to skills in operation. For architecture design, more important standards (styles) include the following categories:
·interface design
·Process Design
· Modeling specifications
·Coding Standards
· Persistent layer design
·Test Data
In my experience, some organizations do not pay attention to the accumulation of standards (style), think that this accumulation belongs to the spurs, but it is these skills that improve communication efficiency and reduce the learning curve of developers. Imagine if the code written by everyone in a team is different standards and styles, then understanding is much more difficult. Of course, we don't have to develop a set of standards (styles), there are many materials that can be borrowed directly. The best standard is the UML language. We can download from the UML's official website to the latest specification, and commonly used coding standards are more visible. However, although there is a unified standard, if the style is not uniform, it will also cause communication obstacles. For example, the class diagram displayed below, although they represent the same class, but due to the difference in version, visibility, the degree of detail, it looks great. In other standards, this difference is also common. Therefore, after we use a unified standard, we should use the same style. Scott W. Ambler has set up a website discussion of UML modeling style, interested readers can do additional reading. Figure 4. Class diagram of two styles
Terminology is further used based on the unified style. Using communication between communication, understanding dedicated terms can represent a lot of information. The best term is the model name of the design pattern. If both parties of communication understand design patterns, then one party only needs to say that this part can use the factory model, and the other will understand without any explanation of the design ideas. This communication method is the most efficient, but the learning curve it needs will also be steep.
Team design four clear
In order to maximize the efficiency of team design, you can consider 4 aspects:
1, clear goals
There is no significance of the general conference in the conference, and there is no such meeting without a distinctive theme. In the demand mode, we talked about the architecture that can have non-functional needs, can have a functional demand architecture. Therefore, before the team design, we need to be determined. What problems to solve this time is the architecture of discussing business logic, or a technical architecture; is a global architecture or a structure of each module.
2, clear division of labor
We pay attention to the team, a very important amount is a region where different members have different good people. Some members may be good at modeling business logic, some good at prototype design, some good at database design, and some are good at Web programming. Can you imagine that a software doesn't have an interface? (Some software may be this case) You can imagine that only a software has a database, and does not have a logic? Therefore, architectural design requires integrated considerations to make full use of members' advantages. This requires all members of the team to clarify their division of labor.
3, clear responsibility
In addition to clearing their own divisions, each member needs to be aware of his responsibility. Without responsibility, the division will not have any effect. Every member needs to be clear what you have to do. Of course, and responsibility is relatively, no members do need to know what their power is. These are clear, the premise of efficient communication is available. Everyone discussed, everyone is clear, what you have to do, what you need to ask others, who should be responsible for yourself. If these problems can't answer, then this discussion is white.
4, clear communication mode
There may be a little inappropriate here, and you can consider information flow in order to clearly express this. A complete architecture consists of several aspects, which are responsible for those people, how to generate, what should be generated? Such an information flow includes three clearly mentioned above. If everyone can work hard for the generation of the architecture, and smoothly design the architecture, then this process is perfect. If you find some of these people don't know what to do, then this is the problem of processes. The perfect process will have an additional by-products. After the architecture is generated, the team's design is very clear. Because we advocate as many developers participating in the architecture. Not just architecture
It is discussed here that there are many contents have been designed from the architecture. That is, many of the principles and techniques are other activities that can be used for software development. What is the ability to use these methods? Everyone can think about this problem with their actual situation. Prompt a point, the key start is that the current efficiency is lower.
