Agile Scrum Handbuch – 3. Ausgabe

Nader K. Rad

• Verlag: Van Haren Publishing
• Jahr: 2022
• ISBN:
  9789401808460
• Auflage: 3
• Thema: Bildung
• Thema: Bildung Allgemein

Dieses Buch ist ein einfacher Leitfaden für alle, die etwas über das Agile Konzept und das Scrum Framework erfahren wollen undsich nicht mit den DOs und DON'Ts bzw. den Klischees zufriedengeben, sondern wirklich verstehen möchten, welche Gründe für die verschiedenen Vorgehensweisen sprechen;nicht nur an den neuesten Trends interessiert sind, sondern die Diversität und Bandbreite an Ideen und Philosophien in diesem Bereich kennen und verstehen möchten.Das Buch deckt folgende Inhalte ab: Grundlegende Konzepte: Das erste und das letzte Kapitel des Buchs beschäftigen sich mit der Bedeutung und Dynamik von Agilen Projekten. Sie schaffen das Fundament, das Sie benötigen, um Details zu verstehen und sich in Agilen Projekten zurechtfinden zu können.Frameworks: Das Kapitel zu Scrum geht auf alle Einzelheiten dieses äußerst beliebten Frameworks ein. Wer mit Agilen Projekten zu tun hat, sollte Scrum kennen und verstehen. Das Gleiche gilt für Kanban, das ebenfalls in einem eigenen Kapitel näher untersucht wird.Praktiken: Die Kapitel zu Crystal, eXtreme Programming und DSDM® erkunden die gängigsten Agilen Praktiken und Techniken mit Hilfe dieser Methoden.

1. Das Agile Konzept

Um Agile ranken sich viele Mythen und Legenden. Dies gilt nicht zuletzt auch für die Antwort auf die grundlegendste aller Fragen: Was versteht man unter Agile?

Die Antworten darauf sind häufig missverständlich wie: „Agile ist eine Einstellung, ein „Mindset“. Aber diese Aussage ist falsch. Agile ist kein Mindset. Richtig ist dagegen, dass Agile ein bestimmtes Mindset voraussetzt. Bezeichnet man Agile als Mindset, so führt dies in der Praxis lediglich dazu, dass manche Mitarbeiter: innen machen, was sie wollen und es Agile nennen, weil dies gerade in Mode ist.

Ein anderes auf diesem Gebiet weit verbreitetes Problem ist die Illusion des externen Feinds. Wer weiß, wie autoritäre Systeme funktionieren, weiß auch, dass ein solches System immer ein Feindbild braucht, um von den Schwächen im eigenen System abzulenken. Ein Feindbild schafft ein gemeinsames Ziel und täuscht darüber hinweg, dass es keine echten, erreichbaren internen Ziele gibt. Viele Agile-Fachleute gehen leider ähnlich vor, in der Regel zum persönlichen Vorteil einiger weniger Führungskräfte.

Die beste Strategie im Berufsleben ist jedoch, für alles offen zu sein und von allen Ansätzen und Methoden zu lernen. Etwas zum Kult zu erheben ist nie förderlich. Dies deckt sich auch mit dem ersten Grundsatz im Leitfaden Nearly Universal Principles of Projects: https://nupp.guide

Sehen wir uns nun also an, was Agile wirklich bedeutet.

1.1 Die verschiedenen Vorgehensweisen in der Softwareentwicklung

In der Softwareentwicklung werden folgende Schritte entweder für einzelne Features oder für die gesamte Softwarelösung auf die eine oder andere Weise durchgeführt:

• Analyse

• Design (Entwurf)

• Realisierung

• Integration

• Test

Selbstverständlich können diese Schritte auch anders bezeichnet, in weniger Schritte zusammengefasst oder in mehr Schritte aufgeteilt werden. Alles ist möglich. Zur Abgrenzung von Managementprozessen, wie Planung und Überwachung, werden diese Schritte auch als Delivery-Prozesse bezeichnet.

Wie also werden Sie diese Prozesse organisieren und durchführen? Überlegen Sie sich ein paar Möglichkeiten, bevor Sie den Rest dieses Kapitels lesen.

1.1.1 Der prädiktive Ansatz

Wahrscheinlich haben Sie schon ein paar Möglichkeiten im Kopf, die alle zu einer der zwei generischen Formen gehören, die wir im Folgenden erörtern werden. Diese Optionen bezeichnet man übrigens auch als Lebenszyklus der Entwicklung oder Entwicklungsverfahren.

