"Battery" Software Development

In software development teams with various "work locks", "joint-type" development is generally not avoided . That is to say, the underlying C programmer is done, handed over to the upper Java programmer, and then handed over to the upper-level front-end programmer, and finally to the operation and maintenance personnel. This is the development of the baton.

And, even worse, if you introduce the software process, this "baton way" will really crash you. For example, the downstream team develops for one month, handed it to QA for one month, and then hands it to the operation and maintenance step by step for one month. Then, the upstream team gets the API for downstream development and develops it for one month, and then gives it to its own QA test for one month. Then I handed it to my own operation and maintenance line for one month, so half a year passed. This is a large waterfall that is stacked by a small waterfall .

Oh, you will say, this is easy to handle, will the upstream and downstream not agree on the interface first? Then do parallel development? Yes, this is one of the optimization methods, but it requires a good interface design. However, in the actual process, you will find out (when I am not talking about it, I am telling the truth),

If the two upstream and downstream teams are still together, if they are not together, then the actual situation is that the latter team will wait until the previous team to test, and then start development, essentially serial development.

If there are more teams? For example: A team -> B team -> C team -> D team. The interface becomes very critical. In the actual situation, because there is no good interface designer, the interface is often modified during the development process, or because the interface is not easy to use.


I used to write an article called " IoC/DIP is actually a management idea ". For this kind of baton, it should be reversed. If the business application team is A team, then the B/C/D team should do their own work. Into a development framework, service, or the application team to access . For example: the front-end is a front-end development framework, PE is an operation and maintenance development framework, various tools, the shared module team to develop a framework, let the application team to access itself, rather than help him. You'll find that the cost of a very casual interface with so many teams' P2P blends has far exceeded the cost of a unified standard .