Software Engineering Blog

Vor ein paar Tagen habe ich ja schon einmal den Vortrag von Alan Atlas über die Einführung von Scrum bei Amazon berichtet, über die der bei ImmobilienScout24 gesprochen hat.

Marion Eickmann von agile42 hat Altas kurz danach zum Berliner Scrumtisch eingeladen und das auch in ihrem Blog mit Fotos dokumentiert. Aus dem Blog heraus kann man auch die Präsentation herunterladen.

Isabel Drost hat sich die Zeit genommen und Atlas' Vortrag in Ihren Blog ausführlich dokumentiert.

Wie gut ein Team kommuniziert und Lösungen findet, läßt sich sehr gut an seinem Whiteboard ablesen. Idealerweise gibt es mehr als ein Whiteboard, aber das nur am Rande. Werden an diesem Whiteboard gemeinsam Probleme diskutiert und Lösungen gefunden, dann ist das, was auf dem Whiteboard steht wertvoll. Doch wie gehen wir mit diesen Werten um?

Oft habe ich bis jetzt beobachtet, daß ein Whiteboard während einer langen Diskussion immer wieder beschrieben wird, um diese dann gleich wieder abzuwischen, da der Platz wieder benötigt wird. Kurz vorher wird noch gefragt: "Alles klar? Kann ich das wieder abwischen?" Dummerweise steckt die Information genau in diesem Moment noch in unserem Kurzzeitgedächtnis und die Wahrscheinlichkeit ist hoch, daß es über dieses nicht hinauskommt. Das heißt nichts anderes, als das es morgen vergessen sein wird.

Wir dokumentieren dieses Wissen nur in wenigen Fällen. Und wenn, dann auch meist falsch. In den meisten Fällen werden einfach Fotos gemacht und diese in irgendeinem Verzeichnis abgelegt. Leider versauern sie dann dort auch. Das ist nicht schade, denn meist sagen die Bilder anderen ohne irgendeinen Kommentar auch nichts.

Aus diesem Grund habe ich vor einiger Zeit eine PowerPoint-Vorlage erstellt, mit denen man sehr einfach Whiteboard-Diskussionen dokumentieren kann. Im Grunde bietet die Vorlage nicht mehr, als ein paar Layoutvorlagen für Bilder in Hoch- und Querformat mit einem Textfeld für Notizen. Hinzu kommt noch eine Titelfolie, auf der man Dinge wie Teilnehmer und Datum bei Bedarf eintragen kann und ein paar weitere Folien für ausführlichere Kommentare.

Die Anwendung

Was wird noch gebraucht? Eine Digitalkamera oder ein besseres Handy. Damit wird das Whiteboard während der Besprechung abfotografiert und die Bilder anschließend in die PowerPoint-Vorlage eingefügt und soweit wie notwendig kommentiert. Anschließend sollte die PowerPoint noch als PDF abgespeichert werden, denn für die Verteilung an Externe sind solche offenen Formate wesentlich besser geeignet.

So lassen sich Diskussionen und Entscheidungen effizient und effektiv dokumentieren und können auf professionell verteilt werden. Und das ohne viel Aufwand.

Beispiel

Auf den Bildern in diesem Artikel ist ein kleines Beispiel für den Einsatz der Powerpoint-Vorlage enthalten und ganz am Ende sind ein paar Download-Links für das Beispiel und die Vorlage selber enthalten.

Beispiel für die Titelseite einer Whiteboard-Dokumentation.

Folie für eine ausführlichere Dokumentation in Textform.

Beispiel für die Verwendung mit einem hochformatigen Bild.

Beispiel für die Verwendung mit einem querformatigen Bild.

Auf der letzten Folie können ein paar Schlußbemerkungen festgehalten werden.

Eine gute Alternative zu dieser Vorlage ist die Dokumentation in einem Blog. In meinem Artikel Tod den Statusmails, es lebe das Blog habe ich hierzu auch schon einmal etwas geschrieben.

Gestern bin ich auf dem Scrum-Symposium hier in Berlin von ImmobilienScout24 gewesen und hatte die Möglichkeit zwei Vorträge über Scrum in der Praxis zu hören. Der erste beschäftigte sich mit Scrum bei ImmobilienScout24. Leider habe ich dank der vereisten Berliner Straßen das meiste davon verpaßt. Der zweite wurde Vortrag an diesem Abend wurde von Alan Atlas gehalten, der bei Amazon die Webservices-Sparte (mit?) aufgebaut hat. Altas erzählte auf eine sehr unterhaltsame Art und Weise, wie er bei Amazon Scrum eingeführt hat. Eine kurze Zusammenfassung kann hier gefunden werden.

