Alle Beiträge von Markus Gärtner

Lesenswerte Agile Bücher

Ein Team, das ich coache, fragte mich gestern nach einer Liste von Büchern. Da ich häufig aus verschiedenen Büchern zitiere, habe ich ein paar der Bücher zusammengestellt, die mir am Anfang mit der Agilität geholfen haben. Da ich die Liste, die ich dem Team zugesandt habe, wertvoll empfand, habe ich mir direkt vorgenommen, diese Liste auf meinem Blog für spätere Hinweise zu verlinken. Auch wenn es für das Weihnachtsgeschenk ein wenig zu spät kommt, hier ist eine Liste an Büchern, die ich für jedes Team im Agilen Umfeld empfehle. Ich habe Links auf amazon.de ergänzt.

Lesenswerte Agile Bücher weiterlesen

Agiles Testen in der Praxis

Vor einiger Zeit nahm ich an einer Umfrage zum Thema Agiles Testen teil. Etwas überrascht war ich heute, als ich über Twitter von Andreas Simon erfuhr, dass die Ergebnisse veröffentlicht wurden. Davon ausgehend, dass ich die Benachrichtigung übersehen hatte, habe ich mir den Artikel dann heute zu Gemüte geführt. Als Tester weiß ich allerdings auch, dass ich keiner Statistik trauen sollte, die ich nicht selber gefälscht habe. Während die Autoren ein paar Interpretation der Daten in dem Artikel beschreiben, möchte ich im Folgenden meine eigene Sichtweise wiedergeben.

Agiles Testen in der Praxis weiterlesen

Was ist Akzeptanztestgetriebene Entwicklung?

In der letzten Zeit erhalte ich viele Anfragen nach Material und Informationen zu ATDD. Solange mein Buch für Einsteiger über ATDD noch nicht veröffentlicht ist, muss ich stets auf ein paar Materialien von Kollegen verweisen. Damit ich auch mal was eigenes habe, worauf ich verweisen kann, dachte ich mir, schreibe ich mal einen Blogeintrag.

Was ist Akzeptanztestgetriebene Entwicklung? weiterlesen

Was ist Software Craftsmanship?

Durch etliche Diskussionen auf Konferenzen bekomme ich immer mehr die Frage nach einer Definition von Software Craftsmanship mit. Auch wenn ich für UserGroups glaube, dass es mehr Sinn macht, sein eigenes Verständnis über die Handwerskkunst der Softwareentwicklung selbst zu definieren, glaube ich, dass uns eine Definition des Begriffes fehlt. In der Tat gab es früh schon Diskussionen zu dem Therm, aber darüber hinaus auch unterschiedliche Verständnisse unserer Mission. Beides zusammen für mich noch ein weiterer Grund, meine Gedanken zu dem Thema einmal nieder zu schreiben.

Was ist Software Craftsmanship? weiterlesen

Softwerkskammer – eine Bewegung zieht durchs Land

Auf der diesjährigen Konferenz zu Software Craftsmanship und Testing verfolgten wir Teilnehmer ein gemeinsames Ziel: ethisch vertretbare Softwareentwicklung im 21. Jahrhundert.

Ganz dem Geist des Manifestos für Software Craftsmanship und dessen Ethiken war uns der Teil „we share“ wichtig. Um das Wort über das Handwerk der Softwareentwicklung voran zu treiben, haben wir deshalb am letzten Tag der Konferenz zusammengesessen und über die Gründung verschiedener User Groups in ganz Deutschland verteilt gesprochen.

Unter dem Namen Softwerkskammer sind diese User Groups nun auf die Menschheit losgelassen worden. Dies sind meine Gedanken nach den jeweils ersten Meetings der Gruppe in Münster-Osnabrück-Bielefeld (ja, das gibt es!) sowie in Hamburg.

Softwerkskammer – eine Bewegung zieht durchs Land weiterlesen

Überlastung und was ich davon lernen kann

