Green Energy

Windräder mit grüner Wiese

Windräder in Südspanien

Dieses Bild hat mein Bruder 2011 in Südspanien aus dem Auto fotografiert. Wir hatten da schon ca. 4000 Kilometer hinter uns. Die Fahrt ging über Südfrankreich nach Nordspanien und von dort aus quer durch Portugal und über Südspanien zurück nach Deutschland.

Steuerelemente gehören dem Betriebssystem

KlaviertastenAuf Internetseiten wird immer wieder probiert durch besonderes Styling der Steuerelemente wie Forumlareingabe/-auswahlfelder oder Buttons das CI des Unternehmens zu untermalen bzw. zu verstärken. Ich kann verstehen, dass man sein Portal oder seine Firmenseite natürlich sehr individuell gestalten möchte, damit sich beim Besucher ein hoher Widererkennungswert einstellt. Leider geht das auf die Kosten der Usability.

“Ein Steuerelement gehört dem Betriebssystem”

Es wird einem Webentwickler sehr schwer gemacht Formularfelder, Buttons, Scrollbars und andere Steuerelemente optisch anzupassen. Das hat einen Grund. Das W3C (Word Wide Web Consortium) hat etwas dagegen. Dort sitzen Leute die Standards für das Web festlegen. Warum machen die das? Ganz einfach, damit ein Benutzer des Internets dieses einfacher und sicherer bedienen kann, damit er schneller und sicherer zum Ziel kommt. Man kann das im weitesten Sinne mit der ISO (International Organization for Standardization) vergleichen. Dort werden auch Standards festgelegt. Z.B. für Stecker. Stell dir einmal vor jeder Hersteller würde seinen eigenen Stecker für den Stromanschluss für seine Geräte Entwickeln. Ohne Handbuch und jeder Menge Adapter wäre das Versorgen mit Strom einzelner Geräte nicht mehr möglich.

Ähnlich kritisch ist das eben mit Steuerelementen im Internet. Da hat das Betriebssystem wie Windows, OS X oder z.B. Linux die “Oberhand”. Es wird davon ausgegangen, das der Benutzer sich an das Verhalten von Steuerelementen so wie sie im Betriebssystem reagieren gewöhnt hat.

Wenn jetzt in Webportalen Buttons andere Formen und Farben bekommen, erkennt der Besucher sie nicht mehr auf den ersten Blick.

Genauso sieht es auch mit allen anderen Steuerelementen aus. Der Benutzer nimmt diese nicht mehr direkt wahr. Er benötigt eine Lernphase um mit dem Webportal umzugehen. Jetzt denken sich aber viele Unternehmen, dass diese kurze “Eingewöhnungszeit” im Gegensatz dazu, dass der Benutzer stärker an das CI gebunden wird tolerierbar ist. Dann überlege dir mal, wieviele Internetseiten es gibt! Wenn jede Internetseite ihre eigenen Steuerelemente mit sich bringt, wird der Benutzer vielleicht keine Lust haben sich damit zu beschäftigen. Oder er wird es einfach nicht verstehen. Viele Leute haben schon Probleme sich an die Steuerelemente von z.B. Windows zu gewöhnen. Gerade die älteren. Wenn jetzt auf einmal in einem Webportal ein Button schon wieder anders aussieht, kommt er damit nicht zurecht.

Webseiten sind erstmal ein weißes Blatt Papier.

Unternehmen haben hier wirklich mehr als genug Möglichkeiten ihr CI und weitere Kreativität unterzubringen. Aber bitte lasst die Steuerelemente wie sie sind! Die Usability der Webseite wird so darunter leiden, dass dies in beinah allen Fällen Auswirkungen auf die Akzeptanz der Website hat.

Denke einfach noch mal über das Beispiel mit dem Stromstecker vom Anfang nach. Oder machen wir es noch einfacher. Nimm z.B. ein Lenkrad. Ich könnte mir noch mindestens 10 andere Möglichkeiten vorstellen wie man ein Auto steuern könnte. Trotzdem wäre die Akzeptanz bei den Fahrern wohl eher gering. Die Autohersteller wissen dass der “Benutzer” sich an dieses Steuerelement gewöhnt hat. Deshalb kommt dort auch niemand auf die Idee es zu ändern. Schwarz und Rund muss es sein. Dann erkennt jeder direkt, was er damit machen muss. Genau so ist es mit dem Button auf Ihrer Internetseite:

“Grau und eckig muss er sein.”

Dann ist jedem Benutzer sofort bewusst: Das ist ein Button. Wenn ich da draufdrücke passiert irgendwas.

Treeline.de – Ein Magentoshop für Snowboards & Co.

