Hier noch die offizielle Ankündigung:

Die Mobile Developer Conference (MDC), die Konferenz für Mobile-Entwickler, findet vom 13. – 14. Februar 2012 zum vierten Mal im Radisson Blu Hotel in Hamburg statt. Nach dem Start 2011 in den deutschen Großstädten München, Köln und Hamburg wird die Konferenz um einen weiteren Tag und einen Thementrack in Hamburg erweitert.

Ein breites Wissen der mobilen Plattformen ist heutzutage erforderlich – auch Themen wie Marketing der App sind relevant. Die Verzahnung mit der IT-Infrastruktur im Unternehmen erfordert ein hohes Maß an Prozessen in mobilen Projekten. Die Mobile Developer Conference widmet sich diesen Themen ausführlich. Aktuelle Trends und Lösungen werden Ihnen präsentiert, damit Sie für Ihre Projekte gerüstet sind.
 

So wie es aussieht werde ich beim abendlichen Feiern/Essen dabei sein. Wer mich also sieht, am besten ansprechen und ein Bier zischen.

So, ich habe ja gerade geschrieben, dass es im Job gerade ein wenig mehr zu tun gibt, als sonst, was wohl auch daran liegt, dass ich neben dem Qualitätsmanagement nun auch die Scrum-Master-Rolle übernommen habe. Und wenn man in einer Rolle aufgeht, dann arbeitet man ja auch gerne mal ein wenig länger. Da wir aber gerade beim Thema sind, handelt der heute Artikel auch von Scrum und dem Schätzen von Stories.

Es ist schon eine Weile her, aber wir haben hier im Blog mal eine Möglichkeit vorgestellt, wie man möglichst gut im Team schätzen kann. Planungspoker war da unser Tipp und ist es auch immer noch. Für mich ist das Pokern die Lösung, die zu den besten Ergebnissen kommt. Nur leider hat es ein Problem: Es dauert ewig. Wenn wir gerade am Anfang eines Projektes auf Planungspoker setzen und sagen wir mal 100 Stories (was eher einem kleineren Projekt entspricht) haben, dann könnt ihr euch ja vorstellen, was es bedeutet bei jeder dieser Stories eine geheime Schätzung abzugeben und danach in Diskussion einen Konsens im Team zu finden. Nach meiner Erfahrung kann man die Teammitglieder nach zwei Stunden eh nicht mehr Schätzen lassen, weil es einfach viel zu langweilig und anstrengend wird.

Wir brauchen eine Lösung, die schnell ist und trotzdem gute Werte liefert. Hier kommt das Team Estimation Game ins Spiel. Erfunden wurde es von Steve Bockman und ist prinzipiell sehr einfach. Man fängt damit an, alle Stories auszudrucken und auf einen Stapel zu legen. Teilnehmer dieses Meetings sind übrigens Team und Product-Owner. Jetzt stellt das Team sich in Reihe und Glied auf und der erste in der Reihe nimmt sich eine STory vom Stapel. Liest sie laut vor und pinnt sie in die Mitte einer Wand (Whiteboard, Pinnwand, …). Der nächste, der an der Reihe ist macht genau das gleiche. Nimmt sich eine Karte, liest sie vor und pinnt sie, falls sie  aufwendiger ist, als die die vorherige über ddiese, wenn sie gleich aufwendig ist neben sie und bei weniger Aufwand unter sie. Ich glaube, die Idee wird jetzt schon klar. Am Ende hat man eine nach Aufwand sortierte Liste der Stories. Jetzt kann man unten anfangen und einen Story-Point vergeben, die nächste Reihe dann 2 und so weiter. Die Fibonacci-Zahlen bieten sich auch hier an.

Damit aber nicht immer nur eine Person den Aufwand schätzt, sondern das Team auch ein Wörtchen mitzureden hat, gibt es noch eine Sonderregel. jeder, der an der Reihe ist, kann statt eine Karte zu nehmen eine bereits geschätzte nehmen und sie umhängen. So können Fehlschätzungen korrigiert werden und die Diskussion, die man in Scrum so liebt wird auch wieder eröffnet. Wenn man will, kann man diese Karte dann markieren, um sich später darüber zu unterhalten.

