Wie kann ich Anwendungsabhängigkeiten kollektiv nachverfolgen?

Da unterschiedliche Teams unterschiedliche Teile einer Gesamtlösung liefern, ist es immer schwieriger zu erkennen, wann eine bestimmte Version einer Anwendung zusammen mit einer anderen Anwendung und einer anderen Version geliefert werden muss, die in die Gesamtlösung passt. Dasselbe Szenario taucht auf, wenn eine Anwendung der Gesamtlösung vor der anderen Anwendung geliefert werden könnte, aber nicht umgekehrt.

Ein hypothetisches Beispiel könnte sein, dass es 4 Anwendungen gibt, die eine End-to-End-Lösung bilden, die unterschiedliche Benutzerbasen bedient. Womit ich zu kämpfen habe, ist eine Möglichkeit, Inter-/Intra-Abhängigkeiten über die Anwendungen hinweg auf einfache und verdauliche Weise zu verfolgen, die während der täglichen Aufgaben in den Teams keine Fülle an Intelligenz erfordert.

Ich habe versucht, Tools (SpiraTeam) zu verwenden und mir eine vereinfachte Matrix in Excel angesehen, aber diese müssen das Problem noch lösen. Ich habe auch darüber nachgedacht, die Versionsnummern selbst zu verwenden, um Auswirkungen schnell zu identifizieren, aber das wurde umständlich und nicht wartbar.

Ich suche vielleicht nach einer einmaligen Lösung und/oder vorheriger Erfahrung, die keinen vollständigen Prozess-/Paradigmenwechsel erfordert, um dies zu erreichen. Hat jemand Erfahrung mit der effektiven Verfolgung voneinander abhängiger Anwendungen und, was noch wichtiger ist, der Release-Zyklen der voneinander abhängigen Anwendungen innerhalb des Unternehmens?

AKTUALISIEREN:

Um dies weiter auszuführen, befinden sich die Abhängigkeiten auf unterschiedlichen Ebenen innerhalb der Anwendungen. Ein Beispiel wäre das Front-End einer bestimmten Anwendung, das mit dem Anwendungs-Back-End kommuniziert, das über Dienste mit einer weiteren Anwendung kommuniziert. In diesem Beispiel müssen die Lieferungen parallel erfolgen, funktionieren jedoch unabhängig voneinander auf separaten Anwendungsversionen. Diese entstehen zweifellos aufgrund von Feature-Level-Lieferungen, aber unser aktuelles Paradigma der Versionierung erfasst das Feature nicht explizit in der Versionsnummer selbst, was diese Verbindung schwieriger macht. Der Plan ist, dass es vom gesamten Team manipuliert wird, was aufgrund der unterschiedlichen gegenseitigen Abhängigkeit und der jeweiligen Eigentümer, die diesem Wissen und der gegenseitigen Abhängigkeit am nächsten sind, gebührend ist. Das Endergebnis ist dann eine schnelle visuelle Darstellung, um zu erkennen, dass eine bestimmte Anwendung einer anderen Version vorausgehen kann oder parallel laufen muss usw. Ich habe eine einfache Matrix in Excel untersucht, aber es fühlte sich seit der Versionsdefinition und der Wartung der Versionsverwaltung umständlich an , etc.. passieren innerhalb eines anderen Tools. Das Problem mit dem Tool besteht darin, dass es keine Interkonnektivität zwischen Projekten (Anwendungen) zulässt, was dieses Problem an dem Punkt lindern würde, an dem es meines Erachtens gelöst werden sollte.

