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/.

Hallo (halbfertiger) Blog

So, nach langer langer laaaaaaaaaaaaaanger Pause bin ich wieder zurück mit meinem persönlichen Blog. Irgendwie plane ich seit Jahren mal wieder einen Blog aufzusetzen um regelmäßig meine Gedanken zu dem ein oder anderen Thema zu veröffentlichen. Aber leider kommt immer das nächste große Projekt in den Weg.

Und dann ist da noch dieser Drang als Webentwickler auch einen perfekten, technisch und optisch einwandfreien Blog zu starten. Wie sieht das denn sonst aus? – Ein mittelmäßiger Blog von einem Webentwickler der normalerweise an hochqualitativen Projekten arbeitet?! Aber ich sag euch wie es aussieht:

“Ich habe mich vorerst von der Perfektion getrennt.”

Aus Erfahrung kann ich sagen, dass zu viele Projekte daran scheitern, dass man mit einem perfekten Produkt starten möchte. Aber das gibt es eben nicht. Oder eben nur für sehr sehr viel Geld. Und das habe ich nicht (wer hat das schon). Und wer weiß, vielleicht will ja auch niemand meinen Blog lesen. Blöd wenn ich dann soviel Zeit investiert habe. Also: Um so mehr Leute diesen Blog hier lesen umso mehr werde ich das Teil auch optisch und technisch verbessern. Ich bin privat jetzt quasi im Scrum-Modus. Und weil ich mein eigener Productowner bin, wird das wahrscheinlich auch gut gehen.