Beratung für Agile Software-Entwicklung Beratung für Agile Software-Entwicklung
Praxis
Wie funktioniert Agile Software-Entwicklung?

Horst Franzke
Gartenstr.23 
D-84508 Burgkirchen 
+49 (8679) 914 795 
h.franzke@t-online.de

Sie sind hier: Startseite > Praxis Praxis | Artikel | Services | Bücherecke | Software | WWW | Über mich | Änderungen | Impressum

Hinweise

Wie funktioniert denn jetzt diese "Agile Software-Entwicklung"?

Das wird wohl die häufigste Frage sein, wenn man anfängt, sich mit mit diesem Thema zu beschäftigen.

Auf dieser Seite möchte ich Ihnen eine Antwort auf diese Frage geben. Diese Antwort ist sehr persönlich. D.h. sie beruht auf meinen Erfahrung mit Agilen Projekten in der Industrie.

Wichtig zum weiteren Verständnis:
es gibt eine ganze Reihe von konkreten Agilen Vorgehensweisen, die man als Einstieg in diese "Welt" benutzen kann (siehe "Agile Software-Entwicklung" auf meiner Startseite). Mein Agiles Verhalten ist vor allem durch folgenden beiden Vorgehensweisen geprägt:

  1. eXtreme Programming (XP)
    ich kenne im Moment keine bessere Zusammenstellung von Best Practices für die eher "handwerkliche" Kern-Aufgabe bei jedem Software-Projekt: nämlich für das Erstellen von Software (-Systemen);
    (Sie wundern sich vielleicht über meine Anmerkung; aber manchmal soll es Software-Projekte geben, die sich auch mit anderen Dingen beschäftigen als mit der Produktion von Programmen; siehe z.B. die Projekte Herkules der Bundeswehr, oder Fiscus der Finanzbehörden, die vor allem Spezifikationen, Definitionen und Pläne produziert haben, bevor sie ohne eine produzierte Zeile Programm-Code eingestellt wurden)

  2. Scrum
    hier findet man Agile Praktiken, die XP gut im Bereich Projekt-Leitung und Koordination im Großen ergänzen;

Was ich hier nicht besprechen möchte, ist die Einbettung von Agilem Vorgehen/Verhalten in Ihrem bestehenden Unternehmens-Umfeld: z.B. wie werden Projekt initiiert und genehmigt? wie gehe ich mit Projekt-externem Berichtswesen um? wie gehe ich mit den Vorgaben einer QS-Abteilung um? wie präsentiere ich mich bzgl. CMM oder ISO 9000:2000/9004:2000.
Nicht daß dies die kritischen Fragen wären, auf "Agil" keine Antworten hat; aber hier muß man sehr speziell und konkret für den jeweiligen Einzelfall eine geeignete "Schnittstelle" finden. Und das würde den Rahmen auf dieser Seite sprengen (siehe aber z.B. [3]).

Anregungen von Ihrer Seite nehme ich immer gerne entgegen und freue mich auch über eine Diskussion mit Ihnen; oder haben Sie Fragen? Einfach per Email an h.franzke@t-online.de.

Seitenanfang

Einleitung

Nach Agilem Grundverständnis soll jedes Projekt die Vorgehensweise (den Prozeß) anwenden, die es benötigt; d.h. soviel wie nötig und so wenig wie möglich; das bedeutet

  1. Agiles Vorgehen oder besser Verhalten hat viele Facetten;

  2. ausgehend von einem Startpunkt ist jedes Projekt-Team (auf-) gefordert, das gelebte Vorgehen/Verhalten ständig anzupassen und zu verbessern;

  3. d.h. es gibt nicht das eine Agile Vorgehen; das wäre ja fast ein Widerspruch in sich. Agil bedeutet eben flexibel, flink, reaktions-schnell, auch in Bezug auf das gezeigte Verhalten in einem Projekt; d.h. der Prozeß sollte angepaßt und angemessen sein;

Mit diesen Aussagen steht wohl fest: Agiles Verhalten gibt es in einer gewissen "Bandbreite". Das soll heißen: es gibt viele Agile Elemente/Regeln/Praktiken, die jeweils in angemessener Weise im Projekt angewendet werden sollen.

Eine Warnung gleich vorweg: oftmals wird Agiles Verhalten und hier ganz besonders eXtreme Programming einfach mit "Hacken" gleichgesetzt: "vogelfreie" Programmierer stürzen sich "wild" auf Programme und "hacken" plan- und ziellos chaotischen Code.
Genau das Gegenteil ist nach meiner Erfahrung der Fall: es gehört eine sehr große Portion Disziplin und Ausdauer dazu, um in einem Agilen Projekt (z.B. mit XP) zu bestehen; und bei keinem mir bekannten "Wasserfall"-Projekt war die Treffer-Genauigkeit der Voraussagen bzgl. Termin, Umfang und Kosten derart hoch und präzise.

Im Folgenden möchte ich die oben angesprochene "Bandbreite" beschreiben: beginnend bei den wenigen Elementen, mit denen Agilität mindestens startet, über mögliche "Ausbau-Stufen" hin zu mehr Agilen Praktiken.

Und bitte denken Sie beim weiteren Lesen daran: wenn bei Ihren Projekten die Beteiligten (Lieferanten, Kunden, Anwender) zufrieden sind mit den Ergebnissen, dem Ablauf und den Kosten, dann gibt es keinen Grund, an Ihrer gelebten Vorgehensweise etwas zu ändern.

Sollten Sie aber punktuell oder bei größeren Bereichen Verbesserungs-Potential entdeckt haben, dann finden Sie bestimmt Anregungen.

Vor dem Überblick noch kurz zur Orientierung das sog. "Agile Manifesto":

Seitenanfang

