Gibt es Best Practices für die Übergabe von der Architektur an die Entwicklung?

Wir wollen den Prozess für die Übergabe von Aufgaben von der Architektur an die Entwicklung verbessern.

An einem Ende der Skala gibt es keine Architekturrichtlinien, bei denen Sie das Risiko eines Chaos eingehen, da jeder Entwickler die Dinge auf seine Weise tut.

Am anderen Ende der Skala, wo alles angegeben ist, dauert die Spezifikation länger als die Entwicklung, und Sie riskieren sehr langweilige Entwicklungsaufgaben.

Hat jemand einen optimalen Mittelweg zwischen diesen Extremen gefunden? Welche Artefakte liefern Sie an die Entwicklung? Zum Beispiel: Module, Klassenstruktur oder Sequenzdiagramme?

Ich möchte zunächst sagen, dass das Konzept eines separaten "Architektur" -Teams einen Verstoß gegen gute Softwareentwicklungspraktiken darstellt. Architekturteams in Unternehmensumgebungen sind in der Regel der Höhepunkt der schlimmsten pseudo-intellektuellen Bull * * -Künstler des Elfenbeinturms , die sich im Pool der Entwickler befinden.

Andere Organisationen behandeln Architekturgruppen als politische Belohnung und Rechtfertigung für ein massives Gehalt für die höchsten Mitglieder, unabhängig von Verdienst, Wissen oder Fähigkeiten. Die meisten bestehen aus beiden Typen.

Jeder Entwickler kann und sollte ein Architekt sein und sollte an den hochrangigen Entwürfen eines Unternehmens beteiligt sein. Der bloße Gedanke, dass eine einzelne Gruppe die vollständige diktatorische Kontrolle über jeden Aspekt des Software-Designs hat und an Entwickler weitergegeben werden muss, die nicht zum Design beigetragen haben, die Gründe für die Design-Entscheidungen nicht verstehen und möglicherweise kritische Fehler verstehen Das Design ist komfortabler und näher an der tatsächlichen Implementierung und dem vorhandenen Code, ist von Grund auf offenkundig vollständig fehlerhaft und führt durchweg zu einem von drei Szenarien:

• Entwickler verstehen das Design nicht oder lehnen es aufgrund der Realität der aktuellen Implementierung sofort ab und bestimmen am Ende ihr eigenes undokumentiertes Design und implementieren es stattdessen. Die Situation sind formale Designdokumente, die nicht die Implementierung der Software widerspiegeln.

• Die Entwickler folgen blind dem Design, das aktuelle Anforderungen oder einzigartige Aspekte von User Stories berücksichtigen kann oder nicht, was zu einer fehlerhaften Implementierung von schlechter Qualität führt.

• Intelligente Entwickler, die die Konstruktionsdokumente verstehen und implementieren können, langweilen sich schnell, wenn sie nicht an Konstruktionsdiskussionen beteiligt sind. Sie werden wahrscheinlich aufgrund politischer oder älterer Probleme von der Teilnahme an der Architekturgruppe ausgeschlossen, sodass sie frustriert, gelangweilt und auf grünere Weiden gehen. Dies wirkt sich negativ auf das Projekt aus und führt zu einer Abwanderung von Fachkräften, wodurch der Teufelskreis schlechter Softwarequalität fortgesetzt wird.

Der beste Weg, um dieses Problem zu lösen, besteht darin, die Architekturgruppe zu ÄNDERN und sie möglicherweise in technische Führungspositionen zu bringen. Die Rolle der Architekturgruppe sollte mehr oder weniger ein "Gedränge von technischen Leitern" sein, wenn Sie so wollen. Sie sollten sich nur selten treffen und nur die Fragen der technischen Richtung auf höchster Ebene diskutieren, z. Denken Sie an eine Diskussion, die von Java nach Scala migriert, Oracle für MySQL aufgibt und möglicherweise allgemeine Dienstprogrammbibliotheken schreibt, die einen bestimmten Typ von Entwurfsprozess über einen anderen vorschreiben, und von StarUML zu Altova UML wechselt.

Tatsächliches und reales Software-Design wird ein Community-Prozess sein, an dem ALLE Softwareentwickler beteiligt sind, der von der extrem hochrangigen Leitung der Architekturgruppe festgelegt wird.

