Agile Patterns – Teil 3/4: Beispiele Crystal Family

Die ersten beiden Teile unserer Blogserie zum Thema Agile Patterns stellten die grundsätzlichen Überlegungen zur Methodensammlung Crystal Family vor. Im heutigen Artikel beschäftigen wir uns mit einigen konkreten Beispielen, die Alistair Cockburn in seinem Buch Crystal Clear: A Human-Powered Methodology for Small Teams nennt. Manche dieser Elemente sind nicht neu – was nichts an deren Wirksamkeit ändert.

Regelmäßige Auslieferung

Es reicht nicht, in Inkrementen zu entwickeln. Natürlich führt iteratives Vorgehen eher zu einer realistischen Planung, da sie sich an kürzeren Zeiträumen orientiert. Der eigentliche Mehrwert liegt aber darin, Feedback von den Anwendern zu erhalten. Und darauf zu reagieren. Werden keine Rückmeldungen von echten Usern eingeholt oder deren Erfahrungen nicht berücksichtigt, bleibt der eigentliche Nutzen, den man erzielen möchte, auf der Strecke. Man könnte es auch so sagen: Sprints einzuführen, ist zuerst Formalismus, auf deren Ergebnisse zu reagieren, das ist Agilität.

Exploratory 360° – in der Projektauftragsphase

Ein initialer Rundumblick, als eigenes Artekfakt, um die wichtigsten Eckdaten innerhalb eines Projektes zu klären und abzustecken.

• Business Value: Welchen konkreten Nutzen erwarten sich wesentliche Stakeholder?
• Requirements: Grobe Aussagen über Funktionalitäten und beteiligte Rollen (High Level Anforderungen)
• Domain Model/Technology Plans: Technische Lösungsansätze, grundsätzliche Machbarkeit
• Project Plan: Grober Zeitplan, gemeinsam mit dem Team erstellt (Blitz Planning, Planning Game)
• Team-Zusammensetzun: Benötigte Rollen / zur Verfügung stehende Personen
• Prozesse/Methoden: Zu wählende Arbeitsweise, abgestimmt auf Projekt und Team

Quick Wins

Das Augenmerk auf soziale Prozesse zu legen, hat zwei Zielrichtungen. Einerseits das Team: Teambildung und Teamentwicklung. Merken, dass man als arbeitsfähige Gruppe funktioniert und etwas erreichen kann. Forming, Storming, Norming, Performing gibt es immer, die Phasen können nicht übersprungen werden. Passend gesetzte Ziele können aber diese Prozesse unterstützen.

Rasch sichtbare Ergebnisse haben noch einen zweiten Wert: Vertrauen. Eine Kennzahl, die sich nicht in Zahlen fassen lässt, aber schwer wiegt. Vor allem, falls sie nicht vorhanden ist. Erhalten Kunden und Anwender nach kurzer Zeit erste Resultate, mit denen sie etwas anfangen, die sie buchstäblich angreifen können, wächst ihre Zuversicht in das Projekt – und die Bereitschaft sich persönlich einzubringen.

Walking Skeleton / Incremental Architecture

Eine kleine, aber durchgängige, beispielhafte Implementierung mit den wichtigsten Architekturkomponenten des zukünftigen Systems. Sie ist nicht vollständig oder robust, aber sie läuft. Mit End-To-End-Funktionalität, als Proof of Concept, als Basis zum schrittweisen Ausbau der gewählten und eingesetzten Technologien.

Information Radiators

Gut sichtbare Informationen zum Projekt, seinem Status, seinem Verlauf. Scrum Boards, Task Boards, Kanban Boards, Produkt-Roadmap, Burndown Charts, am besten haptisch, eventuell elektronisch. Um das Wesentliche in Erinnerung zu behalten bzw. um sich darauf zu konzentrieren.

Methodology Shaping

Aus den Erfahrungen der Projekte lernen, eine Retrospektive im Großen: Am Ende jedes Projekts sammeln, was dort funktionierte, was nicht, was wiederverwendet bzw. vermieden werden sollte. Und zu Beginn eines Projekts anhand des im Unternehmen gesammelten Materials in Form eines gezielten Workshops zu entscheiden, welches davon die wichtigsten Punkte sind, die im künftigen Vorhaben berücksichtigt werden. Da solche Listen bereits nach kurzer Zeit sehr umfangreich sind, ist es wichtig, sich für das nächste Projekt auf einige wenige, aber relevante Elemente zu konzentrieren.

Retrospektive

Nicht nur Befindlichkeiten abholen, sondern Ergebnisse schaffen. Am besten mit einem Canvas/Poster, bestehend aus drei Punkten:

