Agile Entwicklung

Agile Entwicklung und iterative Vorgehensmodelle 2

Der erste Teil unserer Blogserie beinhaltet eine Abgenzung der iterativen Vorgehensmodelle zu klassischen sequentiellen Modellen, wie z.B. dem beliebten Wasserfallmodell. Dieser Artikel  fokussiert die Agile Entwicklung und zeigt die dahinter stehenden Werte und Prinzipien auf.

Wann kann ein Vorgehensmodell als agil bezeichnet werden?

Bereits Mitte der 50er Jahre wurde vom amerikanischen Soziologen Talcott Parson ein aus vier Grundfunktionen bestehendes AGIL-Schema entwickelt, welches sich wie folgt zusammensetzt:

  • Adaptation: Anpassungsfähigkeit an die Rahmenbedingungen, kein starres festhalten an gewohnten Prozessen.
  • Goal attainment: Gemeinsame Ziele und deren Erreichen stehen für alle Beteiligten im Vordergrund
  • Integration: miteinander verbundene Handlungen aller Beteiligten, Integration der Beteiligten in den Prozess
  • Latent pattern maintenance: Aufrechterhaltung grundlegender Werte und darauf basierender Prinzipien

 

Methoden, die diese Voraussetzungen erfüllen, können als funktional bzw. agil bezeichnet werden. Den durch Leichtgewichtigkeit und adaptive Strukturen gekennzeichneten Modellen wird häufig fälschlicherweise ein völliger Verzicht auf Strukturen nachgesagt. Agiles Vorgehen sieht jedoch eine gesunde Balance aus Flexibilität und Struktur vor um sich weder dem Chaos noch der absoluten Unbeweglichkeit hinzugeben. Arbeitsabläufe sollen ausreichend zweckmäßig sein, um ein Ziel zu erreichen, und ausreichend flexibel, um sich an geänderte Rahmenbedingungen anpassen zu können.

Das Agile Manifest – die Geburtsstunde agiler Softwareentwicklung

Vor über 10 Jahren entwickelt bildet das Agile Manifest noch heute den gemeinsamen Nenner diverser agiler Modelle. Obwohl die empfohlenen Praktiken von Modell zu Modell variieren, befürworten Vertreter der unterschiedlichsten Modelle die Werte und Prinzipien des 2001 von führenden Methodikern der Softwareentwicklung erarbeiteten Agilen Manifests.

“Individuals and interactions over processes and tools” – Menschen und Zusammenarbeit über Prozesse und Werkzeuge stellen.

Da mit ihnen ein Projekt steht oder fällt stehen bei agilen Vorgehensmodellen Menschen im Mittelpunkt. Die Eigenverantwortung eines jeden Beteiligten wird gefordert. Auf starr reglementierende Prozesse wird verzichtet, da diese den Handlungsspielraum einschränken und bei auftretenden Problemen nur geringen Mehrwert bieten.

“Working software over comprehensive documentation” – Funktionierende Software über allumfassende Dokumentation stellen.

Funktionierende Software hat oberste Priorität und nimmt auch den primären Fokus aller Beteiligten ein. Eine zu ausführliche Dokumentation fügt eine zusätzliche Abstraktionsebene zwischen den Nutzern und den Entwicklern hinzu und verursacht hohe Aufwände für Erstellung und laufende Anpassung. Das Team entscheidet, welche Teile einer Dokumentation absolut notwendig sind und realisiert nur diese.

“Customer collaboration over contract negotiation” – Zusammenarbeit mit Kunden über vertragliche Vereinbarungen stellen.

Der Kunde wird von Beginn an in das Team integriert, denn nur dieser weiß was er benötigt. Nicht nur die enge Zusammenarbeit mit dem Kunden, sondern vor allem auch die Erforschung seiner Bedürfnisse stehen im Vordergrund. Der Kunde übernimmt Verantwortung und kommuniziert Anforderungen und Feedback während des gesamten Prozessablaufes. Um dies zu ermöglichen, sind frühe, häufige und kontinuierliche Auslieferungszyklen unumgänglich. Sehr zügig nach Beginn des Projektes werden bereits erste Entwürfe und funktionierende Softwareteile vorgelegt. Durch direkte Kommunikationsmethoden wird das Verständnis für das Projekt gefördert. Dieses Vorgehen erspart die Verwendung von Dokumentation zur Kommunikation mit dem Kunden und ermöglicht es, den Kundennutzen mehrfach zu reevaluieren. Das Risiko einer niemals fertiggestellten oder den Bedürfnissen nicht entsprechenden Software wird erheblich minimiert.

