Jeder der schon mal einem 2 jährigen zu Essen geben musste/durfte, weiss, dass dies eine grosse Herausforderung sein kann. Ich durfte dies vor ein paar Tagen wieder mal bei meiner Tochter erfahren. Ich habe aber auch gemerkt, dass Scrumprinzipien bei der Fütterung behilflich sind. Wollen wir doch mal kurz die verschiedenen Prozesse bei der Fütterung analysieren. (mehr …)

Scrum (übersetzt Gedränge -> Chaos) und "Getting things done" (GTD, alles strukturiert und ordentlich) haben mehr miteinander zu tun als man denkt.

In der Software Entwicklung bei meinem Arbeitsgeber bin ich massgeblich an der Einführung von Scrum beteiligt. Scrum hat mich so begeistert, also habe ich versucht, die Scrum Ideen auf meine täglichen Arbeiten zu übertragen. Erst später habe ich von GTD erfahren und konnte mit Freude feststellen, dass meine Arbeitsabläufe stark denen von GTD ähneln.

Zusammenfassung Scrum

Scrum gehört zu den agilen Entwicklungsprozessen. Oberstes Ziel von agilen Entwicklungsprozessen ist ein zufriedener Kunde. Der Kunde sieht nach jedem Sprint (Iteration) ein fertiges Zwischenprodukt. Er kann spielen und testen und Feedback geben, ob sich das Projekt/Produkt in die gewünschte Richtung entwickelt. Falls Diskrepanzen zwischen seiner Vision und dem Zwischenprodukt bestehen/entstehen, kann der Produktowner Korrekturen anbringen.

Der ungefähre Scumablauf sieht wie folgt aus:

1. Product Backlog mit Userstories füllen und diese schätzen. Eine Userstory umfasst gewünschte Features, welche wiederum aus konkreten Tasks bestehen.
2. Wichtigste Userstories durch Productowner selektieren und in Sprintbacklog übertragen. Ein Sprint ist eine Iteration (z.B. 1 Monat oder auch nur 1 Woche). Nach 1 Monat sind die Userstories aus dem Sprint umgesetzt und getestet und die Software ist einsatzfähig.
3. Team organisiert sich, damit die Userstories im Sprint umgesetzt werden können. Dazu trifft sich das Team täglich für max 15 Minuten zum Daily Scrum. Wenn ein Sprint definiert ist und sich das Team dazu verpflichtet hat, dann kommen keine neuen Features mehr rein (die müssen dann auf den folgenden Sprint warten).
4. Bei Sprintende gibt es die Retrospektive: Was ist gut gelaufen, was schlecht, was wollen wir verbessern.
5. Das Zwischen-End-Produkt wird vom Kunden begutachtet, Feedback gegeben und abgenommen. Es geht wieder zu Schritt 2.

Wer es genauer wissen will, es gibt sehr viele Ressourcen. Einfach mal bei Google oder Wikipedia anfangen oder schauen, was es hier im Blog zu Scrum gibt.

Quelle: Wikipedia – Sebastian Wallroth – Der Scrumprozess schematisch dargestellt. Zentral sind die Sprints (Iterationen), welche jeweils ein lauffähiges Produkt erzeugen.

Zusammenfassung GTD

Der GDT Prozess von David Allen sieht eigentlich sehr ähnlich aus. Alle Aufgaben, die reinkommen werden aufgeschrieben. Ziel: 1 zentraler "Posteingang". Dieser kann papierig oder Elektronisch sein, halt was einfacher ist. In regelmässigen Abständen wird dieser Kanal (diese Kanäle) durchgearbeitet und in Kontextlisten sortiert (z.B. @Telefon, @Büro, @Einkaufen usw.) und bestimmt, welche Punkte wann erledigt wird.

Die folgende Grafik zeigt es noch ein wenig ausführlicher auf. Und wer mehr wissen möchte soll einfach mal Google befragen.

Quelle: Wikipedia – René Weber – Der GTD Prozess schematisch dargestellt mit ein wenig mehr Details, als ich sie zusammengefasst habe.

Die Grafik sieht es vielleicht nicht sehr ähnlich (einfach) wie die von Scrum aus, wenn man jedoch alles mal gedanklich durchspielt, dann stellt man doch grosse Ähnlichkeiten fest.

Der Rapsli Prozess

GTD kannte ich bis vor einigen Tagen lediglich vom Namen, wusste jedoch nicht, was sich dahinter verbirgt. So habe ich mein eigenes "Framework" gebaut, welches auf Scrum basiert aber anscheinend viel Ähnlichkeit mit GTD aufweist. Dabei beachte ich folgende Grundsätze:

