Immer dann, wenn ich einen Azubi betreue und ihm in die “Kunst” der Perl-Programmierung einführe, bin ich erschrocken wie planlos die jungen Menschen ihre Programme aufbauen. Leider bleibt es bei vielen Programmierern und IT-Administratoren dabei. Dies führte vor ein paar Tagen zu einer Diskussion, ob Perlcode “schön sein muss”. Ich benutze absichtlich diese Formulierung, um die Brisanz deutlich zu machen. Auch viele meiner Kollegen gehen eher den pragmatischen Weg und schreiben ihre Skripte nicht zum lesen. Dies führt immer wieder dazu, dass jemand der das Skript nicht geschrieben hat und “mal eben” eine Änderung vornehmen muss, bei einem 200 Zeilen Skript einen halben Tag braucht. Leider führt die Freiheit alles kurz und “mal eben” zu schreiben häufig dazu, dass Perlcode, und insbesondere die regulären Ausdrücke, als Leitungsrauschen wahrgenommen wird.
Ich habe mir jedenfalls die Mühe gemacht, die aus meiner Sicht wichtigen Punkte zusammenzutragen, damit man Perlcode schreiben kann, der auch gerne gelesen wird.
Also viel Spaß:
Zum Wochenende habe ich noch eine schöne Diskussion gefunden, die zwar schon etwas älter ist aber aus meiner Sicht aktueller denn je. Es geht darum ein Gewürzregal zu bauen und eben dafür genau das RICHTIGE Werkzeug zu finden. Aber lest selbst: “Why I hate Frameworks“
Tagwolken sind meiner Meinung nach ein schönes Mittel, um die Tags in einem Blog oder Wiki darzustellen. Allerdings kann man sie nutzen um beispielsweise eine Präsentation aufzupeppen. Wer versucht eine Tagwolke von Hand zu erstellen wird schnell merken, dass es nicht so einfach geht wie es letztendlich aussieht. Mit wordle.net ist das etwas anders. Hier reicht eine aktuelle Java-Version und schon kann man aus einem Text oder einem Feed eine schöne Tagwolke erstellen lassen.
In meinem letzten Artikel habe ich bereits das Thema Scrum kurz angerissen. In dieser Präsentation habe ich die Konzepte von agilen Methoden und insbesondere von Scrum etwas genauer erklärt. Bei Gelegenheit werde ich noch eine Tonspur hinzufügen und einen Slidecast daraus machen. Also viel Spaß damit.
Wer kennt es nicht, der Kunde reicht ständig Anforderungen nach, da er die Gesamtanforderungen nicht kennt. Das Projektteam wird ständig bei der Arbeit unterbrochen und der Kunde ist mit den Ergebnissen nicht zufrieden. So, oder so ähnlich habe ich es in einem meiner letzten Projekte erlebt. Für die zweite Phase musste nun ein Vorgehensmodell her, das auf solche Belange eingeht.
Auf der JAX habe ich auch die agile Lego Hour besucht und damit erstmals einen Einblick in die agilen Methoden bekommen. Ich habe mich nun etwas mit Scrum auseinander gesetzt und werde es für die zweite Phase dieses Projekts einsetzen.
Scrum ist ein leichtgewichtiges Prozessmodell das in Japan zur Produktentwicklung entstanden ist. Kern von Scrum ist das “Product Backlog”, in dem die einzelnen Anforderungen des Kunden beschrieben werden. Der Kunde ist der “Product Owner” und pflegt zusammen mit dem Team das “Product Backlog”; er vergibt die Prioritäten für die anfallenden Aufgaben, welche dann in dem sogenannten “Sprint” abgearbeitet werden. Die Sprints sind Entwicklungszyklen, welche mit zwei bis vier Wochen sehr kurz gehalten sind. Bei der täglichen Zusammenkunft (Daily Scrum) treffen sich die Entwickler (Scrum Team) und entscheiden die nächsten Schritte. Hierbei wird geklärt: “Was habe ich gestern gemacht?”, “Was mache ich heute?” und “Welche Hindernisse sind aufgetreten?”. Das Meeting sollte nicht länger als 15 Minuten gehen. Mit dem “Sprint Burndown” wird visualisiert wie das Projekt voranschreitet Transparenz geschaffen.
In der Ausgabe Nr 13 der Zeitschrift ct ist ein Artikel über Scrum zu finden, der einen guten Überblick der agilen Methoden bietet. Außerdem kann ich noch die Seite von Alexander Kriegisch empfehlen. Dort habe ich mich in das Thema eingelsen.
In kürze werde ich hier berichten wie erfolgreich das Projekt mit der agilen Methode wirklich war.
