Seven, combined mode of use
We have discussed the four process modes for agile architecture design. In this chapter, we make a summary of these four process modes and discuss the relationship between 4 people and the agile methodological characteristics embodied in the model. Through this chapter, everyone can have a further understanding of the previous content.
Four modes of focus
I derived the demand, team design, simple design, and iterative design. These four process modes were classified as the first level of architecture design, which can determine the framework of architecture design processes. Here, it is necessary to clarify the meaning of the frame: the framework of architecture design is not to be structural design in strict accordance with the content introduced in the text. In the beginning of the article, we pointed out that the model can stimulate thinking. Therefore, this framework needs to be combined with actual and transformation. Real, we introduced this part, compare the principle, we spent a lot of time to discuss the principle of the dragon, and the principle, you must take yourself. Why don't we discuss the principles? There are two reasons here, one is that the software development team has its own characteristics, which is difficult to define a general degree. The second reason is that my level is not enough, practical experience is not rich enough.
The four modes mentioned earlier are actually discussed from the four sides of the method of architectural design. Since the demand provides the basis for architecture design. During the software, architectural design is to undertake demand analysis. If there is no support for good demand analysis activities, no use is useless. So we put this mode in the first place, as the target of architecture design.
With the identified goals, there is also an organization's guarantee, which is the second mode - the origin of the team design. Agility methods advocate excellent communication, so team design is necessary and effective. Another intention of the team design is to ensure that the downstream activities of the architecture design are smooth, such as detailed design, coding, testing, etc. Since the people in the development team have joined the architectural design, the maximum amount of information loss and low communication efficiency are reduced to the maximum extent. If the demand model is inherently, the team design mode is playing the role.
Communication often plays a very important role in the process of software design. All modes starting from the team design are all communication problems. The contribution of team design to communication is that it can spread the design intent to propagate every corner of the development team with the smallest cost. In this way, the design and downstream activities can be relieved due to problems that are not intensified in communication. In general, design to encoding will undergo a information loss process, and the coder cannot correctly understand the intentions of designers, but designers often cannot take into account some coded details. Although we can improve the quality of communication by common design symbols, such as UML. However, practice proves that as long as it is possible to ensure smooth communication, there is no excellent development method, the probability of success is still high. Therefore, for a single project, the most critical problem is to communicate. As long as the organization is proper, the team design is a model worthy of application. Of course, the modeling language representative represented by UML is more capable of improving communication.
In the design, we found that when the design information is converted to encoding information, it takes a certain time, this time includes the design of the design tissue time, the design is understood. If the design is more complicated, or the design of the document is more complicated, the coding person will be greatly increased. Therefore, the result of the trade-off is that the simple design manual can play a better effect with respect to the detailed design specification. "Simple to be more complicated", this is the basic idea of simple design patterns.
Similarly, simple ideas will also be used in various aspects, such as documents, design, and processes. Adhere to simple principles and constantly improve, which is a very effective way to reduce software development costs.
After having the above ideas, we also need to face two reality. The changes in demand will lead to unstable design, and the complexity of demand will lead to a simple architecture design. In order to solve this problem, we introduce the iteration method, divide the problem into multiple sub-problems (decompose a complex problem into multiple simpler sub-problems is the most common method of processing in the computer.). In this way, the scope and difficulty of the problem are greatly reduced. More critical is that due to insufficient design risk of insufficient user needs, it is lowered to the lowest point. Iterations and the previous model have a relationship. Demand and iteration
Since the demand model is a starting in architecture design, there is no support for this mode, and architecture design can only be air-building. In fact, the strict sense of demand model cannot be considered the characteristics of agile methodology, but should be considered the natural characteristics of software development. Unfortunately, this is such a basic principle, but it has not been able to attract enough to pay enough attention.
Agile methodology puts demand in a very important location, we derived demand models as the first model of architecture design, mainly the purpose of the upstream work - demand for architectural design. Demand decision architecture, therefore, we can see the strict boundary line of demand to design in the classic waterfall model, but in actual development, we will encounter a lot of problems in accordance with the theory of the waterfall model, so we tried Break the boundaries between demand and (architecture) design, forming an overlapping zone, thereby improving the speed of software development. Therefore, we pointed out in the demand model, the architecture design started with demand.
The most impact on software development is the instability of demand. We are all very clear that the curve developed, and the higher the cost of modifying the software. Therefore, changes in the demand for software development will result in the effect of subtoprosting in the downstream of software development. In order to coordinate this contradiction, the soft labor theory puts forward a spiral development model, which is the theoretical basis of our discussion in iterative development model. The software development process is divided into multiple iterative cycles. Each iterative cycle will finally generate a delivery software. After each iteration, the user can try software, put forward the next demand or change the original demand. In this way, the customer, the risk of the developer drops to an acceptable level.
Please pay attention to the premise of iteration: the variability of the demand. Therefore, for items that are prone to changes, we can use iterative development processes, although we will pay some extra costs (just starting this cost is relatively large, but you can use longer iterative cycles to reduce this Cost), but the risk is reduced. For items that are more fixed, it is necessary to use the specific environment. Therefore, we use the development method based on the actual situation, not because advanced or popular reasons.
In fact, due to the characteristics of modern society, most of the projects can use iterative methods. Therefore, our choice has become more than the iterative cycle. The better cycle should be theoretically, better, but there is no absolute value, and the span of time is generally from a few weeks to a few months. In general, iterative cycles will be affected by several factors:
· The degree of correlation between each module. In software development, we sometimes separate some modules to develop modules a, require module B, and module B needs module C. The higher the degree of correlation between each module, the longer iterative cycle. Of course, the corresponding solution, we can take some key points in the functionality of each module, as a milestone, with milestones as an iterative completion point.
· The average of personnel skills and experience. The development capabilities of members in the team are well-developed, which is also a reason for the extension of iterative cycles. Low capability, and less experience will drag the time after each iteration. In response to this situation, it is very important to do a good job in coordinating plan, you can use one or two iterations to find the bottleneck personnel in the team and arrange the corresponding countermeasures. · The lack of tools. The shorter the iterative cycle, it means build, the more the number of issues, the customer has more opportunities to modify demand. This requires related tools to help developer control software. The most important tool is the regression test tool. Every iteration needs to add new features, or for the original function, it is possible to introduce new bugs. If there is no regression test, developers need time to retest the original function.
· Plan, control. The shorter iterative cycles, the stronger the ability to control, the ability to control. Because of the planning and implementation of the plan to develop and implement a high-level subdivision, this requires a strong understanding of the development capabilities, workload, and task allocation to do this. However, the shorter iterative cycle, the more iterations the same development time, the more team adjustments, the opportunity to improve plan control, the more opportunities. Therefore, the later iterations are generally able to perform comparatively more accurate control. And such practices, it is better than the problem that the problem is accumulated to software delivery. Without a sudden backward software, only the software is backward every day.
Simple and iteration
Simple and iterative relationships are two-way.
In realistic design, we have difficulty derived a simple design level. What kind of architecture design is simple? According to our discussion in simple design patterns, the architecture design that is just satisfying the current needs is simple design. However, from another aspect, the variability of demand will limit us to make a simple design because we cannot affirm what changes will change in the future. Therefore, in order to overcome the unknown fear, we spent a lot of strength to design some flexible and adapted to change architectures. This is the impact of the simple design pattern originating from the demand model.
Discussion from the relationship between demand and iterative design recommends that we are divided into multiple iterative cycles. Then, the corresponding architecture design is also divided into multiple iterative cycles. Such methods can reduce the complexity of architecture design. Because designers do not need to consider all the needs of the software, just consider the current iterative cycle. The reduction in complexity will contribute to the simplicity of architecture design, thereby achieving a simple design of a series of benefits (see Simple Design).
We can clearly see how the iterative design is simplified in the last example of iterative design. Grasping iteration design helps us avoid excessive design. This is a problem that a technician is often committed. I can't avoid it many times. For example, in a lot of projects, we spend a lot of time to design a database to the business entity mapping. The technical problem such as such a technical problem is self-evident, but it must be seen that this design will result in a significant increase in development costs. What is even worse is unless there is extensive experience, the value of this type of design will not exceed its cost.
Therefore, we need to learn to weigh the spres and disadvantages, there is a need to invest a lot of resources to develop actually there is no useful function. Therefore, the combination of iterative design and simple design helps us get rid of excessive designs, focus on true and important functions.
In addition, simple design is not equivalent to less pay. Simple design often requires abstraction of the real world, recalls the example of the measurement model we discussed in simple design, it seems simple, but realizes a lot of business knowledge, strong design capabilities. Therefore, it is one of the goals that the programmer is constantly chasing.
In a lot of methodology, it is generally not a matter of paying attention to code repetition, or it is not concerned, or the appropriate code repetition is allowed. And XP depends on the enemy of good code as a good code. "As long as there is a duplicate code, you will show that the code still has the possibility of refactoring." This view looks very absolute, which may also be the origin of EXTREME in its name (English in English belongs to a word that is very heavy). From the perspective of practice, the pursuit of non-repetitive code is hard to do, but the process can effectively improve the quality of writing team code, because it is forced to improve the code in each iteration, can't Silk sloth. And this iterative characteristic promotes simple implementation. Team and simple
We have given a simple design to fully designer in a simple design. In addition, it also needs teamwork. Simplely means that the delivery workpiece between different activities is simplified. That is to say, things like the demand manual, the design documentation, will be relatively simple. Because of this, we are hard to imagine a geographically distributed development team or more than 50 people can use this simple document to complete the development task.
Therefore, a simple design is to ensure the organization of the team. Simple design requirements team's mutual communication can be carried out quickly. After the architecture design is complete, the architecture design ideas convey to all the coder's speed to block, similarly, the encoding is found, give back to the designer, and the designer conveys the speed of the encoder who has received the affected code. fast. As such high efficiency, we can call it "Hot Channel".
In order to ensure the high communication efficiency of "Hot Channel", the best organizational unit is between 3 and 6 people and is in the same studio. Such a structure ensures that the interaction speed of the message reaches the highest, and no additional communication cost is required, nor does it require too complicated version control tools or permission assignments. According to my experience, a shared small version control tool, network sharing, plus a simple network database can solve most of the problems.
In theory, we say that as long as the large team can organize a pyramid sub-team to improve the work efficiency of large teams. However, in practice, with the increase in the number of teams, the difficulty of the task is also increased. The efficiency of communication information will begin, and the balance between the sub-team begins, and the accumulation of various factors leads to agile methods. Not necessarily suitable for large teams, so the agile methods we discuss will be limited by the characteristics of the team.
Source of the pattern
If you have a certain understanding of XP, then you may feel the Practice of XP in our discussion. In this way, there are many excellent practices in XP. If organized, these tiny practices will be combined into a set of great development methods. However, the current software development chaotic status is to prevent the application of advanced software methods, and apply that tonic to a patient's weak patient will only be counterproductive. Therefore, in the previously discussed mode, we have applied some practical methods that are easy to apply and have a significant effect. Appropriate application of these methods in practice does not require additional investment, but it can have a good effect, and it will also make a good foundation for your team.