• Keep These – Was soll beibehalten werden?
• Try These – Was versuchen wir zu ändern?
• Problems – Wir können nicht alle Probleme auf einmal lösen. Aber welche haben wir?

Process Miniature

Eine Lerntechnik – für neue Teammitglieder. Die anzuwendenden Prozesse anhand eines Mini-Beispiels praktisch durchführen. Vom Beginn einer Tätigkeit oder eines Sprints bis zur Auslieferung, z. B. innerhalb eines Zeitraums von 2 Stunden. Um das Procedere praktisch auszuprobieren und vollständig zu verstehen („Beim Einchecken muss ich welche Option in welchem Fall wählen?“).

Side-by-Side Programming

Eine kostenschonendere Variante als Pair-Programming. Zwei Entwickler arbeiten nicht an einem Bildschirm, sondern unmittelbar nebeneinander, jeweils an ihrer Aufgabe, aber so nah, dass sie jeweils auch auf den benachbarten Schirm schauen können. Das Prinzip der engen Kommunikation (osmotic communication) wird so möglich. Benötigt der eine Entwickler vom anderen Unterstützung oder hat eine Frage, kann das auf natürliche Weise ohne größeren Aufwand quasi nebenbei geschehen.

Burn Charts & Iceberg-List

Welche hoch priorisierten Elemente des Backlogs gehen sich bis zur nächsten Release aus? Wenn die Anforderungen sich oft ändern, ein nützliches Werkzeug, um anhand von Business Value und Entwicklungszeiten den Inhalt einer Release zu planen. Im Detail beschrieben unter: http://alistair.cockburn.us/Earned-value+and+burn+charts

Die Beispiele stammen von der ebengenannten Seite:

Wie geht man mit Burn-Charts um, wenn Anforderungen dazu kommen? Auch hier zeigt Cockburn zwei Möglichkeiten, um die erfolgten Änderungen nachvollziehbar zu dokumentieren:

Agile Patterns?

Cockburn führt noch eine Reihe weiterer Work Products oder Techniken an, die bei der Projektarbeit behilflich sein können.

• Project Map (Dependencies) – was ist in welcher Reihenfolge auszuliefern
• Actor-Goal-List
• Release Plan: Actor-Goal-Release, Feature-Value-Release
• Risk List
• User-Role-Model
• Blitz Planning
• Essential Interaction Design
• uvm.

Einige der zuvor angeführten Artefakte oder Praktiken sind inzwischen in der agilen Welt selbstverständlich, manche kennen wir ebenso aus klassischen Projekten. Wir könnten einige von ihnen genauso gut als Project Patterns, Best Practice oder dergleichen bezeichnen. Seine Ziele sorgfältig zu formulieren, Risiken zu sammeln, auf soziale Faktoren zu achten – natürlich gab es das auch schon vor dem Agilen Manifest.

Es wäre nicht zielführend, auf dieses oder jenes zu verzichten, weil es einen Stempel trägt, als klassisch oder als agil klassifiziert. Stellen wir in einem Projekt fest, dieses oder jenes Erfolgselement könnte uns in dieser spezifischen Situation helfen, sollte es selbstverständlich sein, es einzusetzen, ohne ideologische Scheuklappen. Es gibt nicht die beste Methode. Und jedes noch so gute Framework kann in einem Unternehmen so implementiert werden, dass es garantiert nicht funktioniert. Dann nämlich, wenn man sich nur an die erste Lernstufe des Aikido, an das Shu hält, in dem Anweisungen befolgt werden, ohne sie in Frage zu stellen. Ohne Blick für das Ganze, das Spezifische, das Notwendige. Aber genau dafür gibt es ja die weiteren Stufen, das Hi und das Ra, mit dem Ziel, Methoden noch mehr ihrem Sinn entsprechend einzusetzen.

Im nächsten und letzten Teil gehen wir noch einmal gezielt auf ein paar Agile Patterns ein, die Ihnen dabei helfen, sanft auf agile Methoden umzusteigen und mit denen wir bei ANECON in verschiedenen Kundenprojekten gute Erfahrungen gesammelt haben.

Blogreihe
Agile Patterns – Teil 1/4: Überblick Crystal Family
Agile Patterns – Teil 2/4: Prinzipien Crystal Family
Agile Patterns – Teil 3/4: Beispiele Crystal Family
Upcoming:
Agile Patterns – Teil 4/4: Tipps für den sanften Umstieg zu agiler Softwareentwicklung

The post Agile Patterns – Teil 3/4: Beispiele Crystal Family appeared first on ANECON Blog.