Crystal Clear

Die von Alistair Cockburn entwickelte Methode Crystal Clear (vgl. [Co02][Co03]

[Co05]) beschreibt eine Sammlung von Erfahrungen, welche im Kontext der agilen Entwicklung angewendet werden können. Im Gegensatz zu anderen Vorgehensweisen (z.B. XP, Scrum,…) beschreibt Crystal nicht den Ansatz „(…) „so muss man es machen“, sondern (…) „in dieser Situation haben Teams gute Erfahrung gemacht, jenes zu machen mit folgenden Konsequenzen“ (…)“ [Co09].

Crystal Clear ist Bestandteil einer Methodenfamilie („Crystal Family“) wie sie schematisch in Abbildung 23 dargestellt ist.

93 Hierdurch erhält die Methode auch ihren Namen. Kanban stammt aus dem Japanischen und besteht aus

„kan“ (dt. Signal) und „ban“ (dt. Karte) vgl. [Ep11, S.23] [LK14].

Abbildung 23: Crystal Familie nach [Co02]

Abhängig von den zwei Parametern (vgl. x-y-Achsen in Abbildung 23) „Kritikalität“ und

„Anzahl der Projektbeteiligten“ wird die, für das Projekt passende Crystal-Variante ausgewählt und angewendet. Cockburn nutzt zur besseren Visualisierung der Anzahl von Projektbeteiligten verschiedene Farbtöne. Ein dunklerer Farbton symbolisiert eine höhere Anzahl von Projektbeteiligten. Der Parameter der Kritikalität wird von Cockburn in vier Ausprägungen unterteilt⁹⁴: „C“ (Verlust von Komfort), „D“ (Verlust von frei verfügbaren Geldern), „E“ (Verlust von kritischen Geldern) und „L“ (Verlust von Leben).⁹⁵ Muss beispielsweise ein Projekt mit 40 Beteiligten und Kritikalität D durchgeführt werden, muss die Variante Crystal Orange gewählt werden. Die in diesem Abschnitt ausführlich beschriebene Variante Crystal Clear eignet sich für „C6“ und „D6“ (vgl. Abbildung 23), wobei „E6“ abhängig von den Projektbeteiligten⁹⁶ zusätzlich für den Einsatz von Crystal Clear gewählt werden kann.

Unabhängig von der Einteilung der unterschiedlichen Varianten der Crystal Familie werden drei vorgeschriebene Basisprioritäten von Cockburn vorgegeben.

Tabelle 12: Basisprioritäten von Crystal

1 Safety in the project outcome 2 Efficiency in the development 3 Habitability of the conventions

94 Vgl. engl. Übersetzung: C (loss of comfort), D (loss of discretionary moneys), E (loss of essential moneys), L (loss of life).

95 Vgl. Cockburn [Co05, S.234]: „The name Crystal derives from these two dimensions [Kritikalität und Anzahl der Prozessbeteiligte], in an analogy with geological crystals, which also are characterized in two dimensions: color and hardness (…)”.

96 Vgl. Cockburn [Co02, S.166]: „(…) Crystal Clear does not explicitly address “essential moneys”

projects, but that the team may be able to stretch Crystal Clear to such a situation.”

Sicherheit bzgl. des Projektergebnisses ist eine Priorität von Crystal im Allgemeinen.

Projektprioritäten und Rahmenbedingungen werden daher besonders überwacht. Des Weiteren wird die Effizienz der Entwicklung als ausschlaggebende Messgröße festgelegt, um ökonomische Ziele nicht zu verfehlen. Zusätzlich muss die Anwendbarkeit der Methode gewährleistet sein⁹⁷. Die, durch die angewendete Methode, aufkommenden Pflichten und Vorschriften dürfen die Projektbeteiligten nicht belasten.

Um diese drei Basisprioritäten und die dadurch entstehenden Herausforderungen bewältigen zu können, sind in Crystal (Clear) sieben Eigenschaften definiert.

Tabelle 13: Die sieben Eigenschaften von Crystal

1 Frequent Delivery 2 Reflective Improvement 3 Osmotic Communication 4 Personal Safety