1. Einfachheit. Sonst besteht die Gefahr, dass man an den Prozessen erstickt. Einfache Dinge mache ich lieber.
2. Regelmässigkeit. Der Mensch ist ein Gewohnheitstier. Einfache Dinge sind auch einfacher regelmässig durchzuführen.

Mein Prozess sieht daher wie folgt aus:

• Ich habe zwei Backlogs: Eine Excel Tabelle und eine Taskliste (Remember the Milk). Die Excel Tabelle ist für vage Aufgaben, Ideen, interessante aber nicht konkrete Gedanken. In dieser Liste gibt es auch eine Selektion "Ziele". Die Taskliste umfasst explizite Tasks, welche nach der Umsetzung sofort abgehakt werden können.
• Sprintdauer beträgt 1 Woche. Immer am Freitag nehme ich mir 15-30 Minuten Zeit (fest im Terminkalender eingeplant), um mein Backlog durchzuschauen. Unter Umständen ergibt sich aus den Gedanken (aus der Excel Liste) ein konkreter Task. Zudem führe ich eine kurze Selbstreflexion durch, wie ich an meinen längerfristigen Zielen vorankomme und schreibe in ein paar wenigen Stichworten auf, was ich gelernt habe (damit ich beim wöchentlichen Review schnell die vergangenen Lessons Learnt durchschauen kann)
• Täglich schaue ich ganz kurz 1x auf alle Tasks (besonders die ohne Enddatum) und schaue, ob sich etwas davon am kommenden Tag einfach erledigen lässt.

Grösste Herausforderungen

Wichtigster und ebenfalls schwierigster Punk (meine Meinung) ist das konsequente Sammeln von Informationen. Schlussendlich ist es einfach ein Gewohnheitssache, Informationen nicht einfach im Kopf zu archivieren (und damit vergessen), sondern effektiv zu Papier zu bringen.

Was Bringts?

Ich habe viele (meist) kleinere Aufgaben, welche ich leicht vor mir herschieben kann (meistens wenn mich niemand dazu drängt) und hoffentlich (wahrscheinlich) bin ich nicht der Einzige mit diesem Problem. Jetzt jedoch, wenn ich einen Task auf meiner Liste habe, dann gebe ich auch mein Möglichstes, um das zu erledigen. Falls ich es nicht schaffe, dann lege ich mir gegenüber auch Rechenschafft darüber ab.

Meine Frau profitiert ebenfalls davon, denn ich habe endlich die Kartonschachtel, welche seit Wochen im Schlafzimmer steht aus- und weggeräumt.

Was für ein System setzt du ein, um möglichst viel in möglichst wenig Zeit zu erledigen (bzw. überhaupt etwas zu schaffen)?

Foto via Flickr by darkmatter's

Ich finde diese Corporate PowerPoint Präsentationen immer todlangweilig. Die sehen doch immer gleich aus: Irgendwo das Logo, irgend ein Header und ein Footer, wo noch ein wenig Datu, Firmenname usw. drin steht. Dann links ein bisschen Text und rechts ein Bild. Langweilig.

Ich habe mal mit Prezi ein wenig herumexperimentiert. Sehr erfrischend. Besonders um Präsentationen zu erstellen, kann man Mindmappingmässig vorgehen und dann am Schluss alles miteinander verbinden.

Aber auch mit PowerPoint lassen sich extrem cool Präsentationen machen:

Ein Drupal Freelancer verdient im Durchschnitt knapp 1000$ pro Projekt, während ein Joomla Freelancer für ein Projekt knapp 500$ verdient. Das ist auf jeden Fall die Aussage einer Studie, welche von DoNanza (grösste Suchmaschine für Heimarbeit und Freelancearbeiten) durchgeführt wurde. WordPress Entwickler sind sogar noch etwas tiefer.

Ich stelle mir die Frage, was zu dieser Kluft führt. Sind Joomla Entwickler weniger talentiert, lieferen schlechtere Qualität und sind daher schlechter bezahlt? Wohl kaum. Als Grund für diese Kluft sehe ich viel eher die unterschiedliche Marktposition von Drupal und Joomla:

Drupal: Anspruchsvolle, grosse Communityprojekte, komplexe Designs, viel Individualismus.
Joomla: KMU und Vereinsseiten.

Durchschnittliches Projektbudget bei WordPress-, Joomla- und Drupalprojekten.