Treeline.deScreenshot von Treeline.de - Snowboard Onlineshop (Magento)
Screenshot von Treeline.de – Snowboard Onlineshop (Magento)

Der Inhaber von Beatnuts Bergstrasse in Bensheim kam Anfang 2011 auf mich zu, weil er einen Magento-Entwickler suchte der aber auch Ahnung von der Snowboard-Szene hat. Einen Onlineshop für sein Unternehmen wünschte er sich schon länger. Leider hat es nie so ganz geklappt, weil immer wieder technische Probleme auftraten.

“Der Letzte Versuch”

Mit meiner Unterstützung sollte der letzte Versuch gestartet werden. Das System war bereits gesetzt. Es sollte ein Magento-Shop werden. Da ich bereits einige Erfahrung im Bereich Magento-Entwicklung hatte (auch in Großprojekten) konnte ich ihm nach einer Grobschätzung zuversichtlich mitteilen, dass er bis Ende Februar 2011 einen funktionierenden Magento-Onlineshop haben wird. Auch wenn er mir nicht ganz so zu glauben schien, weil er schon mehrere schlechte Erfahrungen diesbezüglich gemacht hatte, blieb ich meiner Sache zuversichtlich. In meiner jahrelangen Tätigkeit als Webentwickler in Mainz wusste ich um die Risiken und Schwierigkeiten und konnte diese bereits in meine Schätzung mit aufnehmen.

Nach einer Entwicklungszeit von ca. einem Monat und ausgiebigem Testen und parallelem Einpflegen von Produkten war es dann Anfang März soweit.

“Der neue Magento-Shop startete mit dem Namen Treeline.de”

Thomas hatte sich entschieden seinen Shop unter der URL treeline.de zu starten. Der Shopname hat sich mittlerweile soweit durchgesetzt, dass sogar der echte Shop in Bensheim und seine bestehende Facebook-Fanpage umbenannt wurde! Alles in allem also ein glücklicher Kunde.

Auch nach der ersten Implementierung gibt es seit dem immer wieder viel zu tun im Shop. Durch ein Ticketsystem behält sowohl treeline.de als auch ich immer den Überblick was noch in welcher Priorität ansteht und welche Features in welcher Zeit noch möglich sind. Entwickungstechnisch ist die Magento-Instanz in einem SVN gehostet und neuere Versionen und Anpassungen werden nach lokaler Implementierung mit Hilfe von Beanstalk nach einem ausführlichen Test auf dem angelegten Testserver automatisiert veröffentlicht. So macht Magento-Entwicklung Spaß.

Abschließend noch mal Danke an Thomas für das coole Projekt! Ich hoffe, dass treeline.de weiterhin wächst und auch noch die nächsten Jahre viel zu erweitern ist ;) Mir hat es auf jeden Fall Spaß gemacht und gezeigt, dass sich eine gute und ehrliche Zusammenarbeit mit dem Kunden am Ende auszahlt.

Ist Scrum das richtige Framework für unser Projekt?

Scrum” ist ein Wort das man derzeit recht häufig in vielen Entwicklungsbüros und Chefetagen hört. Endlich gibt es eine Methode um komplexe Software oder Produkte zu entwickeln ohne das Risiko des Misserfolgs, weil Deadlines nicht eingehalten werden können oder weil Probleme durch falsche Konzeption enstehen die das komplette Endprodukt gefährden. Mit Scrum kann man also ab sofort nichts mehr falsch machen! Das hochqualitative Endprodukt wird schneller und mit weniger Aufwand fertig. Und weil das noch nicht reicht: Auch die Kosten werden niedriger ausfallen. Warum ist da eigentlich vorher noch keiner drauf gekommen?

Das Framework für agile Software-/Produktentwicklung taucht erstmals in einem Buch von Ken Schwaber und Mike Beedle auf. Seit dem zieht Scrum immer mehr in Teams, Unternehmen und mittlerweile sogar in Konzernen als Wundermittel ein.

Dabei steht schon in den ersten Büchern, dass Scrum Probleme nicht lösen kann, sehr wohl aber diese aufzudecken und zu lokalisieren vermag.

Wie, Scrum löst keine Probleme sondern macht welche? Das wurde wohl bei den meisten Präsentationen von Vertrieblern, Projektmanagern und anderen Scrum-Infizierten vergessen zu erwähnen. Ich wiederhohle noch mal: Scrum deckt Probleme auf! – Jetzt fragen sich einige: “Was für Probleme, wir haben doch garkeine!” – Dann komme ich mal mit der Gegenfrage: “Warum dann überhaupt etwas ändern? Dann bleibt doch bei eurem alten Wasserfallmodell wenn alles so problemlos ist!”

