Was ist eigentlich dieses Scrum?

In meinem anderen Leben als erwerbstätige Person mache ich ja was mit Software. Früher habe ich programmiert, heute sage ich anderen Menschen, was sie programmieren sollen. In ersterem Zusammenhang habe ich auch schon das mit dieser agilen Entwicklung gemacht. Ein anderes Buzzword in diesem Zusammenhang ist Scrum, das hat man vielleicht schon mal gehört, denn es wird gerne ganz Buzzwordmäßig in den Raum geworfen, und in den meisten Fällen, das ist jedenfalls meine Erfahrung, wissen die Leute nicht, wovon sie reden.

Ich habe mit Daniel Meßner darüber geredet, was agile Softwareentwicklung ist und wie Scrum funktioniert. Herausgekommen ist eine Folge für seinen Podcast „Coding History“. Und zum Hören geht’s hier entlang.

Die Sache mit der Kolumne und der Wired

Ich schreibe ja seit letzten Jahr zusammen mit Kathrin Passig eine Kolumne für die deutsche Wired. Tatsächlich kam das so überraschend und hat mich gleichermaßen erfreut wie emotional überfordert, so dass ich ganz vergaß, die ganze Zeit ununterbrochen darüber zu reden. Andere Leute nennen das vermutlich Professionalität oder so.

Die Kolumnen erscheinen jeden Monat in der Wired. Auf einer Seite erklären wir irgendwas mit Programmierung und Softwareentwicklung, das uns selber so sehr interessiert, dass wir es auch gerne anderen Menschen mitteilen wollen.

Zwei Eine dieser Kolumnen haben hat sich durch die Wired-Paywall geknabbert und sind ist auch für Nicht-Abonnenten frei verfügbar. In der ersten haben wir darüber geschrieben, warum man sich als Programmierneuling bloß keine Profiprogrammierer als Berater anlachen sollte. In einer der neueren Kolumnen ging es dann um Gummienten und was das mit Problemlösungen zu tun hat.

Ich wünsche viel Vergnügen und vielleicht sogar ein bisschen Erkenntnisgewinn.

(Update: In einem kurzen Zeitfenster waren mal zwei Kolumnen frei verfügbar. Das scheint jetzt nicht mehr der Fall zu sein und man kann eben doch nur noch die erste Kolumne lesen. Ich hab mir das nicht so ausgedacht.)

Was man lernt, wenn man einen Workshop hält

Ich war letztes Wochenende auf dem Zündfunk Netzkongress in München. Dort habe ich in leicht angeschlagenem Zustand einen Vortrag mit dem schönen Titel „Die Entmystifizierung des Codes – It’s no rocket science!“ gehalten und dann noch zwei Nullcheckerbunny-Workshops. Da die Workshops nicht so überlaufen waren wie auf der re:publica im Mai habe ich den Vortragsteil etwas verkürzt und dafür tatsächlich versucht mit den Teilnehmern live zu programmieren.

Wie gut das geklappt hat, können die Teilnehmer besser beurteilen als ich. Mein Gefühl war, dass ich einige doch etwas mehr verwirrt habe als ich wollte, andere jedoch ganz gut mitgekommen sind. In der Tat ist es zwar gut gelaufen, hat aber enormes Potential für Verbesserungen. Möglicherweise ist das aber ein ganz normaler Lernprozess, vor allem, wenn man wie ich recht wenig didaktische Erfahrung hat.

Lesen kann man unter anderem hier darüber oder man kann hier ab Minute 44 hören, was eine Teilnehmerin und ich so erzählen.

Ich habe mir aber fest vorgenommen, die gelernten Lektionen festzuhalten und dann einfach jedes Mal irgendwas besser zu machen. Das Interesse scheint weiterhin da zu sein, insofern glaube ich, dass die Grundidee nicht verkehrt ist, man an der Umsetzung aber sicher noch einiges tun kann.

Wichtige Lektionen von diesem Wochenende:

1. Wenn man glaubt, man hätte den Mindestkenntnisstand des am wenigsten erfahrenen Teilnehmers für sich identifiziert: Mindestens noch eine Ebene tiefer ansetzen. Im ersten Workshop scheiterten wir an der Eingabe von repl.it in den Browser. Ich hatte schlichtweg nicht bedacht, dass das alles nicht so selbstverständlich war, wie es mir schien, schon allein, weil ich ja mittlerweile sehr oft repl.it aufgerufen habe und dieser Vorgang für mich quasi natürlich war. Wahrscheinlich sollte man am besten auch einfach direkt zwei Ebenen tiefer anfangen. Man weiß nie.

