Agile Methoden wie Scrum oder Kanban  etablieren sich zunehmend als Alternative zu klassischen Vorgehensmodellen in der Softwareentwicklung. Ist das alles nur ein großer Hype oder steckt mehr dahinter? Gibt es vielleicht sogar einen echten Business Case? Anhand einer idealisierten Geschichte soll verdeutlicht werden, welche Chancen die Agilität bietet und warum sich ein Umstieg rechnet.

In der aktuellen Ausgabe des Business Technology Magazins beschreiben Andreas und ich anhand einer fiktiven Geschichte, warum sich Agilität auch aus finanzieller Sicht für Unternehmen lohnt.

Die 4 Kernthesen für den Business Case für Agilität sind dabei:

1. Schneller geschäftlicher Nutzen und Time to Market
2. Weniger Fehl- und Blindleistungen
3. Risikomanagement von komplexen Situationen
4. Hohe und nachhaltige Qualität

Den vollständigen Artikel kann man von unserer Webseite herunterladen: Business Case für Agilität

Ab heute gibt es für alle die Möglichkeit diesen Diskussionen teilweise beizuwohnen. Ab heute gibt es den codecentric competence center podcast.

Die Leiter der competence center, und ggf. auch geladene Gäste, setzen sich regelmäßig zusammen und diskutieren aktuelle Themen aus den jeweiligen Bereichen. Initial haben wir uns einen 2-wöchigen Rhythmus vorgenommen. Der erste Podcast behandelt die Themen “Story Points” und “Benennung von Java Klassen”. Langweilig? Ganz im Gegenteil! Wir hatten sehr viel Spaß bei der Diskussion der Themen.

Ich würde mich über Feedback über Inhalt, Gestaltung, Qualität, Länge, etc. im Kommentarbereich des Podcasts freuen. Wer möchte, kann den Podcast auch auf  iTunes abonnieren und bewerten.

Da wir uns starkt mit agiler Software Entwicklung beschäftigen, habe ich mich gefragt, was ein “Agiles Unternehmen” ausmacht. Also habe ich mal Google befragt und ein wenig nachgelesen. Eine gute Zusammenfassung findet man bei Business Dictionary:

Fast moving, flexible and robust firm capable of rapid response to unexpected challenges, events, and opportunities. Built on policies and processes that facilitate speed and change, it aims to achieve continuous competitive advantage in serving its customers. Agile enterprises use diffused authority and flat organizational structure to speed up information flows among different departments, and develop close, trust-based relationships with their customers and suppliers.

Grundsätzlich zusammengefasst sind “Agile Unternehmen” also die Unternehmen, die besonders schnell und flexibel auf sich ändernde Marktbedingungen reagieren können. In den meisten Artikeln, die ich gefunden habe werden Selbstorganisation und Interaktion zwischen Mitarbeitern und Abteilungen als Basis für agile Unternehmen gesehen. Aber was bedeutet das jetzt für die IT?

Aber zurück zum Artikel. Es geht um große ERP Systeme und das die meisten Unternehmen Schwierigkeiten haben auf die steigende Flexibilität und Geschwindigkeit des Business zu reagieren. Grund sind die hohe Komplexität der Systeme, teilweise schlechte Produktqualität, ein hohes Maß an Customizing an des Systemen und teilweise auch das Alter dieser Monolithen. Bleibt die Aussage: “ERP bremst Business!“.

Soweit so gut, viele der Aussagen sind bis dahing für mich durchaus nachvollziehbar und sehen wir auch täglich in unseren Projekten. Nicht nur bei ERP Systemen, sondern bei vielen Standardsoftware “Monstern” – beispielsweise auch im Bereich der Versicherungskernsysteme. Ich habe mich immer gefragt, warum man zunächst viele Millionen in Lizenzkosten investiert, dann merkt, dass der “Standard” eigentlich nicht zu den eigenen Prozessen passt und man nur 20% der Funktionen benötigt. Deshalb führt man auch erst mal ein mehrjähriges Customizing Projekt durch. Meistens hat man die Software danach soweit angepasst, das sie nicht mehr Release fähig ist oder jedes Upgrade wieder mit hohen Anpassungsaufwänden verbunden ist. Aber das beste kommt noch: ca. 20% muss man jedes Jahr für die Wartung der Standard Software zahlen – sprich: Alle 5 Jahre hat man die Software noch mal gekauft.

Leider liefert der Artikel nicht wirklich interessante Lösungsszenarien. Zunächst wird bemängelt, dass die Strategien der ERP Hersteller die großen Versprechen von SOA nicht gehalten haben – insbesondere, weil die SOA von den Herstellern fast ausschließlich technisch betrachtet wurden.

Eine mögliche Lösung wird in der Cloud und in Software as a Service gesehen – da hat mich der Artikel dann auch entgültig abgehangen. Wenn ich also mein “Monster” nicht mehr selber betreibe, sondern in der  “Wolke”, dann sind meine Business Probleme weg und ich bin auf einmal flexibel und schnell!? Da scheinen einige der der Experten doch eher im “Nebel” zu stehen.

Da ich mich seit einigen Wochen damit beschäftige das “Why” für unsere Agile Software Factory zu finden, hat mir dieser Artikel wirklich sehr geholfen.

Aus meiner Sicht liegt die Lösung für das Problem doch klar auf der Hand:

Wenn Agile Enterprise heißt, dass mann innovativ sein (First Mover) und schnell reagieren (Fast Follower) muss, dann kann die Lösung doch nicht in “Standard” und “Monolithen” liegen. Standard ist definitiv nicht innovativ und Monolithen sind in der Regel komplex und wenig flexibel anzupassen.