Dies ist, was ein Planungstool tut, z. B. Microsoft Project oder etwas Ausgefeilteres. Es sei denn, ich vermisse etwas in Ihrer Frage....
Ich möchte etwas Spezifisches für die Anwendungsversion und die Nachverfolgung von Abhängigkeiten gemäß einem Veröffentlichungszeitplan. Ich bin mir nicht sicher, ob Project das richtige Werkzeug ist, da die Benutzer, die das Vorhandensein von Abhängigkeiten und/oder deren Fehlen hervorheben müssen, möglicherweise ein Entwickler, ein Leiter usw. sind.
Sicherlich ist die Abhängigkeits-"Karte" wichtig, nicht wer die Abhängigkeiten aufruft? MS-Project ist gut darin, Zuordnungen von Abhängigkeiten zwischen Aufgaben anhand eines fiktiven Zeitplans zu verwalten. Ich verstehe Ihre Argumentation nicht, warum MS-Project nicht verwendet werden kann.
Um etwas Kontext bereitzustellen, welche Schicht(en) von Abhängigkeiten versuchen Sie, zwischen den Anwendungen zu koordinieren? Handelt es sich um Codeabhängigkeiten auf derselben Ebene, unterschiedliche Ebenen (z. B. Back-End und Front-End), Abhängigkeiten auf Funktionsebene usw.? Welches Maß an Sichtbarkeit und Zugänglichkeit suchen Sie auch, dh wird dies ein PM oder mehrere PMs selbst verwenden und die meiste Zeit in einem lokalen Ordner aufbewahren oder die Wartung mit technischen Leitern koordinieren oder wird es Eigentum sein? und/oder vom gesamten Team manipuliert und als Informationsstrahler im Teambereich genutzt werden?
@JeffLindsey Ich habe die Frage aktualisiert, um hoffentlich zusätzlichen Kontext und Klarheit zu schaffen.
Ich denke, die Frage ist jetzt eher Softwareentwicklung als Projektmanagement. Ich denke, dass das Konfigurationsmanagement ein Teil der Lösung ist, und es ist möglich, dass Sie bei der Planung ähnliche Techniken wie die Aufgabenabhängigkeit verwenden, aber ich glaube nicht, dass Sie dieses Problem gelöst haben, bis Sie es mit Softwareentwicklung und Anforderungen gelöst haben Verwaltung.

Antworten (4)

Dies ist ein Architektur-/Konfigurationsmanagementproblem, kein PM-Problem. Offensichtlich gibt es eine PM-Auswirkung, also müssen Sie sich damit befassen.

Bei Projekten, an denen ich gearbeitet habe, habe ich festgestellt, dass Folgendes sehr hilfreich ist:

  1. Basieren Sie Ihren Arbeitscode. (Welche Versionen der 4 Anwendungen spielen bekanntermaßen gut zusammen?)
  2. Sperren Sie die Schnittstellen/gemeinsam genutzten Ressourcen zwischen den Anwendungen. Kein Einfrieren des Codes, aber stellen Sie sicher, dass alle Änderungen sorgfältig von allen Teams geprüft werden, nicht nur von den beiden, die an der Schnittstelle arbeiten, denn ...
  3. Brainstormen Sie Ihre Grenzfälle. Ich hatte ein Problem, bei dem eine in Java erstellte XML-Nachricht an ein C-Socket-Programm gesendet wurde, die leeren Knoten mit Nullen gefüllt wurden und das C-Programm die Nachricht abschneiden würde. In diesem Fall dachten beide Teams, sie wüssten, was sie erwarten/bereitstellen sollten, übersahen jedoch einen Randfall, der von der Java/DB-Schnittstelle abhängig war. Java hat nach etwas gefragt, die DB hatte es nicht, also lieferte es eine Null.
  4. Wenn Sie eine neue Version einer der Anwendungen erhalten, führen Sie einen vollständigen Regressionstest mit dieser und den anderen Anwendungen durch. Führen Sie nach Möglichkeit eine eingeschränkte Version damit durch und aktualisieren Sie dann Ihre Baselines, um die neue App-Version aufzunehmen.

TL; DR

Denken Sie an Techniken, nicht an Werkzeuge. Tool-Empfehlungen sind bei PMSE immer off-topic. Es gibt jedoch mehrere Techniken , die aus Sicht des Projektmanagements von Wert sein können.

Im Allgemeinen haben Sie zwei Hauptansätze:

  1. Zersetzung.

    Eine Verfolgbarkeitsmatrix oder ein Abhängigkeitsdiagramm kann beim Zerlegen von Aufgaben hilfreich sein.

  2. Vertikalität.

    Wenn Features zu eng miteinander verflochten sind, um sie in lineare Abhängigkeiten zu zerlegen, müssen Sie sie als vertikale Arbeitsabschnitte behandeln.

Mögliche Techniken

