[Recommendation] Twelve principles of extreme programming-minor version

Minor version: Use the minimum amount of Code to bring the greatest business value.

This principle means to demonstrate the development progress with the customer for high iteration. The release of minor versions is a good way to communicate, and the customer can provide targeted feedback. However, the small version reduces the number of modules and affects the overall idea of the software. Therefore, the small version also requires a reasonable overall plan.

In this case, we feel that this principle has no applicability to our company's products, and we cannot let operators bear such a high degree of iteration process. However, as I mentioned at the beginning, the purpose of studying agile development and extreme programming is not to solve all the problems, but to develop ideas and prevent our rigid thinking. I have observed that the automated testing and debugging software developed by our testing department is very suitable for using this principle. Who is the customer? It is an internal customer responsible for production debugging.

Automated Testing and debugging software has a major feature: rapid changes, and this feature is precisely addressed by the agile development theory. At present, the management intensity of such software is far weaker than those of the product software, on the one hand, because the demand for these software changes too fast during use, if according to the company's specifications to output various types of documents, in addition, regular process management will affect your work if you fail to respond in a timely manner. On the other hand, it is the subjective factor of developers. This kind of software is often used by developers to communicate with production debugging personnel on the production line and modify the software instantly. This kind of habit leads to a natural phenomenon, our "customers" have developed a habit, and developers have been forced to develop a habit: At the beginning, developers often want to make software easier to change than hardware, so let's change it, one day, I suddenly found myself in a quagmire.

As the Configuration Management of the technical department, I have discovered many chaotic versions of these automated testing and debugging software, and from the feedback from the personnel who use the software, we can also hear complaints about software quality. This is what I said about the "quagmire": as a developer, I am tired of making changes every day, but cannot get the approval of "customers". How depressing this is!

Can we consider using agile development to solve these problems? Or, how can we "CREATE" A solution suitable for our actual situation through a kind of thinking inspiration? I have come up with some improvement methods:

N. Add the minor version information to view the major and minor version information during software running.

N adds the online update function so that programs can be updated in a timely and accurate manner wherever they are in the company, as long as they can be connected to the internal network.

N adds the version check function to check whether the version needs to be updated as needed, so as to ensure that all clients run on a benchmark when needed.

N added error feedback and log functions to ensure that necessary information can be fed back to developers via email when an error occurs. In this way, the problem cannot be reproduced when the problem is reported, or the problem cannot be clearly reported.

These methods are actually functions that we can see in many software. They are not novel technologies and are easy to implement, in addition, we can use these functions as a public module to ensure that different automated testing and debugging software do not need to be developed repeatedly. The implementation of these functions will make you feel more convenient.

With these foundations, we can make the high iteration process easier to control and implement in the software development process with higher efficiency and time savings, only when possible can we think and improve. Just as our arm is free and our breathing is smooth, we can save ourselves from the quagmire.