Der Software-Lebenszyklus ist den meisten modernen Programmierern bekannt.
Sogar ein Schüler schreibt sein erstes Programm
<?php echo "Hello, ! " ?>
oder
fprintf( ' !\n');
versteht den Prozess.
- Über die Aufgabe nachdenken - das Stadium der Idee
- Er denkt über die Aufgabe nach und wie sie umgesetzt werden muss - Analyse und Ausarbeitung von Anforderungen,
Erstellen eines Softwaremodells und eines Implementierungsplans. Kurz gesagt, die architektonische Bühne. - Programmierung
- Testen. "Was ist dort passiert?"
- Bedienung.
Zwischen den Stufen 1 bis 5 haben wir kontinuierlich interagierende Prozesse.
Dafür gibt es alle Arten von Wasserfällen, Scrum usw.
Die Sache ist also, wenn sich Ihr Projekt auf verschiedene Arten von Frontends aufbläst,
Wie es die moderne IT-Welt erfordert, möchte der Kunde das Publikum maximieren, um seine eigenen Gewinne zu maximieren.
Aus diesem Grund beobachten wir alle eine Fülle von Projekten, bei denen es verschiedene Arten von Frontends gibt, die über die API mit einem zentralisierten Backend interagieren.
Im Allgemeinen hat ein „starkes Standardprojekt“ drei Arten von Fronten:
- Website
- Mobile Anwendung auf Android
- IOS mobile App
Mit einer einzigen entwickelten API für den Datenaustausch über REST.
Ein gutes Beispiel, auf das ich mich verlassen werde, sind soziale Medien (siehe meinen vorherigen Artikel über Ihren eigenen Player basierend auf YouTube-Videos).
Ein großes Projekt hat drei Möglichkeiten, um einen Gewinn zu erzielen, oder ein beliebiges Kriterium dafür
bedingt Web, Apfel und Android.
Programmierer können bequem mit der zentralisierten Backend-Architektur interagieren und sich auf ihre persönliche Front konzentrieren, die sie entwickeln.
Und hier erscheint das Highlight des Artikels.
Tatsache ist, dass auf der obersten Ebene der Entscheidungsfindung unter Vorgesetzten
Es wird ein neues Feature gebildet, das nach hinten geht. Aber da der "Chef" eine unvollkommene Person ist,
dann muss er seine Kräfte auf die unteren Ebenen senken.
Daher erscheinen in unserem Fall in der Regel über jeder Front auch ihre "untergeordneten" Chefs nach hierarchischen oder formalen Gründen. Etwas
Art der Timlides der Einfachheit halber.
Und die Aufgabe, ein großes Projekt in Form einer Art "Entwicklungslebenszyklus" zu entwickeln.
Der Softwarebetrieb ist in seine Lebenszyklen unterteilt.
Und die Frage stellt sich bei der Synchronisierung der Prozesse von „Mini“ -Lebenszyklen, denn wenn Sie beispielsweise einem Webentwickler einer neuen Funktion voraus sind, müssen Sie auf einen mobilen Entwickler warten.
Andernfalls geht die Bedeutung der neuen Funktion als solche an Priorität verloren, da wir jetzt alle im Internet und in mobilen Anwendungen von Smartphones aus sind.
Lassen Sie uns darüber nachdenken, wie die Einführung neuer Funktionen bewertet werden kann, um die Humanressourcen in einer solchen Situation zu minimieren.
Hier werde ich die Thesen aussprechen:
- Bei der Implementierung eines Features in einer der Fronten müssen wir die Zyklen anderer Fronten berücksichtigen oder Standardstubs programmieren, damit wir später die Features anderer Fronten „einholen“ und ausgleichen können.
- Sie können ein Schema für den gesamten Softwareentwicklungszyklus erstellen, sodass alle bedingt gut abschneiden. Dann wird die Funktion pünktlich implementiert, aber zumindest die Unabhängigkeit der Front-End-Teams untereinander geht verloren. Dann verlieren der Feed und die Agilität für das gesamte System ihre Relevanz oder erhöhen die Iterationszeit um Entwicklung. Kurz gesagt, es wird mehr Chatter auftreten und der Code wird langsamer geschrieben.
- Isolierte Fronten sind im Prinzip schneller, aber dann sind mehr Integrationstests für die menschlichen Kosten erforderlich.
- Die derzeit implementierten Schemata - jede Front wird separat und unabhängig voneinander mit einem Minimum an Interaktionen entwickelt, aber hier gehen einige der Grundlagen der IT verloren - werden wir irgendwie eine Gruppe von Benutzern ungleich Null bekommen, die manchmal Fehler sehen.
Hier ist die Philosophie der Frage, dass Benutzer Fehler per Definition nicht mögen. Und der Kunde versucht, den Gewinn zu maximieren, sodass eine große Komplikation des Systems diese Maximierung irgendwie verlangsamt, da dies der endgültige Prozesslebenszyklus der Software ist.
In kleineren Projekten ist dieser Prozess noch schlimmer: Viele Kunden geben dem Remote-Standort eine mobile Entwicklung, obwohl das Back-End und das Web eigenständig ausgeführt werden und regelmäßig eine einheitliche Bremsung bei der Implementierung von Funktionen erhalten.
Auf der anderen Seite gibt es ein gefährliches Hindernis für die formale Automatisierung des Implementierungsprozesses - es ist unter Entwicklern üblich, den Benutzer nach fortlaufenden Updates zu fragen, sodass es im stillen Modus nicht funktioniert, die Änderungen ohne Zustimmung zu übernehmen.
Meine Idee ist eine solche Idee - während Sie den Haupttyp des Lebenszyklus beibehalten und Subtypen in diesem Fall von unabhängigen Fronten haben, müssen Sie eine Priorität berücksichtigen
Art der Front (aus Geldgründen, aus historischen Gründen oder aus anderen Gründen), aber sie sollten eine Einheit unterhalb der übergeordneten Art des Zyklus sein.
Das heißt, wenn die Prioritäts-Webfront mit einem wöchentlichen Scrum funktioniert, sollte das innere Scrum auf der mobilen Front das erste doppelte Scrum enthalten, andernfalls zwei Wochen
Verwirrung wird beginnen. Die Einführung einer gemeinsamen großen Version der Fronten muss jedoch gleichzeitig erfolgen, da Sie sonst den Autor des Artikels haben, der dies schreibt. Denken wir mal ...