next up previous contents index
Nächste Seite: 7.4 Manifest agiler Softwareentwicklung Aufwärts: 7 Agile Softwareentwicklung Vorherige Seite: 7.2.6 Zusammenfassung Extreme Programming   Inhalt   Index

7.3 Agiler Vertreter: Methodikfamilie Crystal

Während Extreme Programming konkrete Aktivitäten vorgibt, sind die Methodiken der Methodikfamilie Crystal wesentlich abstrakter. Crystal, entwickelt von Alistair Cockburn (vgl. Coc03,Coc02), versteht sich als eine Familie von Methodiken. Zentraler Ansatzpunkt lautet, dass Menschen und Projekte unterschiedlich sind und dass es deshalb unterschiedlicher Methodiken bedarf. Deshalb nimmt Crystal eine Klassifizierung von Projekten vor (siehe Abbildung 1346 auf Seite [*]) und bietet entsprechende Methodiken für die einzelnen Klassen an. Laut Crystal wird ein Projekt von folgenden drei Variablen charakterisiert (Coc03, S. 218):

  1. Anzahl der Mitarbeiter, die koordiniert werden sollen
  2. Kritizität des Projektes (Auswirkungen beim Scheitern)
  3. Prioritäten des Projektes (z. B. frühzeitige Auslieferung)
Der Zusammenhang der drei Variablen lässt sich, wie in Abbildung 13 gezeigt, darstellen. Bevor für ein Projekt ein Vorgehen bestimmt werden kann, müssen zuerst die drei Variablen bestimmt werden. Weiterhin muss während des Projekt überprüft werden, ob sich die Variablen verändert haben und somit die Einstufung des Projektes verändert werden muss.
Abbildung: Crystal Projekteinordnung nach Anzahl Mitarbeiter, Kritizität und Prioritäten
Image tabelle

Die Begründung für dieses Vorgehen liegt in mehreren Punkten. Eine Steigerung der Mitarbeiterzahl erhöht den Kommunikationsaufwand. Auf dieses Problem hat bereits Brooks (vgl. Bro01b) aufmerksam gemacht. Dabei übersteigt ab einer bestimmten Teamgröße der Kommunikationsaufwand, verursacht durch einen weiteren Mitarbeiter, den Gewinn an Arbeitskraft durch diesen Mitarbeiter. Eine Verdoppelung der Mitarbeiter führt nicht zu einer Verdoppelung der Arbeitskraft. Cockburn (Coc03, S. 107ff) zeigt weiterhin, dass direkte Kommunikation von Mensch zu Mensch wesentlich effektiver ist, als indirekte Kommunikation. Tatsächlich ist eine direkte Kommunikation nur bei bis zu zehn Mitarbeitern im Projektteam möglich. Da Extreme Programming ausschließlich auf direkter Kommunikation basiert, kann es kaum in Teams größer als zehn Mitarbeiter umgesetzt werden.

Ist das Ergebnis eines Projektes kritisch für das Fortbestehen des Unternehmens, müssen andere Verfahren verwendet werden, als wenn das Projekt weniger kritisch ist. Unter Prioritäten versteht Cockburn z. B. gesetzliche Auflagen. So kann es sein, dass bestimmte Artefakte durch den Auftraggeber oder durch Randbedingungen erforderlich sind. Dann muss die verwendete Methodik die Erstellung der Artefakte sicherstellen.

In der Methodikfamilie Crystal wird davon ausgegangen, dass die Konzentration auf Fähigkeiten der Mitarbeiter, Kommunikation und Gemeinschaft in einem Projekt effektiver ist, als die Konzentration auf vorgeschriebene Prozesse. Daraus leiten sich folgende Grundwerte ab (Coc03, S. 267):

  1. mensch- und kommunikationszentrisch
  2. Möglichkeit zur Anpassung bei Bedarf
  3. Toleranz
