Agile thinking: Methodology in Architecture Design (7)-combined use mode

Introduction:We have discussed four process models for agile architecture design. In this chapter, we will summarize these four process models, the relationships between the four persons and the Agile Methodology characteristics embodied in the model are discussed. Through the description in this chapter, you can have a better understanding of the previous content.

Focus of the four models

I classify four process models from requirements, Team design, simple design, and iterative design as the first level of architecture design. These four models can determine the framework of the architecture design process. Here we need to include
Clarify: the architecture design framework does not mean that you must strictly design the architecture according to the content described in this article.ArticleAt the beginning, we pointed out that the model can stimulate thinking. Therefore, this framework needs to be completed
To adapt to the actual situation. Actually, what we have introduced in this section is more biased towards principles. We have spent a lot of time discussing the ins and outs of principles. However, we need to grasp the principles by ourselves. Why
Do we not discuss principles? There are two reasons: one is that the software development team has different characteristics and it is difficult to define a general degree. The second reason is that my skills are insufficient and my practical experience is not rich enough.

The four models mentioned above actually discuss the methods in Architecture Design from four aspects. The source requirement provides the basis for architecture design. In the software process, the architecture design is undertaken by the demand analysis. If there is no good support for the demand analysis activities, the best architecture design is useless. Therefore, we put this model in the first place as the goal of architecture design.

With a fixed goal, there must also be an organizational guarantee. This is the second model-the origin of team design. Agile Methods advocate excellent communication, so team design is necessary and effective. In addition
One intention is to ensure that the downstream activities of the architecture design can be smoothly carried out, such as detailed design, coding, and testing. Since most people in the development team have joined the architecture design, different activities are minimized.
Inter-device information loss and low communication efficiency. If the demand model plays an inherited role, the team design model plays a starting role.

In the process of software design, communication often plays a very important role. The communication problems should be solved in the several models that started from the design of the team. The contribution of team design to communication lies in its ability to design
The diagram is spread to every corner of the development team at minimal cost. In this way, problems arising from poor communication between the design and downstream activities can be mitigated. In general, designing the code will experience a loss of information.
Coding personnel cannot correctly understand the intent of the design personnel, but the design personnel often cannot take into account some coding details. Although we can improve the quality of communication through common design symbols, such as UML. However
Practice has proved that, as long as smooth communication can be ensured, even if there is no good development method, the probability of project success is still high. Therefore, communication is the most critical issue for a single project. As long
Team design is a model worthy of application. Of course, in combination with the modeling language represented by UML, the communication effect can be improved.

During the design, we found that it takes some time to convert the design information to the encoding information, including the design organization time and the design understanding time. If the design is complex
The file is complex, and the time spent by the coding staff to understand the file will be greatly increased. Therefore, the trade-off is that a simple design specification can work with a certain degree of face-to-face communication.
To achieve better results. "Simplicity is more complex and effective", which is the basic idea of a simple design model.

Similarly, simple ideas are also used in various aspects of software development, such as documents, designs, and processes. Adhering to the simple principle and constantly improving it is a very effective way to reduce software development costs.

With the above ideas, we still need to face two practical problems. Changes in requirements will lead to design instability, and the complexity of requirements will lead to difficulties in simple architecture design. To solve this problem
We have introduced an iterative method to divide the problem into multiple sub-problems (decomposing a complex problem into multiple simple sub-problems is the most common solution in the computer field ). In this way, the scope and difficulty of the problem
Degrees are greatly reduced. What's more important is that design risks are minimized due to insufficient understanding of user needs or incorrect user expression requirements. Iteration is related to the previous models.

Requirements and iterations

The requirement model is the starter in architecture design. without the support of this model, the architecture design can only be a castle in the air. In fact, from the strict sense of demand model, it cannot be regarded as the characteristics of Agile Methodology, but should be regarded as the natural characteristics of software development. Unfortunately, it is such a basic principle that developers do not pay enough attention to it.

