Table of Content
Das Abhängigkeitsmanagement war schon immer schwierig. Eine der besten Veranschaulichungen des Problems ist Microsofts treffend benannte „DLL-Hölle“. Bereits in den 1990er und frühen 2000er Jahren wurden Microsoft-Produkte mit dem Component Object Model (COM) erstellt. COM war ein komplexes System. Eines seiner Vorteile war jedoch die Möglichkeit, eine Programmierschnittstelle (API) freizugeben. Die Integration der API-Funktionalität in andere Anwendungen erfolgte über Dynamic Linked Libraries (DLLs).
Sie konnten beispielsweise die von Microsoft Office bereitgestellten DLLs verwenden. Anschließend konnten Sie mit Word und Excel Berichte erstellen und formatieren. Solange alle Anwendungen auf einem Windows-PC mit der selben Version einer beliebigen DLL liefen, war es eine fantastische Lösung. Die Probleme begannen in der Regel, wenn verschiedene Anwendungen unterschiedliche DLL-Versionen benötigten. Dies ließ bestenfalls die von Ihnen verwendete Anwendung zum Absturz bringen. Im schlimmsten Fall brachte es Ihr gesamtes System zum Absturz.
Nach dem Launch des .NET-Frameworks ist der DLL-Albtraum fast vollständig verschwunden. Es gibt noch viele weitere vergleichbare Beispiele. Aktuelle Entwicklungsverfahren legen Wert darauf, Ihr Projekt in kleinstmögliche Einheiten zu zerlegen. Hier ist das Problem mit diesem Ansatz. Module und ihre externen Abhängigkeiten funktionieren unterschiedlich, wenn sie isoliert getestet werden. Sie funktionieren anders, wenn sie in ihr Host-System integriert sind. Dies führt bestenfalls zu kleinen Verzögerungen, die schnell behoben werden können. Im schlimmsten Fall führt dies zu systemweiten Ausfällen, verpassten Terminen, erheblichen Kostenüberschreitungen und Reputationsschäden.
Abhängigkeiten: Definition & Typen
Beginnen wir mit der Definition, was eine Abhängigkeit ist.
Eine Abhängigkeit ist etwas, auf das Sie sich verlassen können, um ein Ziel zu erreichen, aber das nicht Ihrer Kontrolle unterliegt. Projektabhängigkeiten gibt es in vielen Formen und Größen. Dazu gehören Hardware, Software, Ressourcen und Menschen. Ihr Softwareprojekt ist auf eine Vielzahl von Abhängigkeiten angewiesen, unabhängig von der Größe Ihres Technologie-Stacks oder den verfügbaren personellen und finanziellen Ressourcen.
Es ist verführerisch, jede Abhängigkeit als eine einzelne eigenständige Einheit zu betrachten. Diese Art der isolierten Abhängigkeit ist jedoch selten. Normalerweise ist jede Abhängigkeit Teil eines komplexen Netzes von miteinander verbundenen Beziehungen, das schwer zu entwirren ist. Betrachten wir drei gängige Arten von Abhängigkeiten und wie man sie überwindet.
Funktional
Eine funktionale Abhängigkeit umfasst die Komponenten, Assets oder Ressourcen, die für das Funktionieren eines Projekts erforderlich sind. Funktionale Abhängigkeiten sind das Ergebnis der Aufgaben und Aktivitäten, die ein Unternehmen benötigt, um ein gewünschtes Ergebnis zu erzielen. Der beste Weg, um Probleme zu lösen, die durch diese Art von Abhängigkeit verursacht werden, ist, sie zu identifizieren. Als nächstes erstellen Sie eine Liste und ordnen sie nach Wichtigkeit. Entscheiden Sie dann, welche Abhängigkeiten redundant oder nicht mehr benötigt werden. Entfernen Sie diese aus dem Projekt.
Wenn Sie eine Abhängigkeit benötigen, die sich noch in der Entwicklung befindet oder nicht verfügbar ist, können Sie Mock-Techniken verwenden. Ist Ihre Komponente beispielsweise von einer externen API abhängig, können Sie die API-Aufrufe und -Rückmeldungen simulieren. Fahren Sie mit der Entwicklung und dem Testen Ihrer Komponente fort, bis diese verfügbar ist. Sie können auch Ihre Projektanforderungen neu schreiben, um die Abhängigkeit und alle damit verbundenen Probleme zu beseitigen.
Entwicklungs- und testbezogen
Diese Abhängigkeiten sind Komponenten, Assets oder Ressourcen, die zum Erstellen oder Testen eines Projekts benötigt werden. Entwicklung und Testing können als getrennte Prozesse betrachtet werden, aber moderne Ansätze, wie Agile, Shift-Left und Continuous Testing betrachten sie als eine Einheit. Entwicklungs- und Testprozesse unterliegen funktionalen Abhängigkeiten. Sie sind auch stark von der Qualität der verfügbaren Personalressourcen abhängig.
Verschiedene Teammitglieder haben unterschiedliche Fähigkeiten und Erfahrungen. Teams sind oftmals auf die Expertise einzelner Personen angewiesen. Dies funktioniert so lange, wie jede Person Mitglied des Teams bleibt. Teammitglieder, die längere Zeit abwesend sind oder die Organisation verlassen, hinterlassen eine Lücke, die schwer zu füllen sein kann.
Diese Abhängigkeiten können Sie über ein Training ausgleichen. Stellen Sie sicher, dass alle Teammitglieder die Rollen und Verantwortlichkeiten anderer Teammitglieder übernehmen können. Beseitigen Sie das Risiko, dass Ihre Teams bei der Bewältigung kritischer Aufgaben auf wichtige Einzelpersonen angewiesen sind.
Auf der User-Story-Ebene haben komplexe Szenarien häufig ihre eigenen internen Abhängigkeiten. Zum Beispiel eine User Story, die mehrere Akteure mit individuellen Abhängigkeiten einbezieht. Die Story könnte auch eine Reihe von Schritten enthalten, die nacheinander ausgeführt werden, deren Implementierung und Tests jedoch vom Abschluss der vorherigen Schritte abhängen. Diese Abhängigkeiten können dadurch überwunden werden, dass man jede Story sorgfältig überprüft, die wichtigsten Akteure identifiziert und entscheidet, welche relevant sind und welche herausgenommen werden können. Zerlegt man die Story in Schritte, stellt jeder Schritt eine einzelne Aufgabe dar. Dies wird Ihnen helfen, unnötige Abhängigkeiten zu finden und zu beseitigen. Anstatt individuelle Tests für jede User Story zu erstellen, katalogisieren Sie Ihre bestehenden Tests und ordnen sie, wenn möglich, neuen Stories zu.
Operativ und nicht-funktional
Dies sind Komponenten, Assets oder Ressourcen, die für den Betrieb, die Bereitstellung oder das Deployment eines softwarebasierten Projekts erforderlich sind. Dabei kann es sich um alle Komponenten handeln, die für operative Aufgaben benötigt werden, aber nicht fester Bestandteil des Produkts sind, wie zum Beispiel Anwendungen, Webservices und Datenspeicher. Eine verbreitete Art der operativen Abhängigkeit betrifft die Netzwerkinfrastruktur-, -Management und -Sicherheitsrichtlinien. Darüber hinaus umfasst es alle Deployment- und betriebsbezogenen Performance- und Lasttests sowie deren Management und Überwachung.
Oftmals sind operative Anforderungen in funktionalen Anforderungen und User Stories verborgen. Es ist nicht ungewöhnlich, dass sich implizierte operative Abhängigkeiten in den späteren Phasen eines Projekts zeigen. Diese Abhängigkeiten können durch die Erstellung von Richtlinien, das Verfassen detaillierter Dokumentationen und die Bereitstellung von Tools aufgelöst werden.
Die Lösung: Abhängigkeits-Abbildung
Unabhängig von der Ursache oder Art der Abhängigkeit können sie alle über ein Abhängigkeits-Mapping gemanagt werden. Obwohl jede Art von Abhängigkeit eine andere Art von Mapping erfordert, ist der Prozess der Abbildung ähnlich und jede Art wird langfristig große Vorteile aufweisen.
Abbildungsprozess
Starten Sie den Prozess, indem Sie die relevanten Abhängigkeiten identifizieren. Für funktionale Abhängigkeiten müssen Sie Stakeholder-Beziehungen, funktionale Anforderungen und Technologien identifizieren. Entwicklungs- und Testabhängigkeiten erfordern die Festlegung der Teammitglieder, ihrer Rollen und Verantwortlichkeiten. Auf der User-Story-Ebene müssen Sie die Akteure, User Stories und verfügbaren Tests ermitteln. Sie können es auch dazu verwenden, eine kombinierte Abbildung zu erstellen, die User Stories zusammen mit den Teammitgliedern anzeigt, die damit beauftragt sind, sie zu programmieren und zu testen. Das Operative Abbilden umfasst die Identifizierung von operativen Ressourcen, wie z. B. Anwendungen, Netzwerken, Sicherheitsbereichen und der entsprechenden Hard- und Software.
Sie sollten Abhängigkeiten mit der Methode abbilden, die am besten zu Ihnen, Ihrer Organisation, den verfügbaren Ressourcen und dem Budget passt. Die meisten Abhängigkeits-Mapping-Projekte beginnen mit der Erstellung physischer Pläne mit Whiteboards, Karteikarten und Haftnotizen. Durch die Verwendung der Systeme zum Managen von Anforderungen, Dokumenten, Aufgaben, Backlogs und Tests können anspruchsvollere Abbildungen erstellt werden. Diese Methoden funktionieren gut für alle in diesem Artikel beschriebenen Abhängigkeitstypen. Wenn es um nicht-funktionale/operative Abhängigkeiten geht, gibt es eine Vielzahl von Monitoring- und Mapping-Tools, die helfen können.
Fazit: Managen Sie Abhängigkeiten durch Abbildung.
Jede Art von Abhängigkeit bezieht sich auf die Komponenten, Assets oder benötigten Ressourcen eines Projekts sowie auf ein Gebiet. Es ist wichtig, Anforderungen zu identifizieren und zu definieren sowie die Ideen, Prozesse und Vorteile der Abbildung – und des Managements – der verschiedenen Arten von Abhängigkeiten zu verstehen.
Panayas Release Dynamix [RDx] ist eine vollständige Lösung zum Management und Release softwarebasierter Systeme und Anwendungen. Sie können damit alle Ihre Projekte an einem einzigen Ort verwalten und jedes einzelne verfolgen, um Abhängigkeiten auf Projekt-, Team- und Organisationsebene aufzuzeigen und jede davon zu managen. Mit diesem Tool können Sie zudem Richtlinien und Prozesse managen, wie z. B. IT-Governance, Anforderungen, Tests, Releases und Risikobewertung.
Release Dynamix ist einfach zu bedienen und bietet leistungsstarke Grafiken sowie die notwendigen Tools, um Projekte unternehmensweit zu analysieren, sowie Einheiten und deren Verbindungen abzubilden, um Ihnen zu zeigen, wo Abhängigkeiten bestehen. Diese Erkenntnisse helfen Ihnen, Ihre Softwareentwicklungs- und -releaseprozesse zu steuern und auch interne und externe Abhängigkeiten zu kontrollieren. Insbesondere bildet RDx alle internen und externen Abhängigkeiten ab, macht sie transparent und ermöglicht es Ihnen, sie erfolgreich zu finden und zu bereinigen.