Die Abbildung unten zeigt einen generischen Lebenszyklus der Entwicklung.

In diesem Lebenszyklus wird jeder Prozess abgeschlossen, bevor man zum nächsten Prozess übergeht:

1. Zuerst werden alle Anforderungen vollständig analysiert und festgelegt, was die Lösung beinhalten muss.

2. Danach entwirft man die Architektur der Lösung und untersucht, wie sich die Features am besten gestalten lassen.

3. Im Anschluss daran beginnen die Programmierer mit der Realisierung der Einheiten.

4. Die Einheiten werden dann in einer Lösung zusammengeführt.

5. Abschließend wird die gesamte Lösung getestet und eventuelle Fehler werden behoben.

Natürlich können sich diese Schritte auch überlappen. So kann beispielsweise mit der Integration und dem Testen begonnen werden, bevor alle Einheiten vollständig vorliegen. Ein solcher Lebenszyklus mit Überlappungen sieht dann wie folgt aus:

Dieser Lebenszyklus unterscheidet sich nicht grundlegend vom vorherigen Lebenszyklus, da auch in diesem Fall eine sequenzielle Abfolge von Entwicklungsprozessen vorliegt.

Grundvoraussetzung für diese Art von Lebenszyklus ist die anfängliche Analyse, die uns zeigt, was wir bauen müssen. Die Spezifikation, das Design und folglich auch der Plan (Entwurf) liegen bereits im Vorfeld vor. Man spricht daher auch von einer plangesteuerten Entwicklung. Darüber hinaus versuchen wir vorherzusagen bzw. zu prognostizieren, was wir benötigen und wie sich dies realisieren lässt. Deshalb spricht man auch häufig von prädiktiver Entwicklung.

Der prädiktive Lebenszyklusansatz ist bei vielen Projekten, die normale und geeignete Form der Projektentwicklung. So zum Beispiel bei Bauvorhaben. Zuerst erstellt man einen Rohplan oder -entwurf und erst danach folgen dann die optimierten und detaillierten Pläne und Entwürfe. Für andere Projekte dagegen ist diese Vorgehensweise nicht optimal. So zum Beispiel bei typischen Projekten in der IT-Entwicklung. Hier investiert man unter Umständen viel Zeit in die Spezifikation und in die Analyse der Anforderungen, auf denen dann alles weitere aufbaut. Und was passiert dann häufig? Die Kunden sind mit dem Ergebnis nicht zufrieden. Sie wünschen Veränderungen. Aber Veränderungen sind bei diesem Lebenszyklusansatz kostspielig, da möglicherweise alles, was bis zu diesem Zeitpunkt erstellt wurde, geändert werden muss.

In der IT-Branche gilt es als offenes Geheimnis, dass viele Kunden erst wissen, was sie wollen, wenn sie das Produkt sehen. Aber wann bekommen die Kunden das Produkt bei einem prädiktiven Lebenszyklusansatz zu sehen? Richtig erst gegen Ende des Projekts und damit zu einem Zeitpunkt, an dem die Veränderungskosten am höchsten sind.

Die Agile Community bezeichnet prädiktive System in der Regel als Wasserfallsysteme. Diese Bezeichnung ist inzwischen jedoch negativ konnotiert und sollte daher nicht mehr verwendet werden, da dies in einer an sich rationalen Unterhaltung über verschiedene Entwicklungsansätze eine gewisse Voreingenommenheit zur Folge hätte.

1.1.2 Der adaptive Ansatz

Die Probleme, die prädiktive Lebenszyklen bei IT-Entwicklungsprojekten verursachen, lassen sich überwinden, indem wir den Komfort und die Struktur eines prädiktiven Systems zugunsten eines anderen Lebenszyklusansatz opfern, bei dem das Produkt inkrementell entwickelt und dabei immer wieder gemeinsam mit den Kunden und Usern (Benutzern und Benutzerinnen) überprüft wird. Diesen Luxus bietet uns die IT-Entwicklung im Gegensatz zu vielen anderen Bereichen. Denken Sie nur einmal an ein Bauprojekt. Bei einem Bauprojekt gibt es keine sinnvollen Inkremente und das Produkt ist erst am Ende des Projekts einsatzfähig.

