Service Geist

Zeit für eine kurze Werbeunterbrechung in eigener Sache :). Die Firma codecentric aus Solingen, für die ich seit Anfang Mai arbeite, hat dieses Jahr eine Vortrags-Serie unter dem Titel “Meet the Experts” gestartet.

Die erste Veranstaltung hat das Thema “Performance” behandelt und war echt genial. Man merkt wirklich, dass es den Vortragenden nicht nur darum geht einen Vortrag “abzureissen”, sondern man kommt wirklich ran an die Experten, sei es durch Fragen und Diskussionen während des Vortrags, beim Open Space nach den Vorträgen, beim Essen oder beim Guitar Hero spielen zu später Stunde :).

Jetzt steht also die nächste Veranstaltung mit dem Thema “Agilität” an. Wer also am 4. September noch nichts vor hat und sich für das Thema interessiert kann ja mal auf der Anmeldeseite vorbei schauen. Insbesondere da der Preis für eine solche Veranstaltung echt fair ist (vielleicht sollte ich doch ins Marketing wechseln *grübel*).

Wer einen Einblick in die Qualität der Vorträge gewinnen möchte kann sich hier Online die Präsentationen der ersten Veranstaltung anschauen und hier sind auch noch ein paar Beweisfotos.

Vielen Dank für ihre Aufmerksamkeit und jetzt geht es weiter mit dem normalen ServiceGeist Programm … ach ne shit, da kommt ja gar nix mehr …

Gestern Nacht habe ich noch bei Fabian diesen Artikel gelesen, bei dem es sich um die Frage dreht, ob komplexe Probleme auch komplexe Lösungen nach sich ziehen müssen. Berufsbedingt dreht es sich hierbei um die Software-Entwicklung aber ich denke das ist auf viele andere Bereiche übertragbar. Ich hatte schon angefangen einen Kommentar zu schreiben, aber der wurde länger und länger und so dachte ich mir ich nutze mal die schöne Möglichkeit des Trackbacks und verfasse das direkt als eigenen Blogpost :).

Vielleicht sollte ich es gleich als kleine Warnung vorweg schreiben, dass ich ein glühender Verfechter für einfache Lösungen bin und es spielt dabei meiner Meinung nach auch keine Rolle wie komplex irgendein Problem ist. Dabei sollte zunächst einmal zwischen Komplexität (= Schwierigkeit) und Umfang (= Grösse) einer Problemstellung unterscheiden. Wobei Software-Projekte auch mit Leichtigkeit an ihrer Grösse scheitern können, aber das ist normalerweise eher auf organisatorische Probleme zurückzuführen. Aber ich komme ein wenig vom Thema ab ;).

Wie bereits im Artikel von Fabian beschrieben ist eine grosse Herausforderung die Problemstellung wirklich zu verstehen und auf die (wichtigen) Anwendungsfälle herunterzubrechen. Hierbei kann es durchaus sein, dass die echten Domain-Experten dazu nicht in der Lage sind, da sie einfach zu tief in der Materie stecken. Da heisst es dann erstmal nachfragen, bohren und graben bis klar ist, was denn wirklich die Aufgabenstellung ist und was die Software am Ende leisten soll. Hierbei ist ein iterativer Ansatz natürlich extrem hilfreich, weil damit der Anwender schon möglichst früh abgleichen kann, ob die Funktion der Software auch seinen Ansprüchen entspricht. Nur dann besteht die Möglichkeit bereits früh Veränderungen an der Funktionalität vorzunehmen, was deutlich schwieriger wäre, wenn der Kunde einfach nach einem halben Jahr eine Software vorgesetzt bekommt, die dann seinen Ansprüchen – vorne und hinten – nicht genügt.

An dieser Stelle versuche ich jetzt mal den Bogen wieder zurück zu spannen zur Überschrift: Einfach Lösungen bevorzugt. Eigentlich sollte es sogar heissen: Einfache Lösungen sind ein Muss. Denn so gut wie jedes Software-Projekt wird eigentlich immer nur komplizierter im Laufe der Entwicklungsphase. Es kommen neue Anforderungen vom Kunden oder gewisse Aspekte waren doch nicht so einfach, wie anfangs gedacht, es gibt Ausnahmefälle zu berücksichtigen, etc.. Wenn die Software-Architektur jetzt bereits von Beginn an sehr (zu) komplex angelegt war, sind die Probleme bereits vorprogrammiert, denn jede Erweiterung wird zur Qual, von der Wartbarkeit mal gar nicht zu reden. Einfache Lösungen spiegeln sich dagegen auch in einer einfachen Architektur wieder, welche Erweiterungen erlaubt ohne die ursprünglichen Konzepte über den Haufen werfen zu müssen und damit meiner Meinung nach auch eine tragende Säule agiler Software-Entwicklung ist, die ansonsten überhaupt nicht realisierbar ist.

