Es ist jetzt ein knapper Monat her, seit ich bei der Previon als Entwickler angefangen und mich eigentlich hauptsächlich mit Drupal Projekten beschäftigt habe. Ich kenne Drupal bereits zwei Jahre, habe Erfahrungen im Theming, der Modulentwicklung und auch der Konfiguration und habe die vergangenen Jahren diverse Projekte auf Freelance Basis umgesetzt.
Wenn ich meine Lernkurve anschaue… mir wird fast schlecht, wenn ich an meine ersten Module zurückdenke. Das war überhaupt nicht gut, aber ich kannte die Drupal API kaum. Jetzt arbeite ich an Projekten, wo mehrere Leute entwickelt sind. Nun, was ist so der Eindruck? Es ist schon ein wenig anders.
Dabei ist mir folgendes bewusst geworden: Drupal Projekte verlangen einen agilen Entwicklungsprozess. Die folgende Grafik zeigt den agilen Entwicklungsprozess auf:
[Grafik von Microtool.de]
Die verschiedenen Phasen der Entwicklung werden also nicht starr abgewickelt, sondern es entsteht ein Zyklus bestehend aus den Phasen. Nach jedem Zyklus gibt es einen brauchbaren Prototypen. Durch das Verwenden des Prototypen entstehen dann die Anforderungen für den nächsten Zyklus.
Drupal ist prädestiniert für einen solchen Entwicklungszyklus. Dies hat die folgenden Gründe:
- Drupal ist Open Source. Open Source Projekte werden von Natur aus sehr agil geführt. Es wird was gemacht -> Bereitgestellt -> Wird von der Öffentlichkeit verwendet -> Feedback -> Issue Queue -> neue Version.
- Viele Dinge lassen sich in Drupal out-of the Box umsetzen. Dadurch wird ein gewisser "Standard" vorgegeben. Dadurch können zum Teil coole Zusatzfunktionen hinzugewonnen werden, aber unter Umständen müssen Wünsche ein wenig umgeändert werden. Ein agiler Prozess bietet sich an, weil eben nicht alles von Grund auf geplant werden muss.
Ich finde ein Drupal Projekt könnte nach dem folgenden Schema ablaufen:
- Rohprototyp -> Was ist möglich mit Drupal, Drupal vorstellen, Funktionen vorstellen. Dieser Prototyp sieht sehr roh aus, ist ein Proof of Concept und kann wohl in einem halben Tag zusammengeklickt werden. Module ausprobieren.
- Wichtige Funktionoen definieren und die Grundzüge der Architektur beschreiben. Dazu müssen Grundlegen Entscheide gefällt werden, z.B. für eine Community Seite, soll Organic Groups eingesetzt werden, oder was für wichtige Inhaltstypen sind vorhanden usw. Halt einfach Dinge, welche das Projekt entscheidend beeinflussen.
- Einen neuen Prototypen nochmals von Grund auf bauen (neu daher, weil im ersten Prototypen unter Umständen viele Altlasten herumliegen) und dabei diese Kernelemente einbauen.
- Theme bauen. Es muss nicht komplett fertig sein. Wahrscheinlich gibt es Leute, welche hier anderer Meinung sind, ich denke jedoch, dass es essentiell ist, weil: Der Kunde oder Testpersonen sollen so früh wie möglich auf der Seite testen. Wenn da nur ein Garland Theme mit den nackten Funktionen und Blöcken ist, dann wird er sich damit nicht zurechtfinden, wird es hässlich finden und sich fragen, was wir die ganze Zeit machen.
- Einen Zugang für den Kunden einrichten. Der soll ruhig darauf herumspielen. Er muss sich halt einfach bewusst sein, dass die Seite "under construction" ist. (dazu ist das secure sites Modul sehr hilfreich).
- Sehr nützlich wäre jetzt ein Bugtracker, ein Google Docs oder irgend ein System. Dort sind die Tasks aufgelistet, welche noch umgesetzt werden können und der Kunde kann Fehler und Änderungswünsche reinschreiben. Nicht schlecht wäre es natürlich, wenn der Kunde die Prioritäten der einzelnen Punkte bearbeiten kann. Der Entwickler arbeitet dann jeweils an den Tasks mit der höchsten Priorität -> was je nach dem Ändern kann.
- Im nächsten Zyklus werden jetzt die Punkte aus dem Bugtracker genommen und daran gearbeitet, damit eine neue bessere Version besteht.
- Immer Weiter und Weiter.
Es ist jedoch in der Praxis nicht ganz so leicht, das alles so umzusetzen aber es lohnt sich allemal und resultiert in zufriedenen Kunden und zufriedenen Entwicklern. Bugtracker sind auch ein super Ding!!! Warum. Das werde ich in einem folgenden Blogpost vielleicht mal erläutern.