Das Manifesto für agile Entwicklung (https:// agilemanifesto.org) proklamiert folgende Werte (frei übersetzt vom Verfasser):
Individuen und Interaktionen über Prozesse und Tools
■ Funktionierende Software über umfassende Dokumentation
■ Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
■ Reagieren auf Veränderungen über die Planverfolgung
Der dritte Punkt ist der Stein des Anstosses oder gleich der Lösungsansatz. Wie schon im Artikel «Wasserfallmodell versus agile Methode» Polyscope 14/2019 aufgezeigt, ergibt es keinen Sinn, mit dem Kunden eine abschliessende Anforderungsdokumentation zu erstellen und nach Monaten eine Software zu liefern, um dann herauszufinden, wo man sich nicht verstanden hat. Ein weiterer Bestandteil, der in den Verträgen vereinbart wird, ist die terminliche Situation. Agile Methoden gehen
von Zyklen von Wochen bis Monaten aus, diese können sich mit den Terminvorstellungen des Kunden widersprechen.
Die strategische Bedarfsplanung kann auch von agilen Methoden profitieren
Für eine Firma mit einem Softwareprodukteentwicklungsbereich von einigen hundert Entwicklern, die neue Produkte entwickeln oder bestehende Produkte weiterentwickeln, bietet sich eine Planung in mehreren Ebenen an. In der Hauptsache unterscheiden sich diese in der Bedarfs- und der Ausführungsplanung. Die Bedarfsplanung muss die Fragestellung «was kann und will ich mir leisten?» beantworten. Bei bestehenden Produkten kann unterschieden werden, was in Wartung, Support, Erweiterungen oder Verbesserungen investiert wird. Bei neuen Produkten oder grösseren kundengetriebenen Produkteentwicklungen muss der Inhalt, der Lieferplan und der Entwicklungsressourcenbedarf in der entsprechenden Granularität bekannt sein. Das Ganze wird in einem Themen-Portfolio abgebildet, aus dem ersichtlich ist, wie gross der Auslastungsgrad dafür ist. Der Begriff Thema wurde bewusst gewählt, um eine Unterscheidung zu Projekten zu machen. Ein Thema kann die Wartungen eines Produktes, die Entwicklung eines neuen Produktes oder kundengetriebene Produkteerweiterungen beinhalten. Diese Planung wird nicht isoliert, sondern in Zusammenarbeit mit Kunden und den internen Stakeholdern als eine Iteration eines Entwicklungszyklus erstellt und unterhalten.
Produkte Domains gruppieren in grossen Software-Produktefirmen agile Entwicklungsteams
Auf der Gegenseite ist die Organisation, welche in sich geschlossene inkrementelle abgeschlossene Lieferungen – sprich Funktionalitäten, Erweiterungen oder Fehlerbehebungen – erstellt. Je nach der Grösse der Entwicklungsabteilung kann es Sinn ergeben, die Entwicklungsteams entlang von Produkte-Domains zu gruppieren. Entgegen einer Projektorganisation, bei der die Business-Analysten und -Entwickler fallweise einer Projektorganisation zugeordnet werden, bleibt in dieser Entwicklungsmethode das Team stabil. Die Teams organisieren ihre Arbeit mit einer agilen Methode; sei es Scrum, Kanban oder XP. In dieser Organisationsform wird die Planung pro Ebene in sogenannten Arbeitsbüchern oder – in Neudeutsch – Backlogs abgebildet. Diese Backlogs bestehen aus Einheiten (Initiativen, Epics, Tasks oder Storys), die in eine Rangreihenfolge gesetzt werden. Im Weiteren werden die Elemente in Beziehung zu den anderen Ebenen gesetzt; damit wird eine sehr hohe Transparenz erreicht und die Abstimmung zwischen den Stakeholdern ermöglicht. Die Abstimmung zwischen den Stakeholdern wird erleichtert, wenn standardisierte Kennzahlen (zum Beispiel: Erhöhung Einnahmen, Reduktion Aufwand in der Produktepflege, Grad der Service-Level-Verletzung etc.) für die Wertigkeit der Einträge in den Backlogs verwendet wird. Die Pflege eines Backlogs erfolgt laufend durch den Produkt Domain Owner mit den Stakeholdern. Periodische Planungsreviews mit Produkt Domain Ownern, Stakeholdern und dem Entwicklungschef dienen dazu, Konflikte, die nicht direkt zwischen dem Produkt Domain Owner und den Stakeholdern gelöst werden können, domainübergreifend zu besprechen und lösen.
Jede Ebene plant stufengerecht und hat in den Backlogs jederzeit alle Vorhaben rangiert
Planung in den verschieden Ebenen kann nur erfolgreich sein, wenn die Planung stufengerecht erfolgt. Auf der Themen Ebene wird geplant, wie viel Wartung insgesamt geleistet, wie viel für die Umsetzung eines strategischen Handlungsfeldes, wie viel in die Produkteverbesserung oder kundengetriebene Entwicklungen eingesetzt werden soll. Auf den weiteren Ebenen werden weitere Verfeinerungen von den Produkt Domain Ownern und in Absprache mit den Stakeholdern vorgenommen. Die Themen können sich in folgenden Status befinden. Idee: Es muss abgeklärt werden, ob daraus ein lohnenswerter Business Case werden kann. Planung: Es wird ein Business Case erstellt, es werden die Aufwände und potentiellen Einnahmen abgeschätzt, eine Grobplanung erstellt und die resultierenden Kosten berechnet. Nachdem der Business Case bewilligt wurde, wird das Thema mit dem Status «Development» im Backlog der Entwicklungsabteilung versehen. Wenn die Summe der Themen für die nächsten Quartale die vorhandenen Ressourcen um das Vielfache übersteigt, dann gibt es nur zwei Optionen. Man baut die Kapazität auf, wenn sich die Firma die Investitionen leisten kann oder alimentiert den Themenbedarf entlang der Rangreihenfolge auf die vorhandene, geplante Kapazität. Das heisst in letzter Konsequenz, dass man nicht jedes Thema bis zum geplanten Ende ausführt, sondern es aus dem Rennen für die Entwicklungsressourcen nimmt, wenn der Mehrwert nicht mehr gegeben ist und dadurch Platz für neue Themen resultiert. Die Planungsphase jedes Themas sollte zyklisch, zumindest vor der Finanzjahresplanung, durchlaufen werden, damit die gewonnenen Erkenntnisse eingearbeitet und neue Kennzahlen für die Bestimmung der Rangreihenfolge der Themen ermittelt werden können. Ähnliche Status können auch die Produkt Domain Backlogs für Ihre Vorhaben pflegen. Darum müssen klare Definitionen für die Aufnahme eines Eintrages in den Backlog (was will ich, was darf es kosten?) und wann kann der Eintrag als erledigt betrachtet werden (ist Testen der Software, Dokumentation enthalten?). Diese Punkte klingen etwas nach Wasserfall, sind jedoch notwendig, damit die Domains effizient planen und mit den Stakeholdern zusammenarbeiten können. Die laufende Pflege der Rangreihenfolgen auf jeder Ebene ermöglicht, jederzeit auf Veränderungen zu reagieren und neue Vorhaben aufzunehmen. Die Domain sollte sich vor einem Zyklus zu einer Anzahl Vorhaben verpflichten, diese müssen in Summe nicht der Entwicklungskapazität entsprechen; es ist sogar besser, wenn noch etwas Luft ist. Da alle Vorhaben im Backlog aufgelistet und rangiert sind, kann die Domain weiterarbeiten, wenn der verpflichtende Teil abgeliefert wurde. Der Produkt Domain Owner muss auf jeden Fall Rücksprache mit den Stakeholdern nehmen, wenn er ein versprochenes Vorhaben nicht im vorgesehen Zyklus liefern kann.
Sie können die Planbarkeit Ihrer Themen erhöhen, wenn Sie einem Thema dezidierte Domains zuordnen und keine Störung von aussen zulassen. Sie verlieren damit eine gesunde Konkurrenz zwischen den Themen. Die Gefahr besteht, dass das Budget bis zur Sinnlosigkeit abgearbeitet wird. Es ergibt aber Sinn Mischformen zuzulassen. Ich weise einem hohen rangierten Thema dezidierte Domains zu, bis in der Themenrangierung festgestellt wird, dass sich die Sonderbehandlung nicht mehr rechtfertigt. Zentral ist, dass all diese Entscheidungen faktenbasiert, transparent und aufgrund der Rangierreihenfolge gefällt werden.
Eine Umstellung auf agile Entwicklungsmethoden sollte agil eingeführt werden
Es empfiehlt sich, eine solche Entwicklungsmethode auch mit einem agilen Vorgehen einzuführen. Am besten formiert man ein Kernteam, das den ganzen Prozess einführt, verbessert, moderiert und unterstützt. Das Team kann verstärkt werden durch einen externen Berater, Kontakte zu Firmen, die ähnliche Modelle eingeführt haben oder durch Lesen von Fachartikeln. Das Kernteam muss selbstkritisch sein und nach jedem Planungszyklus mit den verschiedenen Stakeholdern die nächsten zwei bis drei Handlungsfelder identifizieren und diese im folgenden Zyklus einführen. Zum Schluss: Es kann sein, dass ich in einem Jahr wieder einen Artikel über die gewonnenen Erfahrungen verfasse. Man darf gespannt sein. (Fortsetzung folgt)
Infoservice
Thomas Hauser
Swiss Engineering Fachgruppe Elektronik und Informatik (FAEL)
Te. 079 573 20 27
thomas.hauser@fael.ch,www.fael.ch
