Q50: Wo bitte ist die Dokumentation?

Der geneigte Scrummler weiß was nach Sprintende kommt. Die Retrospektive. So wie kein Sprint ohne Kartenspiele auskommt ("Geh, bitte wie kummst auf 20 Storripeuints?"), so geht auch eher ein Mittagessen den Bach runter als das BvQ (aka der Scrummaster) die Retrospektive auslässt. Er hält es da mit Jeff Sutherland, der schon postulierte, dass das Fehlen der Retrospektive immer dazu führt, der Scrumkultur den Garaus zu machen. Denn schlussendlich wollen wir ja aus dem lernen was wir gemacht bzw. nicht gemacht haben. Ich mache seit meinem Warschkrak-Abenteuer (Q20) nach jedem Ausflug eine Retrospektive. Dadurch weiß ich jetzt z.B. dass ich mir am Airport Nürnberg nie wieder eine Flasche Mineral kaufe ohne vorher nach dem Preis zu fragen. Ich sage nur: Bajuwarische Raubritter.

Um 10:00 soll die Retrospektive statt finden. Soll, wie gemerkt. 10:00 Uhr, kein DEV-Fraggle im Büro. BvQ und DLTB machen einen leicht säuerlichen Eindruck. Das Scrumherzal wird sich freuen. Verspäten bedeutet löhnen. Ein Euro fürs Scrum-Herzal.

Schließlich geht's dann um 11:15 los. Soviel zum Thema Meetingkultur und dem Spruch "in time, in scope, in budget". Zu klären sind die Themen:

• Significant Events
• What went well?
• What could be improved?
• Who is in Control?

11:35 Ich bereite mich gerade innerlich darauf vor, die Frage nach "What could beimproved" mit dem Thema "Das Nichtvorhanden sein einer Testbasis aka RFC-Dokument aka Use-Case Beschreibung aka UserStory" anzuzünden. Da kommt BvB (aka Boss von BvQ) in unseren Glashobel und bringt sich ein mit dem harmlosen Satz "I bin grod dabei de Relisdoku zu schreibn". Ein Zucken in meinem rechten Auge gibt mir zu verstehen: Uuuwwweh, da kommt noch etwas. Und? Mein Auge hat recht, denn es folgte die ketzerische Frage: "Wie soi i wissn wos i schreibn soi, wauns ka Doku gibt wo drinnan steht wos ma wia gmocht hom? Wia deids ihr eigentlich entwickln?".

Mein Herz lacht. Ja, danke BigBoss. Endlich ein Einwand von ganz oben. Nach 25minütiger wilder Diskussion und der Feststellung "die anderen sind schuld" verlässt BigBoss die Retrospektive um am 12:00 Uhr-Montag-Meeting der "Anderen" teil zu nehmen und den Sachverhalt zu klären.

Der Rest verläuft nach dem Motto: "Same Retrospektive as every Sprint.".

Mein abschließender Vorschlag die Ergebnisse der Sprintretros in Form einer Gelben-Zettel-Wolke (in Anlehnung an eine Tag-Cloud) öffentlich zur Schau zu stellen, wird abgeschmettert. Beim Weg zum Essen erkläre ich BvQ wie ich mir die Wolke vorstelle. Jetzt reden BvQ und ich nicht an einander vorbei und ich erhalte den Auftrag mich darum zu kümmern. Super, ich wollte schon immer Wettergott spielen und damit den Lauf der Geschichte beeinflussen. Welche Geschicht das wohl sein wird?

Q44: Wie agil ist Session Based Testing?

Y. (aka Ukrainischer DEV-Fraggle) hat die Setups des ReportsSchedulers umgebaut. Der gelbe Zettel auf der Scrumtafel mit der Aufschrift "ENG Test" schreit: "Q., nimm mich. Hallo ich will von dir in Progress genommen werden. Los, du Sack fang endlich zum Testen an!". Nachdem gelbe Zettel mit dieser Aufschrift meine besten Freund sind, komme ich diesem Wunsch gerne entgegen.

