Ralf Hendel, Geschäftsführer
Drupal Enthusiast und Freizeit-Pianist.

Elektronisches Projektmanagement

Projektmanagement: Risiken bei der Kalkulation von OpenSource Projekten

Neulich habe ich es wieder leidvoll erlebt. Dinge, die normalerweise problemlos funktionieren, funktionieren urplötzlich nicht mehr.

Bei der Einbindung eines View-Panes in ein Panel funktioniert die Argumenten-Übergabe von Panels an Views nicht. Im Grunde habe ich nichts anderes gemacht, was wir in Projekten ständig verwenden: Nodes eines bestimmten Inhaltstyps sollen als Panel dargestellt werden. In einem zweiten Bereich sollen alle Beiträge des selben Inhaltstyps, die zusätzlich mit dem selben Term einer bestimmten Taxonomie verschlagwortet sind, in einem View-Pane aufgelistet werden. Dafür muss der Term des Nodes als Kontext im Panel bekannt gemacht werden und der View-Pane muss den Kontext aufgreifen und als Argument verwenden. Ging nicht...

Nun folgten drei Stunden nerviger Fehlersuche. Nervig deswegen, weil ich nicht darauf vorbereitet war und lediglich einen Basis-Task mit einigen Handgriffe zu Ende bringen wollte.

Also zuerst alle Einstellungen geprüft: es reicht ja schon aus, ein falsches Argument zu verwenden und der View gibt keine Daten zurück. Dann munteres Rätselraten: auf Verdacht abweichende Einstellungen versucht. Da es bei Panels keine leicht zugängliche Dokumentation gibt, hilft oft Black-Box Testing: Sprich: Try and error, bzw. see what happens. Das hat aber auch nicht weiter geführt. Ein Vergleich mit einer funktionierenden Konfiguration einer anderen Installation bestätigt mir, dass die Einstellungen richtig waren.

Nun dämmert mir, dass ich es hier mit einem ernsthaften Problem zu tun habe, das methodische Fehlersuche erfordert. Ich versuche, das Problem kleinschrittiger anzugehen und schaue, worin sich meine Installation von der funktionierenden Installation unterscheidet. Das einzig Besondere meiner Installation liegt darin, dass ich einen View mit mehreren Ableitungen verwende, der also mehrere View-Panes bzw. „Inhaltsausschnitts-Ansichten“ besitzt, die unterschiedlich übersteuert sind.

Bei meinem Versuch, mich dem Problem kleinschrittig zu nähern, versuche ich zunächst herauszufinden, ob der Panel das richtige Argument zur Verfügung stellt. Für einen Nicht-Entwickler grenzt das an ein Kunststück. Ein Entwickler würde einen Debug-Print setzen, in dem er die Inhalt der Variablen im HTML lesbar ausgibt. Ich habe bislang noch keine Funktion entdeckt, die diese Inhalte sichtbar machen kann. So habe ich versucht, die Variable (Term-ID) im Titel des View-Panes per „%term:name“ auszugeben. Erstaunlicherweise hat dies funktioniert. Der View hat den Begriff ausgegeben, hat also die Term-ID erhalten und „verstanden“. Um so erstaunlicher, dass er keine Daten zurück gibt. Anstelle von Daten erscheint nur der „leere Text“ „Keine Daten gefunden“. Der letzte Test, die Verwendung eines neuen Views ohne Ableitungen, bestätigt die Annahme. Der Test funktioniert auf Anhieb – der Fehler liegt also darin, dass die Argumente bei Views mit mehreren Ableitungen nicht richtig behandelt werden.

Aus einem Schritt, der mit einer einzigen Stunde veranschlagt war, sind vier Stunden entstanden. Nun zurück zum Thema: wie geht man mit solchen Problemen bei der Kalkulation von Projekten um?

Einerseits besteht ein Projekt in aller Regel aus einer Aneinanderreihung bekannter – also einschätzbarer – Einzelschritte. Andererseits ist die jeweilige Kette der Einzelschritte in jedem Projekt wiederum einzigartig. Aus der Zusammensetzung dieser Einschritte entsteht in jedem Projekt eine neuartige Komplexität, die die benannten Risiken birgt.

Mit diesem Workaround sollte die Arbeit noch nicht zu Ende zu Ende sein. Die scheinbar „verlorene“ Zeit erhält ihren Wert zurück, wenn man den Fehler möglichst nachvollziehbar dokumentiert und in die Issue-Queue des jeweiligen Projektes postet. Auf diese Weise kann man auch als Nicht-Entwickler wertvolle Beiträge leisten, die Software im Ganzen weiter zu verbessern. Gerade Module wie Panels oder Views sind hochkomplexe Software, bei denen die Maintainer auf alle Hinweise angewiesen sind, die diffuse Fehler besser eingrenzen oder – im Idealfall – sogar reproduzierbar beschreiben. Wenn ein Fehler erst einmal reproduzierbar ist, ist er aller Regel schnell gefixt.

Bei der Arbeit mit OpenSource sind diese Arbeiten mit zu berücksichtigen. In Paris war bei einer Projektpräsentation davon die Rede, dass bei allen Projekten generell 20 Prozent Overhead für Interaktion mit der Community eingeplant werden. Diese Einschätzung deckt sich recht gut mit unseren eigenen Erfahrungen.

Natürlich bleibt es jedes Mal aufs neue nervig, weil diese Probleme immer an unerwarteten Stellen auftreten. Ganz anders ist es, wenn man sich explorativ in einen neuen Bereich einarbeitet. Hier weiß man, dass mit Problemen zu rechnen ist und ist darauf vorbereitet. Im operativen Tagesgeschäft werden diese Schwierigkeiten aber immer „zum falschen Zeitpunkt“ auf treten. Hier hilft wohl einfach nur Geduld und vielleicht das Lesen dieses Beitrags.