Write the docs Vorträge im Sketchnotes-Format für alle, die nicht online dabei sein konnten:
https://writethedocs.threadless.com/collections/wtd-portland-2021-sketchnotes

Write the docs Vorträge im Sketchnotes-Format für alle, die nicht online dabei sein konnten:
https://writethedocs.threadless.com/collections/wtd-portland-2021-sketchnotes
Christine Hennig
Selbst im Vollzeit-Homeoffice unter Corona-Lockdown Bedingungen kann ich eine agile Methode auf meine individuelle Situation anpassen und agil arbeiten.
Scrum kommt aus dem Rugby und bedeutet Gedränge. Das Team trift sich unmittelbar vor dem Spiel, steckt die Köpfe zusammen und kungelt eine Strategie für das bevorstehende Match aus.
Gedränge in Zeiten der Pandemie? Die informellen Gespräche unter Kollegen fallen weg. Die Kaffeemaschine steht zuhause in der Küche und ich treffe maximal die Katze dort. Wir alle spüren die Vereinsamung und vermissen Sozialkontakte.
In der Vergangenheit hatte ich gute Erfahrungen mit Scrum im Team und als Scrum Master gesammelt. Das ist ein reichhaltiges Reservoir an agiler Erfahrung. Ich werde die Team-Scrum Methode also nur ein wenig auf meine aktuellen Verhältnisse anpassen. Scrum für mich selbst als Einzelperson zu adaptieren ist mein individueller Versuch, dem Corona-Blues Einhalt zu gewähren.
Ich beginne wie üblich zu recherchieren, ob jemand schon die gleiche Idee hatte. In meinen Notizen findet sich “SoloScrum”, “Scrum of One” und “Scrum4One” als potentielle Suchworte. Ich werde fündig, z.B. bei [1], ein sehr lesenswerter Artikel. Diese Idee ist also definitiv nicht (nur) von mir.
Die Rollen im Scrum bestreite ich alle selbst.
Ich bin also meine eigene Scrum Expertin ebenso wie meine eigene Product Ownerin.
Frei übersetzt aus [2]
Ich liebe Retrospektiven – der berühmte Blick zurück nach vorn. Ziel ist, bisherige Erfahrungen praktisch zu nutzen. Dazu sind in regelmässigen Intervallen folgende Leitfragen zu beantworten.
Eine kurze Bilder-Recherche nach Retrospektive liefert einen ganzen Strauß an Methoden, um die Antworten auf obige Fragen hervorzuholen.
Positiv/Negativ
Der Klassiker
continue, start, stop
Hat mir besonders gut gefallen
Starfish Game
Habe ich erfolgreich probiert. Dabei werden sechs Positionen auf einem Rad platziert.
Starfish Game ist eine gute Abwandlung, damit es nicht so langweilig wird, sich jede Woche exakt die gleichen Fragen zu stellen.
Nimm Zwei
Gefällt mir gut, es ist eine positiv und in die Zukunft formulierte Abwandlung des Klassikers für Einzelpersonen.
Nimm Zwei zielt auf ein positives Ergebnis und sollte schnell gemacht sein. Dabei wird weniger in die Vergangenheit geblickt, als auf die Zukunft fokussiert.
Zwei Veränderungen sollen in die neue Woche mitgenommen werden. Das ist für eine Person realistisch und kann im Alltag dennoch eine Herausforderung darstellen. Immerhin gilt es, Gewohnheiten zu verändern, um bessere Gewohnheiten einzuüben.
Als Scrum Master im Team hatte ich wochenweise Freiwillige gebeten, eine einzelne Maßnahme vorübergehend zu adoptieren und in der kommenden Woche besonderes Augenmerk darauf zu richten. Die Person darf sich die Maßnahme selbstverständlich aussuchen. Die Idee stammte von einem Team-Mitglied. Das funktioniert auch prima mit der Adoption der agilen Prinzipien. [3]
Mich selbst agil planen – dazu gehört erst einmal ganz viel Luft:
Wichtig: Die Planung selbst benötigt zwischen 10 und 30% der Gesamtzeit.
Meine Sprints dauern eine Woche. Ich plane gern in Einheiten von maximal halben Tagen.
Für eine gute Planung muss ich die Aufgaben mindestens auf eine solche Größe herunterbrechen.
Das klassische Projektmanagement kennt dafür den Begriff Work-Breakdown-Structure.
Im Scrum gibt es 3 bzw. 4 Hierarchien:
Je dichter ich fachlich an der Abarbeitung einer konkreten Arbeitseinheit bin, desto präziser kann ich sie formulieren und ihre Dauer schätzen.
Eine Präzise Formulierung hilft mir, die Arbeit konkret abzugrenzen.
Bin ich nicht in der Lage, zu formulieren, wann die Arbeit erledigt ist, bekomme ich ein Problem in der Abarbeitung. Ich werde “nie” fertig. Darum ist es so wichtig, sich darüber klar zu werden, was genau eine Arbeitseinheit umfassen soll. Diese Detail-Planung ist fachlich-inhaltlich. Niemand kann sie mir abnehmen, denn ich bin die Expertin für die zu planende und durchzuführende Tätigkeit. Ich empfinde die Feinplanung nicht als lästig, sondern als geeignet, mir selbst klar zu werden, was genau ich da eigentlich tun möchte.
Die Detailplanung ist einer der Gründe, warum so viel Zeit mit der Planung draufgeht. Sie zahlt sich immer aus, denn sie bewahrt mich auch davor, mich zu verrennen und dadurch u.U. viel mehr Zeit zu verbrennen.
Keine Zeit-Planung ohne Schätzen.
Leichter als absolutes Schätzen ist relatives Schätzen: Aufgabe A benötigt mehr Zeit als Aufgabe B.
Oder Schätzen mit Fehlerbalken: Aufgabe A benötigt mindestens 2h, im Worst Case jedoch 6h.
Hier zahlt sich aus, dass die Arbeiten möglichst konkret definiert sind. Ich kann nur Arbeiten schätzen, deren Umfang einigermaßen klar umrissen ist. Story Points für eine Person benutze ich nicht.
Trotz sorgfältiger Planung gibt es immer mal wieder Tickets, die sich einfach nicht abarbeiten lassen wollen, weil zu viele Unklarheiten bestehen. Wenn ich immer alles schon vorher wüßte …
Dann helfen mir folgende Strategien:
Dies alles wird natürlich (in den Tickets) dokumentiert.
Stories sollten “invest” sein:
Tasks sollten “smart” sein:
Zahlreiche Tipps dazu finden sich in der Grafik in [4], die sich in vielen Varianten im WWW findet. Ich empfehle, unbedingt einen intensiven Blick darauf zu werfen. Definitiv einen eigenen Artikel wert.
Ich mag das haptische Element.
Mein Ticketsystem für die Wochen-Planung ist daher analog:
Die Pinnwand ist in Wochentage eingeteilt. Mein “Burndown Chart” ist ersetzt durch einen Nagel in einem Brett, auf den ich die abgearbeiteten Zettel aufspieße. Das macht Spaß und der Stapel wächst. Meine Pinnwand hängt so, dass ich jederzeit zu ihr rübersehen kann, sie jedoch normalerweise ausblende.
Die eigenen Arbeiten hängen von anderen Arbeiten, Personen, Ressourcen o.ä. ab. Der Management-Klassiker schlechthin. Das ist einer der wesentlichen Gründe, warum Arbeiten auf Vorrat geplant werden müssen und nicht einfach losgelegt wird.
Zum Glück haben wir tägliche Video-Sitzungen. Dort kommen diese Dinge zur Sprache, um:
Im Dezember 2020 habe ich mit Scrum4One begonnen. Ich bin seitdem sehr zufrieden mit meiner Selbst-Führung. Der Corona-Blues zu Beginn des 2. Lockdowns mit Vollzeit-Homeoffice ist in weiten Teilen einer inneren Ausgeglichenheit gewichen. Die Arbeitszufriedenheit ist gewachsen und stabiler. Ich mache dann mal so weiter von Woche zu Woche.
[1] https://www.raywenderlich.com/585-scrum-of-one-how-to-bring-scrum-into-your-one-person-operation
[2] https://www.infoq.com/news/2015/02/personal-scrum/
Beiträge im Magazin “Frauen machen Informatik Heft 44 (Schwerpunkt Medizininformatik)
Hannover goes Online
Berlin goes IT-Frauen
GI Interview
Dank meinem Engagement in der Gesellschaft für Informatik wurde ich (neben vielen anderen Menschen) für einen Video-Beitrag zum 20-jährigen Jubiläum des Wissenschaftsjahres angefragt, dem ich sehr gern nachgekommen bin.
Hier der Link zum Beitrag:
https://www.wissenschaftsjahr.de/2020-21/das-wissenschaftsjahr/20-jahre-wissenschaftsjahre
Paar-Dokumentation bei einem Übergabe-Projekt
Christine Hennig, Wolfram Eifler
Pair documentation sollte doch keine neue Idee gegenüber Pair programming sein – dachten wir.
Die Internet-Recherche zum Thema “pair documentation” lieferte ein mageres Ergebnis.
Hier unsere eigenen Erfahrungen mit dem Thema.
Anlaß war die Arbeits-Übergabe eines Mitarbeiters bei Verlassen des Unternehmens und die Sicherung des erarbeiteten Wissensstandes. Bestandteil der Übergabe war ein Prototyp bzw. Referenz-Implementierung in einem fortgeschrittenen Stadium. Er umfasste mehrere umfangreiche Technologie-Stacks.
Zur Verfügung stand ein Dokumentations-System im Intranet mit einer MediaWiki-Installation. Alle Dokumente sind als einzelne oder Verbund mehrerer Wiki-Seiten im System abgelegt.
Jedes Thema befindet sich in einem definierten Zustand, der von “Inkubator” bis “Freigabe” über mehrere Review-Zyklen läuft. Die Arbeiten fanden während der Corona-Pandemie im Homeoffice statt.
Beschrieben ist zum einen unser initialer Plan und zum anderen unsere Erfahrungen.
Nummer | Stunden | Wer | Zustand | Was |
---|---|---|---|---|
1.0 | 1 | QS | Inkubator | Seite im System anlegen, (ggf. vorläufigen) Titel vergeben |
1.1 | 1 | MA | Sammeln | Material sammeln |
1.2 | 1 | MA | Ordnen | Bezug zu existierender Dokumentation herstellen |
1.3 | 3 | MA | Ordnen | Strukturieren/Gliedern |
2.0 | 1 | QS | Preview | Struktur auf Plausibilität kontrollieren |
3.0 | 10 | MA | Angefangen | schreiben, schreiben schreiben |
4.0 | 5 | QS | Review1 | Inhaltlich, strukturell, Korrektheit, Konsistenz, Aktualität |
5.0 | 3 | QS + MA | – | Hands-On Doku gegen techn. System halten, Lücken aufspüren usw. |
6.0 | 4 | MA | Ergänzen1 | Vervollständigen, ggf. Struktur verbessern |
7.0 | 3 | QS | Review2 | Inhalt, Struktur |
8.0 | 3 | MA | Ergänzen2 | Vervollständigen, ggf. Struktur verbessern |
9.0 | 2 | QS | Review3 | Rechtschreibung, Grammatik, tote Links |
10.0 | 1 | QS | Freigabe | Fertig |
Wie immer kommt es (ein wenig) anders. Zu Beginn implementierten wir einen Backup-Mechanismus zur Sicherung der Doku-Zwischenstände.
Nach unserer Planung erfordert Punkt 3 (Schreiben, schreiben, schreiben) knapp die Hälfte der Zeit. Das entsprach der Realität.
Ab Punkt 5 (Hands-On) arbeiteten wir dann fast nur noch gemeinsam an der Doku. Die geplante Zeit wurde dazu in etwa wie erwartet benötigt, jedoch ergab sich häufig parallele Arbeit im selben Ablaufpunkt an mehreren miteinander verknüpften Themen. Außerdem justierten wir regelmäßig die verbleibenden Arbeiten nach Priorität und Zeitkontingent, teilweise auch in ihrer Struktur.
Die Reviewerin / QS-Verantwortliche hatte natürlich viele Fragen, das ist schließlich ihr Job. Die Fragen führten dazu, dass die Doku viel verständlicher und besser strukturiert wurde. Jede Rückfrage wurde genutzt, um Form und Struktur der Beschreibung zu optimieren. Die Zielvorstellung dabei war, den hinterfragten Sachverhalt noch klarer zu beschreiben.
Wir arbeiteten die Änderungen abwechselnd ein. Die Hands-On Sitzungen wurden mal von der QS, mal vom Mitarbeiter durchgeführt. Die zweite Person passte jeweils auf, dass alles richtig getippt wird und bei jedem Kommandobeispiel klar ist, was damit bezweckt wird und ob dies auch angemessen aus der Doku hervorgeht.
Dabei ging es dann direkt an den Prototyp, ohne ihn kaputtzumachen. Natürlich hatten wir ein Backup für den Notfall.
Aufkommende weitere Themen, Anmerkungen und Wünsche, die den aktuellen Rahmen sprengten, wurden fortlaufend an das Ende einer ToDo Liste angehängt.
Diese Abgrenzung entlastete den Mitarbeiter von Unterbrechungen beim Schreiben, ohne dass Thematiken verlorengingen. Die Liste wurde wöchentlich priorisiert (must, should, could, won’t [3]) sowie mit dem erreichten Fortschritt und Zeitplan abgeglichen.
Gemeinsam kamen wir in gute Energie und der Flow ([4]) ließ nicht lange auf sich warten. Die Zeit verging wie im Flug.
So zogen sich unsere Video-Meetings meist so lange hin, bis eine Person von uns beiden Hunger bekam.
Alles in allem hatten wir viel Spass und ein gutes Gewissen, den Job unter den gegebenen Bedingungen so gut abgeliefert zu haben.
Paar-Dokumentation
Gemeinsame Planung ist hilfreich, um den Fokus zu halten und in jeder Phase Wichtiges von Unwichtigem zu unterscheiden.
Wenn ich ein komplexes Thema inhaltlich beschreibe, stellt es mich vor vielfältige Herausforderungen.
Eine übliche Art der Bearbeitung ist die Aufteilung des Inhalts in sog. Topics, die spezielle Aspekte dieses Inhalts beschreiben.
Diese Topics können mit Assoziationen, also Beziehungen untereinander, versehen werden.
Eine Topic Map dient dazu, den Überblick über alle Topics zu erhalten. Sie ist die “Landkarte”, auf der alle Topics und deren Beziehungen verzeichnet sind.
In ihr kann navigiert werden und auch auf die einzelnen Topics über einen Index zugegriffen.
Hierbei stellt sich die Frage, wie umfangreich die einzelnen Topics erstellt werden und welche Aspekte in welchem Topic dokumentiert werden.
Dabei helfen mir die Regeln der Clean Code Developer [1].
Was für Entwickelnde gut ist, kann für Dokumentierende nicht falsch sein.
Im Orangenen Grad sollen folgende Prinzipien eingehalten werden, die ich gleich auf Topics abbilde:
Die Herausforderungen guter Software-Entwicklung und guter technischer Dokumentation ähneln sich also verblüffend.
[1] https://clean-code-developer.de/die-grade/orangener-grad/
Diesmal als MindMap:
Aus dem Klassiker
“Developing Quality Technical Information”
von Hargis, Carey, Hernandez, Hughes, Longo, Rouiller, Wilder
Download in voller Auflösung:
Dank meinem Engagement in der Gesellschaft für Informatik wurde ich für eine Podiumsdiskussion angefragt. Es ging um die Frage, warum der Frauenanteil in der IT und den technischen Berufen immer noch so gering ist.
Hier der Link zum Beitrag:
Am Wochenende war ich in Prag. Die WriteTheDocs Community hatte ihre EU Konferenz und ich, neu in Tech Docs, war zum ersten Mal dabei:
http://www.writethedocs.org/conf/eu/2017/
Den Eröffungs-Vortrag hielt Daniele Procida mit dem Titel
“The four kinds of documentation, and why you need to understand what they are”
Und das sind sie, die vier Arten der Dokumentation:
TUTORIAL | learning | studying | practice |
HOW-TO | problem-solving | doing | practice |
EXPLANATION | understanding | studying | theory |
REFERENCE | information | doing | theory |
Ich habe nun auch den Unterschied zwischen einem Tutorial und einem How-To verstanden, die ich übrigens beide als “Anleitung” übersetzt bekomme.
Das Tutorial lehrt, wie es prinzipiell geht. Dies gern an einem Beispiel. Es geht aber um das Lernen. “Wir lernen einen Kuchen backen.”
Das How-To erklärt ein konkretes Thema. Das Thema ist eben gerade kein Beispiel, sondern das, worum es geht. Sie setzt ein gewisses Grundverständnis voraus, zum Beispiel wie man einen Kuchen backt und wie man ein Rezept liest. “Wir backen einen Zitronenkuchen.” wird dann das Zitronenkuchenrezept.
In der Referenz kann ich nachschlagen, welche Backeigenschaften das Mehl hat und was eine Kastenform ist.
Eine Erklärung kann die Vor- und Nachteile des Genusses eines Stück Zitronenkuchens für die menschliche Ernährung darstellen.