Die Geschichte von Agile reicht zurück zur Veröffentlichung des „Manifest für agile Softwareentwicklung“, das 2001 aus 12 Grundsätzen besteht. Zweifellos sind bestimmte Ansätze der agilen Methodik bereits zuvor aufgetaucht, aber nur dieses Dokument systematisierte und stellte sie in einem Umfang dar, der für die Anwendung ausreichend war. Jahr für Jahr folgen neue Unternehmen, IT-Spezialisten und Projektmanager dem Manifest. Neue Methoden und Versionen des agilen Entwicklungssystems entstehen.
Was ist die Agile (flexible) Methodik?
Agile ist ein interaktives Entwicklungsmodell, bei dem Software von Beginn eines Projekts an inkrementell erstellt wird, im Gegensatz zu den Wasserfallmodellen, bei denen der Code am Ende des Arbeitszyklus geliefert wird.
Die flexible Methodik basiert auf der Aufteilung von Projekten in kleine operationale Teile, die Benutzergeschichten genannt werden. Je nach Prioritäten werden Aufgaben innerhalb kurzer zweiwöchiger Zyklen (Iterationen) gelöst.
Die 12 Prinzipien, die die Agile Methodik ausmachen, können in 4 Hauptideen zusammengefasst werden:
- Priorität der Menschen und der Kommunikation über Tools und Prozesse;
- Priorität eines funktionalen Produkts über umfangreiche Dokumentation;
- Priorität der Zusammenarbeit mit Kunden über die Bestätigung von Verträgen;
- Priorität der Bereitschaft zu Änderungen über das Folgen des ursprünglichen Plans.
Methoden, die in Agile enthalten sind:
Scrum
Der Begriff Scrum wurde aus dem Rugby entlehnt, wo dieses Wort die Methode des Teamspiels in Form von drei Reihen bedeutet, die von jedem Rivalen aufgebaut werden, um den Ball zu ergreifen. Für ein erfolgreiches Wiedererlangen sind nicht nur gute körperliche Fitness entscheidend – jeder Spieler, der im Scrum spielt, sollte harmonisch mit anderen agieren, mit einem klaren Verständnis des Ziels.
Diese Methode wird erfolgreich von Unternehmen wie Microsoft, Yahoo und Siemens Healthcare angewendet. Ein Projektmanager von Amazon beschrieb sogar einen Fall der Einführung von Scrum basierend auf den gesammelten Erfahrungen.
Da Scrum einen Rahmen für die Entwicklung darstellt, kann jedes nachfolgende Beispiel von dem vorherigen abweichen.
Jeff Sutherland, der Autor des Buches „Scrum. The Art of Doing Twice the Work in Half the Time“, unterschied 8 Schritte zur Anwendung der Methodik:
- Wähle den Product Owner, der sich der Projektziele und der erwarteten Ergebnisse bewusst ist.
- Organisiere ein Team — bis zu 10 Personen mit den nötigen Fähigkeiten, um ein funktionelles Produkt zu erstellen.
- Ernenne den Scrum Master, der den Projektablauf überwacht und dem Projektteam bei Herausforderungen hilft.
- Erstelle ein Product Backlog — für jedes Produktanforderung setze Prioritäten auf dem Agile-Board. In diesem Prozess ist die Rolle des Product Owners entscheidend, da er die Anfragen für das Produkt sammelt, die das Backlog-Team bewerten wird.
- Plane Sprints (Iterationen) — zeitliche Abschnitte zur Bearbeitung bestimmter Aufgabenketten.
- Organisiere tägliche fünfzehnminütige Meetings — stelle jedem Teammitglied 3 Fragen: was er gestern getan hat, was er heute tun wird, was die Erledigung der Aufgabe behindert.
- Mache Überprüfungen der operationale Teile des Produkts — indem Stakeholder in solche Überprüfungen einbezogen werden.
- Führe Retrospektiven durch — Problemdiskussion mit der Suche nach Lösungen nach jedem Sprint. Setze den darauf basierenden Änderungsplan im folgenden Sprint um.
Retrospective in Agile
Scrum hat 4 Schlüsselelemente:
- Product Backlog — Liste der Anforderungen für das Projekt
- Sprint Backlog — Liste der Anforderungen, die im kommenden Sprint erfüllt werden sollen
- Sprint-Ziel — Zweck des Sprints
- Sprint Burndown Chart — das Diagramm, das aktualisiert wird, während Aufgaben abgeschlossen werden. Es erleichtert das Verständnis der Dynamik und des Fortschritts des Teams im Projekt.
eXtreme Programming (XP)
Kent Beck, der Entwickler dieser Methodik, hat eine extrem programmierte Methode geschaffen, die darauf abzielt, volatile Anforderungen an Softwareprodukte zu adressieren und die Qualität der Entwicklung zu verbessern.
Es ist nur im Bereich der Softwareentwicklung anwendbar und basiert auf 4 Prozessen:
- Coding — gemäß den gemeinsamen Layoutstandards des Teams;
- Testing — Tests werden grundsätzlich von Programmierern erstellt, bevor ein Code geschrieben wird, der getestet werden soll;
- Planning — sowohl für den finalen Build als auch für separate Iterationen. Letztere finden im Durchschnitt alle zwei Wochen statt.
- Audition — sowohl von Entwicklern als auch von einem Kunden, um unklare Punkte auszuräumen und Anforderungen sowie Werte zu definieren.
Crystal-Methoden
Diese Familie von Methoden, entwickelt von Alistair Cockburn, einem der Autoren des „Manifest für agile Softwareentwicklung“, ist in einigen lokalen Bereichen des Projektmanagements wenig bekannt. Cockburn schlägt vor, eine Klassifizierung nach Farben vorzunehmen, basierend auf einem Kriterium wie der Anzahl der Personen in einem Team: 2 (Crystal Clear) bis 100 (Crystal Red). Den Farben Maroon, Blau und Violett werden größere Projekte zugewiesen.
Crystal-Projekte sollten 3 grundlegende Merkmale aufweisen:
- raschere Lieferung des operationale Codes — sich entwickelnde Idee für das iterative Modell in der agilen Entwicklung.
- Verbesserung durch Reflexion — eine neue Softwareversion wird basierend auf Informationen zur vorherigen Version verbessert.
- “osmotische” Interaktion — Alistairs Innovation, eine Metapher für Kommunikation und Informationsaustausch zwischen Softwareentwicklern in einem Raum.
Diese Familie von Methoden wird ausführlich im Buch „Crystal Clear: A Human-Powered Methodology for Small Teams” von Alistair beschrieben.
Dynamic Software Development Method (DSDM)
Nicht nur eine einzige Person, sondern ein Konsortium aus 17 britischen Unternehmen arbeiteten an der Entwicklung von DSDM. Wie Extreme Programming wird DSDM überwiegend zur Erstellung von Software eingesetzt.
Der Endverbraucher (Benutzer) spielt eine besondere Rolle im Entwicklungsprozess. Dieses Kernprinzip wird durch die folgenden grundlegenden Prinzipien ergänzt:
- häufige Veröffentlichungen operationale Versionen des Produkts
- Autonomie der Entwickler bei Entscheidungen
- Tests während des gesamten Arbeitszyklus.
DSDM wird in Versionen unterteilt, die aktualisiert werden, während sich Technologien entwickeln und neue Anforderungen an die Softwareentwicklung auftreten. Derzeit ist die letzte Version DSDM Atern, die 2007 veröffentlicht wurde, obwohl die vorherige Version (von 2003) weiterhin in Betrieb ist.
Zu Beginn berücksichtigt das Team die Machbarkeit der Entwicklung einer Anwendung und deren Anwendungsbereich. Dann wird die Arbeit in drei miteinander verbundene Zyklen aufgeteilt:
- Funktionalmodell-Zyklus — Erstellung analytischer Dokumente und Prototypen.
- Design- und Ingenieurzyklus — Inbetriebnahme eines Systems.
- Implementierungszyklus — Systembereitstellung.
Feature Driven Development (FDD)
Diese Methodik entstand sogar noch vor dem „Manifest für agile Softwareentwicklung”.
Obwohl FDD ebenfalls das Iterationsmodell der Entwicklung verwendet, unterscheidet es sich in folgenden Merkmalen von Agile:
- mehr Aufmerksamkeit für das upfront Modeling
- erhöhte (im Vergleich zu Agile) Bedeutung der Erfassung von Berichten und Diagrammen
- die Methodik ist für die Unternehmensentwicklung konzipiert.
Feature Driven Development besteht aus folgenden zyklischen Phasen:
- Erstellung eines allgemeinen Modells — Vision des Projekts basierend auf vorläufigen Daten.
- Entwicklung einer Liste von Eigenschaften — ähnlich dem Product Backlog in der Scrum-Methodik.
- Planung nach Eigenschaften — die Komplexität der Eigenschaften wird von jedem Teammitglied bewertet.
- Für jede Eigenschaft — technisches Design und Implementierung – die letzte Phase, nach deren Abschluss die Eigenschaft in das Produkt übergeht, und der Zyklus sich wiederholt.
Lean Software Development
Lean Software Development ist eine Sammlung von Prinzipien des Lean Managements (eher als eine Methodik), die darauf abzielen, die Effizienz des Entwicklungsprozesses zu steigern und die Kosten zu minimieren.
Dieses Set beinhaltet die folgenden 7 Grundsätze:
- Verluste beseitigen — alles, was dem Endkunden keinen Wert bietet.
- kontinuierliches Training —die fortlaufende Entwicklung eines Teams verbessert die Möglichkeiten für eine effiziente Erledigung von Aufgaben.
- Entscheidungen so spät wie möglich treffen — der Priorität werden durchdachte Lösungen gegeben, die gut ausgearbeitet und auf erworbenem Wissen basieren, anstelle von spontanen.
- schnelle Lieferung — das ist im Grunde das Kernprinzip des iterativen Modells.
- Teamanormierung — ein Grundsatz des „Manifest…“ besagt, dass Menschen und ihre Interaktionen wichtiger sind als Prozesse und Tools. Ein Projektteam ist die beste Garantie für den erfolgreichen Abschluss von Aufgaben.
- Integrität und Qualität — es ist notwendig, ein ursprünglich qualitativ hochwertiges Produkt zu erstellen, um Zeit und Ressourcen für weitere Tests und die Beseitigung von Fehlern zu sparen.
- Vision eines Gesamtbildes — ein Projekt kann nicht in separate Teile zerlegt werden, ohne den aktuellen Status der Entwicklung, sowie die Zwecke, das Konzept und die Strategien der entwickelten Software zu verstehen.
Versionen von agilen Entwicklungsmethoden
Agile Modeling (AM)
Agile Modeling ist eine Sammlung von Werten, Grundsätzen und Praktiken für Softwaremodellierung.
AM wird als Element in vollwertigen Softwareentwicklungsmethodiken verwendet — beispielsweise im Extreme Programming oder Rapid Application Development.
Agile Modeling hat folgende grundlegenden Merkmale:
- effektive Interaktion zwischen den Projektstakeholdern;
- Streben nach der Entwicklung einer letztendlich einfachen Lösung, die alle Anforderungen erfüllt;
- kontinuierlicher Erhalt von Feedback;
- Mut, Entscheidungen zu treffen und dafür verantwortlich zu sein;
- das Bewusstsein, dass man absolut alles weiß.
Agile Unified Process (AUP)
AUP ist eine vereinfachte Version einer anderen Softwareentwicklungsmethodik — Rational Unified Process (RUP). Seit 2012 wurde es durch Disciplined Agile Delivery (DAD) ersetzt, aber AUP ist hier und da immer noch präsent.
Scott Ambler, der Autor der Methodik, hebt die folgenden Schlüsselpunkte im Agile Unified Process hervor:
- Ihr Team weiß, was es tut;
- Einfachheit steht an erster Stelle.
- Übereinstimmung mit den Grundsätzen der flexiblen Entwicklungsmethodik.
- Fokus auf Aktivitäten, die für das Projekt wertvoll sind.
- Unabhängigkeit bei der Auswahl der Tools.
- Individuelle Anpassung der AUP-Konfiguration an die Anforderungen eines bestimmten Projekts.
Agile Data Method (ADM)
ADM ist eine Sammlung von iterativen Softwareentwicklungsmethodiken, die die Bildung von Anforderungen und Lösungen in einem Projekt durch die Zusammenarbeit verschiedener Teams betonen. Wie AUP ist diese Methodik ebenfalls nicht autark.
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 ‑konzept klar verstanden werden.
- Arbeitsgruppen — neben dem Basisteam von Entwicklern gibt es Unternehmensgruppen, die andere Arbeitsgruppen unterstützen.
- Einzigartigkeit — es gibt keine perfekte Methodik, daher erfordert jedes Projekt die Kombination von Werkzeugen aus verschiedenen Methodiken.
- Teamarbeit — gemeinsame Arbeit ist wesentlich effizienter als individuelle Aktivitäten.
- „Sweet Spot” — 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:
- Verwendungsszenario — Beschreibung des Verhaltens eines Systems.
- Iterative Entwicklung — Erstellung operationale Teile des Codes in kurzen Zyklen innerhalb weniger Wochen.
- Teampraktiken — darauf abzielt, das Team zu vereinen und dessen Effizienz zu steigern.
- Prozedurenpraktiken — zum Beispiel: „Denke global, starte klein“ oder „Beziehe Stakeholder in Geschäftsprozesse mit ein“.
In einer Form oder einer anderen sind alle Praktiken in den RUP- und CMMI-Methodiken sowie in der flexiblen Entwicklungsmethodik vorhanden.
Getting Real (GR)
Dies ist eine Methodik, die sich effektiv für Start-ups und neu gegründete Teams eignet und die maximale Nutzung spezifischer Merkmale, die kleinen Projekten und Unternehmen eigen sind, wie Mobilität, Flexibilität, Suche nach neuen Lösungen, Fehlen einer strengen und verwirrenden Hierarchie usw., vorschlägt.
Jason Fried und David Hansson, die Gründer der 37signals Company (derzeit Basecamp), beschrieben Getting Real als ein System zur Lösung realisierbarer Aufgaben, das letztendlich einfach, umfassend und funktional ist.
GR ist eine Mischung aus einem Dutzend von agilen 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 Methodiken übergegangen sind.
OpenUP (OUP)
Dies ist eine unabhängig von Tools und ohne strenge Struktur entwickelte Softwareentwicklungsmethodik, die folgende Praktiken umfasst:
- Messung der Geschwindigkeit des Teams;
- Durchführung täglicher Meetings und Retrospektiven nach Abschluss von Iterationen;
- Konzept der Mikro-Schritte und frühes Testen mit Hilfe von Checklisten;
- Methodik der Agile Model Driven Development (AMDD).
Diese Praktiken werden auf der Grundlage von vier Prinzipien umgesetzt:
- Vereinigung der Interessen und Erreichung einer gemeinsamen Vision in der gemeinsamen Arbeit;
- Kontinuierliche Verbesserung durch fortlaufendes Feedback;
- Fokus auf die Architektur der Anwendung in den frühen Phasen, um Risiken zu minimieren;
- Maximierung des Wertes für den Endverbraucher.
Agile Indikatoren
Angesichts der Diversität agiler Tools, Praktiken, Methoden und Methodiken müssen wir ein Instrument wählen, das uns hilft zu bestimmen, wie effektiv jedes davon ist.
Kennzahlen werden als solches Instrument verwendet.
Für die meisten Projekte werden diese 4 Kennzahlenkategorien ausreichen:
- Produktivität — es grenzt an die Velocity- und WIP-Kennzahlen. Die erste passt nicht zu allen Projekten, da die Anzahl der in jeder Iteration erfüllten Aufgaben gemessen wird, aber die Iterationen nicht gleich sind. Die Work-in-Progress-Kennzahl definiert das Limit der Aufgaben in verschiedenen Phasen: je höher sie ist, desto schlimmer läuft es;
- Vorhersage — die Kapazitätskennzahl, die darin besteht, die Anzahl der verfügbaren perfekten Stunden im nächsten Sprint zu bestimmen. Entsprechend kann die verfügbare Arbeitszeit, der Grad der Effizienz bei der Erledigung von Aufgaben sowie die Anzahl der Aufgaben für einen Sprint geplant werden;
- Qualität — beispielsweise der Stabilitätsindex der Anforderungen, der mit der Formel = (Gesamtzahl der ursprünglichen Geschäftsanforderungen + Anzahl der geänderten Anforderungen zum gegebenen Zeitpunkt + Anzahl der hinzugefügten Anforderungen + Anzahl der subtrahierten Anforderungen) / (Gesamtzahl der ursprünglichen Anforderungen) berechnet wird. Diese Kennzahl wird verwendet, um die aufgewendete Zeit für die Überarbeitung von Aufgaben zu bestimmen;
- Werte — diese Kennzahl wird in jedem Fall individuell berechnet, abhängig vom Projektformat. Beispielsweise wurde im Startup AirBnb die Anzahl der heruntergeladenen hochwertigen Fotos als Kennzahl gewählt, die den Endwert des Produkts für die Benutzer bestimmt. Während diese Zahl stieg, wuchs die Anzahl der Benutzer proportional.
Die Regeln, die für die Kennzahlen gelten, sind die gleichen wie die für andere Agile-Tools.
Es gibt keine einzige Kennzahl, die einzigartig korrekt und relevant für Ihr Projekt wäre.
Kennzahlen sollten kontinuierlich überprüft, veraltete sollten entfernt und neue bei Bedarf hinzugefügt werden. Es sollte umfassend und für das gesamte Team ohne Transformation in ein Ziel an sich verfügbar sein. Kennzahlen um ihrer selbst willen sind eine schlechte Lösung.
Mythen über Agile
Die Popularität der flexiblen Entwicklungsmethodik hat ihr einen Streich gespielt, und Mythen über bestimmte Aspekte von Agile sind sogar auf spezialisierten Portalen zu sehen. Lass sie uns aufklären!
Mythos Nr. 1: Agile eignet sich für alle Projekte.
Dies ist das bestimmendste Missverständnis. Nur eine einzige Agile-Methode an sich wird dem Produkt keinen Wert hinzufügen, noch wird sie das Team motivieren.
Mythos Nr. 2: Agile ist gegen Dokumentation.
Die agile Entwicklungsmethodik ist gegen Dokumentation, sie leugnet Dokumentation als Ziel an sich. Wenn es darum geht, Dokumentation als Kommunikationsmittel auszuwählen, fördert Agile tatsächlich die persönliche Kommunikation.
Mythos Nr. 3: Agile und Planung sind unvereinbar.
Dieser Mythos wird durch tägliche Planereignisse mit 10-minütigen Standups sowie durch Iterationsplanungen, die alle zwei Wochen stattfinden, Sprint-Meetings usw. widerlegt.
Mythos Nr. 4: Agile erfordert viel Nacharbeit.
Die agile Softwareentwicklungsmethodik sieht Nacharbeit in zwei Formen vor: Anforderungen nacharbeiten (Benutzer finden heraus, was sie wirklich brauchen) und Software nacharbeiten (Entwicklungsteams finden verbesserte Möglichkeiten zur Programmierung und Gestaltung von Anwendungen). Doch dies tritt auch in anderen Methodiken auf! Darüber hinaus dient eine solche Neuheit in Agile wie das Iterationsmodell dazu, den negativen Einfluss von Nacharbeit zu reduzieren.
Vorteile und Nachteile von Agile in der Anwendung
Vorteile:
- Einbeziehung der Stakeholder — das Team wird fähiger, die Anforderungen der Kunden zu verstehen. Darüber hinaus stärkt die frühe und häufige Bereitstellung von Software das Vertrauen der Stakeholder in das Projektteam und fördert das Engagement im Projekt.
- Frühe und vorhersehbare Lieferung — das iterative Entwicklungsmodell (in kurzen Zeiträumen von 1 bis 6 Wochen) bietet Flexibilität und fördert die Produkteinführung.
- Fokus auf Geschäftswerte — die Zusammenarbeit mit dem Kunden stellt sicher, dass das Team versteht, wie es das Produkt letztendlich wertvoll für den Verbraucher machen kann.
- Kontinuierliche Qualitätsverbesserung — Tests während jeder Iteration mit der Aufteilung des finalen Builds in separate Teile des operationale Codes erleichtern die Verbesserung und Beseitigung von Softwarefehlern, bevor das finale Produkt veröffentlicht wird.
Nachteile:
- Strenge Anforderungen an das Team und die Kunden — ohne enge Interaktion zwischen dem Projektteam und den Benutzern ist es unmöglich, eine qualitativ hochwertige Produktablieferung mit hohem Wert sicherzustellen. Darüber hinaus bedingen eine Vielzahl von Agile-Tools und ‑Methoden, dass das Team erfahren sein muss für deren korrekte Einführung.
- Nicht geeignet für Outsourcing und für Projekte, bei denen die Teilnehmer sich nur im Online-Modus austauschen.
- Das Risiko, dass die endgültige Softwareversion niemals veröffentlicht wird — überraschenderweise ergibt sich dieser Nachteil aus solchen Vorteilen von Agile wie der iterativen Entwicklung und der fortlaufenden Verbesserung des Produkts.
- Es versagt ohne klare Vision der Geschäftszwecke des Projekts — da ein Agile-Team von den Stakeholdern geleitet wird, ist es unmöglich, ein Produkt ohne ein klar umrissenes Ziel und Konzept zu entwickeln.
Anwendungen
Nicht alle Projektmanagement-Services oder ‑Programme eignen sich für die agile Projektmanagement, da jede von ihnen ihre spezifischen Merkmale hat.
Wenn Ihr Unternehmen eine Marketing‑, Werbe‑, Design‑, SEO- oder Digitalagentur ist, können Sie den SaaS-Dienst 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 Lifehacks, um Agile in Worksection zu konfigurieren:
- Konfigurieren Sie Tags und Status, die für die Arbeit in Ihrem Unternehmen erforderlich sind. Status können sein: in Bearbeitung, Überprüfung, erledigt, Nacharbeit erforderlich, kritisch, Funktionen, Zahlung fällig. Tags lesen 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 Meetings die Sprintaufgaben und übertragen Sie diese vom Backlog in den Sprint.
- Nutzen Sie den Gästezugang von Kunden zu Aufgaben, damit Sie stets koordinierte und relevante Rückmeldungen zum Projekt haben.
- Taggen Sie verantwortliche Personen in Aufgaben, damit jeder Kollege seinen Verantwortungsbereich kennt und sich in das Ergebnis des Sprints eingebunden fühlt.
Urteil
Durch die agile Softwareentwicklungsmethodik erreichen kleine Projektgruppen 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 eingeführt werden,
aber wenn es eingeführt wird, wird Agile die Interaktion zwischen IT und Unternehmen verbessern, es wird die Produkteinführung auf den Markt anregen und den Produktwert für den Endverbraucher erhöhen.