Background of the question:
In the software center of traditional banks, with the rapid development of the mobile Internet, Internet companies have brought a huge impact on traditional banks. Many opportunities are often fleeting, and traditional development methods are difficult to adapt to the rapid changes in the Internet era. Traditional banks are beginning to introduce agile development models in an attempt to solve this problem.
However, at present, within the bank, there are large-scale centralized architecture systems similar to the core system, as well as distributed systems and mobile applications created in the torrent of Internet development.
Naturally, the development of the latter type of system began to try the agile development model. However, in the process of adopting agile, they gradually discovered the following problems:
For a large part of the project, the key transaction routing needs to go to the traditional banking part of the system, and the development method of these systems is still waterfall. Under the agile model, the rapid delivery advantage brought about by requirement splitting iterative development one by one, due to the dependence on the traditional banking system, this advantage has not only not been brought into play, but has become a constraint to the implementation of agile, and has impacted the confidence of the team . Team members gradually began to doubt the correctness of agile, iterative.
In fact, the proponents of agile seem to have recognized this problem from the very beginning, creating what they call agile development. Agile development refers to adopting an agile method only in the development phase, and after the development is completed, it enters the functional testing phase for testing together with the system that adopts the non-agile development method. Agile in the development phase only solves the development problem, not the rapid delivery of the entire project. So in essence, developing agile doesn't solve the problems mentioned at the beginning. It's just a revamp of the way development is done within the team. The advantages brought about by this transformation are usually summarized by members of the agile development team as less audit documentation, and it seems clear or vague that development agile does not inherently solve the problem.
With the implementation of agile culture within the enterprise, traditional banks try to adopt a fully agile approach in some systems, that is, adopt thorough agile, integrate development and testing into iterations, and obtain deliverable products after each iteration. . But the aforementioned constraints of adopting a waterfall development model to adopting a fully agile system were not resolved at this time. Therefore, the product delivered after each iteration with a fully agile system is still not usable. Essentially this more radical experimentation still doesn't address any efficiency issues from a project perspective. All that is brought about is the omission of testable products delivered in the functional testing phase by some systems. Even this kind of experimentation raises a whole new question for a fully agile system: how to effectively mesh iteration with the traditional development-internal-test-functional-test-delivery model to ultimately deliver a quality-assured product? Obviously, this problem should not be solved by the team adopting agile development methods, but should be solved by the people who introduced agile before the introduction, instead of throwing it to the development team, trying to use communication, responsibility, initiative and other unmeasurable things to solve it. make up.
So is agile downright useless?
Obviously not. As can be seen from the problems faced above, the premise of adopting agile is the dependence on non-agile development teams, because once such dependence occurs, agile is not only difficult to implement, but also introduces other problems. So to solve the above problems that agile has to face, the solution seems to be coming out:
The first is to adopt agile for systems that use traditional development methods. But does this approach really solve the problem in the end? How to solve synchronization between two separate agile teams, doesn't seem to give a solution.
Second, systems adapted to the waterfall development method still go through the functional testing phase and are finally delivered. Introduce intra-iteration testing in the development iteration process, and complete functional testing of those functions that do not depend on other systems within the iteration, reducing the cost of the functional testing phase.
However, it is clear that neither of the above solutions seems to address the underlying problem: to deliver a usable product quickly, with a workable solution. Perhaps this requires more exploration and thinking.
In fact, agile development methods are very suitable for projects or products that do not have so many external dependencies, and there is no doubt that they have been verified a lot.
How to solve the current problems faced by traditional banks seems to need to continue to explore.