In Agile Methodology, we place requirements in a very important position. We take the source of the demand model as the first model of architecture design. The main purpose is to undertake the upstream work of architecture design-requirements. Demand decision
Therefore, we can see the strict demarcation line from the requirement to the design in the classic waterfall model. However, in actual development, according to the theory of the waterfall model, we often encounter many problems.
Break the boundaries between requirements and (Architecture) designs to form an overlapping area, thus improving the speed of software development. Therefore, we point out from the requirement model that the architecture design begins with the demand.

The most significant impact of demand on software development is the instability of demand. We are all very clear about the software development curve. The later the software development, the higher the cost of modifying the software. Therefore, the upstream needs of Software Development
The change will have a huge impact on the downstream of the software development. In order to coordinate this contradiction, the soft engineering theory puts forward the spiral development model, which is the theoretical basis of our discussion in the iterative development model. Software
The development process is divided into multiple iteration cycles. Each iteration cycle generates a deliverable software. After each iteration, you can try the software, propose the next step or change the original
Requirement. In this way, the risks of customers and developers can be reduced to an acceptable level.

Note the premise of iteration: the demand is variable. Therefore, for those projects whose requirements are easy to change, we can use the iterative development process, although we will pay some extra costs (at the beginning
This cost will be relatively large, but a long iteration cycle can be used to reduce this cost), but the risk is reduced. For projects with fixed requirements, whether it is necessary to use iterative methods depends on the specific environment.
. Therefore, we choose the development method based on the actual situation, rather than the reasons for advancement or popularity.

In fact, due to the characteristics of modern society, most projects can adopt iterative methods. Therefore, our choice is how long the iteration cycle should be. In theory, the shorter the iteration cycle, the better, but there is no absolute value. The time span is generally from several weeks to several months. Generally, the iteration cycle is affected by several factors:

• The degree of association of each module. In software development, it is sometimes difficult for us to separate some modules. To develop module A, we need Module B, and Module B needs Module C. The higher the degree of association of each module, the longer the iteration cycle. Of course, there are also corresponding solutions. We can select some key points in the functions of each module as milestones and milestones as iteration completion points.
• Average level of personnel skills and experience. The development capability and development experience of team members are poor, which is also a cause for the iteration cycle extension. Developers with low capabilities and less experience will drag the next iteration time. In view of this situation, it is very important to make overall planning well. You can use one or two iterations to find the bottleneck personnel in the team and arrange corresponding countermeasures.
• Lack of tools. The shorter the iteration cycle, the more build and release times the customer has more opportunities to modify the demand. This requires related tools to help developers control the software.
  The most important tool is regression testing. New features or modifications to the original features are required for each iteration, which may introduce new bugs. If regression testing is not performed, developers need
  It takes time to re-test the original function.
• Plan and control capabilities. The shorter the iteration cycle, the more planning and control capabilities are required. Because planning and implementation in a short period of time require a high degree of segmentation, this requires the development team managers
  Only by having a strong understanding of capabilities, workload, and task allocation can we do this well. However, the shorter the iteration cycle, the more iterations of the same development time, and the more opportunities for the team to adjust and improve the plan control.
  Therefore, later iterations can achieve more accurate control. Such an approach is much better than accumulating issues on the Software Delivery Day. No software that suddenly lags behind, only software that lags behind every day
  .

Simplicity and iteration

The relationship between simplicity and iteration is bidirectional.

In actual design, it is difficult to define the degree of simple design. What kind of architecture design is simple? According to our discussion in the simple design model, the architecture design that meets the current needs is simple.
Design. However, from another aspect, we have to make a simple design for the variable nature of the demand, because we cannot be sure of what changes will happen to the current demand in the future. Therefore, in order to overcome the fear of the unknown
Fear, we have spent a lot of effort designing a flexible architecture that can adapt to changes. This is due to the impact of the demand mode on the simple design mode.

From the discussion of the relationship between demand and iterative design, we suggest dividing the demand into multiple iteration cycles. The corresponding architecture design is also divided into multiple iteration cycles. This method can reduce the Architecture Design
Complexity. Because the designer does not need to consider all the requirements of the software, but only the requirements of the current iteration cycle. The reduction of complexity will help simplify the architecture design, so as to achieve a simple design of a Series
Column benefits (see simple design ).