Schritt 1: Testbasis (aka RFC-Dokument aka User-Story aka das-Ding-das-nie-vollständig-ist-wenn-PK-eine-Anforderung-hat" sichten. Was jetzt kommt brauch ich nicht erzählen, es ist eh klar.

Aber halt. Was sehe ich da. Der zuständige DEV-Fraggle hat eine technische Spec geschrieben. Schampus für den Y. Wobei der Lenin-Orden würde dem Ukrainischen-Tom-Cruise-Top-Gun-Absolventen besser stehen.

Na gut. Session Based Testing, mein neuestes Lieblingwort. Ich verfahre auch danach. Vorerst zum Kennenlernen. BvQ (aka den kennt jetzt eh schon jeder, das ist mein Boss) sagt immer "Sehe es als eine Chance etwas neues Auszuprobieren!". Recht hat der BvQ.

Ich definieren als Testcharta: "Prüfe ob die Java-Script-Funktionalität in allen Browsern korrekt arbeitet". SB-Timescope: "90 Minuten". Das muss reichen um zu beweisen dass eine Abweichung vorliegt.

Werfe meine Wunderwaffen an: 6 Virtuelle PC auf meiner 4-GB-aber-nur-2-adressierbaren-Workstation an. Auf jedem läuft der jeweilige Browser (FF35, IE7, IE8, Opera, Safari, Crome) in einer nackten Windows-XP-Umgebung. Weil, man kann ja nie wissen welcher Browser welchen was zusammenhaut.

Richtige Abweichung finde ich keine. Java Script funktioniert. Mir fällt nur auf das ich Datenfelder eingeben kann die keiner braucht und daher auch nicht gespeichert werden. Sofort mache ich meinem Gegenüber DLTB (aka die-lebende-Test-Basis aka BdF aka Boss der Fraggles aka der-Mann-der-jedes-Byte-der-Applikation-kennt) klar das somit ein klarer Usability-Verstoß nach SD§ 4711 Absatz 0815 vorliegt.

Nach heftigen Diskussionen meint DLTB "Des woar scho imma so. Oba du host scho recht. Des kennt ma a noch schnö mochn!". Alarmglocken schrillen, " a no schnö mochn". DLTB formuliert schnell die neue Anforderung und gibt diese verbal über meinen Kopf hinweg an Y. weiter. "Y., geh berücksichtige das die zwa Felder nur angezeigt werden wenn im Feld Periode der Wert  Täglich steht."

Cruise meldet verbal über meinen Kopf zurück: "OK, das haben wir gleich...!"

Ich liebe agile Softwareentwicklung. Doch halt. Was war da zwischen "OK...!" und "Ich liebe agile...."?

Q30: Eine Testbasis brauchen nur Schrägparker!

Nach 135 Tagen Abstinenz habe ich heute den 1. Gelben Zettel (aka Sprint Task) in Progress gesetzt. Das ging runter wie Honig. Ein Blick in die Testbasis* sollte Klarheit darüber schaffen was zu testen ist. Doch, hallo, wo bist du Kleinod des Verlangens? Nicht da, eh klar. Es ist ja "nur" eine Kleinigkeit. Bin ich froh dass mir eine lebende Testbasis gegenüber sitzt. Was hätte ich wohl gemacht wenn das nicht der Fall wäre und der betreffende PMC beim Kunden sitzt?

Ich hätte mir einfach den nächsten gelben Zettel genommen und gehofft das es dazu eine Testbasis gibt. Klar?


*Das ISTQB-Glossar definert die Testbasis wie folgt:
Alle Dokumente, aus denen die Anforderungen ersichtlich werden, die an eine Komponente oder ein System gestellt werden, bzw. die Dokumentation, auf der die Herleitung oder Auswahl der Testfälle beruht. Wenn ein Dokument nur über das formale Änderungsverfahren geändert werden kann, handelt es sich um eine festgelegte Testbasis.