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 clarify the meaning of the framework: the Framework of the architecture design does not mean that you must strictly design the architecture according to the content described in this article. Article At the beginning, we pointed out that the model can stimulate thinking. Therefore, this framework needs to be transformed based on 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 don't we 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. Another intent of the team design is to ensure that the downstream activities of the architecture design can be smoothly carried out, such as detailed design, coding, and testing. Most people in the development team have joined the architecture design, which minimizes the information loss and low communication efficiency between different activities. 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 is that it can spread the design intent to every corner of the development team at minimum cost. In this way, problems arising from poor communication between the design and downstream activities can be mitigated. Generally, the design-to-code process experiences a process of information loss. The 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 as the Organization is proper, 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 complicated, or the design documents are complicated, the coding staff will spend a lot of time understanding it. Therefore, the trade-off result is that, compared with the detailed design specification, 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, divide the problem into multiple subproblems (decomposing a complex problem into multiple simple subproblems is the most common solution in the computer field ). In this way, the scope and difficulty of the problem 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. The requirement determines the architecture. 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. Therefore, we try to break the boundaries between requirements and (Architecture) designs to form an overlapping zone, this increases 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, changes in the upstream demand of software development will have a huge impact on the downstream of 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. The software 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 projects that are prone to changes in requirements, we can use iterative development processes, although we will pay some additional 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 relatively 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 changes to the original features are required for each iteration. This may introduce new bugs without regression testing, developers need to spend time re-testing the original features.
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 need to be highly subdivided, developers need to have a strong understanding of development capabilities, workload, and task allocation in order to do a good job. 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. There is no software that suddenly lags behind, and 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 even a 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, we have made great effort to design a flexible and changeable architecture. 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 complexity of the architecture design. 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 series of benefits of simple design (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 problem that technicians often make. My team is often unavoidable. For example, in many projects, we spend a lot of time designing database-to-Business Entity ing. Such technical problems are self-evident in the degree of attraction to developers, 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, the value that this type of design brings to the development work often 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 process Program One of the goals that Members are constantly pursuing.
In many methodologies, you do not pay too much attention to them. Code Repeated problems are either not concerned, or the appropriate code repetition is allowed. XP, however, regards code duplication as an enemy of good code. "As long as the Code already exists, it indicates that the Code still has the possibility of refactoring. "This view seems absolutely absolute, and this may be the origin of extreme in its name (extreme in English 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, because it forces you to re-improve the Code in each iteration, there is no laziness at all. 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 to say, things like requirement statement and design document will be relatively simple. As a result, 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 tasks.
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 design ideas of the architecture should be communicated to all the coding staff for speed. Similarly, problems found in the coding are returned to the designers, after improvement, the designer can deliver the improvements to the affected coders quickly. We can call it "hot channel" for efficient dissemination like this ".
To ensure high communication efficiency of "hot channel", the best organizational unit is that developers are 3 to 6 people in the same studio. Such a structure ensures that the interaction speed of messages reaches the highest level without additional communication costs or complicated version control tools or permission allocation. Based on my experience, a shared version control tool, network sharing, and a simple network database can solve most of the problems.
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, in reality, as the number of teams increases, the difficulty of correctly assigning tasks also increases, the efficiency of uploading and releasing communication information begins to decline, and the gap between sub-teams begins to emerge, due to the accumulation of various factors, agile methods are not necessarily suitable for large teams. Therefore, the agile methods we discuss will be limited 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 many excellent practices. If well organized, these tiny practices will be combined 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, appropriate application of these methods does not require additional investment, but can have good results. At the same time, it will lay a good foundation for your team.
(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 by email iamlinx@21cn.com.