Es gab immer Probleme beim Informationsfluss von der Architektur zum Entwicklungstest und zum Betrieb. Die Art und Weise, diese Probleme imho anzugehen, hängt von mehreren Faktoren ab, wie zum Beispiel:

• Größe der Software
• Komplexität
• Kultur in Ihrer Organisation
• Glauben.

Für bestimmte Kombinationen dieser Faktoren ist ein rein agiler Ansatz funktionsübergreifender Teams mit neuem Design angemessen. Die Informationen fließen durch Zusammenarbeit. Die Disziplinen dokumentieren, was sie brauchen.

Bei anderen Kombinationen dieser Faktoren kann ein kleines Team aus Architekten, Testern, Betriebsexperten und leitenden Entwicklern mit Architekturiterationen beginnen, die die Architektur langsam aufbauen, dokumentieren und sofortiges Feedback zu ihren Architekturentscheidungen erhalten. Langsam können mehr Entwickler, die Funktionen implementieren, zum Team hinzugefügt und das ursprüngliche Kernteam verkleinert werden.

Vor allem für Regierungs- und Finanzprojekte ist es erforderlich, dass mehr Dokumentation im Voraus geschrieben wird. Dies kann lange dauern, ohne dass ein reales Feedback zu Ihren Entscheidungen vorliegt. In meinen Augen der größte Grund, warum viele dieser Projekte scheitern. Wenn dies dennoch Ihre Situation ist, würde ich die Dokumentation an die Anforderungen anpassen und dann Option 1 oder 2 verwenden, um die Software tatsächlich zu erstellen und die Dokumentation zu verfeinern / anzupassen.

Hoffe das hilft.

Ich weiß, dass dies nicht sehr beliebt sein wird, aber der Kommentar, den Sie gemacht haben

Wenn am anderen Ende der Skala alles angegeben ist, dauert die Angabe länger als die Entwicklung. Und Sie riskieren sehr langweilige Entwicklungsaufgaben.

ist eigentlich etwas, das Sie anstreben sollten. Wenn das Design und die Spezifikation solide genug sind, dass die Entwicklungsaufgaben langweilig sind, sinken die Entwicklungskosten. Das Reparieren einer Spezifikation ist viel billiger als das Reparieren von Code, und die größten Kosten für Softwareprojekte sind nicht der Build, sondern die langfristige Unterstützung. Die Unterstützung von Code, der auf einer soliden Spezifikation basiert, ist viel günstiger.

Ich stimme der Antwort von maple_shaft nicht ganz zu, aber der Kommentar enthielt nicht genügend Platz, um mein gesamtes Wort zu sagen! ;-);

Ich stimme zu, dass jeder Entwickler ein Architekt sein kann und sollte, aber das bedeutet nicht, dass jeder Entwickler für die Architektur eines gesamten Produkts oder Systems verantwortlich sein sollte. Außerdem glaube ich nicht, dass Sie jedes Architektenteam mit demselben breiten Pinsel malen können, und wenn es richtig gemacht wird, können Architektenteams einen großen Wert für den gesamten Produktentwicklungsprozess liefern. Das Missverständnis ist, dass die Architekten jeden Aspekt des Systemdesigns bestimmen sollten. Sie sollten sich stattdessen auf das übergeordnete Design konzentrieren und die Implementierungsdetails ihren Entwicklungsteams überlassen. Das heißt jedoch nicht, dass die Entwickler nicht von Anfang an in den Planungs- und Entwurfsprozess einbezogen werden sollten.

