Blog

Check if oder check that? Oder: Have you tried turning it off and on again?

Wie oft schreiben oder lesen wir in Anleitungen, dass wir etwas prüfen sollen. Beispiel: "Check if the computer is connected to power." Klare Ansage, alles schön. Was aber, wenn dort steht: "Check that the computer is connected to power"? mehr ...

Hoher Qualitätsanspruch ohne mentale Sandburgen und Dünkel - 10 Fragen an Ines Lasch

Ines Lasch macht eine Weiterbildung zur Technischen Redakteurin und absolviert ein achtwöchiges Praktikum bei parson. Wir haben ihr zehn Fragen gestellt. mehr ...

Volontariat für Technische Redakteure. Zwei Sichten auf die berufsbegleitende Ausbildung

Anja Schiel, Volontärin, und Ulrike Parson, Vorstand der parson AG, berichten über ihre Sicht des Volontariats für die Technische Redaktion.* mehr ...

Machen Sie Ihre technische Dokumentation intelligent – der Weg vom Content Management zu Content Delivery

In diesem Beitrag möchten wir Ihnen aufzeigen, wie man CDPs mit technischer Dokumentation so intelligent befüllt, dass die Nutzer schnell und gezielt Antworten auf ihre Fragestellungen bekommen. mehr ...

So funktioniert Mentoring bei parson

Die Bewerbung ist verschickt, das Vorstellungsgespräch war erfolgreich, jetzt kommt die Zusage. Und da ist er schon, der erste Arbeitstag, an dem alles so fremd ist: Kollegen, deren Namen man sofort wieder vergisst, Ablagestrukturen, Prozesse, ERP-System. Nicht mal die Kaffeemaschine funktioniert auf Anhieb. Und wo war noch mal der Besprechungsraum? mehr ...

Spartakiade in Berlin: Jägerschnitzel, Scrum und Funktionsdesign

Vom 19.-20. März 2016 nahm ich an der Spartakiade in Berlin teil. Müde, geschafft, glücklich und mit vielen Gedanken im Kopf kehrte ich zurück. Das habe ich erlebt:

Freitagabend: Das geht gut los. Abendessen im Restaurant Volkskammer mit Jägerschnitzel, Soljanka und roter Grütze.

Spartakiade in BerlinEröffnung der Spartakiade in Berlin. Foto: Anne HoffmannAm Samstag dann: Sport frei! Im Workshop „Ab morgen bitte Scrum“ von Thomas Schissler lerne ich viel über den Klebstoff zwischen Scrum-Guidelines und Scrum-Meetings. Dabei nehme ich Anregungen für kommende Retrospektiven, für die Planung und Priorisierung von Aufgaben sowie für das Teambuilding mit. Der Workshop wird agil gehalten: Wir Teilnehmer stimmen jeweils iterativ ab, was wir als nächstes hören oder machen möchten. Dafür hat der Trainer ein Backlog aus Vorträgen, Spielen und Diskussionsrunden vorbereitet. Es bleibt viel Zeit zum Erfahrungsaustausch über Scrum. Abgeschlossen wird der Workshop mit der Prüfung der am Anfang festgelegten Erfolgskriterien. Das Ergebnis: abgenommen. Das war ein klasse Workshop!

Samstagabend: Party! Freibier, Spaß und Networking. Viele wollen wissen, was in meinem Workshop am Sonntag dran kommt. Ich bleibe eisern und verrate nichts.

Sonntag: Sport frei für die zweite Runde. Heute bin ich die Trainerin. Das Thema meines Workshops ist Funktionsdesign® für Entwicklerdokumentation.

Mit acht Entwicklern übe ich das Funktionsdesign®. Die Idee: Informationsprodukte lassen sich Schicht für Schicht strukturieren - genauso, wie man Matroschkas auseinander nimmt und wieder verschachtelt. Die äußeren Schichten bestehen aus den sichtbaren Blöcken wie Listen, Tabellen, Bilder und Schritt-für-Schritt-Anweisungen. Die inneren Schichten erkennt man meist durch Formatierungen, Farben und semantische Auszeichnungen.

Spartakiade3Bob, Dörte und Petra. Die drei Matroschkas dienen zur Verdeutlichung der Strukturebenen und als Personas. Foto: Anne Hoffmann

Zu Beginn erstellen wir drei Personas und überlegen, wann sie eine API-Dokumentation lesen würden:

  • Bob: Nerd, 25, will zu Hause mit der API per „Trial and Error“ herumspielen.Bob braucht einen Startpunkt, der ihm Informationen zum Ausprobieren und Unterstützung bei der Fehlersuche bietet.
  • Dörte: Product Owner, ehemals Entwicklerin, will eine API einsetzen und weiß nicht, ob sie passt. Dörte möchte sich eine Übersicht über die Features verschaffen und ein Gefühl dafür bekommen, wie der Code funktioniert.
  • Petra: Entwicklerin, soll nach Dörtes „Go“ loslegen und mit der API einen konkreten Use Case umsetzen. Petra sucht sich aus der Referenz die passenden Objekte und Methoden heraus. Zusätzlich möchte sie grundsätzliche Konzepte der API verstehen, um sie richtig einsetzen zu können.

Spartakiade in Berlin. Anne Hoffmann, parson AGMit Teilnehmern meines Workshops Funktionsdesign® für EntwicklerdokumentationMit den Personas und Use Cases im Hinterkopf prüfen wir eine bestehende API-Dokumentation und optimieren sie nach Funktionsdesign®. Alle Teams finden schnell die typischen strukturellen Fehler im Dokument, z.B. fehlende Informationen und Auszeichnungen, verwirrende Formatierungen, falsch eingesetzte Listenformate sowie terminologische Inkonsistenzen. Jeder wird fündig und bringt Ideen für die Verbesserung ein.

Spartakiade 2016 in Berlin Bob, Dörte und Petra wurden am Ende unter den Teilnehmern verlost. Richtig glücklich ist Bob darüber nicht. Foto: Anne HoffmannZum Schluss wird die Zeit leider zu knapp, um noch einmal bei null anzufangen und nach Funktionsdesign® zu schreiben. Auch der Erfahrungsaustausch kommt etwas kurz. Ich hätte mit den Teilnehmern gern auch allgemeine Fragen besprochen, zum Beispiel: „Ist Entwicklerdokumentation deshalb so schlecht, weil sie so einen geringen Stellenwert in den Unternehmen hat?“ Und: „Wie kann man die Asynchronität zwischen Code und Dokumentation verringern?“ Den Erfahrungsaustausch kann man sicher noch nachholen, z.B. auf der nächsten Spartakiade.

Die Spartakiade auf Twitter: https://twitter.com/spartakiade_org

Kommentar schreiben


  • facebook
  • linkedin
  • xing