Der agile Werkzeuggürtel
Kennen Sie die Situation: Jemand kommt zu Ihnen und hat „die“ Lösung für Ihr Problem? Er ist sogar zertifiziert und kann nachweisen, dass er „die“ Lösung schon zigfach angewendet hat? Und trotzdem lässt Sie das Gefühl nicht los, dass er keine Ahnung hat, was Ihr eigentliches Problem ist? Willkommen in der Welt des Hammers!
Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.
Paul Watzlawick
Leider gibt es viel zu viele Menschen, die – nachdem sie ein Werkzeug kennen gelernt haben – aufhören nach neuen Werkzeugen zu suchen. Nur die wenigsten verfügen über einen ganzen Werkzeugkasten und sind in der Lage, je nach Situation das geeignete Werkzeug anzuwenden. Dieser Blogbeitrag soll einen Überblick über eine kleine Auswahl an Methoden geben, die je nach Situation angemessen sein können. Natürlich ist die Liste nicht vollständig – das wird sie hoffentlich niemals sein…
Die Metasicht
In jedem Projekt und jedem Produktentwicklungsszenario müssen mindestens drei Tätigkeiten ausgeführt werden: Anforderungsdefinition, Implementierung und Überprüfung des Ergebnisses. Natürlich sind noch viele weitere Tätigkeiten denkbar, jedoch fokussiere ich mich in diesem Beitrag nur auf diese drei. Ob diese Schritte parallel oder sequenziell abgearbeitet werden, hängt dabei von der Komplexität des zu lösenden Problems ab:
Diese Grafik basiert auf Schwaber & Beedle 2002, die sich wiederum auf Stacey1996 beziehen.
Einfache Probleme zeichnen sich im Wesentlichen dadurch aus, dass sie vorhersagbar sind. Das trifft zum Beispiel auf eine Serienfertigung zu: Alle Parameter sind vorher bekannt und wiederholbar. In einem solchen Umfeld machen sequentielle Ansätze wie „Wasserfall“ Sinn und sollten verwendet werden.
Im komplizierten Bereich, zum Beispiel der Wartung bestehender Produkte, ist eher ein Kanban-Ansatz geeignet. Im komplexen Bereich, zum Beispiel der Neuentwicklung eines Softwareproduktes, überwiegt die Unsicherheit in den Dimensionen Anforderungen, Menschen und Technologie; daher ist ein Ansatz nötig, der mit sich ändernden Rahmenbedingungen umgehen kann, z.B. Scrum.
Im chaotischen Bereich, also einem Umfeld in dem es keine Sicherheiten gibt wie z.B. in Startups oder Forschung, bietet sich eine Kombination aus Lean Startup und Scrum an.
| Ansatz | kurze Erläuterung |
| Wasserfall | Phasenorientiertes, vorhersagendes Prozessmodell, das auch als „klassisches Projektmanagement“ bezeichnet wird |
| Kanban | Flow-orientiertes Prinzip, das auf dem bestehenden Prozess aufsetzt und über Transparenz und Limitierung der Arbeit im System eine evolutionäre Optimierung anstrebt. |
| Scrum | Ein agiles Framework, bestehend aus einigen Rollen, Meetings und Artefakten, das mit Hilfe kurzer Iterationen und einem hohen Fokus auf Geschäftswert schnell greifbare Ergebnisse liefert. |
| Lean Startup | Eine Sammlung von Praktiken, die im Wesentlichen dafür sorgen, dass Hypothesen aufgestellt und mit Hilfe von Prototypen und passenden Metriken validiert werden. |
Alle vier Ansätze müssen aber trotzdem die zuvor beschriebenen Aufgaben Anforderungsdefinition, Implementierung und Überprüfung abarbeiten. Dabei sind die spezifischen Methoden nicht exklusiv einer Methode zuzuordnen: Selbstverständlich kann jedes Werkzeug in jedem Ansatz zur Anwendung kommen, sofern die Situation dies erfordert.
Der Werkzeugkasten
Es gibt weit mehr Werkzeuge, als der durchschnittliche Leser bereit wäre in diesem Artikel zu lesen. Im Folgenden zeige ich Ihnen daher nur acht Methoden, die Ihnen im Alltag helfen können. Dabei fokussiere ich mich auf eine grobe Übersicht.
| Werkzeug | Kurze Erläuterung | Hilft bei |
| Specification by Example (aka Acceptance Test Driven Development) | Die Anforderungen werden in Form von Beispielen spezifiziert und idealerweise sofort mit automatisch ausführbaren Tests hinterlegt. Geschieht dies kollaborativ mit dem Entwicklungsteam, werden Missverständnisse minimiert. Je höher der Grad der Testautomatisierung, desto einfacher ist am Ende auch die Überprüfung des Ergebnisses. | Anforderungs-definition, Überprüfung |
| User Stories | Eine sehr häufig eingesetzte Methode zur Beschreibung von Anforderungen. Das Format soll die Geschichte eines Anwenders erzählen, der eine Aktion ausführt, um ein Ziel zu erreichen. Durch die bildliche Sprache tun sich Anforderer leichter bei der Definition und Entwickler verstehen die Anforderung aus Sicht des Anwenders und sehen so über die Technik hinaus. Die Syntax ist dabei einfach: Als <Rolle> möchte ich <Feature>, damit <Nutzen>. Aber Vorsicht: Fehlt eine der drei Komponenten oder wird als Rolle „User“ oder „Product Owner“ gewählt, sind Sie auf dem Holzweg! | Anforderungs-definition |
| Impact Mapping | Um einen Erfolg versprechenden Weg bei minimalen Kosten durch den Dschungel der vielen Möglichkeiten zu finden, kann man eine „Karte“ erstellen, auf der die Auswirkungen verschiedener Maßnahmen dargestellt werden. Nun kann man sich für die Maßnahme entscheiden, die scheinbar die effizienteste Chance auf Erfolg bietet. | Anforderungs-definition |
| Planguage | Anforderungen werden massiv fokussiert und so formuliert, dass Missverständnisse nahezu ausgeschlossen sind. Dabei folgt diese sehr mächtige Methode den Prinzipien der Objektorientierung. Gerade in Verbindung mit Impact Mapping können exzellente Ergebnisse erzielt werden. Aber Vorsicht: Nutzt man diese Technik mit einem klassischen Mindset, entsteht zu viel Dokumentation bei zu wenig Wert. | Anforderungs-definition |
| Test Driven Development | Entwickler schreiben zunächst einen Test, implementieren dann die zugehörige Funktionalität und restrukturieren den Code anschließend, um ihn zu optimieren. Das schafft Klarheit im Denken bei der Umsetzung. | Implementierung |
| Pair Programming | Zwei Entwickler sitzen an einem Rechner und entwickeln gemeinsam den Code. Einer ist der „Driver“ und benutzt die Tastatur, der andere ist der „Navigator“ und denkt ein wenig voraus. Alle paar Minuten werden die Rollen gewechselt. Da zwei Gehirne schlauer sind als ein einzelnes können insbesondere knifflige Probleme so effizienter gelöst werden und das Wissen steckt nicht nur in einem Kopf. | Implementierung |
| Critical Path Testing | Alle Abläufe des Programms werden grafisch dargestellt und nach Wichtigkeit sortiert. Ist der „kritische Pfad“ identifiziert, also die Abläufe im Produkt, die am Wesentlichsten für den Kundennutzen sind, können diese gezielt getestet werden. Meist wird der kritische Pfad bei jedem Check-In getestet während das Gesamtsystem nur einmal pro Nacht getestet wird. So lässt sich viel Zeit bei der täglichen Arbeit sparen. | Überprüfung |
| Mocking | Manchmal gibt es Abhängigkeiten zur Benutzerschnittstelle oder Datenbank, die es nicht erlauben, diese ständig mit zu testen. Auch kann es sein, dass der Testaufwand für eine vollständige Automatisierung nicht im Verhältnis zum Nutzen steht. Um trotzdem einen realistischen Eindruck über die Funktionsfähigkeit des Systems zu erhalten, können solche Schichten „gemockt“ werden, d.h. die Entwickler simulieren das Verhalten dieser Komponenten. Natürlich muss in geeigneten Abständen trotzdem mit dem realen System getestet werden; bei der täglichen Arbeit ist man die Abhängigkeiten aber los. | Implementierung, Überprüfung |
Fragen Sie sich selbst: Kennen Sie bereits alle acht Werkzeuge? Könnten Sie sie auch produktiv einsetzen? Kennen Sie ein Unternehmen, das noch bei „Scrum“ oder „Kanban“ verharrt, ohne sich Gedanken darüber zu machen, welche weiteren Werkzeuge benötigt werden, um exzellente Ergebnisse zu erzielen? Ändern Sie das!
Quellen:
- Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum (Pearson Internationalth ed.). Upper Saddle River: Prentice Hall.
- Stacey, R. D. (1996). Strategic Management & Organisational Dynamics: The Challenge of Complexity (2nd ed.). London: Financial Times Management.
Aktuelle Beiträge
Artikel kommentieren