Rapslis World

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?

digg_url = 'http://www.rapsli.ch/drupal-freelancer-verdienen-mehr-als-joomla-freelancer'; digg_title = 'Drupal Freelancer verdienen mehr als Joomla Freelancer'; digg_bodytext = "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."; digg_skin = 'standard';

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 2. RewriteCond %{HTTP_USER_AGENT} (nokia|symbian|iphone|blackberry|android) [NC] 3. RewriteRule ^(.*)$ http://m.rapsli.ch [L,R=301]

Kurze Erklärung dazu:

Zeile 1: Da es es lediglich um einen Domain Alias handelt, verwenden beide Domains das gleiche .htaccess. Um zu vermeiden, dass ein Mobilgerät immer wieder weitergeleitet, machen wir auf der Subdomain nichts.

Zeile 2: Wir stellen die Bediengung, dass es nokia, symbian, iphone,.... ist 

Zeile 3: Falls das alles zutrifft, dann machen wir die Weiterleitung auf m.rapsli.ch 

Das war es dann eigentlich auch schon. Jetzt können wir den Cache auch wieder einschalten.

Verwandte Beiträge:  Drupalseiten einfach für Mobile aufbereiten (Tutorial) digg_url = 'http://www.rapsli.ch/drupalseiten-einfach-fuer-mobile-aufbereiten-tutorial-teil-ii'; digg_title = 'Drupalseiten einfach für Mobile aufbereiten (Tutorial) -'; digg_bodytext = "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"; digg_skin = 'standard';

Mit dem IPhone ist das mobile Internet in eine neue Runde gegangen. Das WAP hat ja nicht wirklich den Durchbruch geschafft. Ich glaube ich war 1x auf einer WAP Seite mit meinem Handy und auch genauso schnell wieder weg. Fürchterlich. Zweckdienlich, aber nicht wirklich spassig.

Jetzt sieht es schon ganz anders aus. Täglich bin ich eigentlich mobile im Internet unterwegs. Zu den Websites welche ich fleissig aufrufe gehören u.a. Tagesanzeiger.ch und Twitter. Erst da merkt man, wie viel angenehmer es ist, auf einer solche Seite zu lesen anstatt eine ganz normale, welche nicht fürs Mobile optimiert ist. Auf diesen Seiten muss man dann nämlich immer blöd nach rechts scrollen. Nervig.

Noch nerviger: Das Feed wird nur als Teaser freigegeben. Das führt dann dazu, dass man auf die Seite gehen muss um den kompletten Eintrag zu lesen und die Seite ist dann meistens nicht für Mobile optimiert -> diese Einträge lese ich dann in vielen Fällen nicht.

Meine Bitte: komplettes Feed rausgeben. Alle Mobileleser werden euch dafür dankbar sein.

Also, ich habe mich immer über mein eigenes Blog genervt. Ich konnte es zwar einigermassen auf meinem Android G1 lesen, aber wirklich gut war auch das nicht. Falls jemand anderer Meinung ist, kann er das gerne im Kommentar geben

Mobile Theme Tutorial - 10 Minuten

Voraussetzungen:

• Browscap installieren.
• [Update] Mobile Theme installieren (danke redpanda)
• Seven Theme aktivieren.

Das ist eigentlich auch schon alles. Das ganze noch konfigurieren und schon macht man alle Mobilebenutzer glücklich:

admin/settings/browscap

admin/build/themes/settings/global

Jetzt noch die Blöcke ein wenig umkonfigurieren. Das Seven Theme kennt links und rechts keine Regions. Sprich, falls man dennoch Blöcke haben möchte, dann würden die wohl ganz unten im Footer am meisten Sinn machen.

Schon fertig und das Internet hat wieder eine Seite mehr, welche auch für Handybenützer einfach lesbar ist. Natürlich lässt sich das ganze noch beliebig ausbauen und verschönern.

Einen kleinen Wehrmutstropfen gibt es allerdings: Falls der Pagecache aktiviert ist, dann funktioniert das ganze nicht. Ausweg: Eine Subdomain, z.B. http://m.rapsli.ch und dann für diese Domain das Theme wechseln.

PS: Irgendwie klappt es nicht so ganz mit Screenshots auf meinem Android. Wäre cool, wenn jemand einen Screenshot irgendwo hochladen könnte. Danke.

 

