Abschließende Überlegungen

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

Wir sind am Ende des Kapitels "Warum Agile Engineering" angekommen. Im vorigen Teil der Serie habe ich gezeigt, warum der Code den wir schreiben, nicht der Flaschenhals der Softwareentwicklung ist. In diesem Teil stelle ich noch einige abschließende Überlegungen zu agiler Arbeitsweise und Agile Engineering an.

Mein Name ist David Tanzer und ich helfe seit fast zwei Jahrzehnten Entwicklungsteams dabei, bessere Software in höherer Qualität schneller zu liefern. Wenn du mehr darüber wissen willst, schau einfach bei devteams.at vorbei.

In der agilen Softwareentwicklung passen wir ständig unsere Pläne an. Deshalb ändert sich die Antwort auf die Frage "Wo gehen wir hin?" immer wieder. Aber sollten wir deshalb ein planungsgetriebeneres Vorgehen bevorzugen, wo wir sicher sein können, dass sich unser Ziel für die nächsten 6-12 Monate nicht ändert? Und wenn ja, unter welchen Voraussetzungen sollten wir das tun?

Mach bitte kurz Pause und schreibe die Antwort auf beide Fragen in deine Notizen. Dafür kannst du dir die aktuelle Notizbuchseite herunterladen und doppelseitig ausdrucken. Diese Seite enthält auch weitere Informationen zum aktuellen Teil der Serie.

Effektive Arbeit

"We are in this for the money", sagt GeePaw Hill in "Five Underplayed Premises of TDD". Das bedeutet, wir müssen schnell und effektiv Software liefern, die einen Wert für unser Unternehmen, die Benutzer und die Kunden generiert. Dafür müssen wir uns immer wieder fragen:

• Woher wissen wir, dass wir an den richtigen Problemen arbeiten?
• Woher wissen wir, dass unsere Software diese Probleme löst?
• Woher wissen wir, dass das Design unserer Software die aktuellen Anforderungen erfüllt?

Optionen und Commitment

Auch wenn ich es in der Eingangsfrage etwas zur Diskussion gestellt habe... Wir arbeiten iterativ und inkrementell. Wir passen unser Vorgehen, unser Backlog und unsere Software immer an die aktuellen Gegebenheiten und Anforderungen an, denn wir wissen, dass sich diese Gegebenheiten und Anforderungen ständig ändern. Und auf diese Änderungen müssen wir kontinuierlich eingehen, sonst bauen wir Software für vorgestern.

Dabei spielen folgende Fragen für uns eine Rolle:

• Woher wissen wir, dass das Design unserer Software an zukünftige Anforderungen anpassbar ist?
• Woher wissen wir, ob sich die Anforderungen geändert haben?
• Woher wissen wir, welche Teile unserer Software an geänderte Anforderungen angepasst werden müssen?

Das Richtige zur richtigen Zeit

Da sich unser Plan und unser Ziel ständig ändern, müssen wir aufpassen, dass wir nicht im Chaos enden—was ja oft auch ein Kritikpunkt an agilem Vorgehen ist. Einem Plan zu folgen, der sich ständig ändert, ist nicht einfach. Aber wir ändern den Plan ja nicht einfach zum Spaß; Wir ändern ihn, weil sich unsere Gegebenheiten oder Voraussetzungen geändert haben, weil sich die Welt weitergedreht hat. Oder, weil sich Annahmen, die wir früher getroffen hatten, als falsch herausgestellt haben.

Wir haben also gar keine andere Alternative, als einem Plan zu folgen, der sich immer wieder ändert. Und dafür müssen wir auch ständig neue Antworten auf folgende Fragen finden:

• Woher wissen wir, dass wir genug gemacht haben?
• Woher wissen wir, woran wir als nächstes arbeiten sollen?
• Woher wissen wir, was noch alles zu tun ist?

Inspect and Adapt

Im Allgemeinen finden wir die Antworten auf diese Fragen durch iteratives Arbeiten und duch "Inspect and Adapt". Wir planen einen kleinen Schritt und überlegen uns das erwartete Ergebnis, führen diesen Schritt aus, überprüfen das Ergebnis und ändern unsere Vorgehensweise anhand dessen, was wir durch die Überprüfung gelernt haben.

