Die Geschichte von Agile reicht zurück zur Veröffentlichung des „Manifestes für Agile Softwareentwicklung“, das 12 Grundsätze im Jahr 2001 umfasst. Zweifellos gab es gewisse Ansätze des Agilen Ansatzes bereits zuvor, aber nur dieses Dokument systematisierte und stellte sie in einem solchen Umfang dar, dass sie für die Nutzung ausreichend waren. Jahr für Jahr halten sich neue Unternehmen, IT-Spezialisten und Projektmanager an das Manifest. Neue Methoden und Versionen des agilen Entwicklungssystems entstehen.
Was ist die Agile (flexible) Methodologie?
Agile ist ein interaktives Entwicklungsmodell, bei dem Software schrittweise von Beginn eines Projekts an erstellt wird, im Gegensatz zu den Wasserfallmodellen, bei denen der Code am Ende des Arbeitszyklus geliefert wird.
Die flexible Methodologie basiert auf der Aufteilung von Projekten in kleine operationale Teile, die als Benutzergeschichten bezeichnet werden. Je nach Prioritäten werden Aufgaben innerhalb kurzer zweiwöchiger Zyklen (Iterationen) gelöst.
Die 12 Prinzipien, die die Agile Methodologie ausmachen, können in 4 Hauptideen zusammengefasst werden:
- Priorität der Menschen und der Kommunikation über Werkzeuge und Prozesse;
- Priorität eines funktionalen Produkts über übermäßige Dokumentation;
- Priorität der Zusammenarbeit mit Kunden über die Bestätigung von Verträgen;
- Priorität der Bereitschaft zu Veränderungen über das Festhalten am ursprünglichen Plan.
Methoden, die im Agile vorhanden sind:
Scrum
Der Begriff Scrum wurde aus dem Rugby entlehnt, wo dieses Wort die Methode des Teamspiels in Form von drei Linien bezeichnet, die von jedem Gegner gebildet werden, der versucht, den Ball zu ergreifen. Für ein erfolgreiches Wiedererlangen ist nicht nur eine gute körperliche Fitness erforderlich – jeder Spieler im Scrum sollte zusammen mit anderen agieren, mit klarer Vorstellung des Ziels.
Diese Methode wird erfolgreich von Unternehmen wie Microsoft, Yahoo, Siemens Healthcare genutzt. Ein Projektmanager von Amazon beschrieb sogar einen Fall der Einführung von Scrum basierend auf den gesammelten Erfahrungen.
Da Scrum ein Rahmen für die Entwicklung ist, kann jedes folgende Beispiel von dem vorherigen abweichen.
Jeff Sutherland, der Autor des Buches “Scrum. Die Kunst, in der Hälfte der Zeit doppelt so viel zu leisten”, stellte 8 Schritte zur Anwendung der Methodologie fest:
- Wählen Sie den Produktverantwortlichen, der sich über das Projektziel und das erwartete Ergebnis im Klaren ist.
- Organisieren Sie ein Team – bis zu 10 Personen mit den notwendigen Fähigkeiten zur Erstellung eines funktionsfähigen Produkts.
- Ernennen Sie den Scrum-Master, der den Projektworkflow überwacht und das Projektteam bei der Bewältigung von Herausforderungen unterstützt.
- Erstellen Sie das Produkt-Backlog – für jede Produktanforderung legen Sie Prioritäten auf dem Agile Board fest. In diesem Prozess ist die Rolle des Produktverantwortlichen entscheidend, da er die Anforderungen für das Produkt sammelt, damit das Backlog-Team diese bewerten kann.
- Planen Sie Sprints (Iterationen) – Zeitabschnitte zur Erledigung bestimmter Aufgabenketten.
- Organisieren Sie tägliche fünfzehnminütige Treffen – stellen Sie jedem Teammitglied 3 Fragen: Was hat er gestern gemacht, was wird er heute tun, was behindert die Aufgabenverwirklichung.
- Machen Sie Überprüfungen der operationale Teile des Produkts – indem Sie Interessengruppen in solche Überprüfungen einbeziehen.
- Halten Sie Retrospektiven – Problemdiskussion mit der Suche nach Lösungen nach jedem Sprint. Setzen Sie den resultierenden Modifikationsplan im folgenden Sprint um.
Retrospektive in Agile
Scrum hat 4 Schlüsselelemente:
- Produkt-Backlog – Liste der Anforderungen für das Projekt
- Sprint-Backlog – Liste der Anforderungen, die im kommenden Sprint erfüllt werden müssen
- Sprint-Ziel – Sprintzweck
- Sprint-Burndown-Chart – das Diagramm, das aktualisiert wird, während die Aufgaben fortschreiten und abgeschlossen werden. Es erleichtert das Verständnis der Dynamik und des Fortschritts des Teams im Projekt.
eXtreme Programming (XP)
Kent Beck, der Entwickler dieser Methodologie, hat eine Extreme-Programming-Methode geschaffen, die darauf abzielt, volatile Anforderungen an Softwareprodukte zu adressieren und die Qualität der Entwicklung zu verbessern.
Sie ist nur im Bereich der Softwareentwicklung anwendbar und basiert auf 4 Prozessen:
- Coding – nach den gemeinsamen Layoutstandards des Teams;
- Testing – Tests werden grundsätzlich von Programmierern erstellt, bevor der Code geschrieben wird, der getestet werden soll;
- Planung – sowohl für den finalen Build als auch für separate Iterationen. Letztere finden im Durchschnitt alle zwei Wochen statt.
- Audi – sowohl der Entwickler als auch der Kunde, um unklare Punkte zu beseitigen und Anforderungen sowie Werte festzulegen.
Crystal-Methodologien
Diese Familie von Methodologien, die von Alistair Cockburn entwickelt wurde, einem der Autoren des „Manifestes für Agile Softwareentwicklung“, ist in einigen lokalen Bereichen des Projektmanagements wenig bekannt. Cockburn bietet an, eine Klassifizierung nach Farben vorzunehmen, basierend auf einem Kriterium wie der Anzahl der Personen im Team: 2 (Crystal Clear) bis 100 (Crystal Red). Die Farben Maroon, Blau und Violett sind größeren Projekten zugeordnet.
Crystal-Projekte sollten 3 grundlegenden Eigenschaften entsprechen:
- schnelle Lieferung des operationale Codes – eine sich entwickelnde Idee für das iterative Modell in der Agile-Entwicklung.
- Verbesserung durch Reflexion – eine neue Softwareversion wird auf der Grundlage von Informationen über die vorherige optimiert.
- „Osmotische“ Interaktion – Alistairs Innovation, eine Metapher für Kommunikation und Informationsaustausch zwischen Softwareentwicklern innerhalb eines Raumes.
Diese Familie von Methodologien wird ausführlich in dem Buch „Crystal Clear: A Human-Powered Methodology for Small Teams“ von Alistair beschrieben.
Dynamische Softwareentwicklungs-Methode (DSDM)
Nicht nur eine einzelne Person, sondern auch kein Team, sondern ein Konsortium von 17 britischen Unternehmen arbeitete an der Entwicklung von DSDM. Wie Extreme Programming wird DSDM hauptsächlich zur Erstellung von Software eingesetzt.
Der Endverbraucher (Benutzer) spielt eine besondere Rolle im Entwicklungsprozess. Dieses Kernprinzip wird ergänzt durch die folgenden grundlegenden Prinzipien:
- häufige Veröffentlichungen der operationale Versionen des Produkts
- Autonomie der Entwickler bei Entscheidungen
- Testing während des Arbeitszyklus.
DSDM wird in Versionen unterteilt, die aktualisiert werden, während sich Technologien entwickeln und neue Anforderungen an die Softwareentwicklung erscheinen. Derzeit ist die letzte Version DSDM Atern, die 2007 veröffentlicht wurde, obwohl die vorherige (von 2003) noch im Einsatz ist.
Zu Beginn prüft das Team die Machbarkeit der Entwicklung einer Anwendung und deren Einsatzbereich. Dann wird die Arbeit in drei miteinander verbundene Zyklen unterteilt:
- Funktionsmodell-Zyklus – Erstellen von Analyse-Dokumenten und Prototypen.
- Design- & Ingenieurzyklus – In Betriebnahme eines Systems.
- Implementierungszyklus – Bereitstellung des Systems.
Feature Driven Development (FDD)
Diese Methodologie entstand sogar noch vor dem „Manifest für Agile Softwareentwicklung“.
Obwohl FDD auch das Iterationsmodell der Entwicklung verwendet, unterscheidet es sich in folgenden Merkmalen von Agile:
- größere Aufmerksamkeit auf vorab Modellierung
- erhöhte (im Vergleich zu Agile) Bedeutung von Berichts- und Diagrammdarstellungen
- die Methodologie ist für die Unternehmensentwicklung konzipiert.
Feature Driven Development besteht aus folgenden zyklischen Phasen:
- Erstellung eines Gesamtmodells – Vision des Projekts basierend auf vorläufigen Daten.
- Entwicklung einer Liste von Eigenschaften – ähnlich dem Produkt-Backlog in der Scrum-Methodologie.
- Planung nach Eigenschaften – die Komplexität der Eigenschaften wird von jedem Teammitglied bewertet.
- Für jede Eigenschaft – technisches Design und Implementierung – die finale Phase, nach deren Abschluss die Eigenschaft in das Produkt integriert wird, und der Zyklus wiederholt sich.
Lean Software Development
Lean Software Development ist ein Set von Lean Management-Prinzipien (eher als eine Methodologie), die darauf abzielen, die Effizienz des Entwicklungsprozesses zu steigern und die Kosten zu minimieren.
Dieses Set umfasst die folgenden 7 Grundsätze:
- Eliminierung von Verlusten – alles, was keinen Wert für das Endprodukt für den Verbraucher hinzufügt.
- Kontinuierliche Schulung – die fortlaufende Entwicklung eines Teams erweitert die Möglichkeiten zur effektiven Erfüllung von Aufgaben.
- Entscheidungen so spät wie möglich treffen – der Priorität wird der gut durchdachte, fundierte Entscheidungsprozess gegeben, statt spontane Entscheidungen.
- schnelle Lieferung – dies ist im Wesentlichen das Kernprinzip des iterativen Modells.
- Teilstärkung – ein Grundsatz des „Manifestes …“ besagt, dass Menschen und ihre Interaktionen wichtiger sind als Prozesse und Werkzeuge. Ein Projektteam ist die beste Garantie für den erfolgreichen Abschluss von Aufgaben.
- Integrität und Qualität – es ist notwendig, ein ursprünglich hochwertiges Produkt zu erstellen, um Zeit und Ressourcen für nachfolgendes Testen und Eliminieren von Fehlern nicht zu verschwenden.
- Vision eines Gesamtbildes – ein Projekt kann nicht in separate Teile zerlegt werden, ohne den aktuellen Status der Entwicklung sowie die Ziele, Konzepte und Strategien der entwickelten Software zu verstehen.
Varianten von Agile-Entwicklungsmethoden
Agile Modellierung (AM)
Agile Modellierung ist ein Set von Werten, Grundsätzen und Praktiken für die Softwaremodellierung.
AM wird als Element in vollwertigen Softwareentwicklungs-Methodologien verwendet – zum Beispiel in Extreme Programming oder Rapid Application Development.
Agile Modellierung hat folgende grundlegenden Merkmale:
- effektive Interaktion zwischen den Projektbeteiligten;
- Streben nach der Entwicklung einer letztlich einfachen Lösung aus allen möglichen, die alle Anforderungen erfüllt;
- kontinuierliche Rückmeldung erhalten;
- Mut, Entscheidungen zu treffen und Verantwortung dafür zu übernehmen;
- die Erkenntnis, dass man absolut alles weiß.
Agile Unified Process (AUP)
AUP ist eine vereinfachte Version einer anderen Softwareentwicklungs-Methodologie – Rational Unified Process (RUP). Seit 2012 wurde es durch Disciplined Agile Delivery (DAD) ersetzt, aber AUP ist hier und da trotzdem noch der Fall.
Scott Ambler, der Autor der Methodologie, hob die folgenden Schlüsselpunkte im Agile Unified Process hervor:
- Ihr Team weiß, was es tut;
- Einfachheit geht vor.
- Einhaltung der Grundsätze der flexiblen Entwicklungsmethodologie.
- Fokus auf Aktivitäten, die für das Projekt wertvoll sind.
- Unabhängigkeit bei der Auswahl der Werkzeuge.
- Benutzerdefinierte AUP-Konfiguration für die Anforderungen eines speziellen Projekts.
Agile Data Method (ADM)
ADM ist ein Set von iterativen Softwareentwicklungs-Methodologien, die die Bildung von Anforderungen und Lösungen in einem Projekt durch Zusammenarbeit verschiedener Teams betonen. Wie AUP ist auch diese Methodologie nicht eigenständig.
Das Prinzip der Agile Data Method wird durch sechs Grundsätze definiert:
- Daten – die Grundlage für die Erstellung jeder Anwendung.
- Probleme in einem Projekt – sie können nur erkannt werden, wenn das Projektziel und das Konzept klar verstanden werden.
- Arbeitsgruppen – außer dem Grundteam von Entwicklern gibt es Unternehmensgruppen, die andere Arbeitsgruppen unterstützen.
- Einzigartigkeit – es gibt keine perfekte Methodologie, daher erfordert jedes Projekt Werkzeuge aus verschiedenen Methodologien, die kombiniert werden müssen.
- Teamarbeit – gemeinsame Arbeit ist viel effizienter als individuelle Aktivitäten.
- „Sweet Spot” – die Suche nach einer optimalen Lösung für ein Problem („Sweet Spot”), indem Extremitäten vermieden werden.
Essential Unified Process (EssUP)
Es wurde von Ivar Jacobson, einem schwedischen Wissenschaftler, entwickelt, um den Rational Unified Process zu verbessern.
EssUP verwendet das Konzept der Praxis, das Folgendes umfasst:
- Benutzungsszenario – Beschreibung des Verhaltens eines Systems.
- iterative Entwicklung – Erstellen von operationale Teile des Codes in kurzen Zyklen innerhalb weniger Wochen.
- Teampraktiken – zielt darauf ab, das Team zu vereinen und dessen Effizienz zu steigern.
- Prozesse – beispielsweise „Denken Sie global, starten Sie klein“ oder „Beteiligen Sie Interessenvertreter an Geschäftsprozessen“.
In einer Form oder anderen sind alle Praktiken in den RUP- und CMMI-Methodologien sowie in der flexiblen Entwicklungsmethodologie vorhanden.
Getting Real (GR)
Dies ist eine Methodologie, die effektiv für Startups und neu gegründete Teams ist und die maximale Nutzung spezifischer Merkmale von kleinen Projekten und Unternehmen vorschlägt, wie Mobilität, Flexibilität, die Suche nach neuen Lösungen, die Abwesenheit einer strengen und verworrenen Hierarchie usw.
Jason Fried und David Hansson, die Gründer des Unternehmens 37signals (heute Basecamp), beschreiben Getting Real als ein System zur Lösung machbarer Aufgaben, das letztlich einfach, umfassend und funktional ist.
GR ist eine Mischung aus einem Dutzend agiler Entwicklungstools, die verwendet werden, um Folgendes zu minimieren:
- Alternativen
- Optionen und Einstellungen
- Unternehmensstruktur
- Meetings
- Versprechungen.
Ein solches außergewöhnliches Konzept hat nicht den Mainstream erreicht, obwohl einige seiner Elemente in andere Methodologien übergegangen sind.
OpenUP (OUP)
Dies ist eine Softwareentwicklungs-Methodologie, die unabhängig von Werkzeugen und frei von strengen Strukturen ist und folgende Praktiken bietet:
- Messung der Geschwindigkeit des Teams;
- Durchführung täglicher Meetings und Retrospektiven nach Abschluss der Iterationen;
- Konzept der Mikroschritte und frühe Tests durch Verwendung von Checklisten;
- Methodologie des Agile Model Driven Development (AMDD).
Diese Praktiken werden basierend auf vier Prinzipien realisiert:
- Versöhnung von Interessen und Erreichung einer gemeinsamen Vision in der gemeinsamen Arbeit;
- kontinuierliche Verbesserung durch laufendes Feedback;
- Fokus auf die Architektur der Anwendung in frühen Phasen zur Minimierung von Risiken;
- Maximierung des Werts für den Endverbraucher.
Agile Indikatoren
Angesichts der Vielfalt an Agile-Tools, ‑Praktiken, ‑Methoden und ‑Methodologien müssen wir ein Instrument wählen, das uns hilft zu bestimmen, wie effektiv jedes von ihnen ist.
Kennzahlen werden als solches Instrument verwendet.
Für die meisten Projekte werden diese 4 Kategorie von Kennzahlen ausreichen:
- Produktivität – sie steht in Verbindung mit den Kennzahlen Velocity und WIP. Erstere eignet sich nicht für alle Projekte, da die Anzahl der Aufgaben, die pro Iteration erfüllt werden, gemessen wird, aber Iterationen nicht gleich sind. Die Kennzahl „Work-in-Progress“ definiert das Limit von Aufgaben in verschiedenen Phasen: je höher sie ist, desto schlechter läuft es;
- Prognose – die Kapazitätskennzahl, die darin besteht, die Anzahl perfekter Stunden für den kommenden Sprint zu bestimmen. Dementsprechend kann man die verfügbare Arbeitszeit, den Grad der Effizienz bei der Erfüllung von Aufgaben sowie die Anzahl der Aufgaben für einen Sprint planen;
- Qualität – zum Beispiel der Stabilitätsindex der Anforderungen, der nach der Formel = (Gesamtzahl der ursprünglichen Geschäftsanforderungen + Anzahl der zum gegebenen Zeitpunkt geänderten Anforderungen + Anzahl der hinzugefügten Anforderungen + Anzahl der entfernten Anforderungen) / (Gesamtzahl der ursprünglichen Anforderungen) berechnet wird. Diese Kennzahl wird verwendet, um die Zeit zu bestimmen, die für die Überarbeitung von Aufgaben aufgewendet wurde;
- Werte – diese Kennzahl wird in jedem Fall individuell berechnet, abhängig vom Projektformat. So wurde im AirBnb-Startup die Anzahl hochwertiger hochgeladener Fotos als Kennzahl gewählt, die den Endwert des Produkts für die Nutzer bestimmt. Mit zunehmender Anzahl stieg die Nutzeranzahl proportional.
Die Regeln, die für die Kennzahlen gelten, sind die gleichen wie für andere Agile-Tools.
Es gibt keine einzelne Kennzahl, die für Ihr Projekt eindeutig korrekt und relevant wäre.
Kennzahlen sollten laufend überprüft werden, veraltete sollten entfernt und neue nach Bedarf hinzugefügt werden. Sie sollten umfassend und für das gesamte Team zugänglich sein, ohne sich in ein Ziel an sich zu verwandeln. Kennzahlen um ihrer selbst willen sind eine schlechte Lösung.
Mythos-Busters: Agile
Die Popularität der flexiblen Entwicklungsmethodologie hat ihr einen Strich durch die Rechnung gemacht, und Mythen über bestimmte Aspekte von Agile sind sogar auf spezialisierten Portalen zu sehen. Lassen Sie uns diese aufklären!
Mythos Nr. 1: Agile eignet sich für alle Projekte.
Dies ist das hartnäckigste Missverständnis. Eine einzige Agile-Methode allein wird dem Produkt keinen Mehrwert hinzufügen, noch wird sie das Team motivieren.
Mythos Nr. 2: Agile lehnt Dokumentation ab.
Die agile Entwicklungsmethodologie lehnt die Dokumentation nicht ab; sie bestreitet, dass Dokumentation ein Ziel an sich ist. Wenn es darum geht, Dokumentation als Kommunikationsmittel auszuwählen, bevorzugt Agile tatsächlich die persönliche Kommunikation.
Mythos Nr. 3: Agile und Planung sind unvereinbar.
Dieser Mythos wird durch tägliche Planungsereignisse mit 10-minütigen Stand-Ups sowie durch die alle zwei Wochen stattfinden Iterationsplanungen und Sprint-Meetings in Frage gestellt.
Mythos Nr. 4: Agile erfordert viel Nacharbeit.
Die agile Softwareentwicklungs-Methodologie sieht Nacharbeit in zwei Formen vor: Überarbeitung der Anforderungen (Benutzer finden heraus, was sie wirklich benötigen) und Nacharbeit an der Software (Entwicklerteams finden verbesserte Möglichkeiten zum Schreiben und Entwerfen von Anwendungen). Aber das ist auch in anderen Methodologien der Fall! Darüber hinaus dient eine solche Agile-Neuerung wie das Iterationsmodell dazu, den negativen Einfluss von Nacharbeit zu reduzieren.
Vorteile und Nachteile von Agile in der Anwendung
Vorteile:
- Beteiligung der Stakeholder – das Team wird fähiger, die Anforderungen des Kunden zu verstehen. Darüber hinaus steigert die frühe und häufige Lieferung von Software das Vertrauen der Stakeholder in das Projektteam und vertieft das Engagement im Projekt.
- frühe und vorhersehbare Lieferung – das iterativ basierte Entwicklungsmodell (in kurzen Zeiträumen von 1 bis 6 Wochen) bietet Flexibilität und fördert die Produkteinführung.
- Fokus auf Geschäftswert – die Zusammenarbeit mit dem Kunden stellt sicher, dass das Team versteht, wie das Produkt letztlich wertvoll für den Verbraucher gemacht werden kann.
- kontinuierliche Qualitätsverbesserung – Testen während jeder Iteration mit der Unterteilung des finalen Builds in separate Teile des operationale Codes erleichtert die Verbesserung und Beseitigung von Softwarefehlern, bevor das Endprodukt veröffentlicht wird.
Nachteile:
- strenge Anforderungen an das Team und die Kunden – ohne enge Interaktion zwischen dem Projektteam und den Nutzern ist es unmöglich, die Veröffentlichung eines hochwertigen Produkts mit hohem Wert zu gewährleisten. Darüber hinaus bedingen die zahlreichen Agile-Tools und ‑Methoden, dass das Team erfahren sein sollte für deren ordnungsgemäße Einführung.
- nicht geeignet für Outsourcing und für Projekte, bei denen die Teilnehmer nur online miteinander interagieren.
- das Risiko, dass die endgültige Softwareversion nie veröffentlicht wird – überraschenderweise ergibt sich dieser Nachteil aus solchen Agile-Vorteilen wie iterativer Entwicklung und fortlaufender Verbesserung des Produkts.
- es scheitert ohne klare Vision der Geschäftszwecke des Projekts – da ein Agile-Team sich von den Stakeholdern leiten lässt, ist es unmöglich, ein Produkt ohne ein klar definiertes Ziel und Konzept zu entwickeln.
Anwendungen
Nicht alle Projektmanagement-Dienste oder ‑Programme eignen sich für das Agile-basierte Projektmanagement, da jeder von ihnen spezifische Merkmale aufweist.
Wenn Ihr Unternehmen in den Bereichen Marketing & Werbung, Design, SEO oder digitale Dienstleistungen tätig ist, können Sie den SaaS-Service von Worksection nutzen, damit das gesamte Team darauf arbeiten kann. Bisher werden wir von COXO Digital, Royal ® Advertising und Prozorro empfohlen.
Hier sind ein paar Tipps, um Agile in Worksection zu konfigurieren:
- Konfigurieren Sie Tags und Status, die für die Arbeit in Ihrem Unternehmen notwendig sind. Status können sein: in Arbeit, Überprüfung, erledigt, Nacharbeit erforderlich, kritisch, Funktionen, Zahlung fällig. Tags lesen sich oft so: Layout, Test, Produktion, Konzept, Code.
- Erstellen Sie ein Projekt-Backlog und einen Projekt-Sprint.
- Erstellen Sie Aufgaben und vorläufige Checklisten, Skizzen usw. im Backlog.
- Bestimmen Sie während der Treffen die Sprintaufgaben und übertragen Sie sie vom Backlog in den Sprint.
- Verwenden Sie den Gästezugang der Kunden zu Aufgaben, damit Sie immer koordinierte und aktuelle Rückmeldungen zum Projekt erhalten.
- Taggen Sie verantwortliche Personen in Aufgaben, damit jeder Kollege seinen Verantwortungsbereich kennt und sich am Sprint-Ergebnis beteiligt fühlt.
Urteil
Durch die agile Softwareentwicklungsmethodologie erzielen kleine Projektteams maximale Effizienz. Agile realisiert sich durch andere flexible Methoden wie Scrum, XP, Lean usw.
Es kann nicht hastig, von einem unerfahrenen Team, in kurzer Zeit umgesetzt werden,
aber wenn es eingeführt wird, wird Agile die Interaktion zwischen IT und Unternehmen verbessern, die Produkteinführung auf den Markt anregen und den Produktwert für den Endverbraucher steigern.