Verwandte Beiträge:  Drupalseiten einfach für Mobile aufbereiten (Tutorial) - Teil II digg_url = 'http://www.rapsli.ch/drupalseiten-einfach-fuer-mobile-aufbereiten-tutorial'; digg_title = 'Drupalseiten einfach für Mobile aufbereiten (Tutorial)'; digg_bodytext = "Mit dem IPhone ist das mobile Internet in eine neue Runde gegangen. Das WAP hat ja nicht wirklich den Durchbruch geschafft. Ich glaube ich war 1x auf einer WAP Seite mit meinem Handy und auch genauso schnell wieder weg. Fürchterlich. Zweckdienlich, aber nicht wirklich spassig."; digg_skin = 'standard';

 Im Teil II dieses Artikels habe ich die allgemeinen Randbedingungen beschrieben. Hier in diesem Beitrag möchte ich ein paar Aspekte beleuchten: Wo sind Fehler aufgetreten, was ist gut gelaufen, was müssten wir besser machen, usw.

Fangen wir doch mal mit den Positiven Sachen an

• Kunde war alle zwei Wochen für einen Nachmittag bei uns, um das Projekt anzuschauen und offene Fragen zu besprechen, sowie die Planung der nächsten Aufgaben. Das ganze Team war jeweils während des Eröffnungsteils anwesend. Dadurch hatte auch das ganze Team ein "Gespür" für den Kunden.
• Projektstart war extrem positiv. Das Team war voll drin, wurde nicht durch andere Projekte/Arbeiten abgelenkt. Es herrschte super Stimmung. Jeder fühlte sich als Teil des Teams und Projekts. So macht es auch gleich mehr Spass. Die positive Stimmung ist auch immer gut für die Kommunikation. Dailys Scrums waren in dieser Zeit sehr aufgestellt, unterhaltsam und zugleich informativ.
• Drupal ist hervorragend für Scrum geeignet. Bereits nach einigen Tagen gibt es eine funktionierende Anwendung, die zwar noch Ecken und Kanten hat, aber immerhin läuft.
• Unser Scrumboard war zwar sehr einfach, aber sehr effektiv. Wir konnten uns voll und ganz auf den Scrumprozess konzentrieren, ohne dass wir uns noch mit irgendwelchen Tools hätten plagen müssen. Von daher für den Einstieg ein super gute Lösung: Jeder sieht auf einen Blick, wer gerade woran arbeitet und wer evtl. noch Hilfe braucht.

Es gibt aber auch einige Mängel

• Das Projekte verwässerte gegen Projektabschluss: Mitarbeiter wurden aus dem Team gezogen (Todsünde) und viele Ablenkungen durch andere Projekte/Arbeiten waren hier die Hauptkomponenten. Wenn man den Projektverlauf ein wenig genauer anschaut, dann waren die ersten Sprints sehr effektiv: Es gab viel Arbeit, jeder war beschäftigt. Gegen Ende des Projekts gab es dann keine grossen Baustellen mehr, sondern noch schleifen und feilen an den Ecken. Irgendwie gab es hier noch einen Koordinationsmangel im Kleinen.
• Leider mussten wir feststellen, dass der Kunde seinen Pflichten nicht nachkam und so extrem viel Inhalt fehlte. Das führte dazu, dass: Migrationen nicht gemacht werden konnten, ein Gesamtbild der Seite sehr spät möglich war und eben User Stories als (theoretisch) abgeschlossen waren, aber halt noch nicht getestet werden konnten, weil noch Inhalte/Daten Fehlten. Beispiel: Paymentschnittstelle Postfinance. Eingekauftes Modul, installiert. Task abgeschlossen. Es fehlten Zugangsdaten, um das ganze auch richtig zu testen. 1 Monat später kamen die dann: 1/2 Tag Aufwand, um es einzurichten und daraus resultierende Fehler noch zu beheben.

Was würde/werde ich im nächsten Projekt anders machen

Den Kunden noch besser mit einplanen und einbeziehen. Dazu gehört meiner Meinung:

• Dem Kunden bei Projektbeginn klip und klar machen, dass sein Mitarbeiten unbedingt notwendig ist. Auch der Kunde hat Pflichten! Er muss verstehen, dass wenn er seine Sachen nicht tut, die logische Folge ist, dass sich das Projekt verspätet.
• Bessere Definition von fertig. Solange man Userstories abschliessen kann, welche nur die Aufmerksamkeit des Entwicklers brauchen, ist es wohl relativ klar. Sehr oft ist man jedoch auf irgendwelche Daten angewiesen: Zugangsdaten zu Schnittstellen, Musterdaten usw. Fertig ist ein Task erst, wenn diese Sachen mit drin sind ... der Kunde muss das auch verstehen.

 

