Posted on Leave a comment

Agile Softwareentwicklung

Agile Softwareentwicklung

blank

Agile Softwareentwicklung beschreibt Ansätze des Softwareentwicklungsprozesses mit besonderem Fokus auf Flexibilität und inkrementelles Vorgehen. Dadurch sollen die Qualität des Produktes gesteigert, die Kommunikation verbessert und Risiken minimiert werden. Etabliert haben sich Gedanken rund um agile Entwicklung um das Jahr 2001 mit der Veröffentlichung des agilen Manifests. Wir klären, welche Leitsätze und Prinzipien darin festgelegt werden, welche Vor- aber auch Nachteile agile Entwicklung mit sich bringt und mit welchen Methoden sie heute umgesetzt wird.

Die Leitsätze agiler Softwareentwicklung

Agile Softwareentwicklung beruft sich wie bereits erwähnt auf das sogenannte agile Manifest, das 2001 unter anderem von Kent Beck, Robert C. Martin und Martin Fowler veröffentlicht wurde und auch heute noch im Internet mit all seinen Unterzeichnern zu finden ist. Die agilen Leitsätze aus dem Englischen übersetzt sind:

  • Individuen und Interaktionen stehen über Prozessen und Werkzeugen
  • Funktionierende Software steht über einer umfassenden Dokumentation
  • Die Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
  • Das Reagieren auf Veränderung steht über dem Befolgen eines Plans

Jeder Leitsatz nimmt einen Aspekt des klassischen Projektmanagements, beispielsweise des Wasserfallmodells, bei dem eine strikte Planung meist mit Lasten- und Pflichtenheften im Vordergrund steht, und ersetzt ihn mit einer pragmatischeren Alternative. Vor allem der Mensch und das Ergebnis stehen dabei nun im Mittelpunkt. Das heißt, es kommt weniger auf Prozess und Bürokratie und mehr auf Entwickler und Kunden an.

Die Prinzipien agiler Softwareentwicklung

Um die Leitsätze, die noch recht abstrakt sind, in die Praxis zu übertragen, nennt das agile Manifest insgesamt zwölf Prinzipien:

  • Die höchste Priorität ist es, den Kunden durch die frühzeitige und kontinuierliche Auslieferung von wertvoller Software zufriedenzustellen.
  • Änderungen werden selbst in späten Entwicklungsphasen willkommen geheißen, denn der agile Prozess macht sie zu einem Wettbewerbsvorteil.
  • Funktionsfähige Software wird in regelmäßigen Abständen von wenigen Wochen oder Monaten ausgeliefert, wobei die kürzeste Zeitspanne bevorzugt wird.
  • Fachexperten und Entwickler arbeiten während des Projektes täglich zusammen.
  • Das Projekt wird um motivierte Personen errichtet. Den Entwicklern wird ein Umfeld gegeben, in dem sie ihre Arbeit gut erfüllen können – und darauf vertraut man, anstatt die Arbeit streng zu kontrollieren.
  • Gespräche von Angesicht zu Angesicht sind immer die bevorzugte Form des Informationsaustauschs.
  • Der Fortschritt wird in der Funktionsfähigkeit der Software gemessen.
  • Um eine nachhaltige Entwicklung zu gewährleisten, wird in einem gleichmäßigen Arbeitstempo gearbeitet. Das Tempo kann von Auftraggebern, Entwicklern und Benutzern eingehalten werden.
  • Auf technischer Exzellenz und gutem Design liegt ständiges Augenmerk.
  • Einfachheit (definiert als die Kunst, die Menge nicht getaner Arbeit zu maximieren) ist essentiell. Dieses Prinzip entspricht dem KISS (Keep It Simple, Stupid)-Prinzip. Das Ziel ist es, die vorgegebenen Anforderungen mit möglichst geringem Aufwand zu realisieren. Gleichzeitig soll die gewählte Lösung nicht so komplex sein, dass man später Schwierigkeiten hat, sie zu verstehen, zu erweitern oder anzuwenden.
  • Selbstorganisierte Teams bringen die besten Architekturen, Anforderungen und Designs hervor.
  • Das Team reflektiert in regelmäßigen Abständen, wie es seine Effizienz steigern kann, und passt sein Verhalten entsprechend an.

Jeder Leitsatz findet Anwendung in mehreren Prinzipien. Beispielsweise wird der Fokus auf die Individuen vor allem durch die Vorgabe von selbstorganisierten Teams, die nicht übermäßig kontrolliert werden, realisiert. Die pragmatische Ausrichtung auf funktionierende Software ergibt sich zum einen aus dem KISS-Prinzip und zum anderen dadurch, dass der Fortschritt der Arbeit an den fertig gestellten Funktionen gemessen wird.