Agile Manifesto

Das "Agile Manifesto" ist sozusagen die erklärte Vision bei allen Agilen Vorgehensweisen:

  • Individuen und Interaktion sind wichtiger als Prozesse und Werkzeuge;
  • Lauffähige Software ist wichtiger als umfangreiche Dokumentation;
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen;
  • Auf Änderungen reagieren ist wichtiger als (stur) einem Plan zu folgen;

(Quelle: Agile Manifesto)

Die Frage, wie man trotz (oder vielleicht gerade wegen) dieser Vision geordnet zum Ziel kommt, möchte ich in den folgenden Abschnitten erklären:

Seitenanfang

Übersicht

Die folgende Aufteilung soll als Vorschlag verstanden werden, wie man Agile Praktiken gestaffelt anwenden kann: von einem gewissen Minimum aus bis hin z.B. zu XP "pur". Die Abstufung entspricht meiner Erfahrung und deckt sich im wesentlichen mit häufig vertretenen Meinungen in der Literatur (siehe z.B. [1] oder [2]).

Gruppe 1 (Lernen ermöglichen)

Die folgenden Praktiken sollten mindestens angewendet werden:

  • Aufteilung in kurze Releases;

  • Releases unterteilt in Iterationen;

  • Retrospektiven;

Damit können alle Beteiligten lernen, welchen Charakter das Projekt hat, wo die echten Herausforderungen liegen und wie sich der Fortschritt tatsächlich entwickelt.

Gruppe 2 (Schnelle Lieferungen)

Der Kunde erhofft sich einen Geschäftsnutzen von der in Auftrag gegebene Software. Und diesen Nutzen so früh als möglich zu bekommen ist durchaus attraktiv und sichert Vorteile:

  • "Timeboxed";

  • "Continous Integration" bzw. Automatischer Build-Prozeß;

  • "Simple Design";

Den meisten Kunden sind sehr wahrscheinlich 40% der Funktionalität heute lieber als die vage Aussicht auf die Lieferung von 100% in einem Jahr.

Gruppe 3 (Kommunikation mit dem Kunden)

Im Sinne von "collaboration before contract" (Agiles Manifest) muß die Kommunikation mit den Kunden/Anwendern intensiv gepflegt werden:

  • Planungs-Spiel;

  • Schnelle und direkte Abnahmen/Freigaben;

  • Kunde vor Ort;

Wir benötigen Verständnis auf zwei Seiten:
die Software-Entwickler müssen verstehen, was die Kunden/Anwender brauchen und erwarten;
die Kunden/Anwender sollen ein Gespür dafür bekommen, was in diesem Projekt machbar ist, was schwierig und was leicht ist, was wenig und was viel kostet.

Gruppe 4 (Nachhaltiges Tempo)

Sie haben das vielleicht auch schon beobachtet: nach relativ schnellen ersten Erfolgen wird das Tempo des Fortschritts im Projekt im langsamer und langsamer. Und sobald ein System im Einsatz ist, wird es mit "Verbesserungen" erst recht schwierig.

  • "40-Stunden-Woche";

  • "Test-First";

  • "Refactoring";

  • "Pair-Programming";

Bereits in den frühen Tagen des Projekts wird der Grundstein für flexible und wartbare Software gelegt.

Seitenanfang

Vorteile

Ist es der Mühe wert? Soll man tatsächlich von bekannten Pfaden abweichen?

Ich finde, es lohnt sich, denn es locken attraktive Vorteile:
(die Vergleiche beziehen sich auf schwergewichtige Prozesse nach "Wasserfall")

  1. Reduzierte Kosten;
    ich wage zu behaupten, daß bei vergleichbarer Aufgabenstellung ein Kosten-Vorteil von mindestens 40% erwartet werden darf;
     
  2. Reduzierte Lieferzeit;
    erste Lieferung bereits nach dem ersten Release;
    durch geringen Projekt-Ballast und Fokusierung auf wichtige Funktionen auch insgesamt Laufzeit-Vorteile jenseits der 50%;
     
  3. Hohe Qualität;
    praktikable Programmier-Techniken sorgen für gleichbleibende Qualität auch in Streß-Situationen;
     
  4. Hohe Kunden-Zufriedenheit;
    durch die Art und Weise der engen Einbindung des Kunden ins Projekt kann dessen Zufriedenheit eigentlich nur noch hoch sein;
     
  5. Hohe Zufriedenheit bei den Software-Entwicklern;
    jeder Mensch will gute Arbeit leisten und wird "sauer", wenn man ihn dabei behindert; hier wird dafür gesorgt, daß er seine Erfolge bekommt;
    Erfolge motivieren ...
     
  6. Erhöhte Wartbarkeit;
    konsequent angewendet sorgen die Praktiken dafür, daß das System in einer lange Folge von Änderungen wächst;
    d.h. "Änderung" ist etwas normales für das System wie auch für die Entwickler;
    die Entwickler mußten das System von Beginn an "wartbar" aufbauen;
     
  7. Reaktionsschnelle Änderungen;
    wie bereits im vorherigen Punkt gesagt: "Änderung" war während des ganzen Projekts der Normalfall; weitere Änderungen werden vom Team wie gehabt erledigt: schnell und präzise;
     

Seitenanfang

Verweise

[1] Beck, Kent: Extreme Programming - Das Manifest; ( Addison-Wesley, 2000)
 
[2] Eckstein, Jutta: Agile Software Entwicklung im Großen; (dpunkt.Verlag, 2004)
 
[3] Wake, William C.: Artikel "ISO Certification for XP at LogicaCMG";
 

Seitenanfang

Copyright 2004 - 2007, Horst Franzke Impressum Last Page Update: 21-Jan-2007 (r-5-0-1)