-Build a development and management process with change as the core

Changes in project requirements are the most troublesome thing in project management. If the management and control of changes are poor, it may lead to confusion in the development and management of the project team, this reduces the efficiency of software development, increases project costs, and even causes project failures.
Change-oriented project development management is suitable for the following types of projects:

• The lifecycle is not obvious;
• The requirements and scope are unclear and may change frequently;
• Large-scale application projects;
• A product-based Continuous Development Project.

These projects are characterized by the inability to implement development step by step based on the basic software development lifecycle model, even if each milestone or stage is divided by the lifecycle model, frequent customer or external changes often make the project team tired of coping with these changes, while the internal project team is in disorder in terms of task allocation, job inspection, and role division. Project management is also relatively passive.
Of course, this situation is generally suitable for the middle and late stages of project or product R & D, and the preliminary work is usually a whole task.
How can this problem be solved? In fact, many models have already provided answers, such as RUP and XP. However, when learning and using these models, we often feel that the concepts and implementations proposed by these models are difficult to operate and implement, in addition, no matter it is RUP or XP, since it is a method model, it is inevitable to describe it as a complete and systematic theoretical model, otherwise it will not reflect the theoretical integrity and logic rigor. The following describes the process of development and management with changes as the core, so as to avoid being passive and active in the case of frequent external changes.
At the end of the project, there will be more customers involved, so there will be more changes in customer requirements. In addition, with the deepening of the test, all problems found during the test must be handled and solved by the project team. Therefore, we take a certain version of the project as a baseline and follow-up tasks, whether it is new requirements, change requirements, defect modifications, or other improvements, upgrades, and Optimizations to the system, the change request is not called Cr (Change Request) or Mr (Modify request) because everyone is used to making a change request a passive task, it is even a change in the scope of the project, but rarely a change is regarded as the management mode of the project task. Therefore, update is defined as any modification to the existing system.
Each change is similar to a small waterfall for iterative development. Different iterations can be performed in parallel. You must manage the branches of each version for the configured version. This is very important, otherwise the version issue will become a time bomb for the project.