Die Vorteile von agiler Softwareentwicklung

Nun ist klar, was agile Softwareentwicklung eigentlich ist, und auch einige Vorteile werden in den Prinzipien schon genannt – beispielsweise, dass die Flexibilität von agilem Vorgehen Änderungen, die eigentlich problematisch und teuer sind, zu einem Wettbewerbsvorteil macht. Betrachten wir jetzt noch einmal klassisches Projektmanagement am Beispiel des Wasserfallmodells: Zu Beginn des Projektes gibt es eine Planungsphase, in der die einzelnen Schritte der Entwicklung festgeschrieben werden. Die Planung besteht noch einmal aus einer Analyse- und einer Designphase. Nachdem die Planung abgeschlossen ist, beginnen die Entwickler mit der Programmierung nach diesem Plan. Ist das Produkt fertig, wird es in den Test gegeben und dann an den Kunden ausgeliefert. Abschließend wird das Produkt nur noch gewartet.

Hier sieht man direkt den ersten Nachteil: Zu Beginn des Projektes stehen nämlich fast nie alle Anforderungen fest. Trotzdem wird für die Planungsphase sehr viel Zeit benötigt – ohne, dass man schnell konkrete Ergebnisse oder Tests durchführen kann, insbesondere keine Akzeptanztests beim Kunden. Bei agiler Entwicklung hingegen können die Entwickler relativ schnell damit beginnen, tatsächlich Software zu produzieren und damit etwas fassbares zu erzeugen, über das man zeitnah sprechen kann. So wissen alle Projektbeteiligten stets, dass sie auf dem richtigen Weg sind. Verstehen sich Entwickler und Kunde im Wassermodell an einer Stelle falsch, fällt das möglicherweise erst sehr spät im Projekt auf – danach den Plan zu ändern und ggf. bereits abgeschlossene Features neu zu implementieren ist teuer.

Diese schnelle Reaktion auf sich ändernde Anforderungen ist infolgedessen ein Wettbewerbsvorteil sowohl für den Kunden als auch für die Entwickler: Der Kunde kann sein Produkt jederzeit anpassen, beispielsweise wenn sich Anforderungen durch den Markt oder externe Faktoren ändern, und die Entwickler selbst können den Kunden zufriedenstellen, weil sie Änderung willkommen heißen.

Neben dem wirtschaftlichen Aspekt ist agile Entwicklung positiv für das Arbeitsklima: Der Wegfall von  Lasten- und Pflichtenheften, die Ausrichtung auf bessere Kommunikation und selbstorganisierte Teams steigern die Mitarbeiterzufriedenheit.

Kritikpunkte – Agil ist nicht die Lösung für alles

Agile Projektplanung und -durchführung hat viele Vorteile und wird nicht umsonst immer häufiger auch in anderen Branchen eingesetzt. Trotzdem ist agil natürlich nicht die Antwort auf alle Probleme, die es im Projektmanagement gibt. So empfinden vor allem manche Entwickler die ständigen Meetings eher als anstrengend. Viele agile Methoden sehen vor, dass man sich jeden Tag zumindest einmal trifft und den aktuellen Stand der Arbeit bespricht. Das unterbricht den Arbeitsfluss. Außerdem gibt es nicht immer etwas zu zeigen – trotzdem werden Demos in regelmäßigen Abständen benötigt. Und auch die Präsentationen für Meetings und Abnahmen einzelner Iterationen müssen vorbereitet werden. Auf wirtschaftlicher Seite machen agile Methode es schwerer, bereits zu Beginn eines Projektes eine genaue Kostenabschätzung vorzunehmen. Alle Beteiligten müssen also auch im Prozess darauf achten, dass Kosten nicht plötzlich explodieren.

Diese Kritikpunkte können allerdings gemildert werden, in dem ein Unternehmen oder ein Team agile Prozesse für ihre Arbeitsweise adaptiert. So können beispielsweise regelmäßige Tage ausschließlich für Refactoring und Review festgelegt werden. Das Vorzeigen eines visuellen Ergebnisses ist zu diesen Zeiten dann nicht notwendig.

Agile Methoden

Über die Zeit haben sich unterschiedliche Methoden entwickelt, die versuchen, agile Leitsätze und Prinzipien bestmöglich umzusetzen. Drei bekannte, die wir an dieser Stelle im Detail vorstellen wollen, sind Scrum, Kanban und Extreme Programming.

Scrum

