Crystal Family
Crystal Light ist eine Familie von Software-Entwicklungsmethoden, die zu den agilen Methoden der Softwareentwicklung gerechnet wird. Die Methoden dieser Familie sind in der Regel mit Farben bezeichnet. Die einfachste Variante heißt hingegen Crystal Clear (,glasklar‘).
Crystal Prinzipien
[Bearbeiten | Quelltext bearbeiten]- 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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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/Maroon, Crystal Diamond (optional), Crystal Blue, Crystal Sapphire (optional).[1] 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
[Bearbeiten | Quelltext bearbeiten]| Programmdefekte
bedeuten Gefahr für |
Anzahl Beteiligte | |||
|---|---|---|---|---|
| 1–6 | 6–20 | 20–40 | 60–100 | |
| Leben | - | - | - | - |
| Kritische Gelder | - | E20 | E40 | E100 |
| Verfügbare Gelder | D6 | D20 | D40 | D100 |
| Komfort | C6 | C20 | C40 | C100 |
| verwendete Methodik | Crystal Clear | Crystal Yellow | Crystal Orange | Crystal Red |
Sobald die Kritikalität "Kritische Gelder" erreicht ist, wenn es also um finanzielle Verluste geht, die den Bestand eines Unternehmens gefährden können, ist mindestens die die Methode "Crystal Yellow" zu wählen. In der Kritikalität "Leben" (Belüftung von U-Booten, Aufzugsteuerung …) hat Alistair Cockburn nach eigener Aussage keine Erfahrung – er empfiehlt daher keine Methode.
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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]- 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 (englisch: Agile software development).
- Alistair Cockburn: Crystal Clear. Agile Software-Entwicklung für kleine Teams, Addison-Wesley, 2005, ISBN 0-201-69947-8 (englisch: Crystal Clear. A Human-Powered Methodology for Small Teams).
- Jochen Ludewig, Horst Lichter: Software Engineering. Grundlagen, Menschen, Prozesse, Technik, 3. Aufl., dpunkt.verlag, 2013, ISBN 978-3-86490-092-1.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Vorstellung von Crystal in einer Seminararbeit (Hollenstein) (PDF; 468 kB)
- Alistair Cockburns Wiki über Crystal Methodologies
- Crystal Methods in der englischsprachigen Wikiversität
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Lajos Jenő Fülöp, Péter Körtvélyesi: IT support for project management processes. 5.4 Crystal methodology – According to project size & criticality. Fakultät für Informatik. Universität Szeged, 28. Mai 2019, abgerufen am 30. Juni 2014 (englisch).