Das ganze machen wir auf verschiedenen Ebenen, zum Beispiel innerhalb eines Scrum-Sprints. Zuerst planen wir den Sprint, dann implementieren wir software. Im Review und in der Retrospektive prüfen wir die Ergebnisse und in der Retrospektive und im nächsten Planning passen wir unsere Vorgehensweise wieder an. Aber auch in unserer täglichen Arbeit und auf vielen anderen Ebenen gibt es diese iterativen und inkrementellen Zyklen: Plan-do-check-act.

Auch viele Praktiken des Agile Engineering enthalten einen iterativen Zyklus und unterstützen uns bei inspect and adapt.

Und dieses—in kleinen Schritten zu arbeiten und ständig zu überprüfen, ob die Richtung noch stimmt—ist immer eine bessere Vorgehensweise, als über längeren Zeitraum einen Plan zu verfolgen. Denn viele der Annahmen, die wir am Anfang treffen, werden immer suboptimal oder sogar falsch sein. Oder, wie Dave Farley es sagt:

If you apply agile tools or ideas, but don't use them to inspect and adapt frequently, you AREN'T being agile!

-- Dave Farley

Und jetzt?

In diesem Kapitel "Warum Agile Engineering" habe ich in 7 Teilen verschiedene Überlegungen zu agiler Arbeitsweise angestellt:

• In "Ziele der agilen Entwicklung" habe ich erklärt, was die Werte und Prinzipien der agilen Softwareentwicklung sind, wie sie mit einer "agilen Doctrin" zusammenhängen und wie diese Dinge die Engineering-Kultur in einem Unternehmen beeinflussen—oder beeinflussen sollten.
• In "Weniger, dafür früher, ist besser" ging es um Geschwindigkeit und warum früher fast immer besser ist.
• In "Mean Time to Feedback" habe ich erklärt, warum wir die mittlere Zeit, bis wir gutes Feedback bekommen, optimieren sollten.
• In "Doing Things Right vs. Doing the Right Thing" ging es um Effektive Arbeit und die richtige Balance zwischen diesen beiden Dimensionen.
• In "Agil - Das funktioniert doch gar nicht" ging es um häufige Kritikpunkte an agiler Softwareentwicklung und um meine Sichtweise und Kritik an diesen Kritikpunkten.
• In "Jetzt tun vs. der richtige Zeitpunkt" habe ich über Optionen, Commitment und schnelles Handeln gesprochen.
• Und in "Der Code ist nicht der Flaschenhals" ging es um die eigentlichen Constraints in der Softwareentwicklung: Konsistent hohe Qualität zu liefern und selbst und gemeinsam zu Lernen.

In der agilen Softwareentwicklung ändert sich die Antwort auf die Frage "Wo gehen wir hin?" immer wieder. Aber sollten wir deshalb ein planungsgetriebeneres Vorgehen bevorzugen?

Nein, einen Plan über einen längeren Zeitraum zu verfolgen ist niemals der beste Weg. Alles, was wir am Anfang dieses Zeitraums festlegen, ist mit ziemlicher Sicherheit falsch, oder mindestens suboptimal. Selbst, wenn es manchmal funktionieren kann, ein Projekt zu definieren und nach einem Jahr Software zu liefern, die gewinnbringend eingesetzt werden kann...

• Die Wahrscheinlichkeit dafür, dass es funktioniert, sinkt mit der Länge des Projekts
• Es wäre noch gewinnbringender, die falschen und suboptimalen Annahmen vom Anfang des Projekts iterativ und inkrementell richtigzustellen

Im nächsten Kapitel werde ich einen kuzen Überblick über Praktiken des Agile Engineering geben. Und in den darauffolgenden Kapiteln werde ich zeigen, wie man diese Praktiken einsetzen kann, um die Ziele der agilen Softwareentwicklung zu erreichen.

Weitere Informationen

• Aktuelle Notizbuchseite
• GeePaw Hill, Five Underplayed Premises of TDD
• Dave Farley, Agile Uncertified | Philosophy Over Rituals