Software Engineering Blog

Im Mai 2008 habe ich mit dem Software Engineering Blog begonnen und in den darauffolgenden Monaten und Jahren eine Menge Spaß damit gehabt.

Jetzt ist es aber Zeit das Software Engineering Blog zu Grabe zu tragen. Wollte ich anfangs vorallem zu Themen des Software Engineerings schreiben, sind die Themen mit der Zeit vielfältiger geworden und über den schmalen Bereich des Software Engineerings hinausgegangen, sodaß der Name inzwischen nicht mehr zum Blog paßt. Name und Konzept passen inzwischen nicht mehr zueinander. Weiterhin habe ich in den letzten Monaten auch kaum die Zeit für neue Inhalte gefunden, unter anderem deshalb, weil ich auch wieder begonnen habe für Magazine zu schreiben und mich mit meinen Themen für Konferenzen zu bewerben.

Doch ein Ende kann auch ein neuer Anfang sein. Daher habe ich entschieden, daß Software Engineering Blog einzustellen und mit einem neuen Blog, unter einem neuen Namen, wieder zu beginnen. Mit logbuch@freiheitsgrade werde ich auch in Zukunft bloggen, so wie es die Zeit und die Ideen zu lassen. Inhaltlich wird sich das Blog nicht wesentlich unterscheiden, doch der neue Name spiegelt die Themenbreite besser wieder, als es der aktuelle kann. Auch werden die Artikel wohl eher kürzer sein, als die bisherigen im SWE-Blog.

Das SWE-Blog werde ich irgendwann abschalten und damit auch die meisten Inhalte. Es wird wieder Zeit, daß Vergessen neu zu erlernen. Auch im digitalen Leben.

Kultur ist ein oft gebrauchtes Schlagwort, mit dem ich mich vor einiger Zeit begonnen habe auseinanderzusetzen, als ich mich fragte, was wohl die eigentliche Grundlage für erfolgreiche Projekte ist.

Die obige Präsentation habe ich für den ersten Scrum Day 2010 in München vorbereitet, an dem ich mit dieser Präsentation auf der Reservebank für eventuell ausgefallene Redner teilgenommen habe. Gott-Sei-Dank war dies nicht der Fall und daher werde ich ihn am 17. November auf dem Scrum Day in Berlin halten. Dann aber wohl in einer überarbeiteten Form.

In den letzten Wochen habe ich mich intensiv mit Multi-Touch-Anwendungen beschäftigt und am Ende ist dabei ein Artikel zu MT4j für das JavaMagazin entstanden, den ich jetzt, uff, fertig habe. An dieser Stelle vielen Dank an Uwe Laufs und Chris Ruff vom Frauenhofer IAO für Zusammenarbeit und Hilfe.

Dadurch ist leider wenig Zeit für das Bloggen geblieben, wobei es doch so viel Interessantes gegeben hat. Spontan fällt mir dabei der Post Glaskugel: Architektur in 2020 von Gernot Starke ein. Fünfzig-fünfzig denke ich dabei. Aber eigentlich doch super, endlich wird IT sexy Ich höre schon auf so manchem Campus Gespräche wie "Mein Freund studiert Software-Architektur!" "Ah, nimmst Du mich mal mit, das finde ich unheimlich interessant und vielseitig." Endlich Schluß mit Situationen wie "Was, Du bist IT'ler? Mit Dir kann man sich doch normal unterhalten...." Es kommen goldene Zeiten auf uns zu!

Nacht!

In dieser Woche war ich auf dem ersten Scrum-Day in diesem Jahr in München und saß, bildlich gesprochen, mit einem Vortrag zur Bedeutung von Unternehmenskultur für agile Softwareentwicklung auf der Reservebank, falls einer der geplanten Referenten ausfällt. Ausgefallen ist keiner, womit ich dann die Möglichkeit haben werde auf dem zweiten Scrum-Day in Berlin zum Ende diesen Jahres meinen Vortrag zu halten.