From the last example of iterative design, we can clearly see how iterative design simplifies complex requirements. Grasping iterative design helps us avoid over-design problems. This is a technician.
Frequent mistakes. My team is often unavoidable. For example, in many projects, we spend a lot of time designing database-to-Business Entity ing. Such technical issues for development
The attraction of personnel is self-evident, but it must be seen that such design will lead to a significant increase in development costs. Even worse, unless you have a wealth of experience, this type of design will bring price to the development work.
The value cannot exceed the cost.

Therefore, we need to learn to weigh the advantages and disadvantages and whether it is necessary to invest a lot of resources to develop functions that are not so useful. Therefore, the combination of iterative design and simple design helps us to get rid of the troubles of over-design and focus on the truly important functions.

In addition, a simple design is not equivalent to a small amount of effort. Simple Design often requires an abstraction of the real world, recalling the examples of the measurement model we discussed in a simple design. It seems simple, however, implementation requires a lot of business knowledge and strong design capabilities. Therefore, to simplify the processProgramOne of the goals that Members are constantly pursuing.

In many methodologies, you do not pay too much attention to them.CodeRepeated problems are either not concerned, or the appropriate code repetition is allowed. XP, however, regards code duplication as an enemy of good code. "Only
To duplicate the code, it indicates that the Code still has the possibility of refactoring. "This kind of view looks absolutely absolute, which may be the origin of extreme in its name (in English
Extreme is a word with a very heavy tone ). From a practical point of view, although it is difficult to pursue code that is not repeated, the process can effectively improve the writing quality of the development team's code.
It forces you to re-improve the Code in each iteration, so you cannot be idle. This iteration feature promotes simple implementation.

Team and simplicity

In simple design, we mentioned that simple design requires comprehensive designers. In addition, it also requires the cooperation of teams. Simplicity means simplification of the delivery of artifacts between different activities. That is, similar to requirements
Books, design documents, and other things will be relatively simple. Because of this, it is hard to imagine that a development team geographically distributed in different locations or a large team of more than 50 people can use this simple document to complete
Development task.

Therefore, a simple design requires the team's organizational structure to ensure. Simple design requires that teams communicate with each other quickly. After the architecture design is complete, the architectural design ideas are communicated to all the coders.
The speed of the member is block. Similarly, if a problem is found in the code, it will be fed back to the designer. After improvement, the designer will be able to deliver the problem to the affected encoding personnel quickly. We can call this highly efficient dissemination.
Is "hot
Channel ".

To ensure "hot"
Channel "is highly efficient for communication. The best organizational unit is that developers are 3 to 6 people in the same studio. This structure ensures that the interaction speed of the message reaches the highest level, and no amount is required.
Communication costs, and there is no need for overly complex version control tools or permission allocation. Based on my experience, a shared version control tool, a network sharing tool, and a simple network database can be used to solve the problem.
Most problems are solved.

Theoretically, as long as the allocation is proper, a large team can also be organized as a pyramid sub-team to improve the efficiency of large teams. However, as the number of teams increases
The difficulty of correct allocation also increases, the efficiency of uploading and releasing communication information begins to decrease, and the gap between sub-teams begins to emerge. The accumulation of various factors leads to the fact that agile methods are not necessarily suitable for large teams, so we discuss
The agile methods mentioned in this Article will be restricted by the characteristics of the team.

Source of the Mode

If you have some knowledge of XP, you may feel that XP practices are applied in the model we are discussing. Indeed, XP has a lot of good practices. If it is well organized
Tiny practices will combine into a great set of development methods. However, the current state of chaos in software development blocks the use of advanced software methods, and it is only counterproductive to apply supplements to a weak patient.
Therefore, in the model discussed above, we have applied some practical methods that are easy to use and have obvious effects. In practice, the appropriate application of these methods does not require additional investment, but can have good results.
It will lay a good foundation for your team.