Aus meiner Sicht muss man bei der Umsetzung der Geschäftsprozesse auf individuelle Software setzen. Die genutzten Komponenten können aber sehr wohl Standard sein. Was ich damit meine ist, dass ich niemandem empfehlen würde eine Buchhaltungssoftware inidividuell selber zu bauen – hier ist durch gesetzliche Vorgaben etc. wenig Innovation und Individualität zu erwarten. Allerdings können sich die Prozesse rund um die Buchhaltung sehr wohl stark unterscheiden und zu einem Wettbewerbsvortei werden. Kunden können über Web und Mobile direkt eingebunden werden, Geschäftsvorfälle können automatisiert werden und andere, eigene Systeme können sich direkt integrieren. Insbesondere kann man “Insellösungen” vermeiden und dem Benutzer eine einheitliche Oberfläche und schnelle Bearbeitung in einem System anbieten.

Um schnell und flexibel zu sein, mit unbekannten Anforderungen umgehen zu können und das Risiko von inidividueller Entwicklung zu reduzieren, muss man auf agile Vorgehensweisen setzen. Mit schwerfälligen Wasserfallmethoden und Projekten mit Laufzeiten von mehreren Monaten oder Jahren bis man dem Business etwas Lauffähiges anbieten kann, wird man heute nicht mehr konkurrenzfähig sein.

Genau das ist unsere Agile Software Factory: Ein etablierters Vorgehensmodell auf Basis von Scrum und XP mit vielen Best Practices (“Agile”) und dem Einsatz von standardisierten Komponenten und Frameworks (“Factory”).

Bei den Komponeten setzen wir meistens auf Open Source, da die verwendeten Standards und offene Quellen zu einer verbesserten Integrierbarkeit und schnelleren Entwicklung führen – zudem ist man weniger von der “Politik” einzelner Hersteller abhängig. Alfresco im Bereich ECM, Pentaho für Business Intelligence, Liferay als Portal Lösung, OpenCms als CMS  oder Compiere im Bereich ERP und CRM sind nur Beispiele für Open Source Komponenten, die wir in die Anwendungen unserer Kunden integrieren. Die individuellen Prozesse und Anwendungen werden dabei auch auf Basis von etablierten Best Practices mit Open Source Frameworks wie Spring, Hibernate, Drools, jBpm oder Mule entwickelt. Immer auf Basis leichtgewichtiger, evolutionärer Architekturen!

Die agile Vorgehensweise sorgt dafür, dass das Business alle 2-4 Wochen neue und benötigte Funktionen zur Verfügung gestellt bekommt – und das in hoher Qualität durch automatisierte Unit-, Regressions- und Systemtest, sowie kontinuierlicher Integration, Pair-Programming und automatisierter Code- und Designüberprüfungen.

Mein Fazit: Wenn wir als IT auf sich schneller ändernde Business Anforderungen reagieren wollen (“Agile Enterprise”), dann müssen wir uns von großen “Standardsoftware Mostern” und langlaufenden Projekten trennen. Die Lösung für mich sind agile Projekte – allerdings auf Basis von standardisierten Anwendungsbausteinen und Frameworks.

Man sieht den Langen Weg zum Ziel auf dem wir dem Ziel aber schon sehr nahe gekommen sind. Ich hoffe auf eine Belohnung für die super Sprints und wünsche mir deshalb einen Kuchen hinter der Ziellinie.
Unter dem Weg sind sowohl unsere Architektur also auch der Zweck des Projekts zu erkennen (oder auch nicht). Die Architektur funktioniert gut, und der Kunde erkennt den Wert wo er früher noch Fragezeichen im Kopf hatte.
Über dem Weg ist links oben unsere Teststabilität zu erkennen mit der ich offensichtlich nicht so glücklich bin. Maßnahmen wurden ergriffen um dies zu ändern.
Auch unzufrieden bin ich mit unserem Burndown gewesen. Zwar passt es grundsätzlich, sollte aber unterhalb und nicht oberhalb der Linie liegen.
Zufrieden war ich offensichtlich auch mit der Menge der umgesetzten Funktionalität und, dass diese echten Mehrwert in Form von Geld für unseren Kunden generiert.
Abgerundet wird das Bild durch meinen Eindruck einer erneut super gelaufenen Produktpräsentation.

Was haltet Ihr von dieser Art der Reflection?

Klar sagt man schnell gern: Oh das muss kosmische Strahlung sein. Ich werfe den Build nochmal an. Aber wir wissen alle daß das nicht stimmen kann. Um wirklich effizient ein CI System nutzen zu können im Folgenden eine Liste von Ursachen von solch spontanen Buildfehlschlägen und wie man sie beheben kann.

