Es gibt eine Frage, die während so einer Konferenz immer wieder auftaucht, auf die ich einfach keine richtig gute Antwort habe. Dies ist die Frage, ob man als Tester oder Entwickler arbeitet. Ich könnte antworten „Beides“, aber das irritiert einige Leute, die denken, dass dies nicht wirklich möglich ist. Eine andere interessante Frage ist die wieviele Tester denn in meinem Projekt arbeiten. Tja, die Antwort könnte variieren zwischen „Wir haben keine Tester“ und „Das Team besteht nur aus Testern“. Die beste Antwort auf diese Frage hat mein Kollege Andreas heute gegeben: „Wir arbeiten in Projekten in denen es Arbeit zu tun gibt und wir haben Leute, die diese Arbeit machen.“ Wahrscheinlich sind wir hier in der wirklich glücklichen Situation, dass wir es geschafft haben, sowohl das Wissen als auch das Interesse an den unterschiedlichen Aufgaben die in einem (agilen) Projekt anfallen, unter sehr vielen Team-Mitgliedern aufzuteilen. Dies beduetet natürlich nicht, dass es Kernkompetenzen und verschiedene „Vorlieben“ in den einzelnen Teams gibt. Aber letzen Endes sollten die benötigten Rollen nicht fest auf einzelne Personen im Team übertragen werden, sondern im Team muss es Team-Mitglieder geben, so dass – nach Bedarf – die verschiedenen Rollen besetzt werden können.
Quote from Twitter:
AndreasEK When can we finally replace „what’s the role of a tester in an agile context“ with „what testing skills does an agile team need“ #agiletd
Glücklicherweise gibt es aber auch eine Menge anderer Teilnehmer auf der Konferenz mit einer sehr ähnlichen Sichtweise und Andreas‘ Twitter-Nachricht wurde sogar in der Keynote von Michael Bolten als erstrebenswert zitiert. Es haben sich so ein paar sehr gute Diskussionen ergeben, die ich sehr interessant fand als Mitglied in einem agilen Team :-).
Aber nun zu den Präsentationen von Tag eins der diesjährigen Agile Testing Days in Berlin …
Keynote: Agile Defect Managemant von Lisa Crispin
Diese Präsentation war die erste des Tages und liegt entsprechend am weitesten zurück. Daher muss ich mal sehen, was ich aus meinem Gehirn noch raus quetschen kann bzgl. dieser Session ;-). Das zentrale Thema der Präsentation war wieviel Defect Management wir in agilen Teams brauchen und welche Werkzeuge wir hierzu idealerweise nutzen wollen. Dabei war es besonders interessant zu hören, dass ein Fehler, der während der Arbeit an einer aktuellen User Story im aktuellen Sprint gefunden wird nicht wirklich ein Fehler ist. Irgendwie ist dies offensichtlich, wenn man es hört, aber es ist sicherlich gut sich dies noch einmal klar zu machen. So ein Fehler wird „einfach gefixt“. Natürlich kann es Fehler geben – insbesondere in produktiven Systemen – die nicht sofort gefixt werden können. Diese müssen irgendwie nach gehalten werden. Trotzdem macht es auch hier Sinn sich noch einmal die verschiedenen Möglichkeiten und Werkzeuge anzusehen und eine
Lösung zu suchen, die für das eigene Projekt passend ist.
Think of one thing your team can do to prevent defects, starting next week. – Lisa Crispin
Dies kann natürlich ein komplettes Defect Management System sein, auch wenn sich dieser Ansatz nicht wirklich agil anfühlt. Jira ist natürlich eine nahe liegende Wahl, da Jira ohnehin oft schon im Einsatz ist in agilen Teams. Aber es kann auch eine Notiz auf dem Whiteboard sein oder ein automatisierter Test, den umgehend geschrieben wird, um die gefundene Fehlersituation nachzustellen. Wie so oft gibt es vermutlich auch hier mehr verschiedene Ansätze und mögliche Lösungen, als man auf den ersten Blick vielleicht denkt und Teams sollten sich hier selbst keine Limitierungen auferlegen, kreative Ansätze zu finden und einzusetzen. Dies passt sehr gut zur Präsentation von Rob Lambert, auf die wir im Folgenden einen Blick werfen. Zuvor aber noch kurz der Hinweis auf Lisa’s Slides, die hier zum Download bereit stehen und die Blogbeiträge von Gojko Adzic und Markus Gärtner .
Structure kill testing creativity von Rob Lambert
Die Präsentation von Rob Lamber dreht sich um Kreativität und wie zu viel Struktur genau diese Kreativität „abtötet“. Wie wichtig Kreativität – auch in der Software-Entwicklung – sein kann, zeigt das folgende Zitat:
Creativity is the process of having original ideas that have value. – Sir Ken Robinson
Wir können verschiedene Arten von Intelligenz unterscheiden (und dies nicht nur in der Software-Entwicklung, sondern auch in unserem täglichen Leben):
- Akademische Intelligenz
- Kreative Intelligenz
- Praktische Intelligenz
- Emotionale Intelligenz
Im IT-Umfeld wird oft nur die akademische Intelligenz wirklich positiv bewertet und die kreative Intelligenz z.B. als etwas abgetan, was man doch höchstens in der Marketing-Abteilung braucht ;-). Aber das ist falsch! In der Software-Entwicklung geht es extrem oft darum Probleme zu lösen und gerade hier sind kreative Einfälle oft extrem hilfreich.
Hierfür ist es aber absolut notwendig, dass Mitarbeiter darin unterstützt werden kreativ zu arbeiten. In manchen Organisationen und Firmen passiert das genaue Gegenteil, indem ein Umfeld geschaffen wird in dem Leute Angst haben etwas „Falsches“ zu tun und daher versuchen, sich durch übergroße „Prozesstreue“ abzusichern und bloß nicht aus dem Rahmen zu fallen.
Self-education is, I firmly believe, the only kind of education there is. – Isaac Astinov
Durch den agilen Ansatz versuchen wir ein Umfeld von Vertrauen zu schaffen, in dem Teams kreative Lösungen erarbeiten können. Dies wird unterstützt durch die Arbeit in kurzen Iterationen nach denen zurückgeblickt wird und nach wegen gesucht wird, Dinge in der Zukunft (noch) besser zu machen. Natürlich gibt es auch für agile Teams einen gewissen Rahmen, aber dieser sollte so weit wie möglich gefasst werden.
Mehr Informationen zu Rob’s Präsentation gibt es auch in diesem Blogbeitrag.
Keynote: Deception and Estimation: How we fool Ourselves by Linda Rising
Diese Keynote war für mich definitiv einer der Höhepunkte dieses ersten Tags, zusammen mit der Präsentation von Elisabeth Hendrickson, die mit positiver Energie aufgeladen war (wie immer ;-)). Aber zunächst zurück zum Vortrag von Linda darüber, wie wir uns selber täuschen.
Dies war wirklich einer dieser „nicht-technischen“ Vorträge, die einen besonderen Reiz haben, da diese einem Einsichten vermitteln, die über die Arbeitswelt hinaus gehen. Leider ist es so gut wie unmöglich ihren Vortrag hier angemessen wieder zu geben, denn dieser lebt nicht nur vom Inhalt, sondern auch von der einzigartigen Art und Weise, wie Linda dies vorgetragen hat.
Linda hat ihre Präsentation damit eingeleitet, dass es sich vermutlich um den merkwürdigsten Vortrag der ganzen Konferenz handelt und das die wenigsten Leute wirklich mögen werden, was sie zu hören bekommen. Zumindest auf mich trifft das nicht zu!
Software wird von Menschen entwickelt und dies mit Hilfe unserer Gehirne. Daher ist es sinnvoll sich einmal die Arbeitsweise unserer Gehirne genauer anzuschauen. Hierzu startet Linda mit der folgenden Definition:
Deception: „Consiously or unconsiously leading another or yourself to believe something that is not true.“
(Übersetzung: Täuschung: „Sich selbst oder jemand anderen bewusst oder unbewusst dazu zu bringen, etwas zu glauben was nicht wahr ist.“)
Der erste gute Punkt hier ist, dass wir uns fast täglich selbst täuschen, wenn wir Zeiten abschätzen in unseren Software-Projekten. Aber es ist eine unserer Eigenschaften, dass wir immer denken, dies trifft nicht auf uns zu, sondern immer nur auf „die Anderen“. Dies passiert sogar dann, wenn es klare Zahlen und Fakten gibt, die einen bestimmten Sachverhalt untermauern. Der Grund hierfür ist, dass wir von Natur aus optimistisch sind und alle unsere Entscheidungen emotional begründet sind. Des weiteren besitzen unsere Gehirne sehr gute Filter und wir filtern unbewusst bestimmte Informationen aus, die wir nicht „wahr haben wollen“. Linda hatte hierfür das folgende gute Beispiel einer Umfrage unter Autofahrern. Es wurde gefragt wer sich für einen überdurchschnittlich guten Autofahrer hält und alle Teilnehmer taten dies. Interessanterweise auch solche, die gerade aufgrund von selbst verschuldeten Unfällen im Krankenhaus lagen.
There are no facts about the future. – Linda Rising
Es ist einfach spannend sich dies bewusst zu machen und sich darüber im Klaren zu sein, dass man diese Dinge nicht effektiv verhindern kann, z.B. in Abschätzungen. Es sind nicht immer nur „die Anderen“, bei denen Dinge falsche laufen, auch wenn es eine beruhigende Vorstellung ist. (Natürlich glaube ich trotzdem, dass es „den Anderen“ aber zumindest öfter passiert ;-).) Aber um wieder die Brücke zurück zur Agilität zu schlagen ist z.B. der Ansatz der „Estimation Meetings“, in denen nicht mehr nur eine einzelne Person Zeiten abschätzt, sondern das ganze Team, ein Weg diese Effekte zumindest abzuschwächen. Denn verschiedene Team-Mitglieder haben verschiedene Filter und so erhöht sich die Chance, zu besseren Ergebnissen zu kommen.
There is uncertainty in every project. – Linda Rising
Sehr wahrscheinlich ist es auch nicht wirklich erstrebenswert diese „Schutzmechanismen“ los zu werden und die Welt 100% ungefiltert und realistisch zu sehen (hier kam der nette Zwischenruf „eine Scheibe“ aus dem Publikum ;-)). Denn die einzigen Menschen, die die Welt so sehen sind entweder depressiv oder Soziopathen … nicht wirklich erstrebenswert.
Persönlich bin ich immer ein eher optimistischer Mensch – und bleibe es hoffentlich auch, aber trotzdem ist es einfach gut einen kurzen blick hinter den Vorhang zu werfen und erahnen zu können, wie diese Dinge zusammenhängen und wie sie unser tägliches Leben beeinflussen.
Keynote: Lessons learned from 100+ Simulated Agile Transitions von Elisabeth Hendrickson
Elisabeth hatte die schwierige Aufgabe die letze Keynote des Tages zu halten, wenn die Zuhörer normalerweise schon ein wenig ausgelaugt sind und die Konzentration ein wenig nachlässt. Aber wie bereits erwähnt war ihr Vortrag so energiegeladen, dass sie schon nach kürzester Zeit die volle Aufmerksamkeit des Publikums hatte.
Ihr Vortrag hat die Erfahrungen aus über 100 simulierten Wechseln hin zu agilen Methoden zusammengefasst. Leider habe ich die Chance nicht genutzt an ihrem entsprechenden Tutorial teilzunehmen, aber das werde ich bei der nächsten Gelegenheit nachholen.
Die Grundidee besteht darin die Gruppe in verschiedene Rollen aufzuteilen wie z.B. Produktmanager, Tester, Entwickler und sogar Computer. Natürlich darf hier auch der Kunde nicht fehlen. Dann gilt es bestimmte Aufgaben innerhalb von 15 Minuten zu erledigen und danach kommt eine moderierte „adept and reflect“ Session über den Prozess. Dann kommt die nächste 15 Minuten Runde im simulierten Projekt. Typischerweise kommt es an einem Tag zu vier Runden in denen das Team nach und nach die Ideen aus dem agilen Umfeld „neu erfindet“, wie z.B. kontinuierliche Integration und ATDD, um die Arbeit im Team effizienter zu gestalten.
People add their own complexity and time pressure (to the simulation). – Elisabeth Hendrickson
Elisabeth zeigt auf, das jeder Veränderungsprozess zunächst einmal Chaos bedeutet (für eine bestimmte Zeitspanne). In der Simulation ist dies typischerweise in der zweiten Runde der Fall. Aber dies ist ok, denn diese Phase wird überwunden. Es ist aber auch faszinierend zu beobachten, dass gerade in dieser Phase die „Mitspieler“ das Gefühl haben die Kontrolle zu verlieren und dann oft versuchen eine Person in der Rolle eines guten alten Projektmanagers zu etablieren. Aber es ist nicht die Kontrolle die fehlt, sondern sich Sichtbarkeit. Und genau diese Sichtbarkeit bekommen wir durch die agilen Methoden.
Don’t use communication solutions for visibility problems. – Elisabeth Hendrickson
Es kann in der Simulation sehr gut beobachtet werden, wie bereits kleine Änderungen am physikalischen Arbeitsumfeld große Unterschiede in der Produktivität des Teams bewirken können. Andere wichtige Resultate aus der Simulation sind, dass die täglichen Standup-Meetings“ keine Status-Meetings sind und das Tests ein sehr gutes Werkzeug sind, um sich im Team abzusprechen. Denn durch einen Blick auf die Tests – welche idealerweise in der BDD-Syntax geschrieben sind – bekommt man einen schnellen Überblick welche User Stories bereits implementiert und getestet sind.
Natürlich gab es noch viel mehr in der Präsentation und an dieser Stelle muss auch einmal gesagt werden, dass die Folien absolut fantastisch waren mit den kleinen Figuren, mit denen tägliche Arbeitssituationen nachgestellt wurden. Aber leider kann ich hier nicht alles im Detail wiedergeben, insbesondere nicht die sehr spannende Diskussion, die sich nach dem Vortrag entwickelt hat.
Was sonst?
Es ist sicherlich zwecklos zu leugnen, dass ich ein großer Fan des Robot Framework bin, da mich die Konzepte und die Umsetzung einfach überzeugen. Daher habe ich mich natürlich sehr gefreut Pekka, Juha und Janne zu treffen. Die drei haben ein Tutorial über „Executable Requirements in Practice“ gehalten, bei dem als Tool natürlich das Robot Framework zum Einsatz kam. Desweiteren hat Pekka noch einen Vortrag gehalten über „Acceptance Test Driven Development using Robot Framework“. Der Vortrag hat die Konzepte denke ich sehr gut herausgestellt, auch wenn für mich nicht so viel Neues dabei war und ich war selber zu diesem Zeitpunkt noch etwas ausgelaugt von meinem Vortrag über „Testing Web Applications in practice using Robot Framework, Selenium and Hudson“, den ich im Slot zuvor gehalten hatte.
Ich bin wirklich gespannt auf den morgigen Tag (der zum Zeitpunkt der Übersetzung schon der gestrige Tag ist ;-)) und sollte versuchen noch ein wenig Schlaf zu bekommen. Morgen früh um sieben Uhr treffen wir uns wieder zum Laufen in der Lobby und sollte noch jemand seine Laufsachen dabei haben freuen wir (Andreas und ich) uns über jeden weiteren Mit-Jogger :). Gute Nacht!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Thomas Jaspers
22.2.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Thomas Jaspers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.