Ok, ich komme einfach nicht umhin hier eine kurze Geschichte zu erzählen, die ich von einem sehr guten Kollegen habe, und an die ich immer wieder denken muss, weil einfach viel Wahrheit drinsteckt:

Ein Elefant geht durch den Wald und sieht einen Affen unter einem Baum stehen und nach einer Banane springen. Der Elefant fragt den Affen was dieser denn dort macht und der Affe antwortet er wolle an die Bananen ran. Daraufhin schlägt der Elefant vor, doch einen der Söcke zu nehmen, die auf dem Boden liegen und damit die Banane vom Baum zu schlagen. Doch der Affe antwortet: Keine Zeit, ich muss springen!

Das ist leider der Zustand in dem sich Software-Projekte viel zu häufig wiederfinden (im Grossen wie im Kleinen) und der Schritt zurück und ein Schnack mit Kollegen über das Problem bringt hier häufig die erwünschte einfache Lösung zutage. Doch wie gesagt, auch im Alltag springt man viel zu häufig, statt sich mal nach dem Stock umzuschauen ;).

Und bevor ich mich jetzt ganz anhöre wie Tom-Yoda starte ich lieber mal ins Wochenende, es geht paddeln auf der Sieg, wenn das Wetter denn mitspielt. Und wenn wir nicht absaufen gibt es natürlich einen Bericht an dieser Stelle :).

Jurgen Appelo hat mit 80 Seiten eine wirklich umfangreiche – und wie ich finde sehr gelungene – Presentation zum Thema Scrum ausgearbeitet: The Zen of Scrum … ist auch ein echt cooler Titel.

Alan Skorkin wirft hingegen einen – subjektiven – Blick auf den aktuellen Stand der Dinge was Agile Methoden angeht … und auch darüber hinaus.

Der folgenden Satz (ok, es ist eigentlich nur ein Satzfragment) hat mir irgendwie spontan besonders gut gefallen:

agile doesn’t kill agile, people kill agile

Eine definitive Möglichkeit Agile zu “killen” besteht darin damit Chaos und Planlosigkeit zu entschuldigen, immer nach dem Motto “Wir sind ja Agile”. Bald werde ich hoffentlich wieder die Gelegenheit haben Agile auch wieder in der Praxis zu leben, um dann mehr eigene Erfahrungsberichte einbringen zu können :).

English version of this post …

Jeder der mit Agilen Entwicklungsmethoden zu tun hat kennt wahrscheinlich sicherlich das Agile Manifesto. Nun ja, Gerüchten zu Folge soll es ja Projektmanager gegeben haben, die nicht ganz so überzeugt von agiler Entwicklung waren, dass sie auch gerne schonmal bei Problemen gesagt haben:

Bete einfach 3x das Agile Manifesto runter, dann sind alle Probleme gelöst.

:-)

Jetzt gibt es auf jeden Fall die Idee für eine neue – oder besser gesagt – weitere linke Seite, zu finden hier.

Wobei ich jetzt einfach mal annehme, dass “well-crafted” Software auch funktionierende Software impliziert, sonst würde ich nicht ganz zustimmen. “Adding value” hört sich sehr nach Marketing an, wenn es gelingt ist es aber sicherlich gut. Der Community-Gedanke gefällt mir gut, ebenso den Kunden zu beeindrucken … das ist ein cooler Gedanke :).

Zeit sich mal wieder ein wenig der Software-Entwicklung zu widmen und da ich auf Twitter in letzter Zeit diverse Linktips zur Agilen Softwareentwicklung abgegriffen habe, dachte ich mir ich bündele die mal in ein Posting – und gebe natürlich ein wenig meinen Senf dazu.

Den Anfang machte eine Mail auf unserer firmen-internen Scrum Master Mailingliste über The Decline and Fall of Agilists. Der Artikel stellt einerseits einen sehr interessanten Zusammenhang her zwischen Softwareentwicklung und Komplexitätstheorie. Vor allen Dingen geht es aber auch darum nicht nur strikt auf die Einhaltung von bestimmen agilen “Werkzeugen” zu beharren, sondern sich in seinem Projekt die Flexibilität vorzubehalten, die richtigen (=nötigen) Werkzeuge auszuwählen, auch wenn bestimmte “Agile Evangelisten” solche Projekte nicht mehr als agil ansehen würden.