• Ein Test führt Zeitberechnung durch, und sowohl im Testcode als auch im Produktionscode wird die Zeit genommen. Während das fast immer ohne erkennbare Unterschiede funktioniert, kann es ab und zu Abweichungen geben. Die Meldungen sehen dann merkwürdigerweise so aus: Time was 23:30:00 but expected 23:30:00 (die Milli- und Mikrosekunden werden von den üblichen toString Methoden nicht angezeigt.)
• Code, Testcode oder das CI lassen nach Ausführungen Dateien liegen. Oft handelt es sich um Logdateien, manchmal Ergebnisse von Tests. Dies kann Ergebnisse verfälschen, weshalb unbedingt diese Dateien zu entfernen sind. Auch sollte unbedingt Festplatten Monitoring eingesetzt werden, da auf Buildservern die Platten schnell sehr voll werden (Hudson bietet Optionen zur Überwachung und zum Aufräumen)
• Benutzer die sich auf dem CI Server einloggen können so versehentlich Ressourcen sperren, z.B. Dateien durch Öffnen, oder Ports durch manuelles Serverstarten. Oder sonstwas, womit keiner gerechnet hat. Deshalb sollte es auf Buildservern keine Benutzerlogins geben. Sämtliche Analysen sollten wenn überhaupt nur lesend erfolgen. Dennoch sollte den Entwicklern bewusst sein, daß je nach Tool selbst lesender Zugriff schon Schreibzugriff verhindert.
• Es handelt sich nicht zwingend um einen Bug im Code oder Test wenn das Systemdatum den Ersten Januar 1970 anzeigt. Natürlich könnte es ein Fehler sein, aber eventuell geht die Uhr des Buildservers auch einfach falsch. Buildserver sollten immer die aktuelle Uhrzeit verwenden. Dies kann ganz einfach mit einem ntp daemon sichergestellt werden. Falls ein Test eine bestimmte Uhrzeit testen möchte, so sollte nicht die Systemzeit verändert werden, sondern stattdessen der Code so umgebaut werden, daß er einen TimeProvider verwendet welcher im Test die gewünschte Uhrzeit liefert, sich ansonsten wie die normale Systemzeit verhält.
• Falls es doch schmutziger Tricks bedarf um gewisse Teile des Codes zu testen, so ist es in der Regel sicherer die Testausführung zu forken, dadurch können dann selbst umgesetzte Systemvariablen keinen Einfluss auf die Tests in anderen JVMs haben. Code Coverage Tools und andere Bytecodemanipulierer zählen mitunter auch als Hack. Geforkte Ausführung ist oft sicherer.
• Falls Ihr mehrere Buildserver habt, stellt sicher, daß diese sich so ähnlich wie nur möglich sind. Nur wenn man es sich wirklich leisten kann und will sollte man mehrere verschiedene Server mit fest definierten Unterschieden als Farm aufsetzen. So kann dann auf Systemspezifika getestet werden. Allerdings sollte es keine überraschenden Unterschiede geben.
• Man sollte in Erwägung ziehen das zu testende System für die nächtlichen Integrationstest (automatisch) komplett neu zu installieren. Diese Testserver werden mit der Zeit instabil, insbesondere dann wenn viele explorative Tests und ad-hoc Demonstrationen auf dem System gemacht werden. Komplette Neuinstallation klingt abschreckend, ist aber oft einfacher als gedacht. Allerdings dauert die Installation jede Nacht dann etwas mehr Zeit.
• Wenn man Software für automatische Tests deployed sollte man unbedingt zuerst den Server stoppen, die neue Software an die richtige Stelle kopieren und dann den Server starten. Jegliche Art von “hot deployment” ist leider nicht stabil genug um verlässlichen Ergebnisse zu liefern.
• Nach jeglicher Art von Konfigurationsänderung oder Veränderungen an der erweiterten Testinfrastruktur sollte ein manueller Testlauf gestartet werden. Tut man dies nicht vermischt sich diese Änderung mit dem nächsten Entwicklercommit und dieser sucht dann vergebens in seinem Code nach der Änderung die den Test brach, obwohl es sich um die Konfiguration handelt.
• Falls sich Tests aufhängen oder blockieren, insbesondere wenn mehrere Tests zur gleichen Zeit (nicht zwingend in dem gleichen Prozess) laufen, so sollte man sich darüber freuen, einen Heap und Threaddump machen und erst dann die JVM neustarten. Es kann sein, daß die Tests zufällig eines dieser unheimlich schwer zu findenden Nebenläufigkeitsproblemen gefunden haben. Man sollte dafür dankbar sein, da man den Fehler sonst nie gefunden hätte. Leider wird zu oft einfach nur neugestartet.

Natürlich ist es möglich, daß weiterhin der Build bricht ohne daß die Software Fehler enthält. Aber genau dies verschwendet viel Zeit auf der Suche nach Phantomfehlern. Deshalb muss man die Schwachstellen seines Builds kennen und daran arbeiten diese zu beheben.

Wir hatten zum Beispiel ein Problem mit einer unserer Integrationtest Suiten. Die Tests verbinden sich mit einem externen Dienst, welcher manchmal nicht antwortet oder nur hängt. Bis vor kurzem brach dies unseren Build. Das Ergebnis war, daß jeder Entwickler sich den roten Build ansah, die Logs studierte und schlussendlich zur Feststellung gelangt, daß mal wieder der Dienst nicht verfügbar war. Nach einer Diskussion über dieses Problem beschlossen wir diese Zeitverschwendung nicht mehr zu machen. Also fügten wir eine kleine Mechanik in die Tests ein, welche die Timeouts erkennt und den Build nicht brechen lässt. Dafür markiert es den Test mit dem nichtkritischem Tag “timeouted”. Natürlich können wir keine Aussage über den Test treffen, aber er ist ebenso wenig Grün wie Rot. Da aber Rot das Anzeichen für die Entwickler ist tätig zu werden konnten wir ihn nicht Rot machen. Leider führt dies zu der Einschränkung, daß wirkliche Grüne Builds keine Tests mit dem Tag “timeouted” haben dürfen. Im RobotFramework kann man einen dritten Zustand für “nichtkritische Fehlschläge” definieren. Vielleicht ist dies ja auch eine Option für Euch?

Die wichtigste Botschaft ist: Wenn ein gebrochener Build nicht durch Test- oder Produktionscode verursacht wurde, so muss man unbedingt die Ursache finden und beheben. Man kann nicht einfach auf kosmische Strahlen verweisen, da sonst irgendwann jeder einfach nur “kosmische Strahlen” sagt und der Build keine Aussagekraft mehr hat. Ein roter Build sollte immer bedeuten: Leute macht was!

Vor einigen Tagen fand auf Twitter eine vergleichsweise lebhafte Diskussion zu dem Thema statt (welche durch das 140-Zeichen-Limit effektiv unterbunden wurde). Auslöser war ein Vorschlag von it-agile Zuspätkommende sollten als Strafe auf betterplace.org spenden. Daraufhin regnete es Thesen und Vorschläge, was ich zum Anlass nehmen möchte, das Problem gerne nochmal aus einem anderen Blickwinkel zu beleuchten.

Grundsätzlich produziert jegliches Handeln bestimmte Ergebnisse, welche wiederum eine oder mehrere Folgen nach sich ziehen. Wenn wir als mögliche Ergebnisse “zu spät zum Daily Scrum” und “pünktlich zum Daily Scrum” analysieren, welche Handlungen führen zu den Ergebnissen, und welche Folgen zieht sie nach sich?

Ergebnis: “Zu spät zum Daily Scrum”

Ergebnis: “Pünktlich zum Daily Scrum”

Wer kommt zu spät