Vor einiger Zeit habe ich damit begonnen, ein Experiment zu machen. Ich war mir nicht sicher, wie viele Aufgaben ich übernehmen kann, bis ich vor einem Problem stehe. Zum einen fühlte ich mich nicht überlastet, zum anderen hatte ich die das Gefühl, noch mehr übernehmen zu können. Ein paar Monate später, und ich fand mich überfordert. Ein paar Wochen später, und ich kann drüber reflektieren. Hier sind die Lektionen, die ich davontrage.

Überlastung und was ich davon lernen kann weiterlesen

Das erste Wertepaar des Agilen Manifests

Vergangene Woche entbrannte eine Diskussion auf einem unserer internen Kommunikationskanäle der it-agile. Dabei ging es darum, ob Kanban ohne WIP-Limits Kanban genannt werden darf und kann, oder nicht. In der Diskussion gab es Vergleiche mit Scrum, wann Scrum Scrum ist, und wann man eine bestimmte Implementierung agil nennen kann, und wann eben nicht.

Im Verlauf der Diskussion habe ich mich zu folgendem Kommentar hinreissen lassen:

Sowohl für Kanban als auch für Scrum gilt aber gleichzeitig: Wenn ich nichts verbessern will, brauche ich auch nichts ändern, sprich eine neue Methode einführen. Wie disruptiv ich das mache, kann ich dabei immer anhand der Kultur und bereits in Progress befindlichen Änderungen dosieren. Warum muss ich das dosieren? Das beschreibt das Satir Change Modell. Ich kann Kanban genauso hart einführen, wie ich Scrum weich machen kann, auf die Dosierung kommt es an.

Dieses Statement bedarf ein wenig mehr Eklärungen – Grund genug für einen Blogeintrag. Als Aufhänger nehme ich hierfür das erste Wertepaar des Agilen Manifests: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“.

Das erste Wertepaar des Agilen Manifests weiterlesen

Was Softwareentwicklung vom Handwerk lernen könnte

Ich erinnere mich daran, wie im Dezember 2008 die ersten Gespräche bei 8thLight und Obtiva in Chicago geführt wurden, die im März zum Manifest des Software Craftsmanship führten. Viele der Ergebnisse bekam ich leider nur indirekt über die Software Craftsmanship Mailingliste mit. Dennoch erinnere ich mich an ein Gespräch, das ich zu der Zeit mit einem alten Freund hatte. Mein Freund ist Dachdecker und auch mehr als zwei Jahre später glaube ich noch fest daran, dass wir als Softwareentwickler – Tester wie Programmierer – viel von anderen Handwerksberufen lernen müssen.

Was Softwareentwicklung vom Handwerk lernen könnte weiterlesen

„Agil ist doch auch nur Wasserfall“

Im vergangenen Jahr hatte ich eine Diskussion mit einer Testexpertin über Agile Softwareentwicklung, Software Testen und Scrum. Wir waren beide auf der gleichen Testkonferenz, die primär auf eher traditionelles Tester ausgelegt war. Trotzdem war hier ein dominantes Thema Scrum, Agile Softwareentwicklung und wie testen denn mit diesem Agilen Kram überhaupt funktionieren kann.

In unserer Diskussion kam es schnell zu dem Punkt, bei dem es darum ging, was die Unterschiede zwischen Agil und Wasserfall sind. Besagte Testexpertin war der Meinung, dass Agil nichts anderes als ein Mini-Wasserfall sei. Am Anfang der Iteration werden Anforderungen aufgenommen, diese werden dann umgesetzt, und später am Ende der Iteration getestet. Damit lassen sich dann auch direkt alle bisherigen Methoden nicht nur vermitteln sondern direkt anwenden. Super. Problem gelöst. So geht also Agiles Testen.

Leider stimmt das nicht so ganz. Das Vorgehen löst in meinen Augen vor allem das Problem der traditionell eingestellten Trainer, die auf einmal auf den Agilen Wagen aufspringen sollen, aber birgt gerade im Zusammenspiel mit Agiler Entwicklung auch einige schmerzhafte Probleme. Welche das sind, und was man dagegen machen kann, will ich hier kurz aufzeigen.

