Um das agile Manifest - die Grundlage aller agilen Vorgehensmodelle
- geht es in der einhunderteinundsechzigsten Episode des
IT-Berufe-Podcasts. TL;DR Aus meiner Prüfungsvorbereitung mit
IT-Azubis kenne ich Fragen zu den Grundlagen agiler
Softwareentwicklung. Das agile Manifest von 2001 setzt den
Schwerpunkt auf Menschen und ihren Austausch, lauffähige Software,
die Zusammenarbeit mit Kund:innen sowie darauf, auf Änderungen zu
reagieren. Prozesse und Werkzeuge behalten dabei ihren Wert, ebenso
wie Dokumentation, Verträge und Pläne. Für dein Projekt hängt das
passende Vorgehen davon ab, wie klar die Anforderungen feststehen
und wie viel sich während der Arbeit verändert. Kapitelmarken
[00:00:00] Einstieg ins agile Manifest [00:01:19] Agilität in
Prüfungen und im Fachgespräch [00:03:19] Herkunft und Bedeutung des
agilen Manifests [00:06:37] Werte und Spielraum für klassische
Vorgehensweisen [00:08:13] Wasserfallmodell und Big Design Up Front
[00:10:44] Veränderte Anforderungen und Folgen für Projekte
[00:13:26] Das magische Dreieck im Projektmanagement [00:14:57]
Wasserfallmodell beim IHK-Abschlussprojekt [00:16:53] Ein
Vorgehensmodell passend zum Projekt wählen [00:17:52] Wortlaut und
Grundgedanke des agilen Manifests [00:19:49] Menschen und ihr
Austausch [00:22:48] Lauffähige Software und Dokumentation
[00:25:19] Zusammenarbeit mit Kund:innen [00:27:26] Werkvertrag und
Dienstleistungsvertrag [00:30:40] Auf Änderungen reagieren und
Pläne anpassen [00:33:27] Den Arbeitsprozess an neue Erkenntnisse
anpassen [00:35:21] Änderungen während eines Scrum-Sprints
[00:37:26] Die vier Werte und ihre Bedeutung für IT-Berufe
[00:39:27] Bekannte Unterzeichner:innen [00:42:09] Buch zum
Einstieg und weiterführende Links Inhalt Das agile Manifest wurde
2001 von mehreren namhaften Softwareentwicklern aufgestellt als
Gegenentwurf zum bisherigen Vorgehen bei der Softwareentwicklung.
Es bildet die Grundlage für alle agilen Projektmanagementmethoden
und Softwareentwicklungsprozesse wie z.B. Scrum und Extreme
Programming. Das Manifest verbietet nicht die klassisches
Vorgehensweise, zeigt aber bessere Alternativen auf, um zum
gewünschten Ergebnis zu kommen. Wasserfall und "klassische"
Softwareentwicklung BDUF: Big Design Up Front. Lange Planungsphase
mit viel Dokumentation, danach "standardisierte" Entwicklung als
"Abarbeitung" des Designs. Umgang mit sich ändernden Anforderungen
ist schwierig, weil das System zu starr ist, um darauf zu
reagieren. Durchschnittlich ändern sich aber 2% der Anforderungen
an Projekte pro Monat. Folge: Projekte verzögerten sich, wurden zu
teuer oder lieferten nicht das gewünschte Ergebnis ("magisches
Dreieck": Kosten, Zeit, Qualität). Achtung: Wasserfall ist nicht
immer schlecht. Es gibt auch Projekte, die sich gut dafür eignen
(insb. das IHK-Abschlussprojekt). Agiles Manifest Siehe Manifesto
for Agile Software Development. We are uncovering better ways of
developing software by doing it and helping others do it. Through
this work we have come to value: Individuals and interactions over
processes and tools Working software over comprehensive
documentation Customer collaboration over contract negotiation
Responding to change over following a plan That is, while there is
value in the items on the right, we value the items on the left
more. Menschen sind wichtiger als Prozesse Lauffähige Software ist
wichtiger als Dokumentation Zusammenarbeit ist wichtiger als
Vertragsverhandlungen Reaktion auf Änderungen ist wichtiger als das
Verfolgen eines Plans Einige Unterzeichner Kent Beck: Begründer des
Extreme Programming, Entwickler von JUnit, "Erfinder" von Test
Driven Development (siehe Test Driven Development: By Example*)
Robert C. Martin: Autor von Clean Code*, Entwickler von FitNesse
Ward Cunningham: "Erfinder" des Wikis Martin Fowler: Autor von
Refactoring* und Patterns of Enterprise Application Architecture*
Ken Schwaber: "Erfinder" von Scrum Literaturempfehlungen Eine gute
Einführung in agile Softwareentwicklung liefert das Buch Agile
Softwareentwicklung* von Henning Wolf und Wolf-Gideon Bleek. *
Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts
Manifesto for Agile Software Development Zusammenfassung
Hintergrund und Prüfungsbezug Als ich im Frühjahr 2021 zwei
IT-Azubis bei ihrer Prüfungsvorbereitung begleitet habe, begegnete
mir eine Frage zu den Eigenschaften agiler Softwareentwicklung.
Auch in deiner Abschlussprüfung oder im Fachgespräch als
Fachinformatiker:in Anwendungsentwicklung kann es darum gehen,
warum du dein Projekt auf eine bestimmte Weise durchgeführt hast.
Dafür brauchst du die Grundlagen des gewählten Vorgehens. Auf
agilemanifesto.org findest du das agile Manifest, das erfahrene
Softwareentwickler:innen 2001 aus ihrer praktischen Arbeit heraus
formuliert haben. Seine vier Werte bilden die Grundlage für agile
Vorgehensweisen. Dazu gehören beispielsweise Scrum und Extreme
Programming; auch Feature-Driven Development greift diese Ideen
auf. Die Aussagen sind allgemein gehalten, während konkrete
Vorgehensweisen daraus Regeln für den Arbeitsalltag ableiten. Wie
es zum agilen Manifest kam Beim Big Design Up Front, kurz BDUF,
werden die Anforderungen und der Entwurf vor dem Programmieren
ausführlich ausgearbeitet. Im beschriebenen Wasserfallmodell
entstehen zunächst Lasten- und Pflichtenhefte sowie Modelle, die
den Entwickler:innen anschließend vorgeben, was sie umsetzen
sollen. Während eines längeren Projekts können neue Gesetze oder
technische Möglichkeiten die Anforderungen verändern. Ebenso können
sich Arbeitsabläufe ändern. Ein umfangreiches, bereits abgestimmtes
Pflichtenheft muss dann überarbeitet und erneut besprochen werden,
was Zeit kostet. Wenn solche Änderungen schwer in den Ablauf
passen, kann sich das Projekt verzögern oder teurer werden. Werden
Termine und Budget eingehalten, kann das fertige Produkt inzwischen
an den Bedürfnissen der Kund:innen vorbeigehen. Im
Projektmanagement beschreibt das magische Dreieck die Zusammenhänge
zwischen Kosten und Zeit sowie der Qualität des Ergebnisses. Aus
Erfahrungen mit solchen Projekten entstanden die vier Werte des
agilen Manifests. Alle darin genannten Aspekte behalten ihren Wert;
die agilen Werte erhalten besonderes Gewicht. Die vier Werte
Menschen und ihr Austausch Wenn eine Anforderung unklar ist, kannst
du direkt bei deinem/deiner Kund:in nachfragen. Zum Projekt gehören
neben den Entwickler:innen auch Designer:innen und weitere
Beteiligte, etwa die Projektleitung oder Fachleute für Datenbanken.
Durch den direkten Austausch lassen sich Missverständnisse früh
klären. Extreme Programming behandelt Kommunikation als zentralen
Wert. Bei Scrum schafft beispielsweise das Daily Scrum regelmäßig
Raum dafür, dass sich das Team abstimmt. Prozesse und Werkzeuge
unterstützen diese Arbeit. Lauffähige Software Am Ende eines
Scrum-Sprints soll dein:e Kund:in lauffähige Software ausprobieren
können. Dabei wird sichtbar, ob die Funktionen zu den Anforderungen
passen und was noch fehlt. Wenn du deine Zeit einteilen musst,
erhält das Programmieren deshalb besonderes Gewicht. Zur fertigen
Software gehört auch die Dokumentation, damit dein:e Kund:in mit
ihr arbeiten kann. Bei Scrum kann sie Teil der Definition of Done
sein, die festhält, wann die Arbeit als fertig gilt. Zusammenarbeit
mit Kund:innen Während sich Anforderungen verändern, brauchst du
regelmäßigen Kontakt zu deinem/deiner Kund:in. Gemeinsam lässt sich
besprechen, welche Funktionen gebraucht werden und wie das Projekt
weitergeht. Verträge bilden dafür einen Rahmen. Bei einem
Werkvertrag wird ein bestimmtes fertiges Produkt vereinbart,
einschließlich Preis und Termin. Ändern sich die Anforderungen,
können daraus zusätzliche Abstimmungen oder Konflikte entstehen.
Ein Dienstleistungsvertrag sieht vor, dass geleistete Arbeit
beziehungsweise Entwickler:innenstunden bezahlt werden. Für das
beschriebene agile Vorgehen bietet diese Vertragsform Spielraum,
etwa um den Umfang der Arbeit oder das Team anzupassen. Wie teuer
das fertige Produkt wird, lässt sich dabei vorab schwerer
bestimmen. Auf Änderungen reagieren Wenn du während des Projekts
neue Erkenntnisse gewinnst, muss dein Plan angepasst werden können.
Auch bei agilen Projekten planst du, welche Anforderungen du
bearbeiten möchtest und wie du dabei vorgehst. Agilität bedeutet
Beweglichkeit. Sie betrifft sowohl die Software als auch den
Arbeitsprozess. Beispielsweise kann ein Team seine Sprintlänge
verändern, wenn die bisherige Länge zu den Anforderungen des
Projekts schlecht passt. Damit Entwickler:innen konzentriert
arbeiten können, gibt es weiterhin verlässliche Arbeitsphasen. Bei
Scrum werden Änderungen gewöhnlich für die nächste Iteration
berücksichtigt. Dringende Ereignisse, etwa wenn ein:e Kund:in das
Projekt beendet, können ein sofortiges Eingreifen erfordern. Das
Vorgehen für dein Projekt wählen Für kurze Projekte mit klar
festgelegten, stabilen Anforderungen kommt das Wasserfallmodell
infrage. Beim damals beschriebenen IHK-Abschlussprojekt mit 70
Stunden empfehle ich dieses Vorgehen, weil der Zeitraum kurz und
der Umfang eng begrenzt ist. Einzelne Schritte können wiederholt
werden: Du kannst beispielsweise ein Mock-up dem Fachbereich zeigen
und anhand der Rückmeldung überarbeiten. Wenn dein Projekt länger
dauert oder das gewünschte Ergebnis noch offen ist, bietet agiles
Arbeiten Raum für neue Erkenntnisse. Auch außerhalb der
Softwareentwicklung finden agile Vorgehensweisen Anwendung, etwa in
der Administration oder bei der Daten- und Prozessanalyse. Bekannte
Unterzeichner:innen Aus dem Kreis der Unterzeichner:innen greife
ich fünf Personen heraus: Kent Beck begründete Extreme Programming,
entwickelte JUnit mit und schrieb Test-Driven Development by
Example. Robert C. Martin, auch Uncle Bob genannt, ist der Autor
von Clean Code. Ward Cunningham entwickelte das erste Wiki. Martin
Fowler schrieb Refactoring sowie Patterns of Enterprise Application
Architecture. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.