Choosing a software life cycle strategy when there are several dependent frontends

The software life cycle is known to most modern programmers.

Even a schoolboy writing his first program

<?php echo "Hello, !  " ?> 

or
')

 fprintf( '   !\n'); 

understands the process.

1. Thinks about the task - the stage of the emergence of ideas
2. He thinks about the task and in what way it needs to be implemented - Analysis and elaboration of requirements,
   building a software model and implementation plan. In short, the architectural stage.
3. Programming.
4. Testing. "And what happened there"
5. Exploitation.

Between 1-5 stages of a thread, we have continuously interacting processes.

To do this, there are all sorts of waterfalls, Skramy and so on.

So the fact is that when you have a project blown up to several types of frontend,
as the modern IT world demands, the customer wants to twist the audience as much as possible to maximize their own profits.

And for this reason, we all observe an abundance of projects in which several types of frontends exist at the same time, interacting via API with a centralized backend.

Generally speaking, the “standard strong project” has three types of fronts:

1. Site
2. Mobile application on Android
3. IOS Mobile App

With a single developed API for exchanging data via REST.

Social media are a good example that I’ll rely on (see my previous article on your own vidos player on YouTube)

A large project has three options for profit or any criterion that
conditionally Web, Apple and Android.

Programmers find it convenient to interact with the centralized backend architecture and concentrate on their personal front, which they are developing.

And here comes the highlight of the article.

The fact is that at the top level of decision-making among the authorities
a new feature is being formed that goes to the back. But since the “boss” is an imperfect person,
then he has to lower the powers to the lower levels.

Therefore, in our case, as a rule, over each front there also appear their own “low-level” chiefs according to hierarchical or formal signs. Something
type timlid for simplicity.

And the task of developing a large project in the form of a certain “life cycle” of development
and operating software is divided into its life cycles.

And the question arises in the synchronization of the processes of the “mini” life cycles, because when advancing, for example, the web developer of a new feature, you have to wait for a mobile developer.

Otherwise, the meaning of a new feature as such is lost in priority, because we are all now on the web and in mobile applications from smartphones.

Let's think about how to evaluate the fact of the introduction of new features in order to minimize human resources in this situation.

Here I will voice theses:

1. When implementing a certain feature in one of the fronts, we need to take into account the cycles of the other fronts, or program standard stubs, in order to “catch up” with the features of the other fronts and even out.
2. You can build a software development cycle scheme in general so that everyone will be able to do it conditionally, then the feature will be implemented on time, but at a minimum, the independence of the frontend commands between themselves is lost - then the feed and agile for the whole system lose their relevance, or they increase the iteration time development In short, more chatter will occur and the code is written slower.
3. Isolated fronts, in principle, work faster, but then more human-intensive integration testing is needed.
4. The schemes implemented now - each front is developed separately and independently from each other with a minimum of interactions, but here some IT fundamentals are lost - we somehow get a non-zero user group that will sometimes see bugs.

Here the philosophy of the question is that users do not like bugs by definition. And the customer is chasing profit maximization, so a big complication of the system will somehow lead to the inhibition of that very maximization, because this is the final process — the software life cycle.

In smaller projects, this process is even worse - many customers give away mobile development, although the backend and the web are conducted on their own, and regularly receive uniform inhibition on the implementation of features.

On the other hand, there is a dangerous obstacle for the formal automation of the implementation process - it is customary among developers to ask the user for updates, so in silent mode it will not be possible to roll up changes without consent.

My idea is this idea - while maintaining the main type of life cycle and having subtypes in this case of independent fronts, you need to keep in mind one priority
front type (for bucks, historical reasons, or otherwise), but they must be a conventional unit below the higher level cycle type.

Ie if the priority web-front is working on a weekly scrum, then the internal scram on the mobile front should have a double first scram, a two-week one, otherwise
confusion will begin. But rolling out a common large version of the fronts must be done at the same time, otherwise you will have the author of the article who writes this. Let's think ...