„Agil ist doch auch nur Wasserfall“ weiterlesen

Wie testen Sie Software?

Ich bin der festen Überzeugung, dass irgendwas in den vergangenen 50 Jahren in der Softwareentwicklung schief gelaufen sein muss. Aus irgendeinem Grund existiert nach wie vor die Ansicht, dass wir auf eine bestimmte Art und Weise Software entwickeln sollten. Genau wie bei der Kindererziehung gibt es Kontrahenten für eine bestimmte Ausprägung und andere Kontrahenten für eine andere.

Über die Jahrzehnte haben sich gewissen Regeln und Erkenntnisse etabliert, die sich einem „Jungspunt“ wie mir nicht erschließen. Ein Beispiel ist meine Erfahrung, die ich zu Universitätszeiten gemacht habe, als ich in einem Kaufhaus gejobbt habe. Während meiner insgesamt 10 Jahre dort, habe ich insgesamt drei unterschiedliche Marktleiter und drei Abteilungsleiter erlebt. Alle hatten unterschiedliche Herangehensweisen.

Während einer Periode, als wir einen neuen Abteilungwleiter bekamen, drückte der damalige Chef eine Anordnung durch, dass Bestellungen nur noch vom Abteilungsleiter und dessen Stellvertretung gemacht werden durften. Die übrigen Mitarbeiter sollten „nur“ noch die gelieferte Ware packen, sowie die Reste verwalten.

Für das Trackensortiment hatten wir zwei Kataloge. Diese umfassten ca. 100 Seiten mit jeweils knapp 25 Artikel pro Seite. Das bedeutete für die Führungsebene, dass sie sich durch 2500 Produkte zweimal pro Woche durcharbeiten mußte. Der Faktor Mensch bei einer derartigen stupiden Tätigkeit – die zudem noch unter dem Termindruck, dass die Bestellung zu einem gewissen Zeitpunkt abgeschickt sein mußte, verschärft wurde – ist allerdings nicht zu unterschätzen. Bis dato hatte ich die Aufgabe, die rund 20 Seiten an alkoholfreien Getränken, Wein, Sekt und Spirituosen zu bestellen. Es brauchte einige Zeit der Einarbeitung, bis ich all die unterschiedlichen Ausprägungen an Weinen kannte, die in der Liste auftauchten. Es brauchte mindestens noch einmal so lange, bis ich wußte, welche Sorte gut lief und welche ich nur ab und an bestellen mußte.

Nun, welche Auswirkung hatte die Anordnung des Chefs? Mittelfristig wurde ich gefragt, ob ich nicht auch Konserven und anderen Produkte packen könne. Da ich eine der Ausnahmen war, die weiterhin bestellen durfte, nahm ich keine Veränderung in meinem Bereich der Getränke wahr. Aber was die Konserven anging, empfand ich zunehmend Unzufriedenheit beim Packen. Ein Beispiel waren Soßen zum Backen. Hier gab es eine Sorte Schokosauce in zwei Größen, klein und groß. Diese spezielle Sorte fiel mir beim Packen auf, da Woche für Woche die kleine Größe stets leer blieb, während die große Größe im Regal voll war, und drei weitere Einheiten kamen.

Es dauerte nicht lange, bis sich das LAger zunehmend mit Beständen füllte, die wir nicht verkauften. Der Faktor Mensch plus Zeitdruck führte dazu, dass viele Fehler unterliefen. Viel schlimmer, diejenigen, die die Waren räumten, und auch später die Reste nachräumten, wußten um die Probleme. Aber wegen des fehlenden Vertrauens gelang dieses Feedback auch nicht in die Führungsriege. Dadurch akkumulierten sich die Fehler immer mehr – nun, bis zu einem Kollaps, den ich aber nicht mehr erlebt habe.