Verwandte Beiträge:  Scrum in einem Drupalprojekt Scrum in einem Drupalprojekt Teil II digg_url = 'http://www.rapsli.ch/scrum-einem-drupalprojekt-teil-iii'; digg_title = 'Scrum in einem Drupalprojekt Teil III'; digg_bodytext = "\x26nbsp;Im Teil II dieses Artikels habe ich die allgemeinen Randbedingungen beschrieben. Hier in diesem Beitrag m\x26ouml;chte ich ein paar Aspekte beleuchten: Wo sind Fehler aufgetreten, was ist gut gelaufen, was m\x26uuml;ssten wir besser machen, usw."; digg_skin = 'standard';

Vor 2 Wochen habe ich bei ein paar Entwicklern eine kleine Drupaleinführung für Entwickler gemacht. Dabei waren ca. 7 Entwickler anwesend. Einige kamen aus der Joomla Welt (bzw. haben dort Erfahrungen gesammelt) und andere von Typo3. Einen Drupal vs. Joomla Beitrag habe ich ja bereits geschrieben... und der scheint die Gemüter hochzutreiben. Daher ein paar Zeilen zu Drupal vs. Typo3.

Ich muss fairerweise sagen, dass ich keine tiefen Typo3 Kenntnisse habe. Ich habe es vor langer Zeit mal lokal installiert und musste an der Uni einmal ein paar Inhalt ändern. Mag durchaus sein, dass sich seither einiges geändert hat... ich bin schon mal gespannt auf Kommentare 

Wie dem auch sei. Aus dem Gespräch mit den Typo3 Kennern kommt immer das eine oder andere heraus. Typo3 scheint auf jeden Fall ein sehr mächtiges Werkzeug zu sein. Respekt. Der grosse Unterschied zwischen Drupal ist jedoch sehr grundlegend:

Inhalte (sog. Nodes) in Drupal landen alle in einem riesigen Topf. Alle sind gleich. Es gibt keine Struktur und es gibt keine eigentlich Seiten, sondern nur lose Inhalte. Es liegt nun am Bauer einer Seite, diese Strukturen herzustellen, dazu gibt es diverse Möglichkeiten: Taxonomy, Inhaltstypen, CCK.

Typo3, so wie ich das sehe, hat Seiten. Sprich: Ich lege eine Startseite, eine About us und eine Kontaktseite an. Dann kann ich natürlich auch Hierarchien anlegen, welche dann in einem schönen Menubaum dargestellt werden. Ich bearbeite jedoch die Seite als ganzes. Möchte ich also einen Inhalt von A nach B verschieben, dann mache ich das wirklich physikalisch... kopieren (wahrscheinlich kann man auch irgendwelche Verküpfungen machen, sollte ein Inhalt doppelt vorhanden sein).

In Drupal ist wie gesagt der Grundgedanke anders und viel weniger auf solche starren Seiten ausgelegt, sondern Inhalt erstellen und dann über Ansichten an den entsprechenden Orten erscheinen lassen.

So, ich lasse mich sehr gerne belehren... Für alle Drupal Fans: Hier kann man mal ein wenig mit Typo3 spielen.

Hier ein paar Screenshots aus dem Backend, wenn eine Seite erstellt wird:

digg_url = 'http://www.rapsli.ch/umstieg-von-typo3-auf-drupal'; digg_title = 'Umstieg von Typo3 auf Drupal'; digg_bodytext = "Vor 2 Wochen habe ich bei ein paar Entwicklern eine kleine Drupaleinführung für Entwickler gemacht. Dabei waren ca. 7 Entwickler anwesend. Einige kamen aus der Joomla Welt (bzw. haben dort Erfahrungen gesammelt) und andere von Typo3. Einen Drupal vs. Joomla Beitrag habe ich ja bereits geschrieben... und der scheint die Gemüter hochzutreiben. Daher"; digg_skin = 'standard';

Vor zwei Monaten habe ich einen ersten Scrum Erfahrungsbericht geschrieben. Damals standen wir noch am Anfang des Projektes. Jetzt zwei Monate später stehen wir mehr oder weniger am Ende. Ein guter Zeitpunkt, um ein kleines (oder grösseres) Fazit zu ziehen.

