Best Practice

RETROSPEKTIVE

NUTZEN DER RETROSPEKTIVE

Retrospektiven unterstützen Weiterentwicklung. Hier gibt es die Zeit, um die Stärken zu fördern und Lösungen für Probleme zu entwickeln.

Dabei kann es um Themen der Zusammenarbeit im Team gehen, technische Probleme, Prozess-Defizite, produktspezifische Themen, Akkzeptanz, Wertschätzung, Kommunikation innerhalb und/oder außerhalb des Teams etc.

ABLAUF EINER RETROSPEKTIVE

Der Ablauf einer Retrospektive verläuft in der Regel in fünf Phasen:

  • Intro: Ankommen, Klärung der Ziele zur Retro, evtl. überprüfen der Maßnahmen der letzten Retrospektive
  • Daten sammeln: Was ist gut gelaufen?, was schlecht?, welche Fragen und Ideen gibt?, wem kann/möchte ich danken?
  • Einsichten gewinnen: Stärken und Probleme analysieren und mögliche Lösungsansätze erarbeiten
  • Maßnahmen entwickeln: SMARTE Ziele, die der Verbesserung der Arbeitsabläufe dienlich sind.
  • Checkout: Feedback zur Retrospektive

MÖGLICHE FRAGEN

  • Wie geht es uns?
  • Was läuft gut? Warum?
  • Was läuft schlecht? Warum?
  • Sind wir stolz auf unser Produkt?
  • Würde ich wieder so vorgehen?
  • Welche Risiken gibt es?
  • Haben wir alle notwendigen Infos?
  • Was brauche ich, um die Aufgabe zu meistern?
  • Was behindert mich? Was brauche ich stattdessen?
  • Wem kann ich "Danke" sagen? Wer hat mich unterstützt?

FAKTOREN FÜR EINE HILFREICHE RETROSPEKTIVE

Natürlich ist es oft hilfreich Ereignisse der Vergangenheit zu analysieren, um für die Zukunft daraus zu lernen. Gleichzeitig wissen wir Menschen meist sehr gut, was wir nicht wollen. Allerdings fällt es uns dann nicht leicht zu formunlieren, was wir "stattdessen" wollen. Ein angstfreies und vertrauensvolles Umfeld sind eine wichtige Voraussetzung, dass in einer Retrospektive Offenheit gelebt werden kann. Wichtig hierfür ist eine konstruktive Team- und Fehlerkultur.

Literatur

SCHÄTZEN & PLANEN

Wenn du willst, dass Gott lacht - mach einen Plan!

PLANEN

Das Leben ist Veränderung. Veränderung gehört dazu und ist absolut unvermeidlich.

Dies trifft auch demzufolge auf die Projektarbeit zu. Je weiter Beginn und Ende einer Unternehmung auseinander liegen desto weniger zuverlässig können wir beschreiben, was geschehen wird. Die klarsten Aussagen können wir tätigen, wenn wir nah an der Umsetzung sind und möglichst viele Informationen dazu haben.

Aus diesem Grund wird im agilen Umfeld vom "last responsible moment" gesprochen. Dies bedeutet, mit der Planung so lange wie nur möglich zu warten, um die Chance zu erhalten so viel wie möglich Informationen zu haben, die wir benötigen.

Ebenso erleben wir immer wieder, dass das was heute wichtig für uns ist, nach einiger Zeit an Wichtigkeit verliert. Unsere Vorlieben haben sich geändert, die Umstände sind anders geworden, wir haben dazugelernt und gehen andere Wege, als wir uns zuvor vorgestellt haben. Alle "alten" Pläne werden nutzlos.

Aus diesem Grund ist es eher sinnvoll, Planungen iterativ, in kleineren Zyklen zu wiederholen und weiter zu detaillieren. Dabei erhalten wir immer mehr Informationen und können auf Veränderungen ohne Verschwendung eingehen.

CYNEFIN

Das cynefin-Modell versucht die Komplexität deutlich werden zu lassen.

Einfach

Über einfache Zusammenhänge braucht man oft nicht viel nachzudenken. Ursache-Wirkung ist meist klar. Diese Tätigkeiten finden wir im Tagesgeschäft wieder. 

Kompliziert

Komplizierte Zusammenhänge kann man durch analytische Betrachtung verdeutlichen. Ursache-Wirkung ist analysierbar und die Tätigkeiten sind Planbar. Hierzu gehört z.B. auch der Bau von Flugzeugen.

Komplex

Software-Entwicklung und Erfindungen werden zu den komplexen Tätigkeiten gezählt. Ursache-Wirkung kann meist erst im nachhinein bestimmt werden. Hierbei helfen emergente Praktiken.

Chaos

Chaotische Zustände finden sich bei einem Feuer oder bei Experimenten wieder. Hier sind eine Ursache-Wirkung Prinzipien im System nicht sichtbar. Hier kommen meist ganz neue, innovative Praktiken zum Einsatz.

