Gestern abend war ich auf einer Veranstaltung der Java-User-Group Karlsruhe.
Das Thema war „Testgetriebene Entwicklung – vom Dogma zum Pragmatismus“ vorgetragen von Martin Schneider und allein schon durch die ähnlichen Taglines (LessCode proklamiert „Pragma statt Dogma“), musste ich mir das anhören.
Beeindruckend fand ich die systematische Erfassung der „test smells“ (analog der „code smells“ von Kent Beck): Es geht um die Kategorisierung von nicht optimalen Tests. Z.B. gibt es Tests, die deshalb nicht gut sind, weil sie zuviel auf einmal testen, weil sie ein zu komplexes Testsetup erfordern, Tests die kopiert und nur wenige Zeichen abgeändert werden oder Tests, die nur manchmal fehlschlagen (Eine Auflistung findet sich z.B. hier)
Martin Schneider war 10 Jahre lang in der als Berater unterwegs und erzählte, wie die Vorgehensweise beim Extreme Programming (XP) teilweise zu dogmatisch, zu ernst, genommen wurden. Akribisch wurde sich an die Prozesses des XP gehalten, so dass z.B. jede Zeile Code, die jemand allein entwickelt hat, weggeworfen wurde, weil XP nun mal Pair-Programming vorschreibt. Und der Diskussion, ob eine Arbeitszeitenregelung eingeführt werden soll, weil der Kollege X im Sommer lieber von 6-14 Uhr anwesend ist, da er von 6 bis 9 Uhr morgens auf seinen Pair-Programming-Partner warten müsste.
Generell habe ich aber noch nicht verstanden, wie sich XP als auch agile Prozesse exakt nach Lehrbuch praktizieren lassen sollen: Einerseits sind stringente Prozesse wie Test-First durch XP definiert, andererseits lautet der erste Punkt des agilen Manifestos doch „Individuals and interactions over processes and tools“. Aber ist Test-First nicht ein Prozess, und diese kommen erst nach den Bedürfnissen der Menschen?
Vielleicht kann da mal jemand Licht ins Dunkel bringen; ich würde mich über Kommentare dazu freuen.
Mindestens so interessant, gerade aus Sicht eines LessCoders, sind jedoch die danach stattfindenden Diskussionen. Mehr dazu gibt es hier:
