Inhalt
Agile Softwareentwicklung ermöglicht uns, wenn sie funktioniert:
- Als Organisation flexibler auf geänderte Marktanforderungen und Innovationen der Konkurrenz zu agieren
- Als Entwickler mehr Verantwortung und Gestaltungsmöglichkeiten zu haben
- Deployments, Fehlerbehebung und Betrieb stressfreier zu gestalten
- Keine großen Releases mit Überstunden und Death-Marches mehr zu haben
- Mit weniger Aufwand mehr Wert zu liefern und damit früher Returns für die investierte Zeit und Resourcen zu bekommen
In dieser Serie, "Quick Glance At: Agile Engineering", geht es darum, wie wir das erreichen: Was Agile Engineering eigentlich ist, und wie es uns helfen kann, unseren Kunden wertvollere Software in höherer Qualität früher zu liefern.
Warum Agile Engineering?
Der Überbegriff "Agile Engineering" beschriebt Praktiken und Vorgehensweisen, die uns dabei helfen, die Ziele der agilen Softwareentwicklung zu erreichen.
Peer-to-peer player
für bessere Performance
- Ziele der agilen Entwicklung: Um zu verstehen, wie wir im Engineering die Agilität der Softwareentwicklung unterstützen können, müssen wir uns zuerst darüber unterhalten, welche Ziele die agile Softwareentwicklung eigentlich erreichen will.
- Weniger, dafür früher, ist besser: Iterative Entwicklung, kleine Arbeitspakete, DevSecOps, Continuous Delivery: Alles läuft darauf hinaus, dass wir schneller liefern können. Warum ist das wichtig? Weil kleinere Lieferungen, schneller geliefert, immer besser sind als größere.
- Mean Time to Feedback: Validate every step - Überprüfe jeden Schritt. Wir brauchen in der agilen Softwareentwicklung überall schnelles und gutes Feedback. Die Zeit, bis wir brauchbares Feedback zu unserer Arbeit bekommen - die Mean Time to Feedback - ist entscheidend.
- Doing things right vs. Doing the right things: Wie gut verstehen wir die Bedürfnisse unserer Benutzer*innen? Wie sehr arbeiten wir an den richtigen Problemen? - 'Doing the right things'. Wie lange brauchen wir, um ein Feature zu implementieren? Wie gut sind wir darin, diese Probleme unserer Benutzer*innen zu lösen? - 'Doing things right'.
- Agil? Das funktioniert doch gar nicht!: Gegen agile Softwareentwicklung gibt es viele Vorbehalte. Manche davon kritisieren ein bestimmtes Framework, wie zum Beispiel Scrum oder SAFe; Andere wiederum agile Vorgehensweisen und Praktiken oder sogar agile Prinzipien und Werte. In diesem Teil gehe ich auf einige dieser Kritikpunkte ein.
- Jetzt tun vs. der richtige Zeitpunkt: Move fast and break things oder Move slow and mend things? Besser jetzt etwas liefern oder Optionen und Möglichkeiten für die Zukunft schaffen? Welche Aufgaben müssen wir sofort erledigen und was kann warten?
- Der Code ist nicht der Flaschenhals: Wie produktiv ist eine Softwareentwickler*in? Wie produktiv ist ein Team? Oft verbinden wir damit vielleicht nur unterbewusst, wieviel Code sie produziert haben. Also wieviele Zeilen sie geschrieben haben oder wieviele Function Points sie geliefert haben. Aber spielt gar keine so große Rolle: Der Code ist nicht der Flaschenhals.
- Abschließende Überlegungen: Wir sind am Ende des Kapitels 'Warum Agile Engineering' angekommen. In diesem Teil stelle ich noch einige abschließende Überlegungen zu agiler Arbeitsweise und Agile Engineering an.
Die Prakitken: Ein Überblick
Im aktuellen Kapitel 'Die Praktiken: Ein Überblick' wird es etwas technischer als in den vorigen Teilen: In sieben Teilen werde ich genauer auf die einzelnen Praktiken und Vorgehensweisen eingehen.
Peer-to-peer player
für bessere Performance