Wer nicht weiss, was Scrum ist, soll doch am Besten mal bei Wikipedia vorbeischauen. Dort gibt es eine ausführliche Erklärung

Zuerst einige Randbedingungen:

• Als Backlog dient Jira. Eine ältere Version ohne Agile/Scrum Unterstützung
• Sprintdauer sind zwei Wochen.
• Teamgrösse: 4 Entwickler und 1 Designer
• Das Projekt basiert auf Drupal. Es ist eine Tageszeitung mit diversen Schnittstellen an Redaktionssysteme und SDA.

Der Prozess sah ungefähr wie folgt aus:

1. Retrospektive. Dazu musste jedes Teammitglied zu den folgenden 4 Punkten Auskunft geben:
   1. Teamgeist
   2. Zufriedenheit mit den Tasks
   3. Ablenkung von Aussen
   4. Kommunikation im Team
2. Backlog schätzen. Wir haben es mit sog. Scrum-Pokerkarten gemacht. Ich persönlich fand diese Methode extrem nützlich.
3. Sprint erstmals grob zusammenstellen
4. Dem Kunden als ganzes Team zeigen, was wir gemacht haben
5. Sprint definitiv festlegen
6. Fragen und Details im kleinen Rahmen mit dem Kunden diskutieren
7. ... sprinten... daily scrum ... sprinten ... daily scrum... und dann fängts wieder von vorne an

Für die Sprintplanung haben wir ein einfaches Flipchart verwendet, das ungefähr so aussah:

Die blauen Zettel stellen User Stories dar. Die gelben Zettel die daraus resultierenden Tasks. Die Tafel stand in unserem Büro und so hatte jeder stets im Blick, was noch offen ist.

Von der technischen Umsetzung gingen wir grob gesagt wie folgt vor:

1. Design kam geliefert als Photoshop Datei
2. Drupal Grundinstallation, diverse Grundinhaltstypen
3. Zentrale Elemente für die Zugriffsberechtigung auf Artikel
4. Implementation der diversen Schnittstellen
5. Erstellung der Übersichtsseiten
6. Aufräumarbeiten und der ganze Rest

Die ganzen Entwicklungen haben wir in Features gepackt und dann via SVN regelmässig (1x pro Stunde) auf den Entwicklungsserver gestellt. Dadurch hat jeder Entwickler laufend die Änderungen von den anderen Teammitgliedern auch bei sich gehabt und ist zu jederzeit aufgefordert, Bugs in Jira als solches festzuhalten. Kleinere Bugs haben wir daher nicht immer gleich sofort gesammelt, sondern sog. "Bugdays" geplant, an denen sich das Team ausschliesslich Bugs widmet. In diesem Projekt hielt sich die Anzahl an Bugs massiv in Grenzen (oder kommen noch ;) daher hatten wir auch keine wirklichen "Bugdays".

Damit sind jetzt auch die Randbedingungen klar. Um diesen Eintrag nicht noch weiter in die Länge zu ziehen, werde ich die daraus gezogenen Erfahrungen in einem nächsten Blogpost schildern, denn es gibt doch die eine oder andere Lehre.

 

Verwandte Beiträge:  Scrum in einem Drupalprojekt Scrum in einem Drupalprojekt Teil III digg_url = 'http://www.rapsli.ch/scrum-einem-drupalprojekt-teil-ii'; digg_title = 'Scrum in einem Drupalprojekt Teil II'; digg_bodytext = "Vor zwei Monaten habe ich einen ersten Scrum Erfahrungsbericht geschrieben. Damals standen wir noch am Anfang des Projektes. Jetzt zwei Monate sp\x26auml;ter stehen wir mehr oder weniger am Ende. Ein guter Zeitpunkt, um ein kleines (oder gr\x26ouml;sseres) Fazit zu ziehen.\r\nWer nicht weiss, was Scrum ist, soll doch am Besten mal bei Wikipedia"; digg_skin = 'standard';

Letzte Woche hat mich ein Arbeitskollege gefragt, ob ich kurz ein kleines Teilprojekt schätzen könnte. Hintergrund: Der Kunde wollte ein paar funktionale Erweiterungen für die bestehende Webseite. Mein Arbeitskollege hatte bereits eine Aufwandschätzung gemacht, welche jedoch aus Kundensicht viel zu hoch schien. Also bat er mich, auch einen Blick darauf zu werfen.

