Agile Entwicklungspraktiken: der Ursprung

Keine Kommentare

Agile Entwicklungspraktiken gehören zu den wichtigsten Grundlagen für erfolgreiche Umsetzung der Agilen Softwareentwicklung.Scrum ist aktuell die populärste agile Projektmanagementmethode.Allerdings gibt es keine spezifischen Empfehlungen über Entwicklungspraktiken in Scrum, da sich Scrum ausschließlich auf Projektmanagement beschränkt. Es wird nur empfohlen, gute Entwicklungspraktiken einzuführen.

Der Ursprung der Agile Entwicklungspraktiken

Es gibt zwei agile Methoden, die im Unterschied zu Scrum gut definierten Entwicklungspraktiken haben. Diese Methoden sind Extreme Programming und Feature Driven Development oder FDD (eigenschaftenbasierte Entwicklung). Diese Methoden haben einen unterschiedlichen Hintergrund und fokussieren deshalb auf unterschiedliche Schwerpunkte.

In diesem Blogpost machen wir folgenden Unterschied zwischen Methoden und Praktiken.Eine Methode beschreibt gemeinsame Rahmen, wie man die Software-Entwicklung durchführen soll (d.h. typische Rollen, erforderliche Meetings, Artefakte, usw.) und kann (aber muss nicht) auch die Menge der empfohlenen Engineering-und Management-Praktiken enthalten, die man verwenden soll, wenn diese Methode auf das Projekt angewendet wird.Zu den agilen Methoden gehören Scrum, Kanban, XP und andere.Einige Methoden haben nur Projektmanagementteile. Zu diesen gehören z.B. Scrum und Kanban. Es gibt auch Methoden, die sowohl Projektmanagement- als auch Entwicklungsanteile haben. Dies ist z.B. Extreme Programming, FDD und Tracer Bullet Development.

Extreme Programming (XP)

Die Erfinder von XP haben Smalltalk als ihre Hauptentwicklungssprache benutzt. Smalltalk war eine der ersten objektorientierten dynamischen Programmiersprachen. Die Produktivität der Entwickler auf Smalltalk war dabei im Vergleich zur damaligen Hauptkonkurrenz C++ deutlich höher.Aufgrund der Natur der Sprache war die Ausführung der primäre Weg, um die Korrektheit des Codes festzustellen. Deshalb war die Überprüfung großer Teile des Codes mühsam und fehlerhaft. Die Lösung, die für dieses Problem gefunden wurde, war eine Menge an Unit-Tests schreiben.Wenn man in einer dynamische Sprache entwickelt, dann ist der Einsatz von Pair-Programming gut begründet. Viele Fehler, kleine und große, werden bereits beim Entwickeln festgestellt. Dadurch wird viel Zeit durch Verringerung der Anzahl der Wiederausführungs- /Fehlerbehebungs- Zyklen gespart.Zu den Entwicklungspraktiken des Extreme Programming gehören:

  • Pair-Programming
  • Testgetriebene Entwicklung/Unit Tests
  • Kontinuierliche Integration
  • Refactoring
  • Akzeptanztest
  • Kleine Releases

XP hat auch Praktiken für die Erzeugung und Aufrechterhaltung eines gemeinsamen Verständnisses:

  • Einfaches Design
  • Coding-Standards
  • Metapher
  • Kollektives Code Eigentum

Feature Driven Development

Feature-Driven Development wurde für ganz andere Art von Projekten entwickelt. Die erste Anwendung war ein Festpreisprojekt mit fünfzig Entwicklern und einer Zeitspanne von zwei Jahren. Im Rahmen eines Festpreisprojektes können Refactoring und Nacharbeit sehr nachteilig sein, da sie Investitionen in eine Zukunft darstellen, die nicht notwendigerweise durch den Festpreisrahmen abgedeckt ist.Die erste Phase eines FDD-Projekts ist eine leichtgewichtige Modellierung der Problemdomäne. Dadurch werden mehrere Ziele erreicht:

    • Fixierung des groben Projekt-Umfangs
    • Minimierung des Refactorings auf Modell-Ebene (dies passiert mit Hilfe einer speziellen Modellierungstechnik, die man Color Modeling nennt)
    • Schätzung des Zeitaufwandes

.Ein Ergebnismodell ist dann für die ganze Zeitdauer des Projektes gültig. Das Modell erlaubt dabei die Koordination aller Entwicklungs-und Reporting-Aktivitäten.Zu den Entwicklungspraktiken von FDD gehören:

  • Domain Object Modeling
  • Entwickeln pro Feature
  • Individuelle Eigentum von Code auf Klassenebene
  • Inspektionen
  • Regelmäßige Builds
  • Configuration Management

Im Unterschied zu XP wird bei FDD gefordert, dass Builds mindestens einmal pro Tag gemacht werden.Jede Klasse in dem Domain Modell wird einem individuellen Entwickler zugewiesen. Er ist dann verantwortlich für die Wartung dieser Klasse während des Laufes des ganzen Projekts. Für jedes Feature werden die Klassen, welche voraussichtlich von der Implementierung dieser Features betroffen sind, bestimmt. Danach wird ein Feature Team aus den Klassenverantwortlichen gebildet.Der Prozess der Entwicklung pro Feature ist in FDD gut definiert. Der Chefprogrammierer trifft hierbei die Entscheidung, ob optionale Schritte durchgeführt oder übersprungen werden. Die Umsetzungphase des FDD Projekts enthält zwei Prozesse. Diese sind “Entwurf pro Feature” (Design by Feature) und “Implementierung pro Feature” (Build by Feature).Während des “Entwurf pro Feature”-Schrittes führt das verantwortliche Feature-Team gemeinsam ein kollaborativen Design durch.Die Phase “Implementierung pro Feature” enthält Implementierung, Codeinspektion, Unit Test und Freigabe des Codes. Formale Inspektionen, in Unterschied zu Extreme Programming, sind das primäre Mittel, um Qualität zu erreichen. Diese werden beim Entwickeln auf verschiedenen Ebenen durchgeführt: zuerst auf dem Modell, dann auf dem Design und schließlich auf dem Code. Unit Tests werden zwar gleichfalls als sehr wichtig betrachtet, sind aber nicht das „Nummer Eins“ Werkzeug.

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.