Ihr könnt euch vorstellen, dass das System um einiges schneller funktioniert, als die herkömmliche Vorgehensweise. Nachteile hat diese Methodik aber leider auch. Es ist nur schwer möglich, wenn die ganzen Stories einmal geschätzt wurden, auf Planungspoker zurückzuwechseln, da man dort andere Referenzen benutzt. Des Weiteren muss man immer wenn man wieder neue Stories im Backlog schätzen will sich die Tafel anschauen und mindestens aus jeder “Reihe” eine Story lesen, um zu wissen, mit welcher man sie vergleichen könnte. Diese Aufwärmphase kostet leider Zeit.

Alles in allem ist das Team Estimation Game aber trotzdem zu empfehlen. Wir haben zumindest in der Vergangenheit gute Ergebnisse damit erzielt.

Was passieren kann, wenn man etwas ganz besonderes, noch nie zuvor dagewesenes, versucht zu bauen, haben die Hamburger 2007 und folgende Jahre gelernt. Architektur muss nicht unbedingt in der Softwareentwicklung schief gehen, auch in der ursprünglichen Disziplin, der Architektur von Gebäuden, kann dies geschehen.

April 2007 begann der Bau der Hamburger Elbphilharmonie.  Ein Meisterwerk der Baukunst war geplant und das Gebäude sollte neben drei Konzertsälen und Backstagebereichen auch ein Hotel, Gastronomiebereiche, 47 Eigentumswohnungen, eine öffentlich zugängliche Plaza auf 37 Metern Höhe und ein Parkhaus mit 500 Stellplätzen enthalten. Die Optik sollte an nichts erinnern, was bereits auf der Welt zu finden ist.

Vielen Entwicklern wird diese Situation sehr bekannt vorkommen. Nichts was es auf dem Markt gibt, deckt den Bedarf ab und so macht man alles selbst. Die Schätzung die man am Anfang eines solchen Mammutprojektes abgibt, sollte aber trotzdem möglichst genau sein. Gute Schätzungen beruhen auf Erfahrungswerten. Wenn diese nicht vorhanden sind, wird auch das Zieldatum nicht  eingehalten werden können. Was passiert also mit einem Projekt wie der Elbphilharmonie? Zur ersten Verzögerung kam es 2010, die zweite wurde im Jahre 2011 angekündigt. Mittlerweile sind die Kosten von ursprünglich 77 Millionen auf 476 Millionen gestiegen und ein Ende ist nicht in Sicht.

Was man aus diesem Vergleich mitnehmen kann ist einfach. Wenn eine Architektur aufgesetzt wird, sollte man das bekannte Territorium so selten wie möglich verlassen, denn dort wo man sich nicht auskennt, verläuft man sich mit Leichtigkeit. Der Einsatz von bereits existierenden Frameworks und Bibliotheken ist in den meisten Fällen der Eigenentwicklung vorzuziehen.

Die Welt dreht sich weiter

Baut man ein Haus, so ist das Vorgehen klar. Man engagiert einen Architekten, dieser entwirft das Anwesen und es wird im Anschluss von der Baufirma erstellt. In einem solchen Fall würde Wasserfall das Projekt zum Ziel bringen. Es ist verständlich, dass man nach dem Abschluss des Kellers nicht mehr auf die Idee kommen sollte, dass man vielleicht doch einen Indoor-Pool haben möchte.
Bei Internetanwendungen ist dies aber Gang und Gäbe. Sobald ein Feature fertig ist, stürzen sich die Projektmanager und Konzepter darauf und verbessern bzw. erweitern es. Und das ist auch gut so, denn die Welt hat sich in der Zwischenzeit weitergedreht. Neue Ideen sind entstanden und die Konkurrenz ist mittlerweile auch ein Stück weitergekommen. Alles gute Gründe auch weiter zu denken.
Im klassischen Wasserfall sind Änderungen während der Entwicklung nicht geplant. Kostspielige Änderungsanforderungen müssen eingekippt werden und wahrscheinlich muss auch der Auftrag geändert werden, da der Umfang, der am Anfang geplant wurde, nicht mehr aktuell ist.

80-Prozent-Syndrom

Projekte haben viele Teilaufgaben. So viele Teilaufgaben, dass es eine gute Idee erscheint, zu parallelisieren. Dies ist auch bedingt richtig. Wenn man viele Teammitglieder hat, dann kann man es probieren. Die Bedeutung für das Projekt ist leider häufig sehr ähnlich. Von den 20 gleichzeitig angegangenen Aufgaben sind 15 offen, aber zu 80 Prozent fertig. Leider kann man erst wirklich was damit anfangen, wenn es 100 Prozent sind.

