Posts

Für das Evang. Waldheim Esslingen, in dem ich lange Jahre ehrenamtlich aktiv war, betreibe ich die Website und dahinterliegende Webanwendung (siehe Projekte - Waldheim). Bisher sorgte der apache2 als Webserver und Reverse-Proxy für die Auslieferung der Seiten. Um etwas mehr Performance zu erreichen habe ich in diesem Fall die meisten statischen Inhalte aus der Webanwendung in ein separates Verzeichnis verlagert und Apache2 so konfiguriert, dass diese Inhalte nicht über die Webanwendung (bei mir jetty) an den Reverse-Proxy ausgeliefert werden, sondern apache2 diese direkt ohne Umwege ausliefern kann. ...

Um bessere Qualität in der Entwicklung zu erreichen, gibt es ein Konzept, das sich “Definition of Done” (DoD) nennt. Die Idee, dass das Team sich selbst Gedanken darüber macht, was alles nötig ist, damit eine Aufgabe (Story, …) wirklich erledigt ist, finde ich einen schönen Ansatz. Die Herausforderung sehe ich aber in der tatsächlichen Umsetzung. Ich habe bisher verschiedene Ausprägungen davon erlebt: Die Umsetzung wird mit dem “Holzhammer” durchgesetzt. Durch Zwang von oben oder Gruppendruck entsteht dann eine (evt. unbewusste) Ablehnung und es werden kreative Wege gesucht, die “ungeliebten” Aufgaben zu umgehen. ...

Vor längerer Zeit habe ich als Product Owner mit einem Entwickler-Team zusammengearbeitet. Das Team entwickelte mit Java + Vaadin eine Webanwendung. Als sich die Probleme und Bugs häuften und auch teilweise wiederholten, erkundigte ich mich, ob zu den aufgetretenen Bugs auch dazugehörige Unit-Tests beim Beheben erstellt worden seien. Für jeden Bug ein Unit-Test Das Prinzip, für jeden Bug einen Unittest zu schreiben, hat den Zweck, sogenannte Regressions zu verhindern. Damit ist gemeint, dass ein Bug in der Zukunft wieder auftaucht und erneut behoben werden muss. ...

Gestern ergab es sich, dass ein Kollege und ich in eine Refactoring-Session gestolpert sind. Verschiedene Vorschläge ergänzten sich, aber eines hat mir besonders Spaß gemacht… Als erstes schlug mir IntelliJ folgendes vor: Danach ging es direkt mit dem nächsten Hinweis weiter … Meiner Meinung nach ist es extrem wichtig, die richtigen bzw. gute Werkzeuge zu nutzen, um gute Ergebnisse zu erzielen. Dann macht die Arbeit Spaß und das ist jeden € wert, den die Werkzeuge letztendlich kosten.

Ein Post-Mortem wird häufig im Projekt-Management eingesetzt, um zu analysieren, warum ein Projekt nicht erfolgreich abgeschlossen werden konnte. Im Bereich IT Operations habe ich das Konzept als RCA (Root Cause Analysis) kennengelernt. In der Software-Entwicklung habe ich dieses Konzept bisher noch nicht angetroffen. Auf Störungen im Betrieb wird meistens durch das Erstellen und Bearbeiten von Tickets reagiert. Wir haben Post-Mortem bei uns vor mehr als einem Jahr eingeführt und pflegen ein Dokument, in dem wir jeden Vorfall eintragen und die daraus abgeleiteten Maßnahmen protokollieren. ...