Sicher gibt es Ausnahmen. Ich denke jedoch, dass dies in etwa die Richtung aufzeigt. Nehmen wir einfach mal an, diese Annahme stimmt (Kommentar ist offen, falls du anderer Meinung bist), dann gibt es u.a. folgende Variablen, welche das Honorar (Projektbudget) beeinflussen: Projektdauer, Qualifikation des Entwicklers und in der heutigen Globalisierung der Projektumsetzungsort (grosser Unterschied ob in der Schweiz oder in Ungarn).

Anzahl an Projekten in WordPress, Joomla und Drupal

Noch vorweggenommen: Es geht nicht genau hervor, ob die Zahlen auf Themer, Entwickler oder "Modulkenner und Klicker" (also derjenige, der die Seite konfiguriert) bezogen sind, sprich mit oder ohne PHP Kenntnisse. Ich gehe mal einfach davon aus, dass für die Zahlen in Joomla eher weniger PHP Kenntnisse benötigt werden als für Drupal (eine gute Drupalsite ohne PHP zu bauen ist sehr utopisch).

Drupalprojekte dauern länger

Logischerweise, je länger ein Projekt dauert, umso teurer wird es. In der Studie wäre es daher noch interessant, dies zu erfahren, was wir leider nicht können. Daher müssen wir auf unsere Annahme zurückgreifen: Drupal: grosse Communityprojekte, Joomla: KMU. Wir können somit annehmen, dass die Drupalprojekte im Durchschnitt länger dauern. Ein Drupalentwickler kann somit auch weniger Projekte pro Jahr durchführen. Kein Grund also, dass Drupal Entwickler besser verdienen.

Drupal Entwickler sind besser qualifiziert als Joomla Entwickler

Verbleibt noch die zweite Variable: Qualifikation des Freelancers. Und wie lässt sich diese messen. In der Wirtschaft ist (oftmals) der Stundensatz ein Gradmesser für Qualifikation (ob der Lohn von Gates oder Vasella lediglich von ihrer Qualifikation abhängt…???). Als ich als Drupal Freelancer während dem Studium gearbeitet habe, war mein Stundensatz noch bedeutend tiefer als er dies jetzt sein würde. Alles was sich geändert hat, ist ein Masterdiplom, welches ich besitze und 2 Jahre Erfahrung. Interessant wäre, wenn noch irgend ein Java oder .Net CMS in der Statistik wäre. Ich würde davon ausgehen, dass dort das Einkommen pro Projekt nochmals massiv höher ist, da die Einstiegshürde höher ist und höhere Ansprüche an den Entwickler gestellt werden. Vor ein paar Monaten habe ich mal ein wenig mit dem Java Springframework experimentiert (wenn Drupal ein Kinderdisney Buch ist, dann ist das Java Springframework "Krieg und Frieden" von Leo Tolstoi). Ein Javaprojekt umzusetzen erfordert daher auch ein höheres Budget, da mehr Komplexität und besser Qualifizierte Entwickler benötigt sind.

Ich gehe daher mal davon aus, dass Drupalentwickler tendenziell besser ausgebildet sind als dies ein Joomla Entwickler ist. …ich lass mich mal wieder auf eine hitzige Diskussion ein…. Ich denke jedoch, dass allgemein in PHP Projekten gut ausgebildete Entwickler/Architekten fehlen.

Drupal fehlen kompetente Entwickler

So. Ich habe mir wieder Feinde geschaffen. Ich denke jedoch, dass es wirklich ein Problem von Drupal/PHP ist, gute Software Entwickler/Engineere zu finden (nicht dass es die nicht gibt, aber neben den guten Entwickler gibt es auch sehr viel Ramsch). Die Art und Weise, wie ein ausgebildeter Entwickler Probleme löst ist komplett anders, als dies ein "Garagenprogrammierer" macht. Die Fähigkeiten, Probleme zu erkennen, zu verstehen und selbstständig Lösungen zu entwickeln ist anspruchsvoller als man denkt. Es ist jedoch für einen ausgewachsenen Software Engineer, welcher 4-5 Jahre studiert hat, wenig attraktiv ein paar Websites zu bauen. Ein Tiefbauengineer baut wohl auch lieber den Gotthard Tunnel als ein Sandloch. Wäre ein interessantes Thema für einen eigenen Artikel. Daher ist es wohl auch so schwierig gute PHP Leute zu finden.

Nicht zuletzt ist es auch ein Lohnproblem. Die Grafik von indeed.com zeigt dieser sehr schön auf. PHP ist verhältnismässig einfach zu erlernen und wird in eher einfacheren Projekten eingesetzt. Die Löhne sind daher auch tiefer.