Zehntausende von verstrichenen Deadlines oder nie fertig gestellten Produkten und Millionen von Überstunden sprechen leider eine andere Sprache. Die Wahrheit ist: Die Projekte werden immer komplexer, die Anforderungen immer kurzlebiger. Das ist mit konventionellen Methoden nicht mehr kontrolliert abbildbar. Oft landen ganze Projekte auf dem Müll, weil sich die Welt nach der eigentlich Konzeptionsphase schon x-mal um sich selbst gedreht hat und das fertig Konzeptionierte noch vor Beginn der Entwicklung nicht mehr aktuell ist. Und da kommt jetzt Scrum herbei und verspricht eben diese Probleme unter Kontrolle zu bringen – entschuldigung, ich meine natürlich: diese Probleme aufzuzeigen. Ich sag es noch mal: AUFZUZEIGEN!

Aber was soll jetzt diesen “Aufzeigen” bringen? Ganz einfach: Es soll dem Team ermöglichen strukturiert an Problemlösungen zu arbeiten. Und mit Team meine ich nicht nur die Programmierer die das Produkt oder die Software erstellen. Zu einem Scrum-Team gehört auch der Kunde, bzw. Product Owner wie er in Scrum-Teams genannt wird. Auch er ist ein Produktentwickler. Daraus ziehe ich den Schluss:

Totale Transparenz. Keine Hierarchie.

Das muss jedem der in einem Scrum-Team arbeitet bewusst sein. Mitdenken, Verantwortung, Teilen. Wen das einer nicht kann oder will, ist das Scrum-Team gefährdet. In der Praxis sieht es häufig so aus, dass der Auftragnehmer Teams stellen kann, die dazu in der Lage sind. Aber was ist mit dem Auftraggeber? Auftraggeber sind es gewohnt, einen Wunsch in form eines Pflichtenhefts zu äußern, der dann auch umgesetzt wird. Dafür bezahlt man ja Geld, oder nicht? In einem Scrum-Projekt ist das nicht ganz so. Hier wird davon ausgegangen, dass der Auftraggeber (Produkt Owner) seinen “Wunsch” Stück für Stück mit dem Team über einen großen Zeitraum erarbeitet. Und in dem Wort “erarbeitet” liegt häufig das Problem. Man erteilt ja einen Auftrag um eben Zeit für andere Arbeit zu haben. In Scrum-Teams ist es jetzt aber so, dass der Product Owner ein Glied in der Kette ist dessen Arbeitskraft genauso gefragt ist wie jedes anderen Teammembers. Nur wenn das gegeben ist, wird ein Scrum-Projekt zum Erfolg führen! Um Enttäuschungen vorzubeugen und Entscheidern eine Hilfe zu geben ob Scrum das richtige Framework für deren Projekt ist kommentiere ich anschließend ein paar Zitate über Scrum die ich im Netz gefunden habe:

“Scrum kann keine Erfolgsgarantie bieten.”

Wie schon bereits oben erwähnt: Scrum zeigt Probleme auf. Lösungen müssen vom Team erarbeitet werden.

 

“Wer Scrum macht, muss sich darauf einstellen, dass seine Erwartungen permanent enttäuscht werden.”

Scrum ist dazu da so schnell wie möglich die Abweichungen vom Soll-Zustand aufzuzeigen um schnell darauf reagieren zu können.

 

“Der Erfolg hängt davon ab was das Team aus den gewonnen Erkenntnissen macht.”

Das Team ist dazu angehalten auf aktuelle Probleme zu reagieren. Und mit Team ist jeder einzelne gleichermaßen gemeint.

 

“Die Selbstorganisation im Entwicklungsteam beinhaltet den Grundsatz, dass es im Team keine permanente Hierarchie geben darf.”

Mitglieder die nicht bereit sind ihren bisherigen Status aufzugeben führen zu Konflikten.

 

“Von Scrum wird gefordert, dass prinzipiell alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können.”

Jedes Mitglied soll die Rolle von jedem anderen einnehmen können. Jeder ist Architekt, Programmierer, Tester, …

 

Wenn nach dem Artikel Zweifel aufkommen, dass Scrum vielleicht nicht das richtige Framework für das Projekt ist gibt es zwei Möglichkeiten.

  1. Scrum ist nicht die richtige Mehtode für das Projekt.
  2. Du bist nicht die richtige Person für das Projekt.