Interessant und störend wird die Situation erst, wenn sie gehäuft auftritt. Das heißt entweder kommt eine Person immer wieder zu spät, oder es sind sogar alle Teammitglieder gleichermaßen daran beteilig. Nun bieten sich auf den ersten Blick über die Betrafung oder Belohnung des jeweiligen Verhaltens zwei Hebel an.

Eine Möglichkeit besteht darin, Zuspätkommende zu bestrafen. Wenn die Strafe nur hoch genug ist (ein Finger abhacken pro Minute Zuspätkommen) wird mit Sicherheit niemend mehr auf absehbare Zeit zu spät zum Daily Scrum kommen. Dies wird aber zu lasten von anderen gewünschten Aktivitäten erfolgen, da jeder unter allen Umständen und Eventualitäten pünktlich sein möchte. Dann werden andere wichtige Meetings gar nicht erst wahrgenommen. Die Familie wird vernachlässigt, weil man sich schon um 5 Uhr morgens auf den Weg macht, um gegen Megastaus und Bahnausfälle gewapptnet zu sein. Klar, ich übertreibe jetzt, aber der Punkt ist denke ich klar: Natürlich kann ich ein Verhalten erzwingen, aber um welchen Preis? Außerdem: Verantwortlich für das Stattfinden und die Durchführung des Daily Scrums ist der Scrum Master. Hat er die nötige Weisungsbefugnis, um die Strafen auch durchzusetzen? Vermutlich nicht, denn das würde ja in einem starken Gegensatz zu der vom Team zu recht eingeforderten Selbstorganisation stehen. Eine Sackgasse.

Wie sieht’s mit Belohnungen aus? Wer pünktlich kommt, erhält als kleines Dankeschön € 100,00 in Bar. Ach, warum so geizig: € 10.000. Und, klappts? Abgesehen davon, dass der Product Owner die gestiegenen Kosten wohl nicht finanzieren würde, nutzt sich der Effekt der Belohnung spätestens nach dem einhunderstem Daily Scrum ab: Millionäre dürfen ruhig zu spät kommen. Außerdem ist eins ja wohl sonnenklar: Ohne die Belohnung wird überhaupt niemand mehr kommen.

Ok, abgehackte Finger und Millionenboni sind natürlich absurd (hoffe ich), aber es hilft die Effekte die stattfinden zu beleuchten. Was passiert wohl bei reduzierten Strafen und Belohnungen?

Wie wär’s mit einem Kaffee für alle, die pünktlich sind? Auch was anfangs vielleicht dazu gedacht sein mag ein jungagiles Team an den Prozess zu gewöhnen, kann schnell zum Bumerag werden. Wir Menschen haben da nämlich eine ganz dumme Angewohnheit: Selbst wenn wir Handlungen aus eigenen Antrieb ausführen, wenn es dafür eine Belohnung gibt, neigen wir dazu die Handlung nachträglich dem Erreichen der Belohnung zuzuschreiben. Ein Verdrängungseffekt findet statt: an die Stelle unserer intrinsischen Motivation tritt die extrinsische Belohnung. Um die erwünschte Handlung aufrecht zu erhalten, muß die Belohnung erhalten oder sogar erhöht werden. Irgendwann kommt niemand mehr wegen eines lausigen Kaffees zum Daily Scrum. Da muß es schon ein Latte Macchiato sein. Oder im Winter ein Irish Coffee Die Belohnung lenkt jedenfalls den Fokus vom eigentlichen Ziel ab (nur zur Erinnerung: ein flüssiges und schnelles Daily Scrum) hin zum Erreichen der Belohnung. Das dieser Effekt um so stärker auftritt, wenn die Handlung ursprünglich nicht intrinsisch motiviert war, versteht sich von selbst. Belohnungen sind also kein probates Mittel, um Verspätungen dauerhaft einzudämmen.

Als Bestrafung für verspätetes Erscheinen wurden auf Twitter unter anderem die Zahlung eines kleineren Geldbetrags an einen guten Zweck oder öffentliches Singen genannt. Aber auch kleine Bestrafungen können einen ähnlich desaströsen Effekt haben, wie Belohnungen. Als Beispiel sei hier die Studie “A Fine Is A Price” (2000: Gneezy, U. / Rustichini, A) angeführt: In einigen Kindergärten wurde eine kleine Geldstrafe für verspätetes Abholen der Kinder eingeführt. Es stiegen nicht die Anzahl der Verspätungen an, diese blieben auch auf dem fast doppeltem Niveau, nachdem die Geldstrafe wieder abgeschafft wurde. Die Autoren erklären dieses Verhalten mit einem unvollständigen Vertrag. Auf die Situation des Daily Scrums übertragen könnte das heißen, dass der unvollständige Vertrag formuliert werden kann als: “Wir treffen uns täglich zur selben Zeit und am gleichen Ort zum Daily Scrum. Dies sehen wir als richtig und wichtig an. Wenn sich jemand verspätet wird meistens auf ihn gewartet, und das wichtigste wiederholt, damit wir gemeinsam unser Sprint commitment halten können. Wenn sich die Verspätungen häufen wird aber vermutlich etwas geschehen.” Dieses unkonkrete etwas, das geschieht, ist potentiell unerwünscht, aber sehr diffus. Dies wird durch die Geldstrafe konkretisiert, was in den Augen der Mitglieder die Geldstrafe zur schlimmstmöglichen Konsequenz macht.

Leider gibt die Studie keine Empfehlungen an die Hand, welche besseren Alternativen es gibt, den unvollständigen Vertrag zu konkretisieren.

Informierend oder Kontrollierend