These days, agilists simply claim that agile is about following practices X, Y and Z

Aus meiner eigenen Projekterfahrung denke ich, dass es durchaus legitim ist bestimmte Teile agiler Methoden nicht umzusetzen. Es ist nur absolut notwendig sich dessen auch bewusst zu sein. Es muss ganz klar sein: Dieser Teil meines Projekts ist nicht agil, weil es aus [guten Grund einsetzen] nicht passt. So gab es in einem meiner letzten Projekte zum Beispiel ein Scrum of Scrums, um eine bessere Synchronisation zwischen verschiedenen Scrum Teams zu erreichen. Doch ausser dem Namen hatte dies nichts mit Scrum gemein und es wäre besser gewesen es gleich ein Projekt-Status-Meeting zu nennen (denn nichts anderes war es). Hier kommt aber leider schnell die “Angst” auf, dass man ja agil ist (und sein will) und dann auch bitte an allen Ecken und Enden … aber ich habe meine Zweifel, dass dies gerade in grossen Firmen/Organisationen immer möglich ist … und dann ist es sicherlich besser nur einen (passenden) Ausschnitt an agilen Methoden umzusetzen. Wichtig ist sich dabei nicht in die Tasche zu lügen, denn am Ende zählt immer noch der Projekterfolg; gemessen an Termintreue, Qualität (beides zusammen dürfte die Kundenzufriedenheit massgeblich definieren) und auch Teamzufriedenheit (denn ein “verbranntes” Team hilft niemandem).

Weiter geht es mit zwei Artikeln, die sich mit dem Product Backlog befassen. Hier geht es einmal darum, wie sich Non-Functional Requirements praktisch mit Agilen Methoden managen lassen, denn diese passen normalerweise nicht sonderlich gut in irgendwelche User Stories. Die Idee ist also Non-Functional Requirements an die entsprechenden (neuen) User Stories “anzuhängen”, um sicher zu gehen, dass bei der Implementierung einer neuen User Story keine bestehenden NFR “gebrochen” werden. Ein weiterer Artikel befasst sich mit der Frage Why There Should Not Be a “Release Backlog”.

Ein wichtiger Punkt jeder Softwareentwicklung ist meiner Meinung nach ein Project-End-Review. Wie kann man sonst wissen, was gut oder schlecht gelaufen ist und wie könnte man sonst etwas verbessern. Dieses oft nicht sonderlich strukturierte und wohlmöglich sogar hauptsächlich vom Projekt-Manager getriebene Review (weil es als Punkt abgehakt werden muss) wird bei den Agilen Entwicklungsmethoden durch die Retrospektive ersetzt. Hier wird der Fokus stärker auf das Team gelegt und es findet auch nicht nur ein Review am Ende des Projekts statt, sondern dies wird zu einem kontinuierlichen das Projekt begleitenden Prozess . Der verlinkte Artikel bietet eine sehr gute Zusammenfassung was eine Retrospektive ist (und was nicht).

Retrospectives use a specific structure designed to defuse disagreements and to shift the focus to learning from the experience. The basic technique is to slow the conversation down – to properly explore different perspectives on events before jumping to conclusions.

Das ist schonmal ein ganz entscheidender Punkt, denn es geht nicht darum nur “gemütlich rum zu sitzen” und ein wenig über die letzte Iteration zu sinieren, denn dabei kommt garantiert nicht viel heraus. Daher ist es wirklich ein Muss, dass jede Retrospektive einen (guten!) Facilitator hat. Einen weiteren wichtigen Aspekt definiert die Prime Directive für Retrospektiven von Norm Kerth:

Prime Directive: Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

Das ist ein Punkt, der mich persönlich sehr interessiert und zu dem ich auch schon viele Erfahrungen in meinem bisherigen Berufsleben sammeln durfte/konnte/musste und wird sicherlich auch nochmal Thema eines weiteren Blog-Eintrags werden.

Durch eine Mail in der Firma bin ich heute darauf gestossen, dass ein Test Framework, welches wir in einem grossen Projekt genutzt haben, mittlerweile (vielleicht auch schon länger) frei verfügbar ist. Dabei bin ich zunächst mal über Google Code gestolpert. Das hatte ich zwar schonmal in Zusammenhang mit Android gesehen, aber mir war gar nicht bewusst, dass Google auch Project Hosting betreibt.