Ich kannte das Projekt ein wenig aus der Entwicklungsphase, da ich dort in einigen konzeptionellen Fragen involviert war. Ich hatte jedoch absolut keine Ahnung von den neuen Kundenwünsche und schon gar nicht, was mein Arbeitskollege geschätzt hat.

So machte ich mich an die Arbeit, ich hatte eine Liste mit ca. 10 Punkten aus der Offerte. Ich ging die Liste Punkt für Punkt durch und mir die folgenden Fragen:

• Wie lässt sich der Punkt umsetzen?
• Sind externe System mit involviert?
• Ist Entwicklung notwendig oder lässt sich alles mit bestehenden Modulen umsetzen?
• Gibt es Risiken bzw. Dinge, welche unklar sind?

Je nach dem, wie die Antwort auf die Frage war, wurde der Aufwand ein wenig höher, bzw. ein wenig tiefer. 10x wiederholte ich das Spiel.

Resultat: ca. 20 Personentage Aufwand. Ehrlich gesagt, ich war nervös bzw. aufgeregt, als ich ins Büro nebenan ging. Wieviel würde er wohl geschätzt haben?! 

Auch er hat die Punkte, welche offeriert wurden, einzeln geschätzt. So konnten wir diese Schrittweise durchgehen. Erstaunlich: In den ersten 4 Punkten 100% Übereinstimmung. Es gab 2-3 Punkte, wo es eine ganze kleine Abweichung gab, aber alles in allem doch ein extrem grosse Übereinstimmung.

Fazit: Aufwandschätzungen sind also doch nicht nur Zufall! Besonders das Aufteilen in kleinere Teilaufgaben war extrem hilfreich. Wenn man dann noch ein bisschen was fürs Projektmanagement hinzufügt, sowie eine gesunde Reserve ist man sicher auf der richtigen Spur.

Problem ist dann halt meistens nur, dass das Marketing den Preis drückt, um Konkurrenzfähig zu bleiben... danach fragt man sich, warum es mit dem Budget nicht aufgegangen ist... aber das ist dann nicht mehr ein Entwicklerproblem.

Besonders für Drupalprojekte habe ich die Erfahrung gemacht, dass es einige Punkte gibt, welche den Aufwand fast ausnahmslos steigen lassen:

• Migration von bestehendem Inhalt. Wird immer unterschätzt, da von einer idealisierten Umwelt ausgegangen wird. In der Realität sind oftmals die Daten schlecht, müssen noch umgewandelt werden usw.
• Jegliche Interaktion mit unbekannten Drittsystemen. Auch wenn es noch so trivial ausschauen mag... irgend eine Tücke ist noch drin.
• Mehrsprachigkeit. In Drupal grundsätzlich kein Problem, aber im Detail, gibt es immer wieder ein Modul, welches (noch) nicht mehrsprachig ist oder irgendwo Zeichenketten, welche sich nicht übersetzen lassen.

Dies sind besonders in der Medienbranche immer wieder auftauchende Anforderungen und oftmals auch immer wieder Risikotreiber.

digg_url = 'http://www.rapsli.ch/aufwandschaetzungen-sind-doch-kein-zufall'; digg_title = 'Aufwandschätzungen sind doch kein Zufall'; digg_bodytext = "\r\nLetzte Woche hat mich ein Arbeitskollege gefragt, ob ich kurz ein kleines Teilprojekt sch\x26auml;tzen k\x26ouml;nnte. Hintergrund: Der Kunde wollte ein paar funktionale Erweiterungen f\x26uuml;r die bestehende Webseite. Mein Arbeitskollege hatte bereits eine Aufwandsch\x26auml;tzung gemacht, welche jedoch aus Kundensicht viel zu hoch schien. Also bat er"; digg_skin = 'standard';

Habe soeben gerade gesehen, dass die 1. Beta Version für Drupal 7 bereit zum Download ist :)

Muss ich doch mal schauen, ob die benötigten Module auch bereits eine Alpha oder Dev Version haben, dann könnte ich schon mal das Blog migrieren. Auch sollte ich mich mal wieder an die Arbeit für Fast Gallery machen, damit die D7 Version wieder richtig funktioniert. 