Hier sind einige potenzielle Techniken, die Projekt- oder Planungsaufschlüsselungen mit ausreichender Granularität liefern können:

  1. Erstellen Sie eine Rückverfolgbarkeitsmatrix , die nützlich ist, um komplexe Anforderungen miteinander zu verknüpfen.
  2. Entwickeln Sie ein Mikado-Diagramm , das im Wesentlichen ein gerichteter azyklischer Graph von Abhängigkeiten ist.
  3. Folgen Sie einem „Vertical-Sliced-Feature“-Ansatz, bei dem ein Full-Stack-Feature in Bezug auf die Funktionalität beschrieben wird, die Implementierung jedoch dem Ermessen des funktionsübergreifenden Teams überlassen bleibt, das es erstellt. (Hinweis: Dies ist der Ansatz, der von den meisten agilen Entwicklungsteams verwendet wird.)

Es gibt sicherlich auch andere Ansätze, aber die Techniken fallen letztendlich entweder in die Kategorien Dekomposition oder Vertikalität. Wenn Sie in keiner der beiden Kategorien vorankommen, kann es hilfreich sein, einen Schritt zurückzutreten und zu überdenken, warum Ihr Projekt so eng gekoppelt ist.

Übermäßig gekoppelte Anforderungen sind ein häufiges Projektproblem, aber die Hauptursache ist oft eher ein Konstruktions- oder Planungsfehler als ein unlösbares technisches Problem. Ihr Kilometerstand kann jedoch variieren.

Es hört sich so an, als wären Ihre Abhängigkeiten im Grunde genommen Module oder Schichten innerhalb einer einzelnen Anwendung?

Um ehrlich zu sein, ich bin kein großer Fan von "schwereren" digitalen Tools, aber ich denke, wenn Sie nach etwas suchen, das Änderungssätze nativ an die Versionierung an Abhängigkeiten und Teammitglieder oder Projekte bindet, müssen Sie suchen in etwas wie modifiziertes JIRA oder MSProject/TFS, wie die anderen vorgeschlagen haben.

Ich persönlich habe Erfolg damit, mich einfach auf eine extrem hohe Sichtbarkeit bestimmter Toolfunktionen zu konzentrieren – es ist sehr schwer , sich nicht gut zu koordinieren, wenn der Backlog/Sprint-Chunking jeder Gruppe, der Fortschritt, die aktuellen Risiken und Abhängigkeitselemente an einer großen Wand im Team hängen (s) Bereich. :)

Einige der anderen Antworten bieten einige gute Vorschläge aus Sicht des Projektmanagements. Meiner Erfahrung nach sollte das Projektabhängigkeitsmanagement jedoch nur ergänzend sein. Der größte Teil der Schwerstarbeit in diesem Bereich sollte auf technischer Ebene liegen.

Da dies das PM-Board ist, möchte ich nicht auf zu viele Details eingehen, aber Sie könnten dies dem Team mitteilen, und wenn sie sich nicht sicher sind, wie sie es bewerkstelligen sollen, gibt es andere großartige Stackexchange-Boards für die Programmierung, die geben könnten umfangreiche Informationen zu diesen Themen.

Insbesondere die beiden Bereiche, die den größten Einfluss haben werden, sind:

Code-Repository: Die effektive Nutzung eines Code-Repositorys, insbesondere mit einer guten Suite von Komponententests, kann Builds erstellen, bei denen Sie wissen, dass alle Teile ordnungsgemäß zusammenarbeiten, ohne zu viel Zeit von den Entwicklungszyklen des Teams zu nehmen.

Objektorientierte Prinzipien: Ich versuche, diesbezüglich nicht dogmatisch zu sein, aber im Geiste der objektorientierten Programmierung zu bleiben (ich weise die Leute als Anfang gerne auf die SOLID-Prinzipien hin ), ist ein langer Weg, um Teile der Anwendung zu entkoppeln und zuzulassen Anwendung wachsen, ohne dass der PM jeden kleinen Schritt nach vorne kontrollieren muss.

Natürlich mögen es einige Teams nicht wirklich, wenn ein Projektmanager ihnen sagt, dass sie technische Praktiken verbessern sollen, also müssen Sie das vielleicht vorsichtig angehen.

Wie kann ich Anwendungsabhängigkeiten kollektiv nachverfolgen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v