Misslungene Schätzungen

Sich das fachliche Feinkonzept zu Gemüte zu ziehen und danach eine präzise Schätzung abzugeben hat noch nie geklappt. Trotzdem passiert es immer wieder, dass ein Projektmanager oder ein einzelner Entwickler diese Aufgabe zugeschustert bekommt, dass dies im Normalfall bis zu 500 Prozent danebenliegen kann, ist empirisch belegt. Bei besonders hartnäckigen Projektleitern, kann es auch vorkommen, dass diese Schätzung bereits in einem frühen Projektstadium in Stein gemeißelt wird und die TV-Werbung für den Launch sozusagen schon auf den Tag genau gebucht wird. Eine Anpassung des Zeitplans ist somit nicht mehr möglich.

Priorisieren

Fragt man den Auftraggeber, welches Feature besonders wichtig für den Erfolg des Projektes ist, dann ist die Antwort oft die gleiche. Alle. Viele. Für das Priorisieren ist dies recht kontraproduktiv. Das Team muss entscheiden was zuerst angegangen wird. Wenn dann aber dann an einem bestimmten Meilenstein das falsche fertig ist, wird es den Entwicklern vorgeworfen.

Projektabschluss-Hektik

Das Gute an klassischen Projekten ist, dass auch sie irgendwann mal ein Ende finden. Nur leider ist das Ende meist mit Überstunden, Druck und Stress verbunden. Alles was man bis kurz vor dem Abschluss noch nicht implementiert bekommen hat, muss jetzt in kürzester Zeit nachgeholt werden.  Meist wird in einer solchen Phase auch auf Qualität keinen großen Wert mehr gelegt. Erfahrungsgemäß sind Unit Tests das erste was gestrichen wird, wenn ein Projekt  unter Stress zu Ende geführt wird.

PHP Summit – 18 Power Workshops mit allen wichtigen PHP-Themen

Vom 19. bis 21. März 2012 präsentieren das PHP Magazin und die Entwickler Akademie den nächsten PHP Summit im Holiday Inn München City Centre. Das große Trainingsevent bietet PHP-Entwicklern an 3 Tagen insgesamt 18 halbtägige Workshops und 2 Sessions mit allen wichtigen PHP-Themen.  Die drei PHP-Profis – Sebastian Bergmann, Arne Blankerts und Stefan Priebsch – zeigen und üben mit den Teilnehmern umfassend, wie aktuelle Tools und Methoden in PHP-Projekten effektiv eingesetzt werden können. Der PHP Summit bietet besonders viel Live-Coding statt vorgefertigte foo/bar-Beispiele, hohe Interaktion mit den Teilnehmern, praxisorientierte Lösungswege für typische Problemstellungen und Informationen über neueste Trends in der PHP-Entwicklung. Alle Infos finden Sie auf www.php-summit.de.

Die nächste Konferenz ist nagelneu, aber von den gleichen Veranstaltern. Hat also Potential auch ein Erfolg zu werden. Wer also JavaScript-Fan ist, der sollte sich das mal genauer anschauen.

JavaScript Days 2012

Das Entwickler Magazin präsentiert zusammen mit der Entwickler Akademie vom 12. bis 14. März 2012 die ersten JavaScript Days im Renaissance Hotel Köln! Die insgesamt 18 Workshops des Trainingsevents sind so gestaltet, dass die Entwickler in kürzester Zeit umfassendes Praxis-Know-how zum jeweiligen Thema lernen. Das umfangreiche Programm ist in vier Tracks aufgeteilt: JavaScript Technologies, Best Practices, JavaScript Kickstart und JavaScript Testing. Entwickler lernen tiefgehend wie sie JavaScript-basierte Anwendungen optimal planen, realisieren und zu einem erfolgreichen Abschluss bringen, welche Stärken und Schwächen die verschiedenen Technologien haben oder wie die Teilnehmer bei der Wahl einer geeigneten Architektur vorgehen sollten. Bei all dem profitieren Teilnehmer von der Praxiserfahrung von sechs der bekanntesten JavaScript-Experten – Douglas Crockford, Bastian Feder, Christian Johansen, Kore Nordmann, Hans-Christian Otto und Jakob Westhoff. Alle Infos auf www.javascript-days.de.