Laut der kognitiven Bewertungstheorie (Cognitive Evaluation Theorie) macht es einen Unterschied, ob ein extrinsischer Faktor, wie eine Belohnung oder eine Bestrafung, als kontrollierend oder informierend wahrgenommen wird. Während sich kontrollierende Faktoren negativ auf die intrinsische Motivation auswirken (und entweder rebellisches oder angepasstes Verhalten verursachen), haben lediglich informierende Faktoren keinen negativen Einfluß auf die intrinsische Motivation. Das heißt um auf lange Sicht alle Teilnehmer zur Pünktlichkeit zu bewegen, muß das Team einen Weg finden den Zuspätkommer zu informieren, ohne den Kontrollaspekt des Feedbacks überzubetonen. Dies könnte z.B. durch Ich-Botschaften geschehen, in denen andere Teammitglieder erklären, wie sie die Situation erleben. Wenn alle damit einverstanden sind, kann die Konsequenz fürs Verspäten auch eine öffentliche Gesangseinlage sein, oder ein mitgebrachter Kuchen, oder oder oder. In jeden Fall dürfte der “konkretisierte Vertrag” so individuell wie das Team sein.

Gibt es in Deinem Team Maßnahmen gegen Verspätungen im Daily Scrum – oder allgemein in den Scrum Meetings? Ich würde mich über Eure Kommentare freuen.

Da ich es auch in einem privaten E-Mail-Wechsel nicht geschafft habe, das Vorgehen zu erläutern, habe ich einen kurzen Screencast gemacht (Gegen Ende musste ich den während der Testausführung kurz pausieren, um innerhalb der 5 Minuten zu bleiben).

Hier ist der Screencast: Unten rechts ist ein kleines Icon, mit dem man in den Vollbildmodus wechseln kann:

Bei Scrum gibt es die Rolle des Projektleiters nicht mehr. Die meisten Befugnisse und Verantwortlichkeiten haben sich auf die drei Rollen Product Owner, Scrum Master und Team verteilt. Wie geschieht das im Bereich der Teamzusammenstellung? Dabei sind folgende Teilaufgaben zu betrachten:

• Initiale Teamzusammensetzung
• Fehlende Fähigkeiten im Team
• Vergrößern des Teams (um Velocity zu steigern)
• Verkleinern des Teams (bei „Leerlauf“)
• „Low Performer“ und „Störenfriede“ identifizieren und ausschließen

Initiale Teamzusammensetzung
Die Zusammenstellung des Teams bei Projektstart kann nicht durch das Team selber ge­sche­hen, das gibt es zu diesem Zeitpunkt noch gar nicht. Durch seine Budget­ver­ant­wort­lich­keit hat der Product Owner natürlich einen sehr starken Einfluss, aber die genaue Entscheidung liegt sinnvollerweise beim Scrum Master. Er sollte darauf achten, dass das Team gerade in der ersten Zeit funktionieren kann, sowohl von den fachlichen als auch den sozialen Fähigkeiten der einzelnen Teammitglieder.

Die hier auftauchende Frage wie eine gute Zusammensetzung des Projektteams über den gesamten Projektverlauf aussieht, halte ich für sehr spannend würde aber den Rahmen sprengen. Diese werde ich in einem zukünftigen Artikel beleuchten.

Fehlende Fähigkeiten
Sollten im Team für das Projekt benötigte Kompetenzen fehlen, wird das durch das Team sehr schnell als Hindernis artikuliert. Meist erfolgt dies schon in den Daily Scrums, spätestens aber in den Retrospektiven. Es ist dann die Aufgabe des Scrum Masters dafür zu sorgen das Team mit den fehlenden Fähigkeiten auszustatten. Da bieten sich dem Scrum Master unterschiedliche Handlungsoptionen:

• Veränderung der Teamzusammensetzung
• Schulung/Coaching von Teammitgliedern
• Hinzuziehen eines Spezialisten

Vergrößerung des Teams
Hier geht es um die Entscheidung das Team zu vergrößern um die Velocity langfristig zu steigern. Der Grund kann eine sinkende (oder stagnierende) Velocity, der ansteigenden Termindruck des Projekts von außen oder einfach freie Mitarbeiterkapazitäten die in laufende Projekte eingebunden werden sollen sein.

Dieser Fall beschäftigt vor allem den Product Owner und das Team. Der Product Owner muss immer zwischen einer steigenden Velocity und den höheren Kosten (durch ein größeres Team) abwägen. Das Team wiederum kann beurteilen ob und in welcher Form weitere Teammitglieder überhaupt sinnvoll helfen.

Verkleinerung des Teams
Im Projektgeschäft kommt es immer wieder zu „Leerlauf“. Die Gründe hierfür sind sehr unterschiedlich, z.B. sind alle weiteren Aufgaben abhängig von einer Spezialistenaufgabe und sind so blockiert, zum Sprintende ist das Sprint-Backlog leer oder das Projekt­ende zeichnet sich gar durch eine leeres Product-Backlog ab. Auch lassen Projekte meist nur eine begrenzte Parallelisierung zu. Diese kann im Laufe des Projekts variieren und so „Leerlauf“ erzeugen. Dabei kann es sich beim „Leerlauf“ um ein spontanes Phänomen handeln oder er ist von systematischer Natur.

Erste Aufgabe ist es, zu erkennen, dass ein systematischer „Leerlauf“ vorliegt. Hier sind Team und Scrum Master gefordert. Dann ist eine passende Lösung zu finden, bevorzugt (und auch in den meisten Fällen möglich) im bestehenden Team, z.B. durch Neuschneiden der Aufgaben um die Spezialisten-Engpässe zu umgehen.

Aber gerade wenn es Richtung Projektende geht oder eine bisher genutzte hohe Parallelisierbarkeit entfällt, kann es Sinn machen, ein großes Team zu verkleinern.

Die Frage, welche neue Teamgröße sinnvoll ist, kann evtl. noch das Team entscheiden. Ich halte es aber für unklar, wie und durch wen die Teammitglieder ermittelt werden, die das Team verlassen müssen.