Je größer und modularer und letztendlich komplexer ein Produkt ist, desto wahrscheinlicher werden Sie verschiedene Teile des Produkts finden, die von verschiedenen Entwicklungsteams gehandhabt werden. Solche Teams müssen das System als Ganzes nicht verstehen, vorausgesetzt sie haben ein umfassendes Verständnis der Teile des Systems, für die sie verantwortlich sind. Oft werden diese zusätzlichen Teams als Subunternehmer für den spezifischen Zweck der Entwicklung eines Moduls in einem bestimmten Technologiebereich eingesetzt, in dem die Architekten oder andere Teams möglicherweise kein Fachwissen haben. Meine eigenen besonderen Talente liegen in der Entwicklung von APIs, und ich habe sie noch nicht gesehen eine gut faktorisierte API, die vollständig organisch entwickelt wurde, ohne die Benutzerfreundlichkeit zu beeinträchtigen. oder das erforderte nicht, dass sich jemand als die Person hervorhob, die dafür sorgte, dass zwischen verschiedenen Aspekten der API ein gewisses Maß an Einheitlichkeit bestand. Ich kann weiter viele Beispiele und Gründe auflisten, aber ich glaube nicht, dass diese Art von Situationen der Elfenbeinturm BS sind, von dem viele denken, dass sie es sind. Leider gibt es viele Stellen, insbesondere in den Bereichen Verteidigung, Medizin und Finanzen, an denen die Paranoia von Unternehmen zu einer schlecht spezifizierten und noch schlechter verwalteten Produktentwicklung führt, von der ich sicher bin, dass maple_shaft am meisten besorgt war. Dies sind die Dinge, von denen ich glaube, dass sie Architekten einen schlecht verdienten schlechten Ruf geben (im Allgemeinen). Leider gibt es viele Stellen, insbesondere in den Bereichen Verteidigung, Medizin und Finanzen, an denen die Paranoia von Unternehmen zu einer schlecht spezifizierten und noch schlechter verwalteten Produktentwicklung führt, von der ich sicher bin, dass maple_shaft am meisten besorgt war. Dies sind die Dinge, von denen ich glaube, dass sie Architekten einen schlecht verdienten schlechten Ruf geben (im Allgemeinen). Leider gibt es viele Stellen, insbesondere in den Bereichen Verteidigung, Medizin und Finanzen, an denen die Paranoia von Unternehmen zu einer schlecht spezifizierten und noch schlechter verwalteten Produktentwicklung führt, von der ich sicher bin, dass maple_shaft am meisten besorgt war. Dies sind die Dinge, von denen ich glaube, dass sie Architekten einen schlecht verdienten schlechten Ruf geben (im Allgemeinen).

Wo ist also der Mittelweg, nach dem das OP gesucht hat? Die Antwort hat alles mit dem Öffnen von Kommunikationskanälen zu tun. Die Architekten müssen Spezifikationen übergeben, die ihre Entwürfe so detailliert beschreiben, dass die Entwicklungsteams verstehen, wo die Grenzen liegen. Geschichten und Feature-Szenarien im weitesten Sinne, bei denen alles als Black-Box betrachtet wird. Die Architekten müssen dann sicherstellen, dass die Teams Zugriff auf die Zeit des Architekten haben, um etwaige Annahmen zu bestätigen und Fragen zu Spezifikationen zu beantworten, die zu weit gefasst oder unklar erscheinen. Danach geht es wirklich darum sicherzustellen, dass einzelne Teams darauf aufmerksam gemacht werden, woran die anderen Teams arbeiten, und dass sie wissen, mit wem sie in Verbindung mit den anderen Teams stehen müssen, um sicherzustellen, dass jeder Teil des Systems gut mit den anderen Teilen zusammenarbeitet. Diese Teams treffen sich direkt. Sobald das System auf der breitesten Ebene entworfen wurde, sollten die Architekten eigentlich nur die Personen sein, an die sich die Teams wenden, wenn sie eine Überprüfung der Gesundheit benötigen, und um sicherzustellen, dass die "Vision" des Produkts erhalten bleibt. Sie sollten auch alle erforderlichen Integrationsprozesse berücksichtigen und den Entwicklungsteams von Managern, Kunden und anderen Beteiligten die dringend benötigte "Luftabdeckung" bieten und gleichzeitig sicherstellen, dass diese verschiedenen Personen zusammenkommen können, um zwischen ihnen zu trainieren ihnen, wie die Dinge funktionieren sollen.

