Agile Entwicklungs­prozesse

Zusammenfassung

Ziel der agilen Softwareentwicklung ist, schneller und mit weniger Ressourcen das geplante Ziel zu erreichen. Dabei wird auch berücksichtigt, dass eine genaue Planung aufgrund zu vieler Unbekannten nicht möglich ist und eine laufende Anpassung der Anforderung der einzige Weg zu brauchbaren Ergebnissen ist. Die Einbindung der Auftraggeber ist ein essentieller Teil und wird durch die laufende Fertigstellung von Anwendern nutzbaren Zwischenergebnissen gewährleistet.

Geschichtlicher Rückblick

Wissenschaftliche Forschung und Konzepte zum Thema Softwaretechnik existieren seit den 1940er Jahren. Die Softwaretechnik oder Softwaretechnologie beschäftigt sich mit der Herstellung oder Entwicklung von Software, der Organisation und Modellierung der zugehörigen Datenstrukturen und dem Betrieb von Softwaresystemen.

Erste Ansätze zu agiler Softwarenentwicklung gab es bereits Anfang der 1990er Jahre, aber bekannt wurde dieser Ansatz durch die Veröffentlichung des Buches "Extreme Programming" durch Kent Back. Der Begriff "agil" ist aber erst bei einem Treffen einer Gruppe von erfahrenen Entwicklern entstanden, die gemeinsam das Agile Manifest formulierten.

Agile Leitsätze

Das Agile Manifest wurde von 17 Entwicklern im Februar 2001 formuliert:

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 stehen über Prozessen und Werkzeugen
  • Funktionierende Software steht über einer umfassenden Dokumentation
  • Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
  • Reagieren auf Veränderung steht über dem 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 Methoden

Agile Methoden sind Bausteine, die es — je nach Anforderung — ermöglichen, den Aufwand zu reduzieren.

Beispiele für agile Methoden:

  • Paarprogrammierung
  • Testgetriebene Entwicklung
  • Anwendergeschichten (User Stories)
  • anlassbezogene Refaktorierung
  • Codereviews
  • automatisierte Tests und kontinuierliche Integration
  • Planspiele
  • Coding Standards

Agile Prozesse

Ziel aller Prozesse ist eine raschere Bereitstellung von anwendbarer Software und die Vermeidung von großen Differenzen zwischen realen und laufend sich verändernden Anforderungen und den produzierten Ergebnissen. Es wird versucht, die Probleme des Wasserfallmodells die bei der Verwendung der klassischen Vorgehensmodelle wie dem V-Modell oder dem Rational Unified Process (RUP) auftreten, zu vermeiden.

Zu den Bekannteren zählen:

Scrum vs. Kanban

Kanban und Scrum teilen einige der gleichen Konzepte, haben jedoch sehr unterschiedliche Ansätze. Sie sollten nicht miteinander verwechselt werden.

SCRUMKANBAN
KadenzRegelmäßige Sprints mit fester Länge (z.B. 2 Wochen)Kontinuierlicher Fluss
FreigabemethodeAm Ende jedes Sprints, sofern vom Produktbesitzer genehmigt.Kontinuierliche Lieferung oder nach Ermessen des Teams
RollenProdukteigentümer, Scrum Leiter, EntwicklungsteamKeine vorhandenen Rollen. Einige Teams nehmen die Hilfe eines agilen Trainers in Anspruch.
Wesentliche KennzahlenGeschwindigkeitZykluszeit
ÄnderungsphilosophieTeams sollten sich bemühen, während des Sprints keine Änderungen an der Sprint-Vorhersage vorzunehmen. Dies beeinträchtigt das Lernen in Bezug auf die Schätzung.Änderungen können jederzeit erfolgen

Einige Teams mischen die Ideale von Kanban und Scrum zu "Scrumban". Sie übernehmen Sprints und Rollen mit fester Länge aus dem Scrum und konzentrieren sich auf Work-in-Progress-Grenzen und Zykluszeiten aus dem Kanban. Für Teams, die gerade erst mit Agilität beginnen, empfehlen wir jedoch dringend, die eine oder andere Methode zu wählen und eine Weile damit zu arbeiten.

SCRUM

Scrum ist ein Konstrukt zur Abwicklung komplexer Prozesse ohne, dass dabei Produktivität und Kreativität leiden und Ergebnisse in höchster Qualität entstehen.