Low Performer und Störenfriede
Als eine der schwierigeren Aufgaben im Projektmanagement empfinde ich den Umgang mit Teammitgliedern, die nicht das benötigte Leistungsniveau zeigen oder massiv und anhaltend Unruhe in die Gruppe bringen. Eine Stärke von Scrum kann bei der Selbstregulierung innerhalb der Gruppe liegen. Diese setzt aber entsprechende soziale Kompetenzen und ein gutes Standing bei den anderen Teammitgliedern voraus. Es ist möglich, dass das alleine die Situation nicht rettet. Dann ist der Scrum Master gefordert, solche Dinge zu erkennen, anzusprechen und auf eine Lösung zu drängen. Ultima Ratio bleibt in solchen Situationen, das entsprechende Teammitglied aus dem Team zu entfernen, wobei unklar ist, wer diese (harte und recht endgültige) Entscheidung fällen darf.

Fazit
Auch in diesem Bereich teilen sich die Aufgaben auf die neuen Rollen auf. Gerade für harte Entscheidungen, aber auch in der Startphase von Projekten kann der “klassische Projektleiter” trotz allem vermisst werden.

Betrachtet werden soll hier lediglich die Struktur der Fachtests selbst. Außen vor bleiben sämtliche Überlegungen zur konkreten Ausführung (Logging, Parallelisierung) und Hardware. Wie schon des Öfteren erwähnt benutzen wir das Robot Framework zur Fachtest-Automatisierung, deshalb sind einige der vorgestellten Erkenntnisse spezifisch für das Robot Framework. Das meiste lässt sich aber auch auf andere Testframeworks übertragen. Wenn Ihr also Fitnesse, Cucumber, Concordion, etc. verwendet, braucht Ihr nicht gleich aufhören, zu lesen Genug des Vorworts, los geht’s:

In letzter Zeit hat es viele, gute Artikel gegeben, die sich mit der Frage beschäftigen, was einen einzelnen, guten Fachtest ausmacht: Da sei zum Beispiel Gojko Adzics Beitrag “Anatomy of a good acceptance test” empfohlen, oder Dale Emerys Artikel “Writing Maintainable Automated Acceptance Tests” (PDF), welcher die Ideen mit Codebeispielen und dem Robot Framework illustriert (Uncle Bob zeigt das Gleiche nochmal mit FitNesse). Nun bleibt ein einzelner, exzellent aufgebauter Fachtest aber selten alleine, wie aber schreibt man eine wartbare Test-Suite? Mit Test-Suite bezeichne ich nicht nur die Summe alles Tests, sondern alles, was notwendig ist, um die Tests auch auszuführen (also auch zusätzliche Artefakte, Libraries, Frameworks, etc.). Die Diskussion möchte ich mit einem Zitat aus Dales Artikel einleiten:

The need to change tests comes from two directions: changes in requirements and changes in the system’s implementation. Either kind of change can break any number of automated tests. If the tests become out of sync with either the requirements or the implementation, people stop running the tests or stop trusting the results. To get the tests back in sync, we must change the tests to adapt to the new requirements or the new implementation.

Die Notwendigkeit, Änderungen an der Test-Suite durchzuführen, ergibt sich also zum Einen aus Änderungen an den Anforderungen, und zum anderen aus Änderungen in der Umsetzung. Und was für einen einzelnen Test gilt, gilt natürlich erst recht für eine ganze Test-Suite. Wie soll eine ganze Test-Suite aber aufgebaut sein, um sich den Änderungen möglichst gut anpassen zu können? Offenbar gibt es Teile, die eher stabil sind und Teile, die flexibel und variabel sind.

Stabil sind z.B. das Testframework selbst und die zugehörigen Libraries und Plug-Ins. Diese wird man nicht mal eben austauschen sondern nach Möglichkeit konstant halten. Ebenso konstant sollten die Testfälle selbst bleiben, wenn es keine Geschäftsgrundlage gibt, die Tests zu ändern. Was allerdings problemlos möglich sein sollte: neue Tests unabhängig von den anderen hinzufügen. Wo sind dann die variablen Teile der Test-Suite, wenn sowohl die Tests (gedanklich ganz oben), als auch die Plattform (gedanklich ganz unten) stabil sein sollen. Die nachfolgende Grafik soll dies verdeutlichen und beschreibt den Aufbau einer wartbaren und skalierenden Test-Suite. Die einzelnen Schichten werden unterhalb der Grafik im Detail beschrieben, ganz grob lässt sich die Frage nach den variablen Teilen ganz einfach beantworten: Wenn ich ein System habe, dass an zwei Enden Stabil sein soll, insgesamt aber flexibel, dann müssen die variablen Anteile natürlich in der Mitte sitzen.

Im Folgenden soll der schichtenhafte Aufbau betrachtet werden. Die unterschiedlichen Farben symbolisieren dabei die unterschiedlichen Arten von Dateien im Robot-Framework:

• rot: Testfälle und Test-Suiten selbst sind durch rote Kästchen hervorgehoben.
• grün: Robots Resource-Dateien sind grün. Resourcen beinhalten Keywords, die von anderen Resourcen, oder von Testfällen aufgerufen werden können. Vereinfacht gesprochen ist ein Keyword einer Methode nicht unähnlich, eine Resource ist also eine kleine Sammlung von Hilfsmethoden.
• blau: Elemente des Robot Frameworks selbst sind blau.

Am linken Rand der Grafik ist der Grad der Stabilität, bzw. der Variabilität der Schicht aufgetragen. Oben und unten ergibt sich ein Maximum an Stabilität, welches zur Mitte hin abnimmt und dort ein Maximum der Variabilität aufweist. Das bedeutet, dass die Elemente in der Mitte der Grafik am Häufigsten Änderungen ausgesetzt sind, während die Elemente oben und unten über die Zeit relativ konstant bleiben.

Scalable and Maintainable Acceptance Test-Suite

Die einzelnen Schichten im Detail:

Test Cases

Die Testfälle selbst sollten ausschließlich angefasst werden müssen, wenn sich die Anforderungen ändern. Unsere präferierte Art und Weise das Verhalten in Robot zu spezifizieren ist das “Given / When / Then”-Format, garniert mit Beispieltabellen (das geht auch auf Deutsch). Andersherum formuliert bedeutet das, wenn sich die Anforderungen nicht ändern, darf es keinen technischen Grund geben, die Dateien mit den Testfällen auch nur anzufassen.