IMHO-Architekten sollten in erster Linie Moderatoren und Kommunikatoren sein, und Designer in zweiter Linie. Auf welcher Spezifikationsstufe? Ich denke, dass die besten Architekten diejenigen sind, die ihre Teams nach dem Detaillierungsgrad fragen, den ein Team wünscht, und zwischen ihnen ein Gleichgewicht finden, das funktioniert. Unterschiedliche Teams haben möglicherweise unterschiedliche Anforderungen hinsichtlich des Umfangs der erforderlichen Dokumentation oder Anleitung. Ältere Teams finden möglicherweise ein grob gezeichnetes Diagramm, und ein kurzer Chat kann ausreichen, um loszulegen, während Teams mit relativ jungen Entwicklern möglicherweise etwas mehr benötigen, um sie zum Laufen zu bringen. Vor allem muss der Architekt die Entwickler ermutigen, ihre eigenen Designtalente einzusetzen, um von jedem Team das beste Endergebnis zu erzielen.

Da Sie sich bemühen, etwas zu verbessern, haben Sie bereits ein Problem in Ihrem Prozess festgestellt. Die Hauptursache für die spezifische Situation könnte folgende sein: Die Entwickler können sich nicht mit der Architektur identifizieren, da sie ihnen von einer externen Person auferlegt wurde. Die Übergabe der Architektur an die Entwicklung wird diese Grundursache höchstwahrscheinlich nicht lösen.

Machen Sie die Architektur zu einem Teil des Entwicklungsteams. Die Grenze zwischen Architekt und Entwickler abreißen. Dies stellt sicher, dass die Informationen fließen. Wenn das Entwicklungsteam an der Gestaltung der Architektur beteiligt ist, wird dies nicht als etwas Außerirdisches angesehen. Geben Sie dem Team Wissen über Architektur. Bringen Sie ihnen die treibenden Faktoren hinter der Unternehmensarchitektur bei, um das von Ihnen erwähnte Chaos zu vermeiden. Beziehen Sie Entwickler ein, wenn Architekturentscheidungen getroffen werden müssen, um die von Ihnen erwähnte Langeweile zu vermeiden. Eine Übergabe ist dann nicht mehr erforderlich und Sie haben Ihre Rolle als Architekt in einem Entwicklungsteam erfüllt.

Sie müssen dem zukünftigen Team so viele Informationen wie möglich geben, um den Code zu pflegen. Wenn Sie beispielsweise keine Sequenzdiagramme haben, muss der Entwickler den Code Schritt für Schritt verfolgen, wodurch Zeit verschwendet wird.

Es gibt auch Raum für das neue Team, ungültige Annahmen zu treffen.

Im Allgemeinen sollte ein Dokument über das Projekt, die technischen Spezifikationen, Unit-Testfälle und Sequenz- / Klassendiagramme vorliegen.

Ich würde sagen, dass Klassendiagrammansichten, die sowohl ein Modell als auch Code erstellen, eine Lösung sind. Das Klassendiagramm repräsentiert die statische Ansicht Ihrer Projektarchitektur. Ich meine, Sie haben Pakete> Klassen, Schnittstellen, Aufzählungen> Attribute, Methoden usw. ...> usw. Wenn Sie gut aussehen, hat das UML2-Metamodell genau die gleiche Struktur wie ein Java- oder Dotnet-Projekt.

Was wir in unseren Projekten verwenden, sind einfach Klassendiagramme, die in einem einzigen Modell gespeichert werden. Wir generieren Ansichten des Modells, wenn der Klassifikator bereits vorhanden ist, oder erstellen eine neue grafisch, wenn er neu ist. Entwickler können unsere Diagramme und Modelle sehen, da sie im Stammverzeichnis des Projektordners in CVS gespeichert sind. Was mir gefällt, ist, dass auch der Entwickler modellieren kann, denn wenn etwas auf Codeebene geändert wird, wird das Modell automatisch in CVS für das gesamte Team aktualisiert.

Es funktioniert sehr gut und es ist nicht unbedingt erforderlich, UML zu kennen, da das Klassendiagramm sehr einfach ist und das Reverse Engineering die Aufgabe übernimmt und die grafische Ansicht des Codes erstellt. Einfache Navigation, erweiterte und detaillierte Ansichten, in denen zahlreiche Kommentare mit Diagrammen hinzugefügt werden können, die immer aktuell und in CVS direkt im Projekt sichtbar sind. Mein UML-Klassendiagramm ist jetzt Magic :-)