Agilität ist nach wie vor hype. Da wird mal gerne vom Management beschlossen „das machen wir jetzt auch“. Einige wichtige Aspekte bleiben hier aber unbeantwortet und sorgen dann für viele Diskussionen. Für uns ein Grund die wichtigsten Klärungspunkte aufzuzeigen und diesen dem ersten Kern unseres neuen Plakats zu widmen.
Agil ≠ Agil – welche Teile Ihres Projekts wollen Sie agil abwickeln?
Die erste bewusste Entscheidung – oder Arbeitshypothese – sollte sein, die Phasen zu definieren, die durch ein agiles Vorgehen abgedeckt werden. Normalerweise ist hier immer die Implementierung/Umsetzung der Ausgangspunkt für ein agiles Arbeiten. Dieser wird dann noch durch weitere Phasen davor bzw. danach ergänzt. Es geht aber auch anders. Es kann jegliche Phase „Keimzelle“ von Agilität sein. Auch eine Spezifikation kann agil erstellt werden (User Stories wären hier Aufgaben, um Teile der Spezifikation zu erstellen)
Entsprechend oft reden die Beteiligten schon hier bei Diskussionen aneinander vorbei.
Diese Definition ist aber für den nächsten Punkt entscheidend.
Wollen Sie (vorab) spezifizieren oder (nachher) dokumentieren?
Denn es sollte auch definiert sein – zu mindestens auch hier wieder als erste Arbeitshypothese – ob die Anforderungen vor, während oder nach dem Sprint aufgeschrieben werden – also vorab spezifiziert bzw. im Nachgang dokumentiert.
Auch hier gibt es wieder verschiedene Varianten. Wird eine Ausschreibung oder die Vorgabe eines OEMs umgesetzt, dann wurden die Anforderungen schon (außerhalb des Development-Teams) spezifiziert und nun kontinuierlich umgesetzt. Über Just-in-time Spezifikation nähern wir uns der Spezifikation/Dokumentation im Development-Team, um dann wieder außerhalb des Development-Teams zu dokumentieren.
Wichtig ist: all diese Varianten gibt es und machen auch Sinn. Meist treten diese sogar in Kombination in einem einzigen Projekt auf. Vor allem dann, wenn man nicht nur ein System betrachtet – und das bringt uns zur nächsten Frage.
Wollen Sie Ihre Wünsche systemübergreifend oder systemspezifisch umsetzen?
Stellen Sie sich vor, Sie haben ein großes Finanzsystem, ein Archiv, ein Dataware-House und noch ein altes Host System. Soll jetzt wirklich ein Team all die Systeme anpassen? Diese jeweils komplizierten Systeme mit eigenen Technologien? Und wenn es mehr als ein Team gibt, werden dann mehrere Systeme zeitgleich von mehreren Teams angepasst?
Wir müssen also unsere Aufgaben und Teams sinnvoll schneiden. Eine mögliche Lösung wäre im Team systemspezifisch vorzugehen – dies bedingt aber gleichzeitig auch Vorgaben, die auch möglichst systemspezifisch sind.
Gerade bei der Einführung von Agilität gibt es meist auch Teams die noch nicht agil arbeiten und integriert werden müssen.
Mögliches Gesamtbild für die Systementwicklung
Nimmt man die ganzen Aspekte zusammen, dann kann als Diskussionsgrundlage folgendes Vorgehen dienen:
Durch verschiedene Randbedingungen bzw. durch die ständigen Optimierungen kann oder muss sich dieses Vorgehen noch ändern.
Falls Sie noch mehr Teams einsetzen wollten sollten Sie sich mit agile scaling frameworks beschäftigen – ein Blogeintrag folgt hier in Kürze.
Was muss spezifiziert / dokumentiert werden?
Für das Thema „spezifizieren oder dokumentieren“ ist jetzt noch ein Punkt offen: Was sollte in welcher Qualität vorliegen? Um diese Erwartungen festzuhalten eignen sich z.B. die definition of ready bzw. definition of done. Mehr dazu unter „Ist das Doku oder kann das weg? – Dokumentation in (agilen) Projekten“
PS: Eins haben wir noch
An welchen Stellen einer agilen Entwicklung werden Methoden des RE angewendet?
Das Requirements Engineering beschäftigt sich mit dem Ermitteln und dem Weitergeben von Wissen.
Auch in einem agilen Vorgehen unterstützen die Disziplinen des Requirements Engineering dieses Vorgehen und sind an vielen Stellen vertreten.
Falls Sie das Ganze jetzt noch gerne auf einem Blick hätten, dann können Sie sich das Plakat in unserem Bereich „Wissen 4 free“ als A3 PDF downloaden.