Scrum selbst ist ein einfaches Konzept für effektive Zusammenarbeit bei komplexen Produkten. Statt eines fixen Plans wird durch einen heuristischen Ansatz, mit Respekt vor Menschen und Selbstorganisation, ein Weg gewählt, der die Lösung von unvorhersehbaren und komplexen Problemen ermöglicht.

Ein Scrum Team besteht aus folgenden Rollen:

  • Produkteigentümer
  • Entwicklungsteam
  • Scrum Leiter

Ein Scrum Team organisiert sich selbst und deckt alle benötigten Kompetenzen zur Umsetzung der Aufgabe ab.

Der Scrum Ablauf:

Die regelmäßigen fixen Termine sollen einen gewohnten Rahmen vorgeben und die Anzahl der Meetings insgesamt reduzieren. Alle Termine sind zeitlich begrenzt. Ab dem Zeitpunkt wo ein Sprint beginnt, ist die Durchlaufzeit fixiert und kann weder gekürzt noch verlängert werden.

  • Sprint-Planung
  • Sprint (Umsetzung der geplanten Funktionen)
  • Daily Scrum (tägliches Meeting)
  • Sprint Review (Bewertung der Umsetzung)
  • Sprint Retrospektive (Bewertung des Umsetzungsprozesses und Definition von Verbesserungen)

Die Scrum-Artefakte

Die Artefakte von Scrum stellen Arbeit oder Wert dar, um Transparenz und Möglichkeiten zur Inspektion und Anpassung zu bieten. Von Scrum definierte Artefakte wurden speziell entwickelt, um die Transparenz der wichtigsten Informationen zu maximieren, sodass jeder das gleiche Verständnis für das Artefakt hat. Die Scrum-Artefakte sind:

  • Produkt Backlog (Liste der geplanten Funktionen)
  • Backlog (Liste der für den aktuellen Sprint selektierten Funktionen)
  • Increment (umgesetzte Funktionen, die zur produktiven Anwendung entstanden sind)

Kanban

Kanban ist ein beliebtes Framework zur Implementierung einer agilen Softwareentwicklung. Es erfordert eine Echtzeitkommunikation der Kapazität und vollständige Transparenz der Arbeit. Arbeitselemente werden visuell auf einer Kanban-Tafel dargestellt, sodass die Teammitglieder jederzeit den Status jeder Arbeit sehen können.

Extreme Programming (XP)

Feature Driven Development (FDD)

Feature Driven Development ist ein modellgetriebener Prozess mit kurzer Iteration, der auf erprobten Abläufen für das Software-Engineering basiert, z. B. Modellierung von Domänenobjekten, Entwicklung nach Features und Code-Besitz. Die Vermischung dieser Praktiken, die zu einem zusammenhängenden Ganzen führte, ist das beste Merkmal von FDD.

Feature Driven Development besteht aus fünf grundlegenden Aktivitäten:

  • Entwicklung eines Gesamtmodells
  • Erstellen einer Feature-Liste
  • Planung nach Funktionen
  • Entwerfen nach Merkmal
  • Bauen nach Funktionen

FDD beginnt mit der Erstellung einer Gesamtmodellform, die zu einer Feature-Liste führt. Anschließend wird eine Reihe von zweiwöchigen Iterationen „Plan für Feature, Design für Feature, Build für Feature“ fortgesetzt. Die Funktionen sind klein und in den Augen des Kunden nützlich. Wenn die Erstellung länger als zwei Wochen dauert, müssen sie in kleinere Features unterteilt werden.

Der Hauptzweck vom FDD besteht darin, wiederholt und rechtzeitig greifbare, funktionierende Software bereit zu stellen. Der Vorteil der Verwendung von FDD besteht darin, dass es aufgrund des Konzepts „anfangs gerade genug Design“ (JEDI) auch für große Teams skalierbar ist. Aufgrund seines funktionsorientierten Prozesses ist FDD eine großartige Lösung, um die Kontrolle über das inkrementelle und inhärent komplexe agile Projektmanagement aufrecht zu erhalten.

Dynamic Systems Development Method (DSDM)

Die Dynamic Systems Development Method (DSDM) ist ein agiler Ansatz, der aus der Notwendigkeit heraus entstanden ist, ein gemeinsames Branchen-Framework für eine schnelle Softwarebereitstellung bereitzustellen. Seit 1994 hat sich die DSDM-Methodik weiterentwickelt, um eine umfassende Grundlage für die Planung, Verwaltung, Ausführung und Skalierung von agilen Prozess- und iterativen Softwareentwicklungsprojekten zu bieten.

