Es folgen Vorschläge zum Zuordnen von Verantwortungen analog dem Rollenmodell bei agiler Projektarbeit für ein Softwarehaus.
I. Product Owner versus Kundenprojektleiter
Erste These: Das agile Vorgehensmodell muss die Rolle und die Einschränkung von Kompetenzen für den Kundenprojektleiter meines Unternehmens viel stärker verankern, als dies gemeinhin in der Praxis erfolgt.
Risiko
Kundenwünsche werden individuell umgesetzt und zerstören die saubere Struktur meiner Softwarebasis.
Strategie
Mein Softwarehaus muss wirtschaftlich agieren. Die Lösung, die ein Kunde erhält, sollte mittels der Nutzung meiner Software-Basis implementiert werden. Die Erweiterung dieser Basis erfolgt sukzessive – stets mit Blick auf meinen Softwarestandard*.
*Gemeint sind: eingerichtete Entwicklungsumgebung, Architektur-Bibliotheken, Funktionsbibliotheken bis hin zur Oberfläche – also die Ergebnisse der bisherigen Entwicklungsarbeiten. Diese sind neben dem Humankapital das wichtigste Asset meines Unternehmens.
Mein Kundenverantwortlicher bzw. Kundenprojektleiter – im agilen Vorgehensmodell nach Ansicht des Verfassers nur unzureichend abgebildet – muss seine Vorschläge zur Abbildung von Kundenwünschen in der Software eng mit dem Entwicklungsleiter bzw. dem Product Owner abstimmen.
Andernfalls „zerfleddert“ meine Basis, jeder Kunde bekommt eine „Extrawurst“ und der Second-Level-Support kann bei Befunden nicht mehr effizient arbeiten.
Beachten
Mit dem Kunden ist zu vereinbaren, dass Sonderwünsche so spezifiziert werden, dass ein neues Modul an alle Kunden ausgeliefert werden kann. Über das Berechtigungskonzept wird das Modul beim Anforderer freigeschaltet. Andere Kundenverantwortliche erhalten die Funktionsbeschreibung als Vertriebsinformation und prüfen den Mehrwert für ihre Kunden.
II. Product Owner versus Entwicklungsteam*
*Entwicklungsteam à la Agil: Ein selbstorganisiertes, interdisziplinäres Team, das Arbeit aus dem Product Backlog umsetzt und funktionsfähige Inkremente liefert.
Zweite These: Die Rolle „Entwicklungsleiter“ (hier im Fokus: Technical Lead – Chef der Architektur und Funktionsbibliotheken) ist im agilen Vorgehensmodell nicht exakt genug definiert.
Risiko
Dem Team bzw. einzelnen Mitarbeitenden werden zu viele Freiheiten eingeräumt.
Strategie
Wer Softwareentwicklung geleitet hat, kennt das Szenario: Ein findiges Teammitglied ist schnell fertig, hat aber neue – bislang unbekannte – Bibliotheken eingebunden. Meist Open-Source-Software mit sehr unterschiedlichen Lizenzbedingungen. Eine kostenlose Nutzung kann mit einem Update passé sein und die Kostenkalkulation unvorhersehbar beeinflussen. Neue Bibliotheken bringen zudem neue, oft unbekannte Schwachstellen.
Beachten
Bei der Fülle von Drittsoftware muss die Aufgabe „Bibliotheksverwaltung“ in eine verantwortliche Hand. Teams bedienen sich nur freigegebener Bausteine. Neue Bausteine werden beim Technical Lead beantragt. Ob Product Owner oder benannter Stakeholder diese Arbeit leistet, ist zweitrangig – die Aufgabe muss klar adressiert sein.
III. Bedienphilosophie & Usability versus agile Anpassungen
Dritte These: Eine Bedienphilosophie muss heutigen Standards genügen und sich über die gesamte Software konsistent „ziehen“.
Risiko
Unterschiedliche Bedienlogiken in verschiedenen Bereichen: mal Kontextmenü, mal verstreute Buttons, mal nur mit First-Level-Support nutzbar. Niemand hat Zeit oder Akzeptanz für exotische Bedienphilosophien.
Strategie
Für die User-Interaktion verwendete Bibliotheken müssen auf Usability geprüft sein und verbreiteten Standards entsprechen.
Beachten
Definieren Sie die Bedienphilosophie! Pseudo-Industrie-Standards werden von Systemen wie Amazon, PayPal & Co. geprägt. Organisieren Sie eine „Kundenreise“ (Usability-Tests mit unbedarften Personen). Zwingen Sie die Entwickler, sich mit gängigen Standards auseinanderzusetzen, um kreative, aber exotische Eigenentwicklungen zu vermeiden.
IV. Ausnahmebehandlung & Stabilität
Vierte These: Kein Entwickler kann jedes mögliche Fehlerszenario bei Eingaben, Korrekturen, Copy-&-Paste oder Rücksprüngen in verschiedenen Browsern vorabsehen.
Risiko
Die Software „verklemmt“; nur ein harter Restart ermöglicht weiterzuarbeiten.
Strategie
Funktionsbausteine für Exception Handling bereitstellen, die bei Fehlern den Zustand vor der Verarbeitung wiederherstellen.
Beachten
Mehrere Techniken (idealerweise als Code-Beispiele) bereitstellen: Vorbereitungs-Checks, kontrollierte Verarbeitung, Nachbereitung/Result-Checks. Das bläht einfache Funktionen auf, stabilisiert aber komplexe Softwaresysteme und schafft Handlungssicherheit. Jeder Entwickler muss diese Bausteine sicher anwenden können.
Fazit & Empfehlungen
Erfolg als Softwarehaus oder Inhouse-IT gelingt, wenn Kunden jederzeit bedürfnisgerecht bedient werden – nicht mit individuell „zusammengeschraubter“ Software, die nur 1–2 Personen verstehen.
Notwendig sind auf Anpassbarkeit getrimmte Softwarebausteine, die Kundenwünsche innerhalb der Funktionsbibliothek/Domänenmodelle („digitaler Zwilling“) abbilden. Falls Lücken bestehen, ist eine Erweiterung so zu konzipieren, dass sie allen Kunden zugutekommt.
Erforderlich ist zudem eine stringente Führung der Teams: einheitliche Umsetzungsvorgaben (Bedienphilosophie, Bibliotheken, interne Programmierleitlinien) und klare Rollenverantwortungen – von Kundenprojektleitung über Product Owner bis Technical Lead.
