- Crystal Family
-
Crystal Light ist eine Familie von Software-Entwicklungsmethoden, die zu den Agilen Methoden der Softwareentwicklung gerechnet wird. Die Mitglieder dieser Familie sind in der Regel mit Farben bezeichnet. Die einfachste Variante heißt hingegen Crystal Clear (,glasklar‘).
Inhaltsverzeichnis
Crystal Prinzipien
- passiver Wissenstransfer
- Durch räumliche Nähe und Freiräume für Gespräche wird informeller, "passiver" Wissenstransfer gefördert.
- persönliche Sicherheit
- Kritik und Befürchtungen können ohne Repressalien geäußert werden.
- laufende Kritik und Verbesserung
- Es werden laufend Verbesserungsvorschläge gesucht, gesammelt und die Wichtigkeit ihrer Umsetzung bewertet.
- fokussiertes Arbeiten
- Die Mitarbeiter wissen genau, was ihr Ziel ist, und werden nicht abgelenkt oder für andere Projekte abgezogen.
- häufige releases
- Durch häufige Herausgabe von Zwischenversionen an den Kunden oder andere Projektbeteiligte wird vermieden, dass Erwartungen angestaut werden und größerer Erklärungsbedarf entsteht. Gleichzeitig kann eine höhere Sicherheit für das Team durch Zwischenabnahmen entstehen.
- Zugang zu kundigen Benutzern
- Dadurch, dass ständig ein erfahrener Benutzer des künftigen Produktes erreichbar ist, können Detailfragen schnell und formlos geklärt werden. Dies vermeidet unter anderem, dass Missverständnisse zu Problemen auswachsen.
- automatisiertes Testen
- durch Unit Testing wird für dauerhaft stabilen Programmcode gesorgt, was auch das Vertrauen des Teams in die eigene Arbeit stärkt.
- häufige Integration
- Nicht nur der Programmcode wird getestet, es wird auch regelmäßig (z.B. täglich und automatisiert) eine lauffähige Testversion erstellt.
- Konfigurationsmanagement
- Verwendung von Konfigurationsmanagement, oder zumindest einer Versionsverwaltung.
Die Crystal-Varianten
Crystal ist nicht eine einzelne Methode, sondern – wie erwähnt – eine Familie von Methoden, mit Varianten.
Diese Unterteilung hat den Sinn, dass einerseits ein zu den Projektumständen passender Regelsatz gewählt werden kann, andererseits diese Regeln nicht einzeln ausgehandelt und festgelegt werden müssen.
Aufteilung in Varianten
Die Wahl der Crystal-Variante richtet sich nach der Anzahl der beteiligten Personen und der Kritikalität (Höhe der Risiken).
Die Methoden sind mit Farben benannt: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Magenta, Crystal Blue. Die Farbe spiegelt im Wesentlichen die Personenanzahl wider. So wird die einfachste Variante, Crystal Clear für Teamgrößen von zwei bis sechs Personen empfohlen.
Kritikalität hingegen bildet die Risiken ab, das heißt welche Art und welches Ausmaß von Schaden im Falle eines Scheiterns des Projektes zu erwarten ist. Abhängig von der Kritikalität wird ein „Härtungsgrad“ der jeweiligen Crystal-Variante gewählt. Als Stufen der Kritikalität sind in Crystal definiert: Gefährdung der Kundenzufriedenheit, Verlust von Geld, Imageschaden, und als höchste Stufe: Verlust von Menschenleben.
Je nach gewählter Crystal-Variante ändern sich die Anzahl der Rollen, die Menge der einzusetzenden Methoden und der Dokumentationsumfang.
Die Einordnung nach Kritikalität und Mitarbeiterzahl geschieht nach folgendem Schema:
Auswahl der Variante
Programmdefekte bedeuten Gefahr für
Anzahl Beteiligte 1-6 6-20 20-40 40-60 60-100 100-200 200-500 Leben L6 L20 L40 L60 L100 L200 L500 Unternehmen E6 E20 E40 E60 E100 E200 E500 Geld D6 D20 D40 D60 D100 D200 D500 Komfort C6 C20 C40 C60 C100 C200 C500 verwendete Methodik Crystal Clear Crystal Yellow Crystal Orange Crystal Red Crystal Red Crystal Maroon Crystal Blue Die Gruppierung nach Anzahl der Mitarbeiter wird damit begründet, dass der Kommunikationsaufwand bei steigender Mitarbeiterzahl unterschiedlich strukturiert werden muss. Während ein Team von sechs Personen sich noch jederzeit formlos zusammentrommeln lässt (räumliche Nähe ist ja nach den Prinzipien gegeben), muss man bei einem Team von 20 Personen schon einen Zeitpunkt ausmachen. Bei 60 Personen hingegen ist eine gemeinsame Diskussion unrealistisch.
Für jede der Gruppengrößen werden unterschiedliche Kommunikationsformen und -mittel vorgeschlagen.
Die Gruppierung nach Kritikalität hingegen wirkt sich darauf aus, wie formal und genau vorgegangen wird. Je schwerwiegender die Risiken, umso mehr Zusatzaufwand wird für Korrektheit und Sicherheit des Programms in Kauf genommen. Auch hier gibt es eine Staffelung der einzusetzenden Methoden.
Durch die Kombination der beiden Kriterien kann der Kurzname der spezifischen Variante gefunden werden, deren Details sich dann direkt eindeutig nachschlagen lassen. Dadurch ist eine Anpassung an die Projektumstände gegeben, ohne dass man lange aushandeln müsste, welche Regeln denn im vorliegenden Fall zur Anwendung kommen sollten.
Vergleich mit anderen Agilen Methoden
Im Verhältnis zu anderen Agilen Methoden (wie Extreme Programming) wird Crystal von seinen Befürwortern als weniger dogmatisch und formalisiert angesehen. So wird bei Crystal Clear niemals Paarprogrammierung oder customer on site (,Kunde vor Ort‘, meint eine Vertretung beim Entwicklungsteam) gefordert.
Neutraler kann man sagen, dass Extreme Programming sich um die Art des Arbeitens dreht, wohingegen Crystal sich am einzelnen Projekt orientiert.
Crystal führt nicht dauerhafte Methoden für das Team ein, sondern bestimmt bei jedem einzelnen Projekt neu die dafür einzusetzenden Methoden. Bei einfacheren Projekten kann dies dazu führen, dass viele der auch in XP eingesetzten Agilen Methoden zum Einsatz kommen; bei komplexeren Projekten würde eine Variante eingesetzt, welches eher komplizierteren Vorgehensmodellen ähnelt.
Literatur
- Alistair Cockburn: Surviving Object-Oriented Projects. Addison Wesley, 1998, ISBN 0-201-49834-0
- Alistair Cockburn: Agile Softwareentwicklung. mitp, 2003, ISBN 3-8266-1346-5
- Jochen Ludewig, Horst Lichter: Software Engineering. dpunkt, 2007, ISBN 3-89864-268-2
- Alistair Cockburn: Crystal Clear. Addison Wesley, 2005, ISBN 0201699478
Weblinks
Wikimedia Foundation.