Project Hosting on Google Code is a free service to the open source community. Featuring a Subversion back-end, wiki support, file downloads, issue tracking and a clean, Google-style interface, our project hosting service is the world’s second largest open source hosting site after SourceForge.net.

Aber zurück zum Test Framework mit dem einprägsamen Namen Robot. Das Projekt bei dem ich Robot genutzt habe liegt etwas mehr als ein Jahr zurück, aber ich glaube ich kann mich an die wichtigsten Features noch ganz gut erinnern.

Also, wofür ein … dieses … Test Framework? Es geht darum einen automatisierten Blackbox-Test für eine Software aufzubauen. Automatische Tests sind ein Herzstück agiler Softwareprojekte, denn nur mit (guten!) automatisierten Tests lässt sich innerhalb einer Iteration sicherstellen, dass alle bereits fertigen Teile der Software immer noch wie erwartet funktionieren – und die neuen Teile natürlich auch. Hierbei gilt es die von der Software zur Verfügung gestellten Interfaces abzutesten (”Gutfälle” und “Schlechtfälle” gleichermassen). Natürlich hängt die Qualität der Tests stark vom Test-Entwickler ab, und das beste Framework kann keine schlechten Tests vermeiden, aber es kann die Implementierung guter Tests unterstützen. Und das tut das Robot Framework ganz gut wie ich finde.

Die Einarbeitungszeit in das Tool war relativ gering. Die Tests lassen sich in einzelnen Modulen implementieren. Dies kann entweder in Java passieren, oder in jeder Sprache, die sich per Shell aufrufen lässt, z.B. Perl. Ein Test erwartet einen gewissen Satz von Parametern, die dann an die Testmethode übergeben werden. Diese Methode implementiert dann den Test und liefert OK oder NOK zurück. Ein Testcase lässt sich aus mehreren solcher Methoden zusammensetzen. Auch kann man die Testcases taggen, um sich in den generierten Reports einen besseren Überblick über die getesteten Teile der Software zu verschaffen … Achtung … die benutzten Keywords müssen gut abgestimmt werden, sonst benutzt jeder leichte Abwandlungen.

Testmethoden lassen sich in einer Art Projekt zusammenfassen, wobei es natürlich sinnvoll ist ähnliche – und vor allen Dingen generische – Testmethoden einmal für mehrere Projekte zu schreiben. Solche Tests könnten z.B. sein: “Existiert eine Datei (Parameter Pfad zur Datei)” oder “Existiert ein Directory (Pfad zum Directory)”. Komplizierte Testcases können so aus einer Vielzahl (idealerweise bereits existierender) Testmethoden zusammengesetzt werden. Die generierten Reports zeigen übersichtlich die Anzahl der erfolgreichen/fehlgeschlagenen Tests an und es lässt sich auch anzeigen welche Tests wo fehlgeschlagen sind.

Was ist sonst noch zu beachten? Die eigentlichen Testcases werden in einer simplen HTML-Datei geschrieben, was die Ganze Sache recht einfach macht. Hier werden nur noch vorhandene Testmethoden genutzt und die Parameter übergeben. Zum eigentlichen schreiben der Testmethoden ist aber im Prinzip eher das Wissen eines Entwicklers als das eines Testers gefragt, denn die Entwicklung der Testmethoden kann sich leicht zu einem eigenen kleinen Software-Projekt entwickeln. Auf der anderen Seite ist es gefährlich wenn der Entwickler die Testmethoden für seine eigenen Komponenten entwickelt. D.h. hier sind Tester mit Programmiererfahrung gefragt oder aber die Testmethoden müssen von verschienden Team-Mitgliedern entwickelt werden. Es ist eh fraglich ob “reine Tester” in agilen Teams sinnvoll sind, insbesondere wenn diese auch noch in externe Teams ausgelagert sind. Ich denke es macht deutlich mehr Sinn Testkompentenz – zusätzlich – im agilen Team aufzubauen und zu nutzen. Dadurch bekommen die “Tester” auch direkt mehr Produktkompentenz und wissen besser welche Schnittstellen es zu testen gilt.

Testen von “Backend-Prozessen” und GUI … das werde ich hier nicht vertiefen, zumal ich nur bei Tests im Backend-Bereich involviert war. Aber zumindest schien es einige Probleme mit den Libraries zu geben, die für das GUI-Testen benutzt werden mussten. Aber da das über ein Jahr zurück liegt wird es sicherlich Fortschritte in dem Bereich gegeben haben.

In diesem Sinne “happy testing and roboting” … :-)