5 Focus

6 Easy Access to Expert Users

7 Technical Enviroment with Automated Tests, Configuration Management, and Frequent Integration

In Crystal Clear müssen nach Cockburn die Eigenschaften 1- 3 verpflichtend umgesetzt werden. Somit ist eine regelmäßige Auslieferung einer lauffähigen Software an den Kunden vorgeschrieben. Beispielsweise können dadurch Abweichungen von Kundenanforderungen unmittelbar erkannt werden. Des Weiteren zählen regelmäßige Abstimmungen zwischen den Projektbeteiligten zu den Crystal Eigenschaften. Innerhalb einer solchen Abstimmung wird reflektiert, welche Verbesserungsmöglichkeiten in z.B.

die nächste Iteration übernommen werden können. Als dritte verpflichtende Eigenschaft

97 Das engl. Wort “habitability” wurde frei mit “Anwendbarkeit” übersetzt. Vgl. Cockburn [Co05, S.233]:

„The habitability priority means that the rules need to be such that the people on the team can live with them.“.

von Crystal Clear beschreibt Cockburn eine osmotische Kommunikation. Eine osmotische Kommunikation ist möglich, sobald kleine Teams in einem Raum arbeiten, sodass durch die räumliche Nähe der Projektbeteiligten bereits Informationen ausgetauscht werden (vgl. [Ha10a]). Die weiteren Eigenschaften – Persönliche Sicherheit, Fokus, Einfache Kommunikation mit Anwendern, Technische Umgebung – müssen in Crystal Clear nicht verpflichtend eingehalten werden.

Crystal Clear Projekte werden in unterschiedliche Ebenen gegliedert. Cockburn unterscheidet hierbei zwischen dem Projekt, Delivery-Abschnitten und Iterations-Abschnitten (vgl. Abbildung 24). Im Unterschied zu einer Delivery beschreibt eine Iteration „nur“ das Ende eines internen Entwicklungsabschnitt, während das Ende einer Delivery die Abnahme von Usern (Anwender der implementierten Software) vorschreibt⁹⁸.

Abbildung 24: Unterteilung eines Crystal Clear Projekts (obere drei Ebenen)

Eine Iteration selbst kann noch einmal in „Day“, „Integration“ und „Episode“⁹⁹ unterteilt werden. Diese drei Ebenen dienen zur detaillierten Strukturierung. Hierbei wird sowohl die Tagesplanung („Day“), als auch die Planung einer Integration von Neuentwicklungen

98 Vgl. des Weiteren Cockburn [Co05, S.133]: „In Crystal Clear, you are allowed to have just one iteration per delivery cycle, but if you do so, you must have some intermediate viewings by real users.”

99 Cockburn verweist selbst auf Ward Cunningham bzgl. der Definition einer „Episode“:

http://c2.com/ppr/episodes.html

berücksichtigt. Eine Episode ist die Basiseinheit eines Entwicklers und beschreibt z.B.

eine neu entwickelte Funktion (inkl. Softwaredesign und Test).

In einem Crystal Clear Projekt werden insgesamt acht Rollen¹⁰⁰ definiert: Auftraggeber, erfahrener Anwender, Chefdesigner, Designer-Programmierer, Fachexperte, Koordinator, Tester und Autor (vgl. [Co05, S.140ff]). Die Rollen des Auftraggebers, Anwenders, Chefdesigners und Designer-Programmierer müssen durch unterschiedliche Personen besetzt werden. Der Auftraggeber verantwortet das Projekt und dessen Finanzierung. Diese Rolle entspricht daher auch der Bezeichnung des „Kunden“ [Ha10a].

Der erfahrene Anwender besitzt Wissen über die spätere Anwendung der zu implementierenden Software und dient als Auskunftsperson für die in der Entwicklung tätigen Rollen. Zusätzlich kann die Rolle des Fachexperten ggfs. durch den erfahrenen Anwender übernommen werden. Der Fachexperte besitzt Wissen über IST- und SOLL-Geschäftsabläufe. Die Rolle des Chefdesigners verantwortet die Führung des Projekts und das Design und die Implementierung der Software.