Was hat aber Unternehmenskultur jetzt mit agiler Entwicklung zu tun? Sehr viel! Liest man sich das agile Manifest durch, kann es nach meiner Meinung so zusammengefaßt werden, daß es für unseren Erfolg wichtiger ist, wie wir miteinander umgehen, als welche detailierten Prozesse wir versuchen einhalten. Wie wir mit einander umgehen, daß lernen wir in unserer Umgebung. Wir sehen, wie die anderen sich in unserer Umgebung verhalten, welche Strategien erfolgreich sind oder zumindest vor Schaden schützen, und passen uns daran an. Das paßt gut zur Definition von Kultur in Organisationen, wie ich sie bei Sonja Sackmann gefunden habe:

Organisationskultur ist die von einer Gruppe gemeinsam gehaltenen grundlegenden Überzeugungen, die deren Wahrnehmung, Denken, Fühlen und Handeln bestimmen und insgesamt typisch für die Gruppe sind.

Ein für uns sehr leicht nachvollziehbares Beispiel in der Softwareentwicklung ist der Umgang mit Fehlern. Defekte, das klingt doch wesentlich neutraler, gibt es in jeder Software, denn Software-Entwicklung ist zu komplex, um keine Fehler zu machen und sei es, daß es ab einem bestimmten Punkte nicht mehr wirtschaftlich vertretbar ist, eine Software gegen jeden Fehler abzusichern. Gute Projekte und Entwicklungsteams unterscheiden sich aber im Umgang mit Fehlern. Keiner macht gerne Fehler, denn das Fehlermachen wird negativ bewertet und oft in der einen oder anderen Form bestraft. Das kann ganz diffizil sein, beispielsweise wenn gleich gesagt wird: „Paß auf, nicht wieder die gleichen Fehler zu machen.“ Neulich habe ich in einem Projekt einen Softwarefehler gefunden und wollte zu dem für die Komponente verantwortlichen Entwickler gehen mit der Bitte, den Fehler zu beseitigen. Er sei im Urlaub sagten mir seine Kollegen, worauf hin ich meinte, daß das schlecht sei, denn er sei der Einzige, der den Fehler beheben könne, sagten sie, daß das vielleicht ja auch gut wäre, dann würde es vielleicht ja auch weniger Fehler geben. Ja, ja, der Truckfaktor. Aber, Wissensverteilung, Risikominimierung und Teamarbeit sind ja jetzt nicht mein Thema. Dieses Beispiel zeigt aber sehr gut, wie der Umgang mit Fehlern symptomatisch für die Kultur in einem Team ist. In einer solchen Umgebung werden Fehler bestraft, was dazu führt, Fehler zu vertuschen, zu leugnen, als nicht so wichtig hinzustellen, als sie zu beheben und daraus zu lernen.

In ihrem Buch „Soft Skills für Software-Entwickler: Fragetechniken, Konfliktmanagement, Kommunikationstypen und -modelle“ haben Uwe Vigenschow und Björn Schneider eine kleine Taxonomie von Fehlerkulturen aufgestellt, in der zwischen funktionaler und dysfunktionaler Fehlerkultur unterschieden wird.

Welche Fehlerkultur herrscht bei Ihnen?

Mit seinem ersten Buch "Scrum - Agiles Projektmanagement erfolgreich einsetzen", hat Roman Pichler ein für die deutsche Scrum-Gemeinde wichtiges Buch geschrieben. Was mir an dem Buch besonders gut gefällt, ist der präzise Stil mit dem Pichler die wichtigen Grundlagen von Scrum erklärt, sodaß man das Gefühl hat sofort loslegen zu können, auch wenn dem vielleicht gar nicht so sein mag. Wer sich intensiver mit Scrum beschäftigt hat merkt, das Scrum und seine Grundlagen viel weiter reichen, als es auf den ersten Blick erscheint. Aber das ist ein anderes Thema.

Jetzt gibt es ein neues Buch von Roman Pichler: "Agile Product Management with Scrum", das zuerst auf Englisch bei Addison-Wesley erscheint, da Pichler mittlerweise in Großbritannien lebt. Eine deutsche Übersetzung ist bereits angekündigt und ich hoffe, daß diese von Pichler selber vorgenommen wurde.

Thema des Buches ist agiles Produktmanagement (Produktpolitik). Also all die Tätigkeiten, die bei einer Produktentwicklung notwendig sind, um ein Produkt erfolgreich weiterzuentwickeln.