Scrum ist eine der bekanntesten agilen Methoden, sowohl in der Softwareentwicklung als auch in anderen Branchen. In Scrum wird innerhalb kurzer Sprints, die eine bis maximal drei Wochen laufen, gearbeitet. Zu Beginn des Sprints, werden aus dem Backlog des Projektes – allen Aufgaben, die für den Abschluss des Projektes erledigt werden müssen – die Tasks ausgewählt. Die gewählten Tasks sollten während des Sprints vollständig abgearbeitet werden können. Dazu wird der Aufwand der Tasks von den Entwicklern geschätzt. Die ausgewählten Tasks dürfen nach Beginn des Sprints nicht mehr geändert werden. Nach Ende des Sprints werden die Ergebnisse vorgestellt, es muss also ein ausführbares und vorzeigbares Ergebnis geben.

Scrum definiert für diesen Prozess feste Rollen: Den Product Owner, den Scrum Master und das Scrum Team. Der Product Owner behält die Übersicht über das Projekt und stellt die Schnittstelle zwischen Entwicklern und Stakeholdern, also den Kunden und Nutzern des Produktes, dar. Der Scrum Master managed das Scrum Team und ist auch dafür verantwortlich, zwischen Product Owner und Team zu vermitteln und eine gute Arbeitsatmosphäre zu schaffen. Das Scrum Team schlussendlich sind die Entwickler. Insgesamt sollte das Entwicklerteam nicht aus mehr als sieben Leuten bestehen, damit sich ein Teamgefühl bilden kann und der Organisationaufwand überschaubar bleibt. Das Scrum Team hält jeden Tag einen Daily Scrum ab, ein etwa 15-minütiges Standup-Meeting, in dem jeder einen Überblick über die aktuellen Aufgaben und Probleme gibt.

Kanban

Kanban ist eine weitere agile Methode, die oft in Verbindung mit Scrum verwendet wird. Die Methode kommt ursprünglich aus dem Toyota-Produktionssystem. Das Wort Kanban ist japanisch und bedeutet in etwa „Signalkarte“. Bei Kanban wird der Fluss der aktuellen Arbeit durch Karten an einem sogenannten Kanban-Board visualisiert. Das Ziel ist es, die Anzahl an parallelen Aktivitäten (dem aktuellen Work In Progress) zu minimieren, um fokussiertes und effizientes Arbeiten zu garantieren und Engpässe zu vermeiden. Der Leitspruch von Kanban ist passend gewählt und einprägsam: „Stop starting – Start finishing“.

Auf dem Kanban-Board stehen zur Planung verschiedene Slots bereit, beispielsweise Ready, In Progress, In Review, Tested und Done. Jeder Entwickler hat eine Zeile, in der er seine Tasks den entsprechenden Zuständen zuweist. Jeder Task muss alle Schritte durchlaufen, d.h. ein Entwickler stellt es auf In Progress, wenn er mit der Umsetzung beginnt, reicht das Ticket von da in den Review und nach erfolgreichem Review in den Test. Die klare Übersicht hilft dabei, dass Entwickler nicht zu viele Aufgaben auf einmal beginnen und sich gleichzeitig nicht übernehmen.

Extreme Programming

Die letzte Methode, Extreme Programming, geht auf die 90er Jahre zurück ist und damit sogar etwas älter als das agile Manifest. Es gibt aber viele gemeinsame Prinzipien – vor allem den Fokus auf kurze Release-Zyklen. Daher zählt Extreme Programming genauso zu den agilen Methoden wie beispielsweise Scrum.

