Mit diesem Formular können Sie fehlende, unklare oder fehlerhafte Inhalte in der Dokumentation melden und Verbesserungsvorschläge machen. Ihr Feedback hilft uns, die Qualität und Vollständigkeit kontinuierlich zu verbessern.
Mitentwicklung durch Kunde oder Drittpartner
In einigen Projekten entwickelt der Kunde ebenfalls an seiner Lösung und/oder es wird auch durch Drittpartner für den Kunden entwickelt. Die folgenden Abschnitte geben eine Übersicht über Best Practices in der Entwicklung für diese Szenarien.
Festlegen der Zusammenarbeit
Vor jeder praktischen Umsetzung muss vereinbart sein, wie die Aufgabenteilung im Projekt aussieht. Das Ziel ist eine Struktur, die an möglichst wenig Stellen Fragen der Zuständigkeit und Verantwortung aufkommen lässt. Folgende Vorgehensweisen kommen in der Praxis vor:
| Trennung | Vorteile | Nachteile |
|---|---|---|
| Vollständig separiert GOB, Kunde und Partner nutzen komplett eigenständige Verfahren und Tools. Die Extensions bedingen sich nicht gegenseitig. | Klare Trennung von Verantwortung bei Implementierung und Nachbetreuung. Nur mittelbare Seiteneffekte möglich. | Technischer Gesamtüberblick ist erschwert. Automatismen und Verfahren müssen mehrfach aufgesetzt und gepflegt werden. Erhöhter Koordinationsaufwand. Keine technische Synergie, auch zum Zusammenlegen geeignete Programmteile sind dauerhaft getrennt. Technische Abhängigkeiten zwischen den Extensions sind möglich, aber aufwändig zu managen. |
| Getrennte Extensions in gemeinsamen Workspace GOB, Kunde und Partner schreiben jeweils an eigenen Extensions, die aber für alle zugänglich im selben Workspace und Repository liegen. | Immer noch gute Trennung von Verantwortung bei Implementierung und Nachbetreuung. Nur mittelbare Seiteneffekte möglich. Technische Abhängigkeiten zwischen den Extensions sind gut zu managen. | Auch zum Zusammenlegen geeignete Programmteile sind dauerhaft getrennt. |
| Volle Durchmischung GOB, Kunde und Partner bearbeiten gemeinsam alle Extensions im selben Workspace und Repository. | Größte Flexibilität in der Ressourcenplanung. Volle Freiheit bei technischen Entscheidungen. | Verantwortung in Implementierung und v. a. Nachbetreuung ist nur schwer oder gar nicht zu ermitteln. |
Die Einschätzung dazu kann je Projekt unterschiedlich ausfallen. Diese Empfehlung sollte als Leitlinie dienen:
- Kunde und GOB beginnen mit: Getrennte Extensions in gemeinsamen Workspace. Dies funktioniert gut mit den häufig vom Kunden übernommenen Arbeiten wie Datenübernahme, Belegdesign, Maskendesign, Rollencenter-Entwicklung, Entwicklung spezifischer Schnittstellen oder Einzelmodule.
- Kunde und GOB wechseln in der Nachbetreuung zu: Volle Durchmischung. In der Regel strebt der Kunde ab dieser Phase mehr Autonomie an und will dann ggf. auch an von der GOB ausgelieferten Programmteilen in eigener Geschwindigkeit und Verantwortung Weiterentwicklung vornehmen. Gleichzeitig fordert der Kunde ggf. auch Unterstützung bei Weiterentwicklung seiner Programmbestandteile an, wenn er einen Engpass hat.
- Partner haben in der Regel dedizierte Themen, für die sie beim Kunden entwickeln. Dies ist entweder Vollständig separiert, wenn auch die Nachbetreuung immer beim Partner bleibt oder Getrennte Extensions in gemeinsamen Workspace wenn mehr Handlungsoptionen offen bleiben sollen.
Zugriff von Kunde und Partner auf die Entwicklung
Entwickler des Kunden und des Partners können auf das Projekt in Azure DevOps zugreifen. Stand heute erfordert dies:
- Der Entwickler benötigt eine Visual Studio Subscription (Pro oder Enterprise)
- Mit dieser kann er in die Azure DeOps Organisation eingeladen werden, in der das Kundenprojekt liegt
- Dort kann er als Entwickler berechtigt werden und erhält somit Zugriff auf die Repositories im Projekt
Die Organisation erfolgt über den GOB Projektleiter.