SCHÄTZEN

Agile Schätzverfahren nutzen meist abstrakte Schätzweisen, was schneller geht als her-kömmliche Schätzweisen geht. Das menschliche Hirn tut sich leichter Dinge in "kleiner" oder "größer als" eine Bezugsgröße einzustufen als dagegen detailliertere Unterschiede festzulegen.

Streichen der Wohnung

Dies wird am Beispiel "Streichen der Wohnung" deutlich. Herkömmliches Schätzen geht hier gerne davon aus, wieviel Quadratmeter die einzelnen Zimmer haben und wie lange man dafür braucht, um sie zu streichen. Dabei bestehen vorallem zwei Probleme. Zum einen ist eine zeitliche Abschätzung immer auch abhängig von den Fähigkeiten des Handwerkers. Gleichzeitig sagt die Anzahl der Quadratmeter noch nichts über die Rahmenbedingungen, wie Zustand der Wände, Materialen etc. aus. Muss nun noch ein anderer Handwerker als der Schätzer die Wohnung malern, wird das Ergebnis sicherlich von der Schätzung abweichen.

Beim abstrakten Schätzen, können sich die Schätzer darauf einigen, wie groß die Räume im Verhältnis zu einer Bezugsgröße sind. Z.B. die Küche ist mit 10 qm die Bezugsgröße (= 2 Punkte), das Schlafzimmer ist doppelt so groß als die Küche = (4 Punkte), das Wohnzimmer ist dreimal so groß ( = 6 Punkte), während das Bad nur halb so groß ist, jedoch viele hinderliche Leitungen hat (= 1 Punkt + 1 "Problem"-Punkt). Diese Einschätzung der Wohnung wird sich nicht ändern, egal welches Team nun antritt. Ein Team mit vielen Lehrlingen wird wahrscheinlich länger brauchen als eines mit langjährig erfahrenen Mitarbeitern.

Wie lange das Streichen nun dauert kann über die Velocity bestimmt werden. Die Velocity ist die Anzahl der Punkte, die das Team in einer best. Zeit abarbeiten kann. Und je nach Teamzusammensetzung wird sich eine andere Velocity einstellen.

PRIORISIEREN

Im agilen Umfeld wird der Priorisierung ein wichtiger Stellenwert eingeräumt. Wichtig dabei ist, die wichtigsten Arbeiten zuerst zu erledigen. Dies bedeutet, dass wir diese Ergebnisse schneller nutzen können und darüber hinaus die Freiheit haben, Projekte früher zu beenden, ohne dass ein großer Werteverlust eintritt. Am Beispiel des "Streichen der Wohnung" würde es Sinn machen, das Wohnzimmer vor der Abstellkammer zu renovieren.

Eine einfache Priorisierungsmethode ist die von Stephen Covey bzw. ursprünglich von Eisenhower.

TEST-DRIVEN-DEVELOPMENT (TDD)

TESTAUTOMATISIERUNG

Zur Verbesserung und Erhaltung von Qualität sind automatisierte Tests eine wichtige Praktik. Veränderungen und Code-Erweiterungen müssen so getestet werden, dass auch bestehende Features noch so funktionieren wie vor der Veränderung. Testautomatisierung macht Fehler schnell sichtbar.

PAIRPROGRAMMING

Pairprogramming (= Zusammenarbeiten zu zweit) ist eine wichtige Praktik, die aus dem "eXtreme Programming" kommt. Die Zusammenarbeit führt zu Qualtitätsverbesserung, weil nach dem 4-Augen-Prinzip Fehler schneller gefunden werden. Außerdem dient Pairprogramming dem Wissenstransfer. Know-How wird im Team weitergegeben, Einarbeiten neuer Mitarbeiter wird effektiver.

Pairprogramming fördert die Kommunikation im Team und erhöht den Spaß-Faktor.

Wikipedia: Pairprogramming

REFACTORING

Refactoring bedeutet eine Veränderung der internen Software-Struktur, ohne deren Verhalten zu verändern.

WANN IST REFACTORING SINNVOLL?

Agiles Arbeiten bedeutet permanetes Refactoring. Dies hält den Quellcode sauer und verhindert veraltern. Mit regelmäßigen Refactoring bleibt die Aufwandskurve niedrig und dient der Kombination von Feature und Qualität.

So bleibt der Quellcode leichter verständlich und macht somit die Erweiterung einfacher.

BAD SMELLS

Martin Fowler hat eine umfangreiche Übersicht entwickelt

CONTINUOUS INTEGRATION

CI-NUTZEN

Hierzu hat Martin Fowler einen wunderbaren Artikel erstellt.

CI-PRAKTIKEN

Hierzu hat Martin Fowler einen wunderbaren Artikel erstellt.

CI-EINFÜHRUNG

Hierzu hat Martin Fowler einen wunderbaren Artikel erstellt.