Quelle: indeed.com

Fazit

Wer schlussendlich besser verdient lässt sich nicht wirklich aus den Zahlen belegen. Schade ;). Es zeigt jedoch wieder mal, dass für alle ein Markt vorhanden ist. Joomla und WordPress wachsen schnell mit einfachen und kleineren Projekten. Drupal sucht sich die grösseren, individuelleren Projekte heraus, obwohl hier vermehrt auch Anstrengungen im Gang sind, Drupal als Produkt (z.B. OpenPublish, OpenAtrium usw) besser am extrem schnell wachsenden Joomla Markt zu platzieren.

Was sind deine Erfahrungen? Verdienen Drupalentwickler besser?

Im ersten Teil ging es darum, das Theme zu wechseln, sobald ein Benutzer mit einem Mobiltelefon kommt. Das ging ja auch ganz einfach, wir verlieren dabei jedoch Cachingmöglichkeiten. Für kleinere Seiten sicher kein Problem, falls es etwas grösser wird jedoch undenkbar.

Caching wird ab einer bestimmten Popularität der Webseite unumgänglich. Daher ist es doch sehr erstrebenswert, auch für unser Problem eine Lösung zu finden. Wollen wir doch zuerst mal ganz schnell ein paar Cachingmechanismen in Drupal anschauen:

• Einzelne Elemente cachen (z.B. Blockcache). Nehmen wir an, wir hätten einen Block der die Weltformel berechnet und das dauert 20 Sekunden. Wir wollen natürlich nicht, dass diese bei jedem Seitenaufruf neu berechnet werden wird, da das Resultat jeden Tag gleich bleibt: Wir berechnen den Block einmal und zwischenspeichern (cachen) das Resultat. Dem nächsten Besucher wird dann der bereits berechnete Block serviert.
• Für den anonymen Besucher wird die ganze Seite gecached. Z.B. der Page Cache oder Boost. Vom Prinzip her genau gleich wie das Beispiel vorher, aber halt auf die ganze Seite bezogen.

Nehmen wir also an, wir schalten den Page Cache an:

1. Ein Besucher (Fritz) kommt. Drupal und die Datenbank rechnen und rendern. Die Seite wird ausgegeben und das ausgegebene Stück HTML wird zwischengespeichert.
2. Ein weiterer Besucher (Hans) kommt auf die selbe Seite. Bevor Drupal überhaupt irgend etwas macht, wird im Cache geschaut, ob da evtl. bereits etwas vorhanden ist: Hurra, ja: Seite servieren und schluss.
3. Ein IPhone Jünger (Steve, natürlich via IPhone) kommt auf eine neue Seite (die weder Fritz noch Hans vorher besucht haben). Drupal schaut im Cache, findet nichts. Drupal merkt, aha, hier kommt ein IPhone daher, also Theme umstellen. Jetzt wird gearbeitet und die Seite zusammengestellt und das HTML schlussendlich ausliefern und im Cache ablegen.
4. Hans folgt Steve. Drupal schaut wieder im Cache und findet eine Seite, weiss jedoch nicht, dass die im Cache liegende Seite eigentlich nur für Mobilgeräte gültig ist. Hans bekommt nun die Mobileseite ausgeliefert… er wird wohl nicht wirklich begeistert sein.

So. Wir haben also zwei Möglichkeiten. Beide sind in Drupalumsetzbar:

1. Die Mobileseite so auslieferen, dass Drupal für Mobile und Desktop das Gefühl hat es wäre eine andere Seite (mittels Subdomain)
2. Den Cachingmechanismus so anpassen, so dass er nach Theme unterscheidet.

Ich habe mich für die erste Möglichkeit entschieden, da diese viel einfacher umsetzbar ist:

1. Einen Domainalias http://m.rapsli.ch anlegen (die Domain zeigt auf den gleichen Server wie rapsli.ch), ein sog. Domain Alias. Leider wird diese Möglichkeit nicht von allen Hostern angeboten (besonders nicht von den günstigen).
2. Jetzt geht es nur noch darum, mobile Geräte auf diese Domain weiterzuleiten. Dazu dient ein einfacher Eintrag in der Datei .htaccess

1. RewriteCond %{SERVER_NAME} !^m.rapsli.ch$ [NC]

a bunch of user agent tests

RewriteCond %{HTTP_USER_AGENT} (nokia|symbian|iphone|blackberry|android) [NC]
RewriteRule ^(.*)$ http://m.rapsli.ch [L,R=301]

Kurze Erklärung dazu: