Agile Entwicklungspraktiken: die zweite Generation

Keine Kommentare

Die Welt steht nicht still. Nach dem initialen Erfolg der agilen Methoden zwischen Ende neunziger und Anfang 2000 ist ihre Verwendung stark gewachsen, und ihre Anwendungsbereiche haben sich auch weit über ursprüngliche Sweet-Spots erweitert.Eine der Erweiterungen ist die Verwendung der agilen Praktiken für die Arbeit mit Datenbanken. Dies beinhaltet Arbeit an der Automatisierung von Änderungen der Datenbankschemata und auch Testen und Refactoring von Datenbanken.

Domain Modeling

Der FDD Ansatz für die Erstellung des Domain Models hat seine Weiterentwicklung durch Domain Driven Design (oder kurz DDD) gefunden. Man zwar kann nicht behaupten, dass DDD ein direkter Nachfolger der Color Modeling/Streamlined Object Modeling Ansatz ist, aber Streamlined Object Modeling ist in DDD Gemeinschaft weithin anerkannt und hoch angesehen.

Unit- und Akzeptanztests

Testgetriebene Entwicklung hat sich zu Behavior Driven Development oder BDD (verhaltensgetriebene Softwareentwicklung) weiterentwickelt. Der Hauptunterschied zwischen beiden liegt in der Sprache, die man für den Ausdruck der Anforderungen benutzt. Diese Sprache ist hilfreich, lesbarere Spezifikationen zu erzeugen.Zwei verschieden Varianten des Unit Tests haben sich kristallisiert. Diese sind zustandbasiertes Testen und interaktionsbasiertes Testen. In der zweiten Variante wird sehr stark Mocking verwendet.Die Gemeinschaft experimentiert aktuell mit weiteren Varianten des Unit-Tests. Eine dieser Varianten ist eigenschaftsbasierte Testen (property-based Testing auf Englisch), das seine Wurzeln in Haskells QuickCheck-Framework hat. Im eigenschaftsbasierten Testen wird der gleiche Test mit verschiedenen generierten Eingabewerten mehrfach ausgeführt .Eine andere Entwicklung ist die Adaption der agilen Entwicklungspraktiken für die Arbeit mit Legacy-Code. Dies hat zum Verständnis geführt, dass Unit-Testen in bestimmten Szenarien sehr kompliziert ist. Drei solcher Szenarien sind Unit-Tests für Legacy-Code, Unit-Tests für Oberflachen (GUI) und Testen von asynchronem Code.Die Techniken des automatisierten Akzeptanztestens haben sich gleichfalls weiterentwickelt. Diese wurden weiter als „Spezifikation durch Beispiel“ verfeinert. Viele verschiedene Akzeptanz-Test-Frameworks wurden neben dem Original Fit & Fitnesse entwickelt. Gleichzeitig bleibt diese Praxis nach wie vor eine der umstrittensten in der agilen Software-Entwicklung. Die Nachteile des automatisierten Akzeptanztestens werden aktuell allerdings deutlich besser verstanden. Deshalb hat manuelles Testen sein Comeback in Form von explorativem Testen.

Code Reviews und Statische Code Checks

Mehrere gute Software-Systeme wurden zur Durchführung verteilter Code-Reviews entwickelt. Zu diesen gehören Code Collaborator, Crucible, Review Board und andere. Sie haben den Aufwand der schwergewichtigen formalen Inspektionen reduziert.Aber auch die Verwendung statischer Code-Checks trägt sehr stark zur Code Qualität bei. Und auch hier wurden einige Plattformen entwickelt, die die Ergebnisse von verschiedenen Code-Check-Systemen zu einem Dashboard zusammenfassen. Man kann im Dashboard mit Hilfe eines Drill-Downs weitere Details erkunden. Dies ermöglicht laufende Qualitätsüberwachung des Quelltexts. Ein Beispiel für solches System ist SonarQube.

Kontinuierliches Testen

Die Erfahrung hat gezeigt, dass kontinuierliche Integration eine der wertvollsten agilen Praktiken ist. Diese wurde in zwei Richtungen erweitert.Zum einen ist die Praxis der Testausführung vor jedem Commit, die ursprünglich die Verantwortung des einzelnen Entwicklers war, durch Werkzeuge für kontinuierliches Testen verallgemeinert worden, was es erlaubt, Tests und statische Checks bei jeder Speicheroperation des Entwicklers automatisch durchzuführen.

Continuous Deployment und Continuous Delivery

Die zweite Richtung der Erweiterung sind Continuous Deployment und Continuous Delivery.Wenn man den Gedanken häufiger Releases bis zum konsequenten Ende durchdenkt, dann muss man über kontinuierliche Integration hinausgehen. Im idealen Fall sollte ein Release in eine beliebige Umgebung (Stage) eine Operation mit minimaler manueller Arbeit sein, im besten Fall eine „Ein-Klick“-Operation. Um dies hinzubekommen, muss deutlich mehr gemacht werden als für Continuous Integration, und vor allem müssen auch die verschiedenen Umgebungen genau wie die Skripte, die für das Deployment verwendet werden, automatisch aufgesetzt und verwaltet werden. Deshalb wurde Deployment-Automatisierung geboren.Deployment-Automatisierung ist eng mit der Notwendigkeit gekoppelt, Umgebungen leicht zu reproduzieren und Software auf mehreren identischen Knoten bereitzustellen. Insbesondere in Cloud-Umgebungen ist dies eine Notwendigkeit. Dies hat zu der Verbreitung von Werkzeugen für die Virtualisierung, automatisierte Bereitstellung und Konfigurierung von virtuellen Maschinen geführt. In Folge muss es natürlich notwendig sein, diese vielen Umgebungen zu überwachen, um Probleme sehr schnell festzustellen. Dies führt zu einem stark gesteigerten Interesse an Werkzeugen zur Echtzeitüberwachung.Die kürzer werdenden Zyklen von Entwicklung bis zur Produktion sorgen in Folge für einen deutlich erhöhten Bedarf an Testautomatisierung auf allen Ebenen, von Unit-Tests über Integrations- und Lasttests bis zur Automatisierung von Akzeptanz- und GUI-Tests.Die Sammlung der miteinander verknüpften Praktiken für die automatisierte Deployment, Umgebung Erstellung, Provisioning, Konfiguration und Überwachung werden unter dem Begriff „Continuous Deployment“ vereint.

Soziale Aspekte

Unsere Übersicht wäre nicht vollständig ohne eine Erwähnung der sozialen Aspekte der Softwareentwicklung.Der inhärente Wunsch, qualitativ gute Ergebnisse zu liefern und am Abend eines jeden Tages mit einem guten Gefühl nach Hause gehen zu können, hat zur Software-Craftmanship-Bewegung geführt, die mehr und mehr Schwung bekommt.Die Umsetzung des Continuous Deployments besteht aus zwei Teilen, dem technischen, der beherrschbar ist, und dem sozialen, der einen Prozess des Umdenkens bei jedem Einzelnen erfordert. Dies erfordert häufige Interaktion, Zusammenarbeit und Integration von Entwicklern und Mitarbeitern des Betriebs, die ihre verschiedenen Ziele verstehen und in Übereinstimmung bringen müssen. Die zugehörige Bewegung „DevOps“ hat das Ziel, die Fertigstellung von Software und ihre Inbetriebnahme so effizient und zuverlässig wie möglich zu machen, ohne dabei die längerfristigen Ziele des Betriebs aus den Augen zu verlieren.Wollen Sie mehr über Agilität erfahren? Oder vielleicht wollen Sie ihre Erfahrungen tauschen? Dann freuen wir uns auf ihre Teilnahme beim Agilen Stammtisch Frankfurt. Das Thema des Lightning Talks des nächsten Stammtisches ist „Agility und Datenbanken“.14. Agiler Stammtisch Frankfurt findet an 4. September um 19:00 an „die Zentrale“ statt. Kostenlose Registrierung über XING.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.