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 …

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 :).

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.

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” … :-)