Leider kann ich noch nicht allzuviel zum Buch selber sagen, da ich es erst heute bestellt habe und nach Angaben von Amazon die Lieferung erst im Mai erfolgen soll. Empfehlen kann ich aber in dem Zusammenhang "Management von IT-Produkten", auf das ich in diesem Blog-Artikel schon einmal hingewiesen habe. Das Buch gibt einen sehr guten Überblick über alle notwendigen Tätigkeiten im Umfeld von IT-Produkten. Der Anspruch des Buches dabei ist es eine Einführung in die Grundlagen zusammen mit einem theoretischen Überblick zu geben. Das gelingt den Autoren auch sehr gut, vorallem da sie sich bewußt sind, daß dies nur die Grundlage für eigenes Handeln sein kann. Pichlers Buch könnte da eine gute Ergänzung sein.

Mails sind oft kurze Antworten auf andere Mails und ab einer bestimmten Anzahl von Mails, die im Ping-Pong-Verfahren, teilweise aus nur einem Satz bestehend, werden die Quotes immer unübersichtlicher.

Ab einer bestimmten Ebene sieht man einfach nicht mehr durch, welche Antwort sich worauf bezieht, da sie sich ja nur durch Anzahl der > unterscheiden (Voraussetzung ist natürlich, daß ein vernünftiger Mail-Client benutzt wird ).

Wer das Problem kennt, der sollte sich Quote Colors ansehen. Diese kleine Thunderbird-Erweiterung färbt die Zitate entsprechend ihrer Stellung ein. So bilden sich leicht übersichtliche farbliche Blöcke, die helfen die Übersicht zu bewahren.

Meine Empfehlung, weil es einfach auch gut aussieht und hilft die Übersicht zu bewahren.

Am 7. und 8. Juni diesen Jahres wird in Berlin die Berlin Buzzword 2010 stattfinden. Im Mittelpunkt dieser zweitägigen Community-Konferenz stehen all die Themen, die zur Zeit wohl als angesagt gelten dürften, wenn es um skalierbare Systeme und Massendatenverarbeitung geht; also Themen wie NoSQL, Hadoop, Lucene, Solr und und und. Isabel Drost, die auch das Berliner Hadoop Get Together organisiert und die treibende Kraft hinter Berlin Buzzword ist, hat in "Why 'Buzzwords'?" kurz erklärt, um welche Themen es auf der Konferenz gehen soll.

Derzeit läuft der Call-Of-Papers für die Konferenz. Wer also eine gute Idee für einen Talk auf Englisch und Zeit am 7. oder 8. Juni haben sollte und noch einen guten Grund sucht, um nach Berlin zu kommen, der kann sich gerne bei Berlin Buzzwords bewerben. Das ist übrigens auch die günstigste Art Zugang zur Konferenz zu bekommen. Momentan sind noch Karten zum Early-Bird-Preis von 297,50 € zu haben.

An dieser Stelle möchte ich noch erwähnen, daß ich bei der Organisation der Konferenz durch die Begleitung der Konferenz auf XING, Facebook und Co. mitwirke. Dies aber aus reinem Enthusiasmus für ein spannendes Thema und somit ohne irgendwelchen finanziellen Vorteile daraus zu erhalten. Der Eintrittspreis ist so ausgelegt, daß er die Konferenzkosten deckt.

Früher hatte ich einen Zettel an meinem Monitor, auf dem Stand, daß das kein Touch-Screen ist. Es gab einige Kollegen, die immer gern direkt auf dem Monitor gezeigt haben und ich mußte hinterher... Sie kennen das vielleicht noch selbst, denn bei CRT-Monitoren war das noch störender als heute.

Aber bald werden wir schreiben "Berühr mich!" und werden das ganz ernst meinen. Ich habe ja im letzten Artikel schon geschrieben, daß ich der festen Meinung bin, daß die neue Generation von Touch-Screens unsere Arbeit mit Computern verändern werden. Und für uns Software-Entwickler heißt das auch wieder: Auf zu neuen Ufern. Und dabei haben wir ja das letzte Ufer noch gar nicht richtig erkundet. Aber das ist ein anderes Thema.

Multi-Touch für Java!

Hier ist ein Demo, das sehr gut zeigt, was heute auch im Java-Ökosystem möglich ist.

Das Frauenhofer IAO-Institut hat für Java MT4J entwicklet, auf dem das obige Demo beruht. Also, was hält uns auf! Her mit den neuen Ideen!

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.

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