Warum!?

Weil es einfach so ist, wie ich es mir vorstelle. Wir sehen uns beim nächsten Hangout.

Wenn ich so nachdenke, dann denke ich zuerst an den Vortrag von Jutta Eckstein, deren Buch „Agile Softwareentwicklung im Großen“ ich schon in meiner Diplomarbeit zitiert haben, und Mirko Novakovic (codecentric AG), der anhand eines Business Cases vorgestellt hat welche Vorteile Agilität uns bringt und wie Agilität das Projektrisiko senkt, wenn das Projekt mal in Zeitverzug geraten sollte. Je länger ich über den Vortrag nachdenke, desto einleuchtender erscheinen mir seine Gedanken. Das Pareto-Prinzip (auch bekannt als 80/20-Prinzip) war auch gestern wieder ein „Allheilmittel“ für den Erfolg agiler Methoden. Mirko Novakovic wies darauf hin, dass durch die richtige Priorisierung des Product Backlogs in Kombination mit dem Pareto-Prinzip die Wirtschaftlichkeit von Software-Projekten erheblich gesteigert werden kann. Ein automatisiertes Testen ist dabei genauso wichtig wie ein automatisierter Releaseprozess und ein automatisiertes Deployment. Auch wenn das Automatisieren des Releaseprozesses relativ große Aufwände mit sich bringt, ist es besonders wichtig um die Vorteile der Agilität nutzen zu können. Leider wird dabei oft nicht erkannt, dass die Automatisierung des Releaseprozesses von Java-Projekten mit Java selbst viel aufwändiger ist, anstatt mit leichtgewichtigen Dingen wie Python-Skripten und Shell-Skripten. (Für den folgenden Satz entschuldige ich mich im voraus:) Der automatisierte Releaseprozess muss nicht besonders schön und tricky entwickelt sein, sondern funktionieren. Dennoch ist es korrekt. Der Releaseprozess soll nur funktionieren. Der Funktionsumfang ist überschaubar, aber es ist lästig, fehleranfällig und zeit-verschwenderisch die Releases immer wieder von Hand zu bauen.

Ein spannender Vortrag war sicher auch der Vortrag „Wer braucht ausführliche Dokumentation?“ von Markus Schramm (compeople AG). Der durchaus provokante Titel war sehr gut gewählt. Neben der Frage nach dem „Wie?“ wurde auch nach dem „Was?“ und „In welcher Form?“ gefragt. Für mich habe ich mitgenommen, dass man auf abgefahrene proprietäre Formate verzichten sollte, wenn man seine Dokumentation schreibt. Vielmehr muss der Einsatz von Wikis an dessen Stelle treten. Dinge bzw. Schnittstellen die nach außen gegeben werden sollen, sollten auch zukünftig eine Dokumentation in Form einer Word-Dokuments oder eines PDFs besitzen. Im internen Bereich jedoch ist es in der agilen Welt wesentlich wertvoller den Mut zu zeigen, dass fachliches Wissen statt in einer wasserdichten Dokumentation in den Köpfen der Mitarbeiter existiert. Das klingt im ersten Moment abgefahren, aber im Ernst: Was macht ein Entwickler, wenn er an einem unbekannten System arbeiten soll zuerst? – Er erkundigt sich bei jemandem, der das System kennt, statt in Eigenbrödler-Manier eine möglicherweise veraltete und unvollständige Dokumentation zu lesen. Dieses KnowHow über eine Software-Komponente sollte dabei über Reviews innerhalb des Teams gestreut oder im Falle der Mitarbeiterfluktuation in Form einer Übergabe weitergegeben werden. Eine solche Übergabe soll dabei allerdings nicht nur an einen anderen Mitarbeiter, sondern an zwei bis drei andere Mitarbeiter erfolgen. 80 Prozent der Dokumentation können dabei mit Wikis und JavaDoc ausreichend dokumentiert werden und 20 Prozent der Dokumentation dienen der Beschreibung der nach außen gerichteten Schnittstellen. Auch wenn der der Titel der Veranstaltung sicherlich absichtlich provokant gewählt war, ist die Frage tatsächlich notwendig. Welche Dokumentation brauche ich wann? Bin ich vom Gesetzgeber an die Einhaltung einer Dokumentationsstruktur gebunden (Stichwort: Datenschutz)?

Jens Coldewey (it-agile) hat in einem Vortrag mit dem Titel „Langfristige Planung in agilen Vorhaben“ festgestellt, dass es eine „Langfristige Planung“ gar nicht gibt. Planung ja, aber langfristig!? – Das ist nicht möglich, da man langfristig mit zu vielen unvorhergesehenen Dingen konfrontiert wird. Die Velocity eines Scrum-Teams zum Beispiel sinkt daher durch unvorhersehbare Ereignisse von Sprint zu Sprint exponentiell. Um feststellen zu können zu welchem Zeitpunkt der „80/20-Punkt“ eines Projekts – der Zeitpunkt, an dem 80 % der geforderten Anforderungen umgesetzt wurden – erreicht ist, sollte man die Velocity des Scrum-Teams mitschreiben und analysieren.