Punkt 1 bedeutet, dass Werkzeuge, Artefakte und Verfahren lediglich als Unterstützung für die menschlichen Komponente dienen. Punkt 2 stellt klar, dass die Methodik während des Projekts überarbeitet werden muss, um sich ändernden Anforderungen anzupassen. Punkt 3 hebt hervor, dass das Team anhand seiner Erfahrung entscheidet, welche Artefakte und Prozesse sinnvoll sind und damit letztendlich umgesetzt werden.

Anhand dieser Darstellung wird ersichtlich, dass die Methodikfamilie Crystal sehr abstrakt ist. Für die konkrete Umsetzung wurden je nach Einstufung des Projektes verschiedene konkrete Ausprägungen entwickelt. Die einfachste Ausprägung für kleine nicht kritische Projekte (die Zellen C6, D6 und E6 in Abbildung 13) ist Crystal Clear. (vgl. Coc02) Für Crystal Clear ist erforderlich (Coc02, S. 258):

Dabei wird im Gegensatz zu Extreme Programming nicht auf Dokumentation verzichtet. Das Team muss allerdings selbst entscheiden, welche Artefakte sinnvoll zur Speicherung des im Projekt gewonnenen Wissens sind. Als wichtiges Werkzeug wird ein System für das Konfigurations- und Versionsmanagement angesehen. Auf den Wandtafeln und Flipcharts wird z. B. das Design und andere Entscheidungen kommuniziert. Weiterhin dienen sie während einer Diskussion im Projektteam als Zeichenfläche.

Im Vergleich zu Extreme Programming fällt auf, dass Crystal Clear weniger konkrete Forderungen stellt. Lediglich die Forderung von Dokumentation geht über den Umfang von Extreme Programming hinaus. Es werden keine Aussagen über die Programmierung (Technologie, Programmiersprache, Standards, Programmieren in Paaren, usw.) oder den Umfang von Tests getroffen. Dies liegt im Ermessen des Teams.

Für komplexere Projekte stehen eine Vielzahl von weiteren Ausprägungen der Methodikfamilie Crystal zur Verfügung. Diese sind wesentlich umfangreicher, da eine größere Anzahl von Mitarbeitern koordiniert werden muss. Auch in diesen Ausprägungen werden die drei oben genannten Grundwerte umgesetzt. Cockburn betont, dass mit zunehmender Projektgröße die Formalien zunehmen müssen, da eine direkte Kommunikation im ganzen Projektteam aufgrund des exponentiell steigenden Kommunikationsaufwandes nicht möglich ist. So bestehen z. B. bei rein direkter Kommunikation in einem Team mit sechs Mitgliedern 15 Kommunikationswege, wie in Abbildung 14 Teilbild a) auf Seite [*] nachvollzogen werden kann. In Abbildung 14 Teilbild b) wurde das Projektteam in zwei Teilteams untergliedert. Eine Kommunikation zwischen beiden Teilteams findet über jeweils eine Person aus den Teilteams statt. Durch diese Maßnahme können die Kommunikationswege mehr als halbiert werden. Allerdings wird die Kommunikation für die einzelnen Teammitglieder, wenn sie mit einem Mitglied aus dem anderen Teilteam kommunizieren müssen, erschwert, da eine Vermittlung über die Verbindungspersonen notwendig ist.

Abbildung 14: Anzahl Kommunikationswege bei direkter und bei gemischter Kommunikation am Beispiel eines Teams mit sechs Mitgliedern
Image netze

Trotzdem bleiben große formalisierte Projekte laut Cockburn agil, wenn sie die auf Seite [*] genannten drei Grundwerte umsetzen. Allgemein kann davon ausgegangen werden, dass die Einführung von Formalien nicht Agilität verhindert.


next up previous contents index
Nächste Seite: 7.4 Manifest agiler Softwareentwicklung Aufwärts: 7 Agile Softwareentwicklung Vorherige Seite: 7.2.6 Zusammenfassung Extreme Programming   Inhalt   Index
Sebastian Stein 2004-08-30