Fairerweise muss hier jedoch gesagt werden, dass sie bei einem Bauvorhaben zwar keine Inkremente entwickeln können, dafür aber beim Bau eines Krankenhauses, ganz gleich wie viele Änderungen sie auch vornehmen, am Ende immer ein Krankenhaus entsteht und nicht zum Beispiel ein Freizeitpark. In der IT-Entwicklung dagegen, kann es durchaus vorkommen, dass sie im übertragenen Sinn mit dem Bau eines Krankenhauses beginnen und am Ende kommt eine Art Freizeitpark heraus.

Machen wir uns also mit einem Lebenszyklusansatz wie in der Abbildung unten dargestellt die Tatsache zu Nutze, dass bei IT-Entwicklungsprojekten Inkremente geliefert werden können

Bei diesem Lebenszyklus gibt es keine wirklichen Prognosen. Anstatt das Produkt detailliert zu planen (und sich auf den Plan oder Entwurf zu verlassen), werden in kurzen Iterationen Inkremente des Produkts erstellt. Jede Iteration konzentriert sich dabei auf ein paar vielversprechend erscheinende Features. Wir bauen ein Inkrement, stellen es den Kunden und Usern vor, holen ihr Feedback dazu ein und entscheiden dann, was wir in der nächsten Iteration tun. Wir treffen also keine Vorhersagen mehr, sondern setzen das Projekt fort, indem wir es an das Feedback anpassen (adaptieren). Dies entspricht einem adaptiven Lebenszyklusansatz. „Agile” ist die populäre Bezeichnung für adaptive Systeme.

Um ein Inkrement zu erstellen, müssen alle Entwicklungsprozesse innerhalb eines bestimmten Zeitraums ausgeführt werden. Im nächsten Zeitraum wird das Ganze dann wiederholt bzw. iteriert. Daher bezeichnet man diese Zeitspannen auch als Iterationen und diese Art der Entwicklung als iterative Entwicklung. In der iterativen Entwicklung wird jeder Prozess (wie z. B. das Design) nicht nur einmal für das Produkt ausgeführt, sondern für verschiedene Elemente des Produkts wiederholt, d. h. mehrfach ausgeführt.

Die Entwicklung in Iterationen und die Lieferung in Inkrementen erfolgen in der Regel in Kombination.

1.1.2.1 Iterationen mit festgelegtem Umfang versus Iterationen mit festgelegter Dauer

Was ist Ihrer Meinung nach vorzuziehen, Iterationen mit festgelegtem Umfang oder Iterationen mit festgelegter Dauer?

Theoretisch ist beides möglich, aber in der Praxis haben sich Iterationen mit festgelegter Dauer bewährt, denn bei Iterationen mit festem Umfang:

• verschwendet man möglicherweise zu viel Zeit auf einzelne Features und auf Schnickschnack. Bei Iterationen mit festgelegter Dauer dagegen ist man kontinuierlich angehalten, sich zuerst auf die Aspekte zu konzentrieren, die am meisten Wert bringen.

• benötigt man in der Regel mehr Zeit als erwartet, um den Umfang abzuschließen. Dies wiederum führt zu längeren Iterationen und reduziert die Zahl der Feedback-Schleifen. Weniger Feedback bedeutet aber auch weniger Adaption.

Daher nutzen fast alle Agilen Methoden Iterationen von fester Dauer, sogenannte Timeboxes, und bestehen meist auf deren Einhaltung. Eine Timebox ist eine Zeitspanne mit einer maximalen (oder festgelegten) Zeitdauer, die unter keinen Umständen verlängert wird (denn wenn man sie einmal verlängert, wird dies gerne zur Gewohnheit).

1.1.2.2 Länge der Iterationen

Wir haben also festgestellt, dass Iterationen zeitlich beschränkt, d. h. timeboxed, sind. Welche Dauer sollte eine solche Iteration demnach haben?

Wir können zwar jederzeit Feedback einholen, aber maßgeblich ist das strukturierte Feedback am Ende jeder Iteration. Bei kürzeren Iterationen erhalten wir demnach häufiger strukturiertes Fe...

Inhaltsverzeichnis

• Cover
• Titelseite
• Impressum
• Inhalt
• 1. Das agile konzept
• 2. Scrum
• 3. Crystal
• 4. Extreme programming (XP)
• 5. Dsdm®
• 6. Kanban
• 7. Die philosophie
• Über den autor
• Index