DSDM basiert auf acht Schlüsselprinzipien, die das Team leiten und eine Denkweise entwickeln, um pünktlich und innerhalb des Budgets zu liefern. Diese agilen Prinzipien drehen sich hauptsächlich um Geschäftsanforderungen / -wert, aktive Benutzerbeteiligung, befähigte Teams, häufige Bereitstellung, integrierte Tests und Zusammenarbeit mit Stakeholdern. DSDM nennt speziell "Eignung für Geschäftszwecke" als Hauptkriterium für die Bereitstellung und Akzeptanz eines Systems und konzentriert sich auf die nützlichen 80% des Systems, die in 20% der Fälle bereitgestellt werden können.

Die Kompromittierung eines der folgenden Prinzipien untergräbt die Philosophie von DSDM und birgt Risiken für das erfolgreiche Ergebnis des Projekts.

Die acht wichtigsten Prinzipien von DSDM:

  • Konzentrieren Sie sich auf die geschäftlichen Anforderungen
  • Pünktlich liefern
  • Zusammenarbeiten
  • Gehen Sie niemals Kompromisse bei der Qualität ein
  • Bauen Sie schrittweise auf festen Fundamenten auf
  • Iterativ entwickeln
  • Kommunizieren Sie kontinuierlich und klar
  • Kontrolle demonstrieren

Die Geschäftsanforderungen werden zu Beginn des Projekts auf hohem Niveau festgelegt. Nacharbeiten sind in den Prozess integriert, und alle Entwicklungsänderungen müssen reversibel sein. Die Systemanforderungen werden in kurzen Zeitfenstern mit fester Länge - auch als Sprints oder Iterationen bezeichnet - geplant und bereitgestellt und mithilfe der MoSCoW-Regeln priorisiert.

MoSCoW-Regeln:

  • M - Muss Anforderungen haben
  • S - Sollte wenn überhaupt möglich sein
  • C - Könnte aber nicht kritisch sein
  • W - Wird diese Zeit nicht haben, aber möglicherweise später

Alle kritischen Arbeiten müssen in der festgelegten Zeitbox eines DSDM-Projekts ausgeführt werden. Es ist wichtig, dass nicht jede Anforderung in einem Projekt oder einer Zeitbox als kritisch angesehen wird. In jeder Zeitbox sind auch weniger kritische Elemente enthalten, damit sie entfernt werden können, um Anforderungen mit höherer Priorität im Zeitplan nicht zu beeinträchtigen.

Crystal

Die Crystal Methode ist eine der leichtgewichtigsten Ansätze in der Softwaretechnik.

Crystal besteht tatsächlich aus einer Familie agiler Prozessmodelle, darunter Crystal Orange, Crystal Clear, Crystal Yellow und anderen. Jedes hat einzigartige Eigenschaften, die von verschiedenen Faktoren wie Teamgröße, Projektprioritäten und Systemkritikalität abhängen. Die Crystal-Methode befasst sich mit der Erkenntnis, dass für jedes Projekt möglicherweise leicht angepasste Richtlinien, Praktiken und Prozesse erforderlich sind, um die einzigartigen Eigenschaften des Produktes zu erfüllen.

Crystal wurde von Alistair Cockburn eingeführt und konzentriert sich hauptsächlich auf Menschen und die Interaktion zwischen ihnen, während sie an einem agilen Softwareentwicklungsprojekt arbeiten. Ein weiterer Schwerpunkt liegt auf der Geschäftskritikalität und der Geschäftspriorität des in der Entwicklung befindlichen Systems.

Im Gegensatz zu herkömmlichen Entwicklungsmethoden versucht Crystal nicht, die Werkzeuge und Techniken der Entwicklung zu reparieren, sondern hält Menschen und Prozesse im Mittelpunkt des Prozesses. Am wichtigsten sind jedoch nicht nur die Menschen oder Prozesse, sondern auch die Interaktion zwischen ihnen.

Zu den wichtigsten Grundsätzen von Crystal gehören Teamwork, Kommunikation und Einfachheit, sowie Reflexion, um den Prozess häufig anzupassen und zu verbessern. Wie andere agile Frameworks fördert Crystal die frühzeitige und häufige Bereitstellung von Arbeitssoftware, eine hohe Benutzerbeteiligung, Anpassungsfähigkeit und den Abbau von Bürokratie oder Ablenkungen.