Neben dem Chefdesigner dient die Rolle des Designer-Programmierer¹⁰¹ zur Implementierung der einzelnen Kundenanforderungen eingesetzt. Die Rollen des Koordinators und Autors besitzen Aufgaben zur Koordinierung und Dokumentation.

Beispielsweise übernimmt der Koordinator die Projektprotokollierung und Projektplanung, während der Autor die implementierte Software dokumentiert (z.B. in Form von Benutzerhandbüchern). Die Rolle des Testers verantwortet die Kontrolle der implementierten Anforderungen.

Zusätzlich zu den für Crystal Clear vorgeschriebenen Prioritäten, Eigenschaften, Strukturen und Rollen beschreibt Cockburn eine Vielzahl von Praktiken (vgl. [Co05, S.45ff]). Diese Praktiken sind für die Crystal Clear Methode nicht verpflichtend, unterstützen dennoch deren Anwendung. Cockburn unterteilt diese Praktiken noch einmal in Strategien und Techniken. Zum Beispiel kann die „Exploratory 360°“-Strategie angewendet werden, um zu Beginn eines Projekts Aspekte zu untersuchen, welche Auswirkungen auf die tatsächliche Ausführung haben. Hierbei werden zum Beispiel der

100 Vgl. engl. Übersetzung: Sponsor, Expert User, Lead Designer, Designer-Programmer, Business Expert, Coordinator, Tester und Writer.

101 Die Verbindung der zwei Begriffe „Designer“ und „Programmierer“ zu dem Begriff Designer-Programmierer beschreibt Cockburn wie folgt [Co05, S.142]: „I merge the words „designer“ and

„programmer“ in the designer-programmer role to highlight that each person both designs and programs (...).”

Geschäftswert („Business Value“) diskutiert, grundlegende Anforderungen festgelegt und das Projektteam fixiert. Ein weiteres Beispiel ist das „Methodology Shaping“. Diese Technik dient zur Optimierung der Methode hinsichtlich der aktuellen und zukünftigen Anwendung. Nicht-bewährte Praktiken werden ersetzt, andere erweitert, sodass diese in die Organisationsstruktur integriert werden können. Die „Burn down Charts“ dienen zur Visualisierung des Projektfortschritts und sind nach Cockburn ein einfaches aber effektives Mittel. Die Abbildung 25 skizziert ein Burn down Chart Beispiel. Die y-Achse des Charts visualisiert den Grad der Fertigstellung (z.B. in Prozent), die x-Achse stellt den zeitlichen Verlauf an (z.B. Zeit in Tagen). Die in Abbildung 25 dargestellten Linien (schwarz, rot) skizzieren sowohl den geplanten, als auch den aktuellen Projektablauf.

Verzögerungen (z.B. durch Erfassung und Implementierung von veränderten Anforderungen) werden direkt deutlich.

Abbildung 25: Burn down Chart ohne Meilensteine (vgl. [Co05, S.95])

Um eine höhere Zuverlässigkeit (z.B. Einhaltung des Zeitplans) beschreibt Cockburn die Notwendigkeit weitere Meilensteine (neben dem Start- und Endpunkt) zu definieren.

Beispielsweise kann ein „Delivery“ (vgl. Abbildung 24) aus einzelnen Funktionen bestehen, die bereits nach der Hälfte der Zeit an den Kunden ausgeliefert werden können.

Zusammenfassend wird festgestellt, dass aufgrund der Parallelen hinsichtlich Herausforderungen und Zielen (z.B. Kostenreduzierung, Verbesserung der Zusammenarbeit der Prozessbeteiligten,…), die Anwendung von agilen Ansätzen der Softwareentwicklung im Bereich des agilen Geschäftsprozessmanagements (vgl.

Abschnitt 2.4) durchgeführt werden kann. Die in dieser Arbeit beschriebene Methode adaptiert und erweitert Ansätze aus Scrum, Extreme Programming, Kanban und Crystal Clear (vgl. Abschnitt 4).