“Responding to changes over following a plan” – Auf Änderungen einzugehen ist wichtiger, als einem starren (vielleicht schon überholten) Plan zu folgen.

Bei traditionellem Projektmanagement wird davon ausgegangen, dass die exakte Einhaltung und Erfüllung eines Plans mit Erfolg gleichzusetzen ist und dadurch Kundennutzen entsteht. Wie bereits im Abschnitt “Sich ändernde Bedingungen und bewegliche Ziele” beschrieben, entsprechen die vor Projektbeginn erstellten Pläne rasch nicht mehr den realen Anforderungen. Nicht nur Bedingungen ändern sich – auch gewonnenes Feedback soll direkten Einfluss auf die weitere Entwicklung nehmen und damit zu einer Verbesserung des Endresultates beitragen. Agile Vorgehensmodelle versuchen daher nicht, Veränderungen zu verhindern, sondern sie vielmehr zu fokussieren. Der Projektplan soll dabei form- und dehnbar gestaltet werden, sodass er Raum für Veränderung beinhaltet. Um die Gesamtplanung auf die aktuelle Situation anzupassen und sie aktuell zu halten soll diese möglichst grob definiert und laufend angepasst werden.

Die zwölf agilen Prinzipien des agilen Manifests im Detail >

Ausblick: Fortsetzung folgt …

In unserem kommenden Blogpost werden wir diese Serie weiterführen und einen Einblick bieten, aus welchen Methoden sich die Vorgehensweise zusammensetzt, die wir für Entwicklungs- und Intergrationsprojekte insbesondere im Hinblick auf die Erstellung von Unternehmensportalen für uns adaptiert haben.

2 Kommentare zu Agile Entwicklung und iterative Vorgehensmodelle 2

  1. Agile Methodik immer noch als über das Agile Manifest definiert zu sehen erscheint nicht mehr akzeptabel.

    Die Begründung hierfür findet sich im Dokument The New (2011) Definition of Agile.

    Siehe hierzu auch die Diskussion Be Agile – Forget the Manifesto.

    • NoraKuhn Nora Kuhn says:

      Guten Tag Herr Greiter, vielen Dank für Ihren Kommentar. Wie insbesondere im dritten Teil unserer Blogreihe hervorgeht, kommt es auf den richtigen Mix an Methoden an. Es ist richtig, dass ein Projektmanager an das Projekt mit einer anderen Sichtweise herangehen sollte als ein Programmierer oder Designer. Genau das betrifft auch alle anderen Rollen, die im RUP beschrieben sind, denn jede Person verfolgt das Projektziel unter den Aspekten seiner Rolle.
      Die in Ihrem Artikel beschriebene Aussage eines Managers, dass sich nach zwei Jahren hunderte unterschiedliche Lösungen mit dupliziertem Code und Anforderungen vorhanden waren, hat nichts mit Agile Development zu tun. Das Problem dieses Mannes ist, dass vermutlich die Rolle des Architekten gefehlt hat, oder Agil mit Chaos und Undiszipliniertheit verwechselt wurde. Agil heißt nicht, dass auf sämtliche Architekturkonzepte verzichtet werden soll. Wenn die Architektur konsequent erweitert wird und regelmäßigem Refactoring unterzogen wird, entsteht ein Framework das variabel und ausbaufähig ist, und damit die Wartungskosten verringert und die damit verbundenen Aufgaben vereinfacht.
      Eine gute Definition der Rollen innerhalb von Software Projekten bietet das Microsoft Solution Framework (MSF), das eine klare Abgrenzung der Rollen und deren Aufgaben bzw. Zielen wiederspiegelt. Bei Softwareprojekten (jeder Größe!) geht es darum, die richtigen Methoden miteinander zu kombinieren. Richtig im Sinne der Rahmenbedingungen wie Projekt- und Teamgröße.

Hinterlasse eine Antwort

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

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>