Test Suites

Testfälle sollten zu funktional zusammenhängenden Test-Suites gruppiert werden. Anfangs hatten wir einzelne Testfälle nach der User Story gruppiert, in welcher diese entstanden sind. Im Nachhinein hat sich aber herausgestellt, dass man dann oft suchen musste, wo sich welcher Test versteckte, wenn mehrere thematisch verwandte Stories existierten. Besser ist es, die Test Cases mit der User Story zu taggen, und die Tests nach Thema zu gruppieren.

Imports

Die nächste Schicht habe ich “Imports” genannt. Ihr Zweck ist das Mapping von Testfällen zu Resource-Dateien, welche die Keywords zur Automatisierung des Fachtests enthalten. Da die Tests selbst nicht durch technische Gründe geändert werden sollen, die Keywords aber laufend refactored und verschoben werden, brauchen wir etwas, das genau dieses Mapping herstellt. Da thematisch verwandte Tests in einer Test-Suite vermutlich ähnliche Imports brauchen, verwenden alle Tests in einer Test-Suite die gleiche Import-Resource. Umgekehrt wird jede Import-Resource nur von Tests aus einer Test-Suite verwendet.

Eigentlich enthalten die Import-Resourcen keine eigenen Keywords. Sie bieten sich allerdings trotzdem für solche “Einmal-Keywords” an, die ausschließlich in genau dieser Test-Suite verwendet werden, und in keiner der Resource-Dateien aus dem Layer darunter Sinn machen.

Aggregierende Objekte

Die Schicht mit der größten Änderungsfrequenz beinhaltet aggregierende Objekte: Bei Tests einer Weboberfläche hat sich schon das Entwicklungsmuster eines “Page Objects” etabliert (hier weitere Beispiele für Page Objects mit Selenium selbst oder mit JBehave). Abstrahierend vom Konzept einer Webseite findet in dieser Schicht das klassische Softwaredesign statt: wie wird Code strukturiert, um flexibel um wartbar zu sein. Page Objects sind eine Möglichkeit, wenn es tatsächlich um Webseiten geht. Allgemein können das auch andere Aggregate wie Business- oder Domänenobjekte, Services oder ähnliches sein.

Library Adapter

Wir haben eine Schichte der “Library Adapter” eingeführt, nachdem wir auf der robotframework-users Mailingliste recht ausführlich über das Thema “Multiple initialization of a Library” diskutierten (an dieser Stelle ein dickes Dankeschön an Pekka, Janne und die anderen Roboter, die auch auf schräge Fragen schnell und kompetent antworten). Fazit der Diskussion war, dass man Libraries am besten über eine Resource importiert, um sicher zu stellen, dass man nur eine Instanz der Library im System hat. Nach der Einführung der Library Adapter haben sich diese aber auch aus weiteren Perspektiven als nützlich erwiesen: Wird eine Library mit Parametern initialisiert (wie das z.B. bei der SeleniumLibrary der Fall ist) hat man nun nur noch eine Stelle im Code, an der die Parameter stehen (DRY). Desweiteren kann die Library still und heimlich um weitere Funktionalität ergänzt werden,  indem Keywords die thematisch eigentlich in die Library gehörten temporär in dem Library-Adapter aufgefangen werden, bis die entsprechende Funktionalität in der Library abgebildet ist.

Platform

Die Plattform umfasst die installierten Komponenten des Robot Frameworks und der verfügbaren Libraries.

Fazit

Abschließend kann ich feststellen, dass wir mit unserer neuen Struktur der Test-Suite deutliche Fortschritte gemacht haben. Andrerseits lernen auch wir ständig dazu und ich bin mir sicher, dass neue Erkenntnisse weiteren Einfluss auf Struktur und Gliederung der Test-Suite und einzelner Tests haben. Ich hoffe, dass wir unser bisher erworbenes Wissen hier gut zusammenfassen und präsentieren konnten, damit auch andere Projekte davon profitieren können.

Wie sehen Deine Erfahrungen bzgl. der Wartbarkeit von Test-Suites aus? Führen andere Technologien zu anderen Test-Suites? Gibt es in der vorgestellten Zwischenlösung noch Probleme, die uns bisher nicht aufgefallen sind? Ich freue mich auf die Kommentare.

Häufige Waffe der Wahl für Tests von Web-UIs ist Selenium. In der Konstellation “Selenium vs. Download” ergeben sich gleich mehrere Probleme, die gelöst werden müssen:

1. Dateidownload: Der Download-Dialog, der sich nach einem Klick auf ein Dokument öffnet ist in allen Browsern nativ und kann nicht über JavaScript gesteuert werden. Eine schlechte Ausgangslage für Selenium: Ohne eine Möglichkeit auf den Dialog Einfluß zu nehmen, bleibt dieser geöffnet und der Testcase hängt.
2. Dateitransfer: Unter der Annahme, dass das erste Problem gelöst werde kann, ergibt sich ein Folgeproblem: Falls der Selenium-Server nicht auf dem gleichen Rechner läuft, wie der Server zur Testautomatisierung, muss die gerade heruntergeladene Datei auch noch irgendwie auf den Testautomatisierungs-Server transferiert werden.

Ansätze zur Lösung des Downloadproblems

Das Problem des Dateidownloads kann auf unterschiedliche Weisen gelöst werden.

1. Fensterautomatisierung
Der erste Ansatz hat was von “Brute Force”: Sucht man im Internet nach einer Lösung findet man recht schnell Vorschläge, den Download-Dialog über eine native Fensterautomatisierung wie AutoIt fernzusteuern. D.h. man würde AutoIt so vorbereiten, dass es auf einen Download-Dialog unterschiedlicher Browser wartet, und an der Stelle an der Selenium hängen bleiben würde das Ruder übernimmt, die Datei speichert und den Dialog wieder schließt. Danach kann Selenium wie gewohnt weitermachen.