Was können wir daraus lernen? Nun, zunächst einmal ist frühes Feedback wichtig. Je eher ich weiß, dass ich einen Fehler gemacht habe, desto eher kann ich daraus lernen. Wie Jerry Weinberg in „Becoming a Technical Leader“ erklärt, ist Lernen aus Fehlern ein Schritt, der zu Innovation führt. Zweitens schafft Vertrauen das Verhältnis, in dem ich gefahrlos Probleme kommuniziere. Vorwürfe sorgen dafür, dass ich mehr Energie meiner Arbeit darin stecke, diese Fehler zu verheimlichen. Energie, die ich andererseits vielleicht für meine Arbeit aufbringen würde. Und drittens habe ich daraus gelernt, dass die Trennung von Ausführendem und Verantwortlichen in einigen Situationen keinen Sinn macht. In einem Sportverein schreibt ja schließlich nicht der beste Trainer die Trainingspläne für alle Gruppen. Das würde gar keinen Sinn ergeben aus den zwei vorgenannten Gründen.

Nun, drei Jahre später fand ich mich in meinem ersten Job wider. Meine erste Reaktion war, warum in der Softwareentwicklung derartige Praktiken üblich waren. Tester und Programmierer arbeiten in unterschiedlichen Teams und Abteilungen, Analysten und Programmierer sind voneinander getrennt. Kunden und Entwickler sprechen nicht direkt miteinander. Wir nehmen uns dadurch wesentliches Feedback, das uns dabei helfen kann, bessere Software zu entwickeln.

Nun, damals hat mich das vielleicht ein wenig verwundert, und ich habe seitdem daran gearbeitet, dieses Silo-Denken abzuschaffen, wann immer ich es gesehen habe. Bis ich heute morgen das volle Ausmaß der Misere in der Softwareentwicklung wahrgenommen habe. Ich lese momentan ein Buch aus dem Jahr 1961. Der Name des Buchs ist „Computer Programming Fundamentals“ von Leeds und Weinberg. In diesem Buch wird das erste Mal über Softwaretesten geschrieben. Umso dramatischer empfand ich die folgenden Worte auf Seite 67:

In summary, the process of programming is not a fixed set of analyzable steps but rather a series of tentative trials, followed by careful testing of the results of those trials. Each step may be repeated several times before its particular problems are all solves. Sometimes it is necessary to attempt the succeeding steps in order to verify a particular step. […] It occurs far too frequently that a program is completed, only to reveal that the problem it solves is not really the problem of interest. Similarly, if the analysis is incorrect, the answers from any resulting program will not be solutions to the problem.

Das war vor ziemlich genau fünfzig Jahren. Die Autoren sprechen in dem Buch darüber, wie Assembler funktionieren, dass sie numerische Codes aus Assemblerbefehlen generieren, und worauf man aufpassen muss, wenn man diese händisch übersetzt. Wie kommt es, dass wir fünfzig Jahre später, nach weiteren Abstraktionsebenen wie höheren Programmiersprachen, prozeduraler Programmierung und objekt-orientierter Programmierung immer noch der Meinung sind, dass diese Mechanismen nach wie vor funktionieren können? Haben sich unsere Probleme in den letzten fünfzig Jahren denn gar nicht gewandelt?

Ich denke, wir sollten – insbesondere als Tester – kritisch gegenüber Meinungen anderer sein. Wie kommt es dann, dass wir nicht kritisch gegenüber der Methoden sind, die wir tagtäglich einsetzen sollen, nur weil sie ein Trainer uns mal beigebracht hat? Ich denke, wir sollten jede Methoden viel häufiger hinterfragen, und darüber reflektieren, wie sie uns bei der Lösung unseres derzeitigen Problems hilft. Natürlich sollten wir dafür erst einmal wissen, welches Problem wir überhaupt haben.

Und ich hoffe, dass jemand genau diese Sichtweise ebenfalls in Frage stellen wird.