Choosing a Software Life Cycle Strategy with Multiple Dependent Front Ends

The software life cycle is known to most modern programmers.

Even a schoolboy writing his first program

or

fprintf( 'Привет Хабр на Матлабе!\n');

understands the process.

1. Thinking over the task - the stage of the idea
2. He thinks over the task and in what way it needs to be implemented - Analysis and elaboration of requirements,
   construction of a software model and implementation plan. In short, the architectural stage.
3. Programming.
4. Testing. “What happened there”
5. Exploitation.

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

For this, there are all kinds of Waterfalls, Scrum, etc.

So the fact is that when your project is inflated to several types of
front-end , as the modern IT world requires, the customer wants to maximize the audience to maximize their own profits.

And for this reason, we all observe an abundance of projects in which there are several types of frontends that interact via the API with a centralized backend.

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

1. Website
2. Mobile application on Android
3. IOS mobile app

With a single developed API for exchanging data through REST.

A good example that I will rely on is social media (see my previous article about my own player based on YouTube vidos).

A large project has three options for making a profit or any criterion, which are
conventionally Web, apple and android.

It is convenient for programmers to interact with the centralized backend architecture and concentrate on their personal front, which they are developing.

And here the highlight of the article appears.

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

Therefore, in our case, as a rule, above each front there also appear their “low-level” chiefs according to hierarchical or formal grounds. Something
like timlids for simplicity.

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

And the question arises in synchronizing the processes of “mini” life cycles, because if you are ahead of, for example, a web developer of a new feature, you have to wait for a mobile developer.

Otherwise, the meaning of the 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 introduction of new features in order to minimize human resources in such a situation.

Here I will voice the theses:

1. When implementing a feature in one of the fronts, we need to take into account the cycles of other fronts, or program standard plugs in order to then “catch up” with the features of other fronts and align.
2. You can build a scheme for the software development cycle as a whole so that everyone will conditionally do well, then the feature will be implemented on time, but at least the independence of the front-end teams among themselves will be lost - then the feed and agile for the whole system lose their relevance, or increase the iteration time by development. In short, more chatter will occur and the code is written more slowly.
3. Isolated fronts, in principle, are faster, but then more human-cost integration testing is needed.
4. The schemes currently being implemented - each front is developed separately and independently from each other with a minimum of interactions, but here some of the basics of IT are lost - we will somehow get a non-zero group of users that will sometimes see bugs.

Here the philosophy of the question is that users do not like bugs by definition. And the customer seeks to maximize profits, so a large complication of the system will somehow slow down that very maximization, because this is the final process-software life cycle.

In smaller projects, this process is even worse - many customers give mobile development to the remote site, although the back-end and the web are conducted on their own, and regularly receive uniform braking on the implementation of features.

On the other hand, there is a dangerous obstacle to the formal automation of the implementation process - it is customary among developers to ask the user about rolling updates, so in quiet mode it will not work to roll over the changes without consent.

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

That is, if the priority web front works on a weekly scrum, then the inner scrum on the mobile front should have with it the first double scrum, two weeks, 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 that writes this. Let's think ...