2. Ergebnissicherung betreiben. Ich kannte das Wort auch nicht, es wurde mir von Stephan im Techniktagebuchredaktionschat beigebracht und es bedeutet mehr oder weniger, dass man, nachdem man jemandem etwas beigebracht hat, sicherstellt, dass es bei dem anderen auch richtig angekommen ist. Im Zweifelsfall durch einfaches Nachfragen. Das hat in diesem Fall nicht funktioniert, weil auf einmal die Zeit vorbei und die Leute zu anderen Sessions wollten oder beim zweiten Workshop die Ecke im Foyer, wo der Workshop statt fand zugunsten einer Sendungsaufzeichnung recht zügig umgebaut werden musste. Das ist natürlich auch eine Ausrede. In Wirklichkeit hatte ich die Zeit nicht im Blick, ansonsten hätte ich auch rechtzeitig abbrechen und Ergebnissicherung betreiben können.

Für das nächste Mal habe ich also schon zwei wertvolle Lektionen gelernt, es kann also nur besser werden. Eine Stunde bleibt weiterhin zu kurz, das Codebeispiel könnte überarbeitet werden und vermutlich gibt es noch zehn bis hundert weitere Aspekte, an denen man schrauben könnte. Wenn nach jedem Workshop nun aber zwei bis drei konkrete Ansätze zum Besserwerden rausfallen, finde ich das aber schon okay. Damit kann man arbeiten.

Anne erklärt Programmieren: Unnötige If-Verzweigungen im Alltag

Die re:publica wirkt nach. Deswegen möchte ich auch weiterhin allen Null- und Hilfscheckerbunnys ein bisschen was über Programmierung erklären. Heute zum Beispiel etwas über leider unnötige If-Verzweigungen im Alltag.

„Wenn der mitkommt, fahren wir um Viertel vor acht los“, sagt der Mann, als ich schon mit Körbchen zum Einkaufen bereit im Flur stehe.

„Wer? Der Rolf?“ frage ich.

„Ja.“

Wie wir im Nullcheckerbunnykurs gelernt haben, gibt es in der Programmierung sowas wie If-Konditionen. Wer schon mal ein bisschen mit Excel rumgespielt hat, wird dort vielleicht auch schon mal über diese WENN-DANN-Konstrukte gestolpert sein. Eine If-Kondition oder -Verzweigung fragt nach einer Bedingung. Ist diese korrekt, schlägt sie einen bestimmten Pfad im Programmablauf ein. Ist sie nicht korrekt, wird entweder nach einer anderen Bedingung gefragt (else if), es wird einfach etwas anderes gemacht (else) oder es passiert gar nichts besonderes und es geht weiter im Programm.

In diesem Fall hätten wir also:

var Abfahrtszeit;

if (RolfKommtMit == true){
    Abfahrtszeit = "19:45 Uhr";
}

Jetzt muss man natürlich noch wissen, dass man sich den zweiten Teil der Bedingung sparen kann. Gesetzt den Fall, dass Rolf mitkommt, ist der Wert der Variablen RolfKommtMit ja true, die Abfrage ist also übersetzt if (true == true). Folgendes reicht also völlig aus:

var Abfahrtszeit;

if (RolfKommtMit){
    Abfahrtszeit = "19:45 Uhr";
}

An dieser Stelle fangen wir jetzt an, wie ein Programmierer zu denken. Denn wir möchten ja auch wissen, wann Abfahrtszeit ist, wenn Rolf nicht mitkommt. Anders gesagt: Wir brauchen noch ein else für unseren Code, weil wir ansonsten gar nicht losfahren. Das wäre doof.

Ich frage also: „Und was, wenn Rolf nicht mitkommt?“

„Dann fahren wir auch um 19:45 Uhr los.“

Also:

var Abfahrtszeit;

if (RolfKommtMit){
    Abfahrtszeit = "19:45 Uhr";
}
else{
    Abfahrtszeit =  "19:45 Uhr"; 
}

Hm.

Aufmerksamen Bunnys ist vielleicht schon etwas aufgefallen: Egal, was passiert, die Abfahrtszeit ist immer 19:45 Uhr. So wichtig es oft genug ist, an dieser Stelle brauchen wir dieses ganze If-und-Else-Zeug gar nicht und wir schreiben:

var Abfahrtszeit = "19:45 Uhr";

Damit merken wir auch: Es ist wumpe, ob Rolf mitkommt oder nicht. Diese Information hat auf die weitere Abendplanung zunächst überhaupt keinen Einfluss und unsere schöne Variable RolfKommtMit wird gelöscht und ward nicht mehr gesehen. An dieser Stelle soll aber auch Schluss sein mit Programmieranalogien, denn in der Realität freuen wir uns natürlich, wenn Rolf mitkommt und es ist uns keineswegs egal. Nur für die Abfahrtszeit bleibt die Information irrelevant. Denn wir fahren ja so oder so um 19:45 Uhr los.