Crystal Family
aus Wikipedia, der freien Enzyklopädie
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 hingegen heißt 'Crystal Clear'.
Inhaltsverzeichnis |
[Bearbeiten] 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.
- Verwendung von Konfigurationsmanagement, oder zumindest einer Versionsverwaltung.
[Bearbeiten] 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.
[Bearbeiten] 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:
[Bearbeiten] 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 |
| verwendent Methodik | Crystal Clear | Crystal Yellow | Crystal Orange | Crystal Red | Crystal Red | Crystal Maroon | Crystal Blue |
Die Gruppierung nach Mitarbeitergröße 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 Kommunkationsformen und -mittel vorgeschlagen.
Die Gruppierung nach Kritikalität hingegen wirkt sich darauf aus, wie formal und genau vorgegangen wird. Je schwerwiegender die Risiken, um so 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.
[Bearbeiten] 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' gefordert. customer on site bedeutet: Es muss ständig ein Vertreter der Kundenposition beim Entwicklungsteam anwesend sein.
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.
[Bearbeiten] 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
