Agile Softwareentwicklung bezeichnet Softwareentwicklungsmethoden, die sich um die Idee der iterativen Entwicklung drehen, bei der Anforderungen und Lösungen durch die Zusammenarbeit zwischen selbstorganisierende und funktionsübergreifenden Teams entstehen. Die Agile Softwareentwicklung soll es ermöglichen, dass Teams schneller, mit höherer Qualität und Vorhersagbarkeit Leistungen abliefern und gleichzeitig besser auf Veränderungen reagieren zu können. Um dies zu erreichen, wird versucht, die Entwurfsphase soweit wie möglich zu reduzieren und so schnell wie möglich Software zu entwickeln, die sich ausführen lässt. Im Verlauf der weiteren Entwicklung wird die Software dann regelmäßig mit dem Kunden abgestimmt und inkrementelle Verbesserungen werden implementiert. Durch diese Art des Vorgehens kann das Risiko gemindert werden, dass der initiale vom Kunden abgesegnete Entwurf im Laufe der Entwicklung nicht mehr den wirklichen Wünschen des Kunden entspricht. Somit wird weniger an die Vorstellungskraft und mehr an das Entscheidungsvermögen der Kunden appelliert.
Geschichte der Agilen Softwareentwicklung
Bereits in den 1990ern gab es eine Gegenbewegung zu den gängigen Softwareentwicklungsmethoden, wie zum Beispiel dem Wasserfallmodell. Die Kritiker empfanden diese als zu reguliert und selbst auf Mikroebene zu durchgeplant, was sie insgesamt zu unflexibel macht. Die daraufhin entwickelten Modelle waren beispielsweise Extreme Programming, Scrum oder Crystal Clear. Ähnliche Bewegungen gab es zur gleichen Zeit auch in den Bereichen des Managements und der Fertigung.
Der Ursprung der Bezeichnung “Agile Softwareentwicklung” lässt sich dabei auf 2001 datieren. In diesem Jahr trafen sich siebzehn Softwareentwickler in einem Resort in Snowbird, Utah, um Entwicklungsmethoden wie beispielsweise Scrum oder Extreme Programming zu diskutieren. Das Ergebnis war ein gemeinsam veröffentlichtes Manifest namens “Manifesto for Agile Software Development”. Infolgedessen wurden die bereits vorher ausgearbeiteten Entwicklungsmethoden unter dem Begriff der Agilen Softwareentwicklung geführt. Agil stammt im übrigen aus dem Lateinischen und heißt so viel wie beweglich oder flink.
Agiles Manifest
Agile Leitsätze
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“
Agile Prinzipien
- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
- Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
- Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
- Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
- Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
- Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
- Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
- Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Modelle der Agilen Softwareentwicklung
Für die Umsetzung der Agilen Prinzipien gibt es mehrere Entwicklungsmethoden, die alle zum Überbegriff der Agilen Softwareentwicklung zählen. Exemplarisch für diese werden im Folgenden die zwei wohl bekanntesten Vorgehensmodelle genauer betrachtet: Scrum und Kanban.
Scrum
Beim Scrum wird die gesamte Projektlaufzeit in einzelne Sprints unterteilt. In diesen Sprints wird versucht das Produkt – in der Softwareentwicklung die Software – um ein Inkrement zu erweitern. Dabei beginnt der Sprint mit dem Sprint Planning und endet mit dem Sprint Review. Ein Sprint ist in der Regel zwei bis vier Wochen lang und darf das Zeitfenster von vier Wochen auch nicht überschreiten. Innerhalb dieser Sprints gibt es tägliche Treffen, sogenannte Daily Scrums, des Entwicklerteams, zum Anfang jedes Arbeitstages, die für den Informationsaustausch gedacht sind. Diese sind maximal 15 Minuten lang und häufig beteiligt sich hier nur das Entwicklerteam.
Diese Herangehensweise ermöglicht es Teams, sich selbst zu organisieren, indem die Zusammenarbeit aller Teammitglieder sowie die tägliche Kommunikation von Angesicht zu Angesicht zwischen allen beteiligten Teammitgliedern und Disziplinen gefördert wird.
Ein Schlüsselprinzip von Scrum ist die doppelte Erkenntnis, dass Kunden den Umfang dessen, was gewünscht wird, ändern werden und dass es unvorhersehbare Herausforderungen geben wird – für die ein vorausschauendes oder geplantes Vorgehen nicht geeignet ist.
Scrum Teammitglieder
Die grundlegenden Mitglieder, die es für Scrum braucht, sind ein ein kleines Team, bestehend aus einem Product Owner, einem Scrum Master und Entwicklern.
Product Owner
Der Product Owner ist im Grunde das Bindeglied zwischen den Entwicklern des Scrum Teams und dem Kunden (auch Stakeholder genannt). Dieser vertritt die Wünsche des Kunden und definiert das Produkt im Hinblick auf kundenzentrierte Ergebnisse. Diese “Kundenwünsche” werden seitens dem Product Owner dem Backlog hinzugefügt und auf Basis von Wichtigkeit priorisiert. Der Product Owner schreibt nicht vor, wie das Team eine technische Lösung erreicht, sondern sucht den Konsens unter den Beteiligten. Der wichtigste Skill des Product Owners ist die Kommunikation sowie die notwendige Empathie für die Beteiligten.
Entwickler
Die Entwickler führen in jedem Sprint alle erforderlichen Arbeiten durch, um am Ende des Sprints ein verbessertes Produkt abliefern zu können.
Der Begriff Entwickler bezieht sich auf jeden, der eine Rolle bei der Entwicklung und dem Support des Systems oder Produkts spielt, und kann unter anderem Forscher, Architekten, Designer, Datenspezialisten, Statistiker, Analysten, Ingenieure, Programmierer und Tester umfassen. Das Team organisiert sich selbst. Während dem Team nur durch den Product Owner Arbeit zufließen sollte und vom Scrum Master erwartet wird, das Team vor Ablenkungen zu schützen, wird das Team ermutigt, direkt mit Kunden und/oder Stakeholdern zu interagieren, um maximales Verständnis und Unmittelbarkeit des Feedbacks zu erlangen.
Scrum-Master
Scrum wird von einem sogenannten Scrum-Master unterstützt. Dieser ist dafür verantwortlich für den Rest des Teams Hindernisse zu beseitigen, sodass sich Entwickler und Product Owner voll und ganz auf ihre eigentlichen Aufgaben konzentrieren können. Obwohl es so klingen mag ist der Scrum Master kein klassischer Teamleiter oder Projektmanager, sondern fungiert als Barriere zwischen dem Team und allen ablenkenden Einflüssen. Er wird deshalb auch als Servant Leader also als dienender Leiter bezeichnet, der versucht durch seine Taten bestmöglich dem Rest des Teams zu dienen. Der Scrum Master stellt außerdem sicher, dass das Scrum-Framework befolgt wird, indem er das Team coacht oder wichtige Sitzungen moderiert.
Kanban
Kanban ist eine relativ einfache Lean-Methode, bei der sich auf einen kontinuierlichen Workflow innerhalb der Softwareentwicklung fokussiert wird. Ziel von Kanban ist es durch das Visualisieren von Softwareentwicklungsprozessen und dem Limitieren von Work in Progress, schneller zu werden, Engpässe schnell zu erkennen und einen kontinuierlichen Fluss an Arbeit zu schaffen. Kanban (was aus dem japanischen kommt und so viel bedeutet wie “Signalkarte”) kommt ursprünglich aus der Fertigung von Toyota. Die Person, die als Begründer von Kanban in der IT gilt, ist David J Anderson. Dieser hat hat vier Grundprinzipien sowie sechs Kernpraktiken für Kanban formuliert.
Grundprinzipien von Kanban
1. Start with what you do now! – Beginne mit dem, was du jetzt tust!
Um Kanban einzuführen bedarf es keiner zwangsweisen Änderung der aktuellen Prozesse. Wichtiger ist, die aktuellen Prozesse weiterzuentwickeln. Dies macht es einfacher, mit einer Kanban-Implementierung zu beginnen, da keine umfassenden Änderungen vorgenommen werden müssen.
2. Agree to pursue incremental, evolutionary change – Willige ein, inkrementelle, evolutionäre Veränderungen zu verfolgen
Die Entwickler führen in jedem Sprint alle erforderlichen Arbeiten durch, um am Ende des Sprints ein verbessertes Produkt abliefern zu können.
Ohne Einvernehmen, dass ein langsamer, sanfter, evolutionärer, inkrementeller Ansatz der richtige Weg ist, wird es nicht die richtige Umgebung oder Managementunterstützung für eine Kanban-Initiative geben. Deshalb ist es wichtig, dass die Organisation bzw. die Team Mitglieder dem zustimmen, dass eine Verbesserung der aktuellen Umstände gerechtfertigt ist.
3. Respect the current process, roles, responsibilities and job titles – Respektieren Sie den aktuellen Prozess, die Rollen, Verantwortlichkeiten und Berufsbezeichnungen
Es ist wahrscheinlich, dass aus Angst vor Veränderung und dem damit einhergehenden Verlust von Macht oder Einfluss, Widerstände entstehen. Um diesen vorzubeugen ist es wichtig, die bestehenden Verantwortlichkeiten mit dem notwendigen Respekt zu behandeln. Kanban verbietet Veränderungen nicht, schreibt sie aber auch nicht vor. Wenn Änderungen vorgenommen werden sollen, fördert Kanban inkrementelle Änderungen. Inkrementelle Änderungen erzeugen nicht das Maß an Angst, das Fortschritt behindert.
4. Encourage acts of leadership at all levels in the your organization – Ermutige zu Führung auf allen Ebenen der Organisation
Wenn Änderungen schnell und effektiv vorgenommen werden sollen, müssen sich Personen, die Verbesserungen für möglich halten, in der Lage fühlen, diese umzusetzen. Es muss eine Sicherheitskultur vorhanden sein, in der Maßnahmen ohne Angst vor Vergeltungsmaßnahmen ergriffen werden können, sofern Änderungen auf der Grundlage logischer Erklärungen unter Verwendung von Modellen und Daten verteidigt werden können. So kann Führung auch von Mitarbeitern kommen, die sich weder in einer Führungsposition, noch im Management befinden.
Kernpraktiken von Kanban
1. Visualize (the work, the workflow and the business risks) – Visualisiere den Workflow
Grundsätzlich ist es wichtig die immateriellen und unsichtbaren Prozesse sichtbar zu machen. Nur so ist es möglich diese auch zu verwalten und inkrementelle Verbesserungen vorzunehmen. Um das zu tun sollte ein Kanban-Board angelegt werden, wo jede Anfrage als Karte abgebildet ist. So kann die Abfolge vom ersten Eingang einer Anfrage bis zum Abschluss und zur Auslieferung an den Kunden visualisiert werden. Außerdem sollten Risiken die mit der Arbeit verbunden sind, wie z.B. Verzögerungen, Macht des Kunden oder auch Verzögerung durch eventuelle Veränderungen, erfasst werden. Möglichkeiten der Visualisierung sind beispielsweise Farbe oder Symbole auf den Karten.
2. Limit WIP – die Menge des “Work in Progress” also die Anzahl der angefangenen Arbeiten begrenzen
Aufgaben und Arbeiten werden nicht geschoben also “gepusht”, sondern gezogen also “gepullt”. Das soll dadurch realisiert werden, dass die Anzahl der angefangenen Arbeiten begrenzt wird. Wenn beispielsweise in der Programmierung zwei Karten bearbeitet werden und die Begrenzung bei zwei liegt, so darf den Programmierern keine dritte Karte hingelegt werden. So können sehr schnell Informationen über Engpässe gewonnen w
3. Manage Flow – Fluss verwalten
Flow bezieht sich hier auf Workflow. Zunächst einmal müssen Durchlaufzeiten für Prozesse festgehalten werden um dann zu schauen, ob inkrementelle Veränderungen auch die gewünschten Verbesserungen mit sich bringen. Anhand des Workflows lässt sich feststellen, wie gut die Organisation der Abläufe ist und wo es Engpässe bzw. zu lange Wartezeiten gibt.
4. Make Policies Explicit – Mache die Regeln für den Prozess explizit
Softwareentwicklung ist ein kreativer Prozess. Dementsprechend kann es schwierig sein, Prozessgrenzen klar zu definieren. Allerdings kann ohne klare Regeln und ohne eine explizite Definition des Prozesses auch keine Verbesserung stattfinden. Prozesse müssen abgegrenzt werden. Die Regeln dafür sollten explizit festgehalten werden. Beispielsweise die “definition of done”, also wann etwas wirklich fertig ist oder auch die Regeln, wann und auch was gepullt werden kann. Ohne solche Definitionen sind die Diskussionen und Versuche Verbesserung zu erschaffen zu subjektiv. Die Regeln für den Prozess explizit zu machen impliziert eine höhere Objektivität und rationalere Herangehensweise.
5. Implement Feedback Loops – Feedbackschleifen einführen
Verbesserung ohne Rückmeldung oder Bewertung der Prozesse ist blindes Versuchen. Häufig verwendete Methoden für Feedbackschleifen sind: das Stand-up-Meeting; die Überprüfung der Leistungserbringung; die Betriebsüberprüfung; und die Risikoprüfung. Der Zweck von Feedbackschleifen besteht darin, erwartete Ergebnisse mit tatsächlichen Ergebnissen zu vergleichen und Anpassungen vorzunehmen.
6. Improve Collaboratively, Evolve Experimentally (using models/scientific method) – Die Zusammenarbeit verbessern (mithilfe von Modellen und wissenschaftlichen Methoden)
Das, was letztlich wirklich dazu führt, dass Veränderungen angeregt werden, ist das WIP-Limit. Durch dieses werden schnell Störungen des Workflows sichtbar. Wenn Teams ein gemeinsames Verständnis von Theorien zu Arbeit, Workflow, Prozess und Risiko haben, sind sie eher in der Lage, ein gemeinsames Verständnis eines Problems aufzubauen und Verbesserungsmaßnahmen vorzuschlagen, die einvernehmlich vereinbart werden können.
Vor- und Nachteile der Agilen Softwareentwicklung
Agile Softwareentwicklung bietet, wie fast jedes Vorgehensmodell Vor- und auch Nachteile. Im Folgenden sind einige Vor- und Nachteile der Agilen Modelle aufgelistet.
Vorteile
Flexibilität
Der erste Vorteil, den eine agile Herangehensweise mit sich bringt, ist die gewonnene Flexibilität innerhalb des Entwicklungsprozesses. Falls während der Entwicklung seitens der Auftraggeber kurzfristige Änderungen gefordert werden, ist eine agile Herangehensweise massiv im Vorteil. Insbesondere, wenn die Entwicklungszyklen, wie bei Scrum, zwischen 2 und 4 Wochen liegen und es tägliche Events gibt, an denen sich Entwickler über Stände austauschen können, kann flexibel auf neue Anforderungen reagiert werden.
Geschwindigkeit
Agile Vorgehensweisen haben zum Vorteil, dass immer wieder Zwischenergebnisse präsentiert werden können, da inkrementelle Verbesserungen innerhalb von einzelnen Iterationen geschaffen werden, anstatt von einem ganzheitlichen Endergebnis. So können auch in kürzeren Abständen Ergebnisse präsentiert werden.
Fehlentscheidungen
Die Anzahl an Fehlentscheidungen bei der Agilen Softwareentwicklung wird reduziert. Dadurch, dass in Agilen Methoden, Feedbackschleifen eine wichtige Rolle spielen und die Zusammenarbeit mit dem Kunden im Fokus liegt, kann insgesamt die Anzahl an Fehlentscheidungen reduziert werden.
Nachteile
Höhere Kosten
Insbesondere in der Softwareentwicklung können durch Agile Vorgehensweisen höhere Kosten entstehen. Normalerweise wird ein Preis pro Sprint vereinbart. Das kann dazu führen, dass bei einer Reihe an Änderungswünschen aufgrund von kurzen Planungszeiten auch ungeplante Kosten auf den Kunden zukommen. Im Gegensatz dazu, kann bei “unflexibleren Methoden” ein Festpreis ausgemacht werden, wodurch Mehrkosten vermieden werden können.
Abweichungen
Flexibilität und das agile und flinke Reagieren auf veränderte Vorstellungen des Kunden sind zwar der größte Vorteil von agilen Herangehensweisen, können aber auch schnell zum Nachteil werden. Durch wenig Planung kann das Endprodukt in Teilen sehr weit von der initialen Idee abweichen.
Agile Softwareentwicklung – idesis GmbH
Die idesis GmbH ist ein Individualsoftware-Hersteller aus Essen. Seit über 15 Jahren entwickeln wir individuelle Software für individuelle Vorstellungen. Um dabei die Einzigartigkeit unserer Kunden in den jeweiligen Softwareentwicklungs-Projekten abbilden zu können, berufen wir uns auf verschiedene Vorgehensmodelle. Insbesondere bei Kunden mit denen die Zusammenarbeit über Jahre hinweg auf Vertrauen basiert, sind agile Methoden zur Softwareentwicklung wie beispielsweise Scrum ideal. Unabhängig der Softwareentwicklung oder der Kundenbeziehung arbeiten wir bei der idesis GmbH allerdings nach den Kanban Prinzipien und organisieren so all unsere Projekte.
Falls Sie Unterstützung in Ihrem nächsten Softwareprojekt benötigen, freuen wir uns persönlich von Ihnen zu hören.