Wem das Aufzeigen von Problemen nicht reicht und sich doch für eine konventionelle Methode entscheidet, hat eben genau dieses “Aufzeigen” auch noch verloren.
Scrum ist ehrlich und transparent. Und Transparenz und Ehrlichkeit ist im politischen Umfeld von Konzernen nicht immer so einfach umsetzbar oder manchmal auch einfach nicht erwünscht.

SVN/Git-Hosting bei Beanstalk

Logo von Beanstalk (beanstalkapp.com)Wer häufig Produktionssysteme in verschiedenen Projekten aktualisieren muss, sucht früher oder später nach einer Möglichkeit das ganze zu automatisieren. In professionellen Projekten ist eine anständige Versionsverwaltung wie zum Beispiel SVN oder Git sowieso Voraussetzung. Wenn jetzt das eigene Unternehmen nicht groß genug ist für die Versionsverwaltung eigene Server bereitzustellen, oder die Unternehmensstruktur so aufgebaut ist, dass mehrere Entwickler von den verschiedensten Orten der Welt an einem Projekt arbeiten, denkt man vielleicht darüber nach das Hosting des Sourcecodes auszulagern.

Eine Lösung dafür ist Beanstalk. Nach dem Vergleich von mehreren Anbietern habe ich mich für Beanstalk entschieden. Unter anderem war der Grund die offene Unternehmenspolitik und die Deployment-Features. Gerade die angesprochen Deployment-Features haben mit in der Praxis einige Arbeit abgenommen. Kein stundenlanges schnüren von Paketen die auf dem Server entpackt und angepasst werden müssen. In Beanstalk gibt man einmal an von welchem Branch wohin deployed werden soll und kann jederzeit ein Deplyoment starten. Wenn sich in großen Projekten nur wenige Dateien relativ zum letzten Deplyoment geändert haben, werden auch nur diese veröffentlicht. Wichtig: Es werden auch Dateien gelöscht wenn diese aus dem Repository gelöscht wurden (das hat leider bei anderen Anbietern die ich getestet habe nicht immer ganz so gut funktioniert).

Auch das Zurücksetzen auf eine ältere Version ist kinderleicht.

Ist bei der Entwicklung eines neuen Releases doch mal etwas schief gegangen, oder hat man aus Versehen eine falsche Version “deployed”  ist das auch kein Problem. Genauso leicht wie man eine Version veröffentlicht hat, lässt sich diese auch wieder auf eine frühere zurücksetzen.

Im Notfall ist es natürlich immer so, dass man keinen Zugriff auf seinen eigenen Rechner hat um Modifikationen am Sourcecode vorzunehmen und diese dann entsprechend zu “committen”.

Für das “Durchbrowsen” und Ändern der Repositories bietet Beanstalk auch eine eigene Weboberfläche.

Hier kann man Dateien ändern, löschen, hinzufügen oder sich das Changeset ansehen. Wem das noch nicht ausreicht und noch mobiler sein möchte lädt sich einfach die passende iPhone-App herunter. Da der Anbieter eine API bereitstellt, gibt es auch Plugins und Implementierungen für viele Systeme wie z.B. Basecamp oder GitTower. Mehr Infos zu den verschiedenen Tools finden sich hier.

Das eigene Deplyoment ist dann wirklich schnell eingerichtet.

Die Weboberfläche fragt nach dem Server und den entsprechenden FTP-Zugangsdaten und nach dem Repository-Ordner der veröffentlicht werden soll. Dann kann man sich entscheiden ob automatisch (also z.B. bei jedem Commit) oder manuell deployed werden soll. Ganz so viel Vertrauen habe ich dann doch nicht, weshalb ich mich für “manuell” entschieden habe ;) – Wer möchte kann auch noch Pre- und Post-Deployment-Scripts auf seinem Server anlegen die entsprechend ausgeführt werden. Anwendungsfälle hierfür werden z.b., dass man einen Webshop während des Deplyoments automatisch Maintenance-Mode setzen möchte. Oder man möchte automatisch eine neue Versionsnummer in seinem Bugtracker hinzufügen lassen.

Fazit:

Alles in allem sehr hilfreich und hat auch noch Potential zum Wachsen. Mir hat es zumindest geholfen meine Projekte (hauptsächlich Magento-Shops) ordentlich zu verwalten und ohne Probleme und Stress zu “deployen”. Wer Beanstalk erstmal Testen möchte kann sich einen Trial-Account anlegen. Dieser beinhaltet 100 MB Storage, einen User und ein Repository. Den Bronze-Plan mit 3 GB Storage, 5 Usern und 10 Repositories gibt es dann auch schon für 15 $. Für den Service und vor allem die spätere Zeitersparnis auf jeden Fall erschwinglich.

Mehr Infos zu Beanstalk auf http://beanstalkapp.com/.