Agile thinking-methodology in Architecture Design (1) view architecture design from methodology

What does methodology mean for software development? How do we look at the methodology in software development? Can methodology become a lifeline for software development? After reading this article, these questions will be answered.
In Article 1ArticleTo understand the meaning of some words in the title. What is methodology?
What is agility?
Why is architecture discussed?
Methodology
The methodology is methodology in English and is interpreted as "a series of related methods or techniques". We can define it as software development (for software development) A complete set of methods, processes, rules, practices, and technologies. I agree with Alistair Cockburn's statement about the issues with methodology. "methodology stems from fear. "Due to fear of Project expiration, out-of-control costs, and other factors, the project managers developed some methods and techniques for controlling and monitoring projects based on their previous experience. This is the cause of the methodology.
In agile software development, the author mentioned the thirteen elements of methodology, which can basically cover all aspects of methodology:
Role)
Personality)
Skill (skills)
Team (teams)
Techniques)
Activity (activities)
Process)
Work Products)
Milestone (milestones)
Standard)
Quality)
Tools)
Team Value)
The relationship between them can be expressed in a diagram:
Figure 1. 13 elements of methodology

Many methodologies involve part of the thirteen elements listed above. Therefore, we can regard methodology as an abstract, infinite superset, in reality, methodologies refer to a finite subset of supersets. The relationship between them is like the relationship between rational numbers and integers 1 to 100. Both XP and uidesign experience belong to a subset of methodology, but there is a size difference between the two subsets. We should also see that it is meaningless to discuss a complete methodology. Therefore, this methodology does not exist, just as if the view did not cite all rational numbers. Therefore, our statement about a general methodology is meaningless. Good methodologies, such as XP and the crystal series, all have a suitable scope, because they understand that they are not an omnipotent methodology.
In reality, we are constantly engaged in methodology. For example, to control the project progress, the Project Manager asks all developers to submit a detailed progress report every week. This is a method and a skill. If we organize these skill systems in the development process, we can become a methodology. You may say that the generation of that methodology is too easy. No, the methodology generated in this way does not have much practical value, and there is no need for a methodology without practical value. Therefore, a successful methodology is a methodology that can be accepted by multiple projects and successfully implement the delivery of software.
My colleagues and I have done some experiments in practice, hoping to apply some good methodologies to the development team. The results of the experiment were helpless and the effects of methodology implementation were not ideal. At first we thought it was the reason for the method itself. Later, we found that things were not that simple. During the experiment, developers agreed with the advantages of the methodology, but they did not stick to it during the implementation process. In Agile Software Development, I found that the author encountered the same problems as ours.
After interviewing a large number of project teams, Alistair Cockburn wrote agile software development. Prior to the interview, he decided that he would find that highly precise process control is the key to success. As a result, he found that this was not the case. He attributed his findings to seven laws. My findings are also included in these seven laws. In summary, there are only two points: communication and feedback.
As long as good communication and instant feedback are ensured, the development team can succeed even if it does not adopt an advanced methodology. On the contrary, those "high-quality" teams often fail due to the lack of these two factors (Here we refer to failure where users refuse to use the final software ). Face-to-face communication is the most effective way, and the lowest cost. As the project team grows, or some other factors (such as geographic location isolation), face-to-face communication becomes more and more difficult to implement, which leads to the increasing cost of communication and the decreasing of quality. However, this does not mean that non-face-to-face communication is indispensable. What is important is that we need to know that the cost and quality of different communication methods are different. The XP method emphasizes face-to-face communication, and ensures effective communication through on-site customers, standing meetings, and Pair programming. In my experience, a development team actually needs a combination of multiple communication methods. Complete face-to-face communication is difficult for some teams to implement. The key to the problem is how you apply the communication methods to achieve the desired effect. A team was particularly eye-catching in the l'oreal Entrepreneurship Program competition, where they had never met each other and completed efficient cooperation with the Internet and telephone. Although they did not use face-to-face communication, they still achieved their stated goals. The same is true for software development. Face-to-face communication is essential, but other communication methods are also required.
Looking at the feedback, whether it is controlling the progress or ensuring customer satisfaction, these activities need to manage costs. A common feature of management costs in software development is intermediate delivery ). For example, our requirement specification, analysis documents, design documents, and test plans are all intermediate deliverables. The increase in intermediate deliverables will lead to a reduction in efficiency, because the time spent by developers is spent on completing the work of intermediate deliverables, the time spent on new software features is reduced. The main purpose of the intermediate output is to ensure that the software is as intended as the customer, such as the requirement specification, and the other is to serve as input to the work of other members of the team, such as development plan and test plan. Therefore, we can also discuss countermeasures based on these two points. One is to use iterative ideas to increase the frequency of software release, so as to ensure that customers' needs are indeed met, the other is to narrow down the communication scope of the team and ensure that Members can get new ideas from others, instead of writing standard internal documents (internal documents refer to documents only required for communication between internal developers ).
Therefore, the success of a software project is not directly related to the development methodology you adopt.
Weight
Based on the fact that we have a large number of artifact (the official version of the RUP is an intermediate product in the software development process, such as the requirement specification and Design Model) compared with the complex control software development method, the heavy (heavy weight) method is called the light weight method. In the traditional concept, we believe that heavy methods are much safer than light methods. The reason why we come up with a heavy-duty approach is that in medium and large projects, project managers tend to stay away from code and cannot effectively understand the progress, quality, cost, and other factors of the current project. To overcome the unknown fear, the project manager has developed a large number of intermediate management methods to control the entire project. The most typical case is to require developers to frequently submit various reports that indicate the current status of the project.
In the book of planning XP, there is an incisive discussion of the lightweight and heavy-duty methodology. It refers to the heavy-duty methodology as a defensive posture (defensive posture ), the light methodology comes down to a desire for success (plan to win) mentality. If you adopt a defensive posture, your work will focus on preventing and tracking errors. A large number of workflow is developed to ensure that the project does not make mistakes, rather than project success. This method is not bad, but the premise is that if the entire team can meet the two conditions mentioned above, the project will certainly succeed, but one drawback of the heavy methodology lies in, everyone is preventing errors and fearing errors. Therefore, the relationship between people is very subtle and it is difficult to achieve full communication. In the end, even the evaluation of people becomes the basis for evaluation, rather than achievement. When we were doing the experiment, a project manager joked, "the methodology stems from the fear of the project manager. That's right. But the worst thing is that the entire team only has one project manager who is afraid. If everyone can fear it, there will be no fear. "This sentence reminds us that if a team is striving for success, the team's mentality is different from that of other teams, especially the wrong attitude. There is no need to spend a lot of effort to prevent mistakes at all. If a mistake is made, you can immediately correct it. This is actually a desire for success.
Methodology Art
Management is called the integration of science and art, while the artistic part of management is largely reflected in human management. I said that methodology is also a fusion of science and art. This is well-founded. In fact, methodology and management are close relatives. One branch of management is project management. In software organization, project management is very important, methodology is a specific project management (or a subset of project management) for software development ).
One of the biggest problems with heavy-duty methods is that he does not know or ignore the art layer, ignoring the human factors, and regards people as a measurement unit, a resource, and a linear element. The human element is very important in software development. Software development is actually a transfer of knowledge and intelligence. The final product is a kind of knowledge product, its cost depends on the Knowledge Value of developers. Therefore, people are the most important factor. It is difficult to measure the human factor. Everyone has different personalities, ideas, experiences, and experiences. The combination of so many complex factors leads to unpredictability. Therefore, we emphasize the art of manipulation.
The simplest example is that in heavy-duty methods, our basic assumption is that we do not trust people. The project manager must control the project. However, distrust can lead to many problems, such as low morale, inability to keep up with changes, low innovation capability, and high skip rates. People all want to be respected, and technicians pay more attention to this point. Many companies also say how people-oriented they are, but they use development methods that are based on untrusted people. We say that the starting point of agile methods is mutual trust. It is very difficult to achieve this, but once it is done, this team is very competitive. Therefore, this creates a problem. Before we fully trust each other, do we trust others? This is the artistic question I mentioned, when do you want to trust people? When you don't trust people, these are the issues that need to be weighed, and they are also the issues that express your artistic nature.
Agility
Agility represents efficiency and flexibility. We call lightweight and effective methods agile methods. In heavy-duty methods, we waste too much energy on unnecessary and repetitive intermediate links, while agility avoids such waste. Our article will focus on the Agile Methodology. The predecessor of agile is lightweight. An agile alliance has been established, and they have formulated the agile declaration:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
My understanding of agility includes the following aspects:
Low management costs and high-quality output. There are two extremes in software development: one is that there is no management cost, and all the work is for the production of software, but this method often leads to chaos in the software development process, low product quality, low team morale. The other is the addition, review, change management, and defect tracking of a large number of management activities. Although the addition of management activities can improve the orderliness of the development process to a certain extent, the cost is increased, worse, it can easily lead to team inefficiency and lower innovation capabilities. Therefore, the agile method view finds a balance point and uses low-cost management activities to bring the maximum output, that is, the high quality of software.
Respect human nature. Agile Methods respect human nature and emphasize efficiency. Software development can be said to be a mental investment. If the developer's voluntary investment cannot be ensured, the product will be compromised. Facts have repeatedly proved that the efficiency of a developer who is willing to invest is more than three times that of a developer who is unwilling to invest, and the contribution to the Organization is more than ten times.
Communication and feedback are the foundation of everything. We have discussed the importance of communication, and instant feedback is a prerequisite for embracing changes.
The customer is God. Without a customer, the importance of the customer can be described in one sentence, that is, building the right system at the right cost at a reasonable cost ).
In fact, agility is equally important. The key is whether it can be effective and flexible. Therefore, an idea advocated by Agile Methodology is "barely sufficient )". However, this "enough" is not so easy to judge. An eight-person team adopts the XP method. With the skillful use of the method, the team's abilities are constantly improved, and the problems that can be handled become more and more complex, maybe they can handle the problems that 20 teams of people using heavy-duty methods can handle. However, if the number of people in the team suddenly increases to 12, the team will certainly have problems, and his performance may not be as good as that of the team of 20 people. When the number of people increases, the original method must be adjusted as appropriate. For example, you can add some heavy method skills in the original agile method. We cannot require a team of 6 people and a team of 20 people to use the same method. The former may adopt less agile methods, and the latter may adopt more agile methods, the key issue is that both teams focus on the key factors of communication, feedback, and frequent delivery of software, that is, being effective and flexible.
Architecture Design
Architecture (also known as architecture) is an important part of software design. In the process of software development, the software can be finalized after the requirements and architecture are determined. This is like determining the skeleton. This person's shape will not change much. So I chose architecture design to discuss Agile Software Development (I have already written about the requirements ). We have discussed the concept of superset and subset before, so the architecture design we will discuss next is also a very small subset. If methodology has not gone through the tests of many projects, it cannot be called a successful methodology. I do not think that my architecture design is a good methodology, but it still needs to be thrown out, his main purpose is to spread an idea. Therefore, I have adopted the Pattern Language (Plop) as the form of writing architecture design. The main reason is that pattern is a good way of organizing ideas.
Therefore, in our next journey, we will focus on the three elements of architecture, methodology, and agility. This article does not discuss how to code and implement the software architecture, nor simply regard it as a guide to architecture design. In fact, many ideas in this article come from the methodology, therefore, many of the architectural design ideas mentioned here are also applicable to other work. If you can understand this, you may get more from this article.
(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.