Was aber für mich wieder am interessantesten zu beobachten war, war daß in den Fragerunden, fast egal wo man ist, immer wieder die gleichen Fragen auftauchen. Wie gehe ich mit dem Testen um? Wie plane ich richtig und auch über längere Zeiträume? Wo bleibt der Architekt und was macht er? Wie tue ich dies oder jenes? Warum sagt und Scrum nicht, wie wir das zu tun haben? Einige Punkte hierzu werden von auch von Uncle Bob angesprochen oder auf XING in der Scrum-Gruppe diskutiert.

Der Kern von Scrum

Scrum hat kein Problem. Das was einige für ein Problem halten, ist die Grundeigentschaft von Scrum. Scrum ist wie viele agile Prozesse schlank aufgestellt und bringt nur wenige Regeln mit. Doch wir wollen an die Hand genommen werden und in Sicherheit sein, in dem wir die Regeln befolgen, die es gibt. Gibt es diese nicht, fühlen wir uns unsicher.

Bleibt also die Frage, was Scrum ist, wenn es uns doch keine Antwort auf alle Fragen in jeder Situation ist?

Scrum kann ganz einfach auf folgendes heruntergebrochen werden:

• Scrum ist Selbstorganisation. Wir sind angehalten uns selber die Regel zu geben, die wir für richtig halten.
• Scrum ist Kommunikation. Dadurch sollen wir anfangen uns auszutauschen, gemeinsam Probleme zu lösen und Wissen zu verteilen.
• Scrum ist kontinuierliche Verbesserung. Probleme sollen nicht auf die lange Bank geschoben werden, sondern aktiv gelöst.

Dafür gibt uns Scrum ein Rahmenwerk mit ein paar Regeln und Rollen. Umsetzen müssen wir es. Das ist schwer, aber auch sehr spannend.

Ein Freund meinte einmal zu mir, daß das doch alles "gesunder Menschenverstand" sei. Sicherlich ja, aber beherzigen wir den auch immer?

Seit letzter Woche bin ich Certified ScrumMaster und damit von der Scrum Alliance berechtigt, "to transform the world of work".

Gerade habe ich meinen Artikel zu Apache Hadoop bei heise Developer abgegeben. Sobald er durch die Redaktion durch ist, werde ich den Link zum Artikel hier posten.

How the Mighty Fall ist ein Buch von Jim Collins, der darin den Aufstieg und Fall von großen Unternehmen beschreibt und das erinnert mich gerade an Toyota.

Zur Erinnerung: Toyota hat diese Woche eine große Rückrufaktion für seine Wagen aufgrung von defekten Gaspedalen gestartet und im Rahmen der Wirtschaftskrise sich auf dem US-amerikanischen Markt übernommen.

Toyota? Die Firma, deren Management- und Produktionsmethoden nicht unberechtigt auch auf die agile Softwareentwicklungsbewegung großen Einfluß ausgeübt hat? Ich möchte hier nur einmal an Scrum und Kanban erinnern.

Wie kann das sein? Toyota wird wie soviele Unternehmen irgendwann seinem Erfolg erlegen sein und wollte in zu kurzer Zeit zu viel erreichen. Den auch in der Softwareentwicklung wissen wir, daß Zeitdruck und der Zwang zum Erfolg meist eine adversen Effekt hat und jedes System nur mit der ihm eigenen Geschwindigkeit wachsen kann.

Auch wenn manche schon vom Ende von Toyota sprechen, wird es dazu nicht so schnell kommen, denn nicht jede Krise bedeutet das Ende. Vielmehr ist die Frage immer, ob aus Krisen die richtigen Schlußfolgerungen gezogen und auch umgesetzt werden.

Alexander Kriegisch von Scrum-Master.de hat dem "Scrum on a Page" von William c. Wake aktualisiert und über seine Homepage uns allen zur Verfügung gestellt.

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Wie gestern versproche, habe ich meinen Vortrag zu MapReduce und Apache Hadoop auf Slideshare online gestellt.

