Agile Modeling
Begriff und Definitionen
Agile Modeling (AM) ist eine Philosohpie für die erfolgreiche Arbeit in kleinen und mittelgroßen Softwareprojekten. Es quasi eine entwurfsseitige Ergänzung zum Extreme Programming (XP).
Es geht wie bei allen Agilen Prozessen letztendlich darum, basierend auf klassischen und erfolgreichen Vorgehensmodellen zur SW Entwicklung eine für kleine und mittelgroße (neuerdings auch für richtig große) Entwicklungsprojekte angepasste Varainte zu finden, um effektiver, effizienter, erfolgreicher zu werden.
Exkurs Vorgehensmodelle und Innovationszyklen der IT
Am Anfang der IT Entwicklung wurden Programme und Daten so bearbeitet, dass sie für die Hardware zugänglich wurden. Später gab es maschinenneutralere Sprachen, welche die paradigmale Sicht von der HW auf die SW lenkte (es entstanden die funktionale und die objektorientierte Programmierung -> Ja, Smalltalk und Eiffel sind etwa genauso alt wie C und deutlich älter als C++ oder gar JAVA), was die strukturierten Entwurfstechniken ermöglichte, die hardwareneutral, softwareorientiert und (more or less) sprachneutral waren. Bis hierher war es so, dass die phasenorientierten Vorgehensmodelle notwendig waren, um überhaupt eine Chance zu haben, Lochkarten, Lochstreifen, Magnetbänder und erste Disketten mit 360 kB Platz zu verwalten, Debugging war ja noch was anderes als es heute ist ;) Nachdem aber die Sprachen eine weitgehende Hardwareneutralität für die Programme sicherten und die Standardisierung von Sprachen sogar crossplatform Kompatibilität sichern, wurde der Entwurf weiter normiert. In der Folge wurde der Entwurf konsequent sprachneutral (was er bei der Hollerith Zählmaschine übrigens auch schon mal war), wodurch der Inhalt der SW Entwicklung als funktionierende Software definiert werden konnte, was in den agilen Modellen als primäres Ziel definiert wird. Die Weiterverbreitung der objektorientierten Technologie ermöglichte in den 90er Jahren des 20. Jahrhunderts die Entwicklung der UML und damit die Entwicklung neuer Vorgehendmodelle. Während im strukturierten Entwurf die Idee der mehr oder weniger seriellen Projektabläufe zu Grunde lag, wurden in der objektorientierten Denkweise schnell die zyklischen Ideen zur festen Basis. Dies hat sowohl philosophischen wie auch rein praktischen und wirtschaftlichen Hintergrund. Typische Vertreter solcher Prozesse ist der Rational Unified Prozess. Agile Prozesse sind nun kein Bruch mit dieser Enbtwicklung, sondern sie nehmen sich die klassischen Vorgehensmodelle her und ergänzen sie um einen philosophischen Background sowie einen grundsätzlichen Wechsel im Denken, der dem deutschen Ingenieur oft zutiefst widerstreblich ist und deshalb hier hervorgehoben wird. Ersetze das Dogma durch die Zweckmäßigkeit lautet die Parole. Menschen werden statt der Prozesse ind en Mittelpunkt gerückt, das Ergebnis zählt, nicht der Weg. Begünstigt wird dies dadurch, dass Programmierer zunehmend für ihre Leistung bezahlt werden und nicht für ihre Anwesenheit im Unternhemen. Nachfolgend finden sich die Grundsätze für Agilen SW Entwurf. In der Zukunft wird sich der serviceorientierte Entwurf etablieren. Prinzip bis hierher also:
- hardwareorientiertes Vorgehen zur SW Entwicklung bis zur Erfindung prinzipiell maschinenunabhängiger Sprachen wie FORTRAN, ALGOL, C (Phasenmodelle) --> Tom deMarco
- funktional-strukturiertes Vorgehen mit Blick auf die Software (strukturierter und objektorientierter Entwurf) seit der Verfügbarkeit sprachneutraler Entwurfstechniken (Phasen-, Prototypische- und Verbesserungsmodelle) Tom deMarco, Barry Boehm
- verfügbarkeitsorientiertes Vorgehen (serviceorientierter Entwurf) --> MDA, komponentenorientierter Entwurf, Rapid Prototyping, Codegenerierung, Modellgenerierung per Patterns und regelbasierter Systeme
Dieser Exkurs basiert auf meiner Vorlesung zu Vogehensmodellen and er AIK Dresden.
Prinzipien
- AM erfüllt seinen Zweck.
- AM ist in ausreichendem Maße verständlich.
- AM ist in ausreichendem Maße genau.
- AM ist in ausreichendem Maße konsistent.
- AM ist in ausreichendem Maße detailliert.
- AM liefert positive Ergebnisse im Sinne eines kundennahen Projekterfolges.
- AM ist so einfach wie möglich, aber nicht einfacher.
- AM ist nicht perfekt.
- AM ist eine Philosophie und kein vorgeschriebener Prozess.
- AM ist eine Ergänzung zu vorhandenen Methoden und keine komplette Methodenlehre.
- AM ist eine Methode effektiver Zusammenarbeit um die Bedürfnisse des Kunden, des Managements und der Entwickler zu erfüllen.
- AM ist effektiv und handelt von Effektivität.
- AM ist nicht nur theoretisch sondern auch in der Praxis einsetzbar.
- AM ist für den durchschnittlichen Entwickler gedacht und kein Ersatz für Kompetenzteams.
- AM ist kein Angriff auf die Dokumentation, stattdessen fordert es die Erstellung tatsächlich nützlicher Dokumente.
- AM ist kein Angriff auf CASE-Tools, es fordert nur deren sinnvollen Einsatz.
- AM ist nicht für jedermann - es ist für flexible, effizienzorientierte Menschen.
Werte
- Kommunikation
- Innovation
- Kundennähe
- Bescheidenheit
- Einfachheit
Praxis
- Integriere alle Beteiligten in das Projekt
- Kollektiveigentum an Projektteilen heißt flexible, unter hoher Selbstbestimmung koordinierte Arbeitsteilung
- Sichere die Testbarkeit Deiner Lösung
- Visualisiere deine Modelle
- Arbeite in kleinen Schritten
- Unterlege dein Modell mit (Pseudo-) Code
- Wähle ein passendes Werkzeug - nicht das Üblichste!
- Erstelle mehrere Modelle parallel
- Erstelle einfachen Inhalt
- Präsentiere deine Modelle
- Entwickle im Team
- Verwende möglichst einfache Werkzeuge
- Finde einfache Lösungen
- Verwende Modellierungsstandards
- Wende Patterns zurückhaltend an
- Standardisiere Deine Vertragsmodelle zur Optimierung Deiner Kommunikation mit dem Kunden
- Modelliere um zu Kommunizieren
- Modelliere um zu Verstehen
- Verwende vorhandene Ressourcen mehrfach
- Aktualisiere nur wenn unbedingt erforderlich