digg_url = 'http://www.rapsli.ch/1-beta-version-fuer-drupal-7'; digg_title = '1. Beta Version für Drupal 7'; digg_bodytext = "Habe soeben gerade gesehen, dass die 1. Beta Version f\x26uuml;r Drupal 7 bereit zum Download ist :)\r\nMuss ich doch mal schauen, ob die ben\x26ouml;tigten Module auch bereits eine Alpha oder Dev Version haben, dann k\x26ouml;nnte ich schon mal das Blog migrieren. Auch sollte ich mich mal wieder an die Arbeit f\x26uuml;r Fast Gallery machen, damit die D7"; digg_skin = 'standard';

This is a quick start for setting up a Fast Gallery. I did this with Fast Gallery 5.5 and Drupal 6.17.

First a quick introduction on how Fast Gallery works. Basically Fast Gallery displays a pictures from a folder, just like you know it from Windows Explorer. So lets say you uploaded 50 pictures to your site via FTP, you point your gallery to the folder, then user is presented those 50 pictures. If there are subfolders, the user can just click on the folder and will see the pictures from this subfolder (just like in Windows Explorer).

1. Copy the latest version of Fast Gallery into your modules folder
2. Install Fast Gallery
3. Install Imagecache and setup two presets: "thumbs" and "full" (for example)
4. Go to admin/settings/fast_gallery/general. Here we are going to setup a gallery
5. On the top we got three text fields: "Path to Gallery", "Path Alias" and "Title of Gallery". Path to gallery would the folder where the images are located relative to the Drupal index.php, so for example sites/default/files/galerie. Path Alias, would be any alias, so for example: my_gallery, and the "Title fo Gallery" could be something like "My first Fast Gallery"
6. There are two dropdowns for selecting imagecache presets. Since you created two imagecache presets previously you can select them now here
7. On the same page we we have other options, which we can leave as they are
8. Hit the submit button
9. That's it, you are done! Go to http://mysite.com/my_gallery and you should see some images

German Version

Verwandte Beiträge:  Fast Gallery - Step by Step digg_url = 'http://www.rapsli.ch/fast-gallery-quickstart'; digg_title = 'Fast Gallery - Quickstart'; digg_bodytext = "This is a quick start for setting up a Fast Gallery. I did this with Fast Gallery 5.5 and Drupal 6.17.\r\nFirst a quick introduction on how Fast Gallery works. Basically Fast Gallery displays a pictures from a folder, just like you know it from Windows Explorer. So lets say you uploaded 50 pictures to your site via FTP, you point your gallery to the"; digg_skin = 'standard';

Es scheint, als hätte die Twitter API geändert. Alle die, welche das Twitter Module im Einsatz haben, werden somit ein kleineres Problem haben, da das Posten nicht mehr funktioniert. Schade, dass das Twitter Modul nicht sehr aktiv ist, denn sonst wäre bereits eine aktuelle Version vorhanden. Ist eigentlich sehr erstaunlich, da es immerhin 15000 Installationen des Moduls gibt. Mal schauen, dass ich hier eine Lösung finde.

digg_url = 'http://www.rapsli.ch/twitter-api-geaendert'; digg_title = 'Twitter API geändert'; digg_bodytext = "Es scheint, als h\x26auml;tte die Twitter API ge\x26auml;ndert. Alle die, welche das Twitter Module im Einsatz haben, werden somit ein kleineres Problem haben, da das Posten nicht mehr funktioniert. Schade, dass das Twitter Modul nicht sehr aktiv ist, denn sonst w\x26auml;re bereits eine aktuelle Version vorhanden. Ist eigentlich sehr erstaunlich, da es"; digg_skin = 'standard';

With the 5er version Fast Gallery got so much more handy. The latest changes with the plugable Frontend make development for fast gallery a pleasure as you don't have to be afraid anymore killing the whole module when you only want to switch presentation. It's really a charm.

Well, somebody asked about 
http://www.cooliris.com/ support. I do think this does look really cool. So I looked into it. The bummer is, the cooliris needs a feed... which is kinda cool, but again for Fast Gallery not really handy. Well here is my plan of attack: Use the fast gallery API module (which I started developing, but kinda lost interest).

The in detail plan looks like this:

1. Extend hook_fast_gallery_info

Allow two more parameters: type and source. Type would be "feed" and source would be the base path of where to find the feed (something like fast_gallery_api/get)

2. Fix fast gallery api module

As said this needs some love. Probably we just need to test it a little be in depth, maybe an additional handler and make sure that the feed is being outputted correctly so that cooliris will understand the format.