Morgen halte ich einen kleinen halbstündigen Einführungsvortrag zu dem MapReduce-Programmiermodell und dem Apache Hadoop-Framework. Die Folien werde ich anschließend über SlideShare online stellen.

Wenn wir mit anderen zusammenarbeiten besteht immer die Gefahr sich gegenseitig zu stören. Wir arbeiten im gleichen Projekt, bearbeiten die selben Klassen, schreiben in die selbe Datenbank, gegen die der Kollege seine Tests fährt, machen Änderungen, die sich gegenseitig ausschließen. Oft stellt das kein Problem dar, wenn es koordiniert oder zumindest mit dem Wissen der Kollegen geschieht. Was ist aber, wenn wir genau das nicht wollen? Wenn wir in Ruhe die nächsten zwei Wochen an einem ganz besonderen Feature arbeiten wollen oder ein größeres experimentelles Refactoring vornehmen wollen? Es geht aber nicht nur um die großen Aufgaben. Auch in unserer alltäglichen Arbeit, sollte die Gefahr mit der Arbeit Anderer zu kollidieren möglichst gering sein.

Wir müssen uns also isolieren können und unsere Entwicklungslandschaft muß das unterstützten, uns dafür die technischen Möglichkeiten geben. Solange es für ein gesamtes Team nur eine Datenbank, auf der alle arbeiten, oder nur einen Application Server gibt, gelingt das nicht. Solche Systeme nenne ich immer scherzhaft Synchronisationssingularitäten, also Punkte, an denen alle Arbeiten zusammenlaufen laufen. Aber was bedeutet jetzt Isolation für eine Entwicklungslandschaft?

Hier meine Definition:

Isolation ist die Fähigkeit einer Entwicklungslandschaft an dem SUD (System Under Development) Änderungen vorzunehmen, ohne dabei von Anderen ungewollt beeinflußt zu werden oder Andere ungewollt zu beeinflußen.

Ein sehr gutes praktisches Beispiel für Isolation unterstützende Werkzeuge in einer Entwicklungslandschaft sind Versionsverwaltungssysteme wie Subversion oder Git, das die Isolation durch seinen dezentralen Ansatz noch weiter vorantreibt als früher CVS oder jetzt Subversion. Aber der Einsatz eines Versionskontrollsystems kann nur ein erster Schritt sein. Abgesehen davon: zeitgemäße Softwareentwicklung ohne Versionskontrollsystem ist ein Widerspruch in sich.

Heute lassen sich die meisten Systeme, die wir für Entwicklung und Test benötigen ohne Probleme für jeden Entwickler bereitstellen. Eine eigene Datenbank auf dem Laptop, ein lokaler FTP- oder Mailserver oder auch Applikation-Server sind immer möglich. Manche dieser Systeme müssen sogar nicht festinstalliert werden, sondern können im Rahmen eines Builds installiert und konfiguriert werden. JBoss, GlassFish und Apache Tomcat können aus ZIP-Archiven vollständig installiert und angepaßte Konfigurationsdateien anschließend generiert werden. Wird eine saubere Installation gebraucht, wird die alte gelöscht und eine neue automatisch installiert. Mit etwas Ehrgeiz ist das durchaus möglich.

Aber Isolation bringt noch weitere Vorteile für die Software-Entwicklung:

• Ruhe und Ungestörtheit, weil es nicht ungewollt zu Konflikten mit den Arbeiten von anderen Entwicklern im Team kommt. Änderungen werden nur noch gewollt zusammengeführt.
• Verbesserung der Reproduzierbarkeit, weil alle positiven und negativen Effekte nur durch mich selber verursacht wurden und beispielsweise Testergebnisse so nicht verfälscht werden.
• Besseres Konfigurationsmanagement und Setup, weil Isolation als Ziel besondere Maßnahmen erfordert, die zwangsläufig auch zu Zielen wie besserer Modularisierung und Konfigurierbarkeit führen.

Wenn wir beim Aufbau unserer Entwicklungslandschaft Isolation konsequent von Anfang an verfolgen und beachten, erhalten wir die Chance besser im Team zusammenarbeiten zu können, weil wir es dann geschafft haben gegenseitige Abhängigkeiten weiter aufzulösen. Gerade für agil arbeitende Teams sollte Isolation immer ein zu erreichendes Ziel sein, den deren Fehlen stört den Arbeitsfluß.