In einem weiteren Vortrag der Telefonica o2 Germany GmbH & Co. OHG und der C1 SetCon GmbH wurden die Erfahrungen aus einem agilen Outsourcing-Projekt dargestellt. Auch hier habe ich auf meinem Block einige Notizen gemacht. In dem vorgestellten Beispiel wurde darauf hin gewiesen, dass es nicht zu vernachlässigen ist, dass der Teambuilding-Prozess eines Scrum-Teams Zeit braucht. Das ist eine durchaus ernst zu nehmende Erkenntnis. Nach meinem Eindruck kranken viele Projekte daran, dass die Entwickler nicht ausreichend Zeit bekommen, dass „Miteinander“ zu finden. Auch in dieser Veranstaltung wurde wieder auf das „Wie?“ der Dokumentation hingewiesen und die Erfahrung berichtet, dass Word- und Excel-Dokumente viel zu weit weg von der Software-Entwicklung sind. Stattdessen solle man sich lieber auf Wikis und JavaDoc konzentrieren. Auch das ist für mich absolut nachvollziehbar. Word-Dokumente, die auf irgendwelchen Netzlaufwerken aufgehoben werden, veralten schon zum Zeitpunkt der Speicherung. Auch wenn der Inhalt eines solchen Word-Dokuments absolut wichtig und brauchbar ist, ist er in einem Word-Dokument total falsch aufgehoben. Es können keine Revisionen gespeichert werden und es können auch nicht mehrere Autoren gleichzeitig an der Dokumentation schreiben. Ein Wiki hingegen bringt in der Regel all diese Funktionen von vorn herein mit und ist auch vollständig durchsuchbar. Bei einer Komponente, die im Rahmen diesen Projekts, von insgesamt 3 Scrum-Teams mit jeweils 8 Entwicklern bearbeitet wurde, wurden Team-übergreifende Konfliktpotenziale gefunden. Jedes Team sollte deshalb eine Code Ownership für den von ihm bearbeiteten Bereich übertragen bekommen, der mit den Bereichen der anderen Teams interagiert.

Im Großen und Ganzen kann ich als Fazit feststellen, dass wir in der Software-Entwicklung des Kraftfahrt-Bundesamts schon relativ fortgeschritten mit der Nutzung agiler Methoden sind. Auch wenn man sich nicht an den Negativbeispielen misst, stelle ich an dieser Stelle fest, dass es in der Wirtschaft teils große Unternehmen gibt, die diesbezüglich erheblich mehr Nachholbedarf haben. Das hat mich total erstaunt, da man so etwas von einer Bundesoberbehörde in der Regel absolut nicht erwartet. Trotzdem ist es wichtig am Ball zu bleiben und sich kontinuierlich weiter zu entwickeln.

Anders als vermutet gab es heute Nacht kein Gejaule und Theater. Beide waren artig und haben bisher nichts kaputt gemacht. Die Katze ist schon relativ zutraulich und lässt sich auch mal kraulen. Der Kater hingegen ist ein kleiner Schisser. Er traute sich zuerst gar nicht und nun wagt er sich bis zu einem Sicherheitsabstand von 50 cm an uns heran. Der Plan für die Zukunft heißt bei uns jetzt: Spielen, Fressen, Sch******, Schlafen…

• Running bzw. Jogging,
• Cycling,
• Skating
• und viele mehr

Nach dem Training/Work-Out wird die gelaufene Strecke auf eine Google Map eingezeichnet. RunKeeper-Benutzer können ihre Jogging-Strecken auch ins Netz übertragen und mit anderen teilen. Man kann auf RunKeeper.com auch kleine Sportgruppen – sogenannte Street Teams – bilden. Hier mal beispielhaft meine heute abgelaufene Strecke mit allen Zusatzinformationen. Man kann genau sehen, wie ich an Steigungen langsamer wurde und am Meer wieder “Vollgas” gegeben habe. Insgesamt habe ich 3,51 Meilen (umgerechnet 5,65 Kilometer) zurückgelegt. Dabei habe ich 489 Kalorien verbrannt.

Und jetzt das Beste: Weil ich mich in der Zukunft ja von meinen iPhone trennen möchte, hatte ich Sorge, dass es RunKeeper im Android AppStore noch nicht gibt. Doch weit gefehlt: RunKeeper gibt es sowohl für das iPhone als auch für Android. Das bedeutet ich kann auch in Zukunft wieder RunKeeper spielen. Ich habe auf meinen iPhone die Pro-Version der RunKeeper App, die zum aktuellen Zeitpunkt 7,99 Euro kostet.

Hier nochmal meine heute gelaufene Route:

Falls jemand mit mir ein Street Team machen gründen möchte, dann meldet Euch… Wie immer per Comment, Messenger, E-Mail oder via Telefon.

Liebe Mobilfunkprovider,

wir – die jungen Menschen – haben ein anderes Surfverhalten als die “Generation 50+”. Wir nutzen ICQ, Google Talk, E-Mails, und und und… SMS als Messaging-Funktion hat bei uns ausgedient.  Die Idiotie der herkömmlich SMS liegt schon allein in der Begrenzung auf 160 Bytes 1120Bit wofür dann auch noch Geld verlangt wird. Wenn wir uns Begrenzen wollen, dann nennen wir das Microblogging und tun es öffentlich und kostenlos mit Twitter. Wir gucken Youtube-Videos überall. Wir gehen durch den Einzelhandel und entscheiden und für ein Produkt und vergleichen dann die Preise auf Amazon oder Google. Andere Länder mit anderen (und zum Teil den gleichen) Providern können es doch auch. Es ist an der Zeit brauchbare Tarife zu definieren, die nicht so etwas unsinniges wie SMS enthalten. Es kann doch nicht so schwer sein. Man man man…

Gruß
Phil

Und wäre das alles nicht schon schlimm genug, gibt es heute schon wieder Spinat. Ich fühle mich schon wie Popeye. Und das alles nur weil die Läden in der Umgebung geschlossen haben und das Auto in einem riesigen Schneeberg steckt. Ich mag keinen Spinat. Pfui!

Am Samstag kommt laut Wetterbericht die die nächste Ladung der weißen Pracht. Ich weiß langsam echt nicht mehr ob ich weinen oder lachen soll.