Fünf Grundwerte spielen im Extreme Programming eine zentrale Rolle: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Daneben gibt es vierzehn Praktiken, die in der Entwicklung angewendet werden sollen. Einige dieser Praktiken überschneiden sich direkt mit dem agilen Manifest, andere wiederum kommen zwar nicht im Manifest vor, werden dafür aber in anderen agilen Methoden verwendet. Völlig neu im Gegensatz zu Scrum und Co. ist, dass die Praktiken auch vorgeben, wie konkret entwickelt werden soll. Hier eine Übersicht über die vierzehn Praktiken:  

  • Pair-Programming: Zwei Programmierer arbeiten zusammen an einem Problem, wobei einer der Driver und der andere der Partner ist. Das fördert die Kommunikation und den Wissenstransfer. Es handelt sich nicht um eine typisch agile Vorgehensweise.
  • Collective Ownership: Aufgaben werden an das Team und nicht an Individuen verteilt, sodass ein starkes Gemeinschaftsgefühl und auch eine Verpflichtung dem Team über entsteht. Der Code gehört dem Team, nicht einer Person.
  • Continuous Integration (CI): CI ist in vielen agilen Methoden ein wichtiger Aspekt. Die Änderungen aller Teammitglieder werden in regelmäßigen, kurzen Abständen in die gemeinsame Gesamtsoftware integriert, sodass alle Features und Funktionen in einem lauffähigen Gesamtsystem vorliegen. Dadurch  können Release-Zyklen minimiert werden.
  • Test-Driven Development (TDD): Bei Test-Driven Development (testgetriebener Entwicklung) werden die Tests für ein Modul geschrieben, bevor das Modul selbst implementiert wird. Das hat den Vorteil, dass man vor der Implementierung die Anforderungen genau durchdenken muss. Obwohl TDD ein unbestreitbar nützlicher Ansatz zur Softwareentwicklung ist, wird er in der agilen Entwicklung eigentlich nicht vorgeschrieben.
  • Kundeneinbeziehung: Der Kunde soll in die Planung mit einbezogen werden, die Ergebnisse von Entwicklungs- und Release-Zyklen testen und neue Ziele mitbestimmen.
  • Refactoring: Refactoring bedeutet die Verbesserung von Code, Design oder der gesamten Architektur. Insbesondere Reviews helfen dabei, Fehler oder unsaubere Strukturen zu erkennen und zu beseitigen.
  • 40-h-Woche: Überstunden zehren an der Freude für die Arbeit und verringern die Konzentration. Sie sollten daher vermieden werden. Diese Vorgabe ist vergleichbar mit der Vorschrift das agilen Manifests, ein gleichmäßiges und einhaltbares Arbeitstempo zu wählen.
  • Iterationen: Iterationen sind das, was in anderen Methoden – und mittlerweile auch außerhalb eines agilen Projektumfelds – als Sprint bezeichnet wird. Es handelt sich um eine in sich geschlossene Phase, die aus Auswahl und Umsetzung der Aufgaben, Test, Review und schlussendlich Abnahme besteht
  • Metapher: Damit Produktmanager, Entwickler und Kunden alle dasselbe Vokabular verwenden und es zu weniger Missverständnissen kommt, soll mit Metaphern gearbeitet werden. Diese können beispielsweise mit User Stories umgesetzt werden. In einer User Story beschreibt man in Alltagssprache, welches Feature aus welchem Grund benötigt wird. Die Story kann dann in einzelne Tasks aufgeteilt werden. Da User Stories die Kommunikation und Anschaulichkeit fördern, werden sie beispielsweise auch für das Backlog im Scrum verwendet.
  • Coding Standards: Jeder Entwickler soll sich bei der Implementierung eines Features an gemeinschaftlich festgelegte Coding Standards halten – beispielsweise, wie Code formatiert oder Variablen benannt, aber auch Klassen und Module strukturiert werden.
  • Einfaches Design: Man sollte immer die einfachste Lösung, die den geringsten Overhead erzeugt und nicht „über das Ziel hinausschießt“, wählen. Diese Praktik orientiert sich am bereits genannten KISS-Prinzip.
  • Planning Game: Planning Game oder Planning Poker bezeichnet die gemeinsame Abschätzung, wie aufwändig eine Aufgabe sein wird. Das hilft dabei, eine gute Menge an Tasks für einen Sprint oder eine Iteration auszuwählen. Das Planning Game wird in vielen agilen Methoden gespielt.

Wie gut zu sehen ist, gibt es einige Überschneidungen zwischen einzelnen agilen Methoden. Oft werden in der Praxis die Prinzipien und Arbeitsweisen, die gut zu einem Team passen, aus verschiedenen Methoden ausgewählt und miteinander verbunden. 

Zusammenfassung

Agile Softwareentwicklung vereint verschiedene Ansätze, den Softwareentwicklungsprozess flexibler zu machen. Dazu wird in inkrementellen Iterationen oder Sprints gearbeitet. Der Fokus liegt auf der ständigen Bereitstellung funktionsfähiger Software und der Kommunikation zwischen den Beteiligten. Insgesamt sind agile Projekte damit pragmatischer als klassisches Projektmanagement, das strikte Phasen von Planung über Entwicklung bis Auslieferung fordert. Es ist möglich, schnell auf neue Anforderungen zu reagieren und Missverständnisse frühzeitig aufzudecken. Dadurch werden Risiken minimiert und ein Wettbewerbsvorteil gegenüber starren Projekten geschaffen. Im agilen Manifest – der Grundlage für diese Bewegung – sind verschiedene Leitsätze und Prinzipien festgehalten, die als Grundlage für agile Methode dienen. Zu den bekanntesten Methoden, die mittlerweile nicht nur in der Softwareentwicklung genutzt werden, gehören unter anderem Scrum, Kanban und Extreme Programming.

Ähnliche Produkte

Schreibe einen Kommentar