Das mag funktionieren, aber ich fand die Lösung technischen overkill, und wie sich gezeigt hat, geht es auch wesentlich einfacher.

2. Standardverhalten des Browsers anpassen
Die zweite Möglichkeit besteht darin, das Profil des Browsers dahingehend anzupassen, dass sich z.B. beim Klick auf ein PDF erst gar kein Dialog öffnet, der fragt, was der Benutzer mit der Datei anstellen möchte, sondern diese kommentarlos und ohne jede Nachfrage in ein vorbestimmtes Verzeichnis schreibt. Dazu muss mit dem entsprechenden Browser und Profil einmal ein Download durchgeführt werden, um dann dort das Standardverhalten festzulegen (“Für Dateien dieses Typs immer diese Aktion ausführen”).

Na gut, das könnte funktionieren. Man muss “nur” sicherstellen dass alle EntwicklerInnen, Hudson-Instanzen, etc das gleiche Browserprofil verwenden. Und je nach dem wieviele unterschiedliche Dateitypen heruntergeladen werden sollen, ist das auch ein kleines Stück arbeit.

3. Direkter Download
Warum eigentlich den Umweg über Selenium? Wäre es nicht viel cooler, wenn man die Datei einfach ohne Selenium runterlädt? Dann hätte man das zweite Problem auch gleich mit erschlagen. Warum eigentlich nicht, wget gibt es schließlich nicht nur für Linux, sondern auch für Windows. Problem gelöst? Nicht ganz: was ist mit Dateien, die nicht frei zugänglich sind? Was ist wenn ich erst mit Selenium einen bestimmten Zustand herstellen möchte, um dann auf eine möglicherweise generierte Datei zuzugreifen? Für öffentliche Dateien scheint die Lösung gut zu funktionieren, aber für manche Situationen ist die Lösung wohl noch nicht ausreichend.

Fazit: Downloadproblem
Ok, es ist möglich Dateien herunterzuladen, es ist aber mit etwas Arbeit und eventuell weiteren Werkzeugen verbunden. Aber der erste Schritt ist ja, dass man überhaupt eine funktionierende Lösung hat.

Was war nochmal das andere Problem?

Ansätze zur Lösung des Dateitransfer-Problems

Na gut, zugegeben, das ist kein wirkliches Problem. FTP kann heutzutage doch jeder. Fast jeder. Für unser favorisiertes Werkzeug zur Fachtestautmatisierung, das Robot Framework, gibt es leider noch keine Library, die per FTP auf entfernte Dateien zugreifen kann. Hier hieße es also mal wieder flugs eine eigene kleine Library geschrieben, was aber auch nicht so schwierig sein dürfte.

Problem gelöst

In Verbindung mit den Ansätzen 1 und 2 von oben wäre es also möglich das Problem vollständig zu lösen:

• Datei mit Selenium herunterladen und in ein Verzeichnis schreiben, das über FTP erreichbar ist
• Dann per FTP die Datei zum Server zu Fachtestautomatisierung transferrieren.
• Danach können dann nach belieben Checks auf der Datei ausgeführt werden.

Puh … das sieht nach einer Menge Arbeit für ein eigentlich recht einfaches Problem aus.

Irgendwie nagt immer noch das wget an mir, was ja eigentlich nach einer sehr einfachen, aber unvollständigen Lösung aussieht … Wäre es nicht cool, wenn man wget irgendwie sagen könnte, es soll da weitermachen, wo Selenium aufgehört hat? Man kann!

Gesamtlösung

Letztendlich ist die Lösung sehr einfach und elegant, und ich frage mich, warum ich nicht direkt darauf gekommen bin — vermutlich ein Anzeichen dafür, dass die Lösung wirklich sehr einfach ist.

Wie kann man wget also sagen, es soll an dem Punkt weitermachen, an dem Selenium gerade aufgehört hat? Woher weiß ein Webserver, wer da überhaupt den Request stellt: über die aktuelle Session! Man kann wget über Cookies und Header-Parametern die Session-ID mitgeben, um dann auf die Datei zugreifen zu können. Das ganze ist als Keyword implementiert ein Zweizeiler!

Keyword "Download File"

Download File  [Arguments]  ${COOKIE}  ${URL}  ${FILENAME}
  ${COOKIE_VALUE} =  Call Selenium API  get_cookie_by_name  ${COOKIE}
  Run and Return RC  wget --cookies=on --header "Cookie: ${COOKIE}=${COOKIE_VALUE}" -O ${OUTPUT_DIR}${/}${FILENAME} ${URL}

Zuerst wird also über einen direkten Aufruf einer Methode der Selenium API ein bestimmtes Cookie ausgelesen und dessen Wert zwischengespeichert. Im zweiten Schritt wird ein neuer Prozess gestartet und so lange gewartet, bis dieser Prozess terminiert. Das ist der Fall, wenn die Datei erfolgreich mit wget heruntergeladen werden konnte. Dazu muss wget natürlich irgendwo im Pfad liegen, ansonsten wird der Test nicht funktionieren. Über den Headerparameter “Cookie:” arbeitet wget in der gleichen Session weiter wie Selenium, und hat somit Zugriff auf die Datei. Voilà

Das neue Keyword nimmt drei Parameter entgegen

1. COOKIE Das Cookie wird vorher über Selenium ausgelesen und dann an wget weitergegeben. Das ist üblicherweise ein Indikator für die laufende Session
2. URL Der Link zu der Datei die heruntergeladen werden soll
3. FILENAME Der Name unter dem die Datei in Robots Outputverzeichnis abgelegt werden soll

Gebrauch des neuen Keywords

Der Gebrauch des neuen Keywords ist jetzt schon fast trivial, trotzdem hier der Vollständigkeit halber der Download eines PDFs, das als “file.pdf” in das Ausgabeverzeichnis gelegt wird (d.h. dort, wo auch die Reports landen). Das Cookie mit der Session-ID ist JSESSION.

Download File  JSESSIONID    http://<...>/web/pdf?id=4711  file.pdf

Dateidownloads mit Selenium – einfach möglich!