3. embed cooliris

That's probably going to be the easiest part. Just past in the object tag and point the source to where specified.

I guess 1 and 3 are a matter of 15 minutes, while 2 is going to take some time. So if any of you guys wants to help... Get your hands dirty and start coding. The plattform for patches would be in the fast gallery issue queue.

digg_url = 'http://www.rapsli.ch/cooliris-integration-my-plans'; digg_title = 'Cooliris Integration - My Plans'; digg_bodytext = "With the 5er version Fast Gallery got so much more handy. The latest changes with the plugable Frontend make development for fast gallery a pleasure as you don\'t have to be afraid anymore killing the whole module when you only want to switch presentation. It\'s really a charm."; digg_skin = 'standard';

Heute mal wieder ein wenig an Fast Gallery gebastelt. Hier was dabei herausgekommen ist. Das Galleria Modul wird integriert (Galleria ist dazu nicht notwendig). Fast Gallery hat die nötige Javascript Bibliothek mit dabei.

Galleria Ansicht sieht dann wie folgt aus.

Die Standardansicht sieht wie folgt aus:

Für Entwickler ist zudem weiter interessant, dass das Frontend plugable ist. Das will heissen, es muss lediglich ein Hook implementiert werden, und dann kann ein zusätzliches Frontend inzugefügt werden. Ich bin noch auf der Suche nach coolen Galerien.

Wäre cool, wenn jemand den Hook implementiert und ein Frontend für Fast Gallery schreibt. Die Galleria Ansicht braucht noch ein wenig Arbeit (Ordner und Titel müssen noch unterstützt werden), aber das ist a

Verwandte Beiträge:  Fast Gallery - Introduction for developers digg_url = 'http://www.rapsli.ch/fast-gallery-654-galleria-integration'; digg_title = 'Fast Gallery 6.5.4 - Galleria Integration'; digg_bodytext = "Heute mal wieder ein wenig an Fast Gallery gebastelt. Hier was dabei herausgekommen ist. Das Galleria Modul wird integriert (Galleria ist dazu nicht notwendig). Fast Gallery hat die n\x26ouml;tige Javascript Bibliothek mit dabei.\r\nGalleria Ansicht sieht dann wie folgt aus.\r\n\r\nDie Standardansicht sieht wie folgt aus:"; digg_skin = 'standard';

Seit einigen Wochen setzen wir ernsthaft Scrum als Projektmethodik ein. Noch gibt es vieles zu lernen, aber die ersten Wochen sind sehr positiv verlaufen. Hier ein paar Grundsätze:

• Team besteht aus 4 Entwickler und 1 Designer
• Productowner ist leider nicht auf Kundenseite
• Scrummaster (auch Mitglied des Teams)
• Sprints dauern 2 Wochen
• Team arbeitet pro Woche 3 Tage am Projekt (grundsätzlich Di - Do)

Da die ganzen Scrummethodik noch sehr jung ist, haben wir beschlossen, bereits nach einer Woche eine kleine Retrospektive zu machen. Daraus resultierten 3-4 Punkte konkrete Punkte, welche wir ändern/verbessern wollen (nicht nötig dafür noch eine weitere Woche zu warten, besonders da die Projektdauer sehr kurz ist).

Fazit: Sehr positiv. Besonders hervorzuheben ist vor allem die Motivation und der Teamgeist, welcher viel stärker zur Geltung kommt. Jeder ist bedacht, die Tasks bis zum Sprintende zu erfüllen und auch bereit Aufgaben von anderen Mitgliedern zu erfüllen. Dadurch entsteht ein viel besserer Wissenstransfer.

Negativ: Kommunikation zum Kunden hin noch nicht optimal. Bei offenen Fragen dauert es einfach noch zu lange, bis Antworten zurückkommen. Ist nicht direkt etwas, was wir ändern können, aber muss sicher bei Projektbeginn klip und klar kommuniziert werden und vor allem müssen auch die Konsequenzen aufgezeigt werden: Verzögerung des Projektes.

Und das Beste: Man kann die ganzen Scrumansätze den eigenen Gegebenheiten und Eigenheiten anpassen. Ich kann es also nur weiterempfehlen.

Verwandte Beiträge:  Scrum in einem Drupalprojekt Teil II digg_url = 'http://www.rapsli.ch/scrum-einem-drupalprojekt'; digg_title = 'Scrum in einem Drupalprojekt'; digg_bodytext = "Seit einigen Wochen setzen wir ernsthaft Scrum als Projektmethodik ein. Noch gibt es vieles zu lernen, aber die ersten Wochen sind sehr positiv verlaufen. Hier ein paar Grunds\x26auml;tze:"; digg_skin = 'standard';

This blogpost should give a quick kickstart to every developer who is interested in helping to advance Fast Gallery. The architecture is intended to have a swapable storage engine. So far I've only written one storage engine, which means that interfaces are not 100% clearly defined, but would instead need some work when actually going to be used in practice. First a quick overview over the files and what their responsibilities are.

• fast_gallery-image-wrapper.tpl.php: template file to display the image
• fast_gallery.admin.inc: the general admin stuff (UI), that would be used by any storage engine (setting up galleries, scanning galleries...)
• fast_gallery.cache.class.php: incase Imagecache is not available there's a simple caching class, that creates thumbnails and caches them.
• fast_gallery.class.php: this is the heart of the module. Here we recursively explore directories for images and send them to the storage engine or get images from the storage engine and return them to the frontend
• fast_gallery.css: if you are developing, you should know what this is for ;)
• fast_gallery.info: same here
• fast_gallery.install: and same here
• fast_gallery.module: Mostly it's just implementations of hooks and actually displaying the gallery in fast_gallery_alias()
• fast_gallery.test: I started once writing some tests.... this really needs some work!
• FGImage.class.php: Internally Fast Gallery treats images as objects of this class.

Ok, then we have a couple folders:

• images: just some images
• integrations: possible integrations into other modules. So far: features integration
• modules: Other modules for fast gallery. I started once the Fast Gallery API module, which should provide some kind of REST API... but it's not there yet
• storageengine: well this contains some classes and interfaces that are responsible for actually storing and retrieving images and hierarchy retrieved from directories
• tests: just some folders that are used when doing the simpletests

Just some more info on the storageengine folder:

• Istorage.php: contains and interface that all possible storageengines must implement.
• default.config.inc: Well, just some UI stuff for storageeninge specific configuration
• default.storage.inc: the actual storage engine, that stores data into the db, makes sure hierarchy is correct and returns the right images depening on the path.
• node.config.inc, node.storage.inc: sample data to build a nodestorage, which was actually my goal at a given point.... but unfortunately not there yet :(

Oky, this is the first attempt. I'll write another blogpost and describe some of the important concepts in detail.

digg_url = 'http://www.rapsli.ch/fast-gallery-introduction-developers'; digg_title = 'Fast Gallery - Introduction for developers'; digg_bodytext = "This blogpost should give a quick kickstart to every developer who is interested in helping to advance Fast Gallery. The architecture is intended to have a swapable storage engine. So far I\'ve only written one storage engine, which means that interfaces are not 100% clearly defined, but would instead need some work when actually going to be used in"; digg_skin = 'standard';

In der neuen Version von Fast Gallery gibt es mal wieder ein neues Feature. Bilduntertitel können über IPTC ausgelesen werden. Dabei gibt es mehrere zur Auswahl. Sehr oft ist es jedoch der Fall, das noch gar keine IPTC Daten vorhanden sind. In dem Fall können diese jetzt gleich direkt in der Galerie editiert werden und werden dann ins Bild gespeichert.

Patrick war so freundlich und hat dafür einen Patch geschrieben. Fertig sieht es dann in etwa so aus:

Zudem konnte im neuesten Release auch noch ein Bug behoben werden, so dass auch falls der Ordner leer ist, die Unterordnet aufgelistet werden.

Dieses Feature basiert auf dem jQuery Edit in Place Plugin, welches separat heruntergeladen und installiert werden muss.

digg_url = 'http://www.rapsli.ch/inplace-editing-fast-gallery'; digg_title = 'Inplace Editing - Fast Gallery'; digg_bodytext = "In der neuen Version von Fast Gallery gibt es mal wieder ein neues Feature. Bilduntertitel k\x26ouml;nnen \x26uuml;ber IPTC ausgelesen werden. Dabei gibt es mehrere zur Auswahl. Sehr oft ist es jedoch der Fall, das noch gar keine IPTC Daten vorhanden sind. In dem Fall k\x26ouml;nnen diese jetzt gleich direkt in der Galerie editiert werden und werden dann"; digg_skin = 'standard';