QUALITÄT


Quali­tät

cards+ ist Quali­täts­poli­tik

Quali­täts­poli­tik kennen wir aus dem Sprach­gebrauch der Quali­täts­manage­ment­norm ISO 9001. Mit dem Begriff «Poli­tik» tun sich viele schwer. Im Englischen spricht man von quality policy, über­setzt also Quali­täts­strate­gie oder -leit­linie. Und so ist der Ansatz mit cards+ auch zu ver­stehen.

Agile Ent­wick­lungs­­pros­zesse haben sich aus der Erkennt­nis ent­wickelt, dass sich Anfor­derungen für ein IT-System nie so exakt spezifi­zieren lassen, dass kein Spiel­raum für Inter­preta­tionen bleibt. Die Welt dreht sich wäh­rend der Reali­sierung wei­ter. Was heute eine gute Idee ist, kann mor­gen schon ein alter Hut sein.

cards+ hilft bei der Umset­zung der Werte und Prin­zipien aus dem Mani­fest für agile Soft­ware-Ent­wick­lung. Beim Thema Doku­menta­tion ist natür­lich der zwei­te Punkt im Mani­fest beson­ders inter­essant.

Wir schätzen funktio­nierende Soft­ware mehr als umfassende Doku­menta­tion.

Mit “wir” ist dabei die ganze Pro­jekt­­­organi­sation gemeint.

Das Ziel beim Ein­satz von cards+ ist keine umfas­sende, sondern eine ange­messene Pro­dukt­doku­men­tation. Autoren im Wiki dürfen bei der Beur­tei­lung der Ange­messen­heit nie ver­gessen, dass Wissen vor allem im Pro­dukt selbst steckt. Wissen wird in Soft­ware trans­formiert. Der größte Teil des Wissens befin­det sich im Code und in den Test­plänen, die den Code prüfen.

Eine Pro­dukt­doku­men­tation muss Quali­täts­merk­male wie Voll­ständig­keit und Richtig­keit auf­weisen. Die ISO 9001 lehrt uns, dass Quali­täts­merk­male mess­bar sein müssen. Voll­ständig­keit wird mess­bar durch die Struk­tur im Wiki, mit Bau­steinen, die einen festen Auf­bau haben. Mode­rierte Kommen­tare geben Autoren ein Maß für die Richtig­keit der Bau­steine.

cards+ ist ein Rahmen, inner­halb dessen Menschen es schaffen, eine kom­plexe Doku­men­tation inkre­mentell zu erstel­len. Sie werden in die Lage ver­setzt, produk­tiv und krea­tiv Fähig­keiten der Soft­ware in mög­lichst ho­her Quali­tät zu beschrei­ben. Bau­steine, Prinzi­pien und Prak­tiken der Methode machen Autoren ihre Arbeit im Wiki so ein­fach wie mög­lich. Trotz­dem kann cards+ keine Feh­ler ver­hin­dern. Sie werden aber sicht­bar.


Quali­tät

cards+ schafft Ord­nung

Das Wiki ist das zen­trale Werk­zeug für den Pro­dukt­verant­wort­lichen. Dort gibt es eine ordent­liche Struk­tur, die er gut kennt, mit Bau­steinen, die er prü­fen kann. Jeder Bau­stein hat seine Ziel­gruppen. Bei jedem Bau­stein ist klar, welche Fähig­keiten ein Autor haben muss.

Das Glossar bringt Ord­nung in Begriffe. Es ist das Wörter­buch des Pro­duktes. Die Begriffe sind das Voka­bular der gemein­samen Sprache. Es ist ein Mini-Lexi­kon, zuge­schnit­ten auf das Pro­dukt. Seine konse­quente Nutzung bedeu­tet, dass Autoren Begriffe in den Tex­ten der Bau­steine mit Ein­trä­gen aus dem Glossar ver­knüpfen. Autoren können ihre Texte dadurch sehr kom­pakt gestal­ten, weil sie Begriffe nicht immer wieder erklä­ren müssen.

Die Medien­­biblio­thek schafft Ord­nung in Bil­der. Sie bil­det einen Kata­log für die Wie­der­­ver­wen­dung von Abbil­dungen und Dia­grammen. Es ent­steht eine gemein­same Bild­sprache. Ver­ände­rungen an einem Bild werden sofort an allen Stellen sicht­bar, es gibt keine zwei Ver­sionen eines Bil­des.

Die zentrale Ver­waltung von exter­nen Links in einer Link­samm­lung folgt der Idee der Medien­biblio­thek. Sie bil­det einen Kata­log für doku­men­tierte Infor­matio­nen außer­halb des Wiki.

Für andere Doku­menten­arten ist das Wiki ein zen­trales Ver­zeich­nis. Spezifi­kationen der Ent­wick­ler werden im Wiki zum Lesen ver­öffentl­icht. Durch das Prin­zip COD gibt es Brücken zu den Arte­fakten der Ent­wick­ler, Tester und Nutzer der Soft­ware. Mit dem Wiki gibt es einen “Ort”, an dem alle doku­men­tier­ten Infor­mationen zen­tral für alle Leser erreich­bar sind.

Die Sprache der Domä­nen­exper­ten und Ent­wick­ler.


Quali­tät

Leit­linien von cards+

Die Leit­linien sind der Ver­such, die Methode cards+ auf vier Begriffe zu redu­zieren. Es sind Quali­täts­ziele, die zum Ent­wurf der Struk­tur und der Bau­steine geführt haben.

Nach­haltig­keit

Nach­haltig­keit steht für das Bestre­ben, Wissen über ein Pro­dukt perma­nent zu sammeln und quali­täts­gesichert für alle Ziel­­gruppen ver­fügbar zu machen. Es geht um das Ver­sprechen des Pro­dukt­verant­owrt­lichen, jede Änderung am Pro­dukt in der Pro­dukt­doku­mentation zu ver­öffent­lichen.

Prüf­bar­keit

Alle inter­essier­ten Par­teien sind moti­viert, jede doku­men­tier­te Infor­mation im Wiki zu prü­fen und konti­nuier­lich zu ver­bessern. Sie orien­tie­ren sich an der fes­ten Struk­tur. Sie prü­fen den Auf­bau und Inhalt der Bau­steine anhand abge­stimm­ter und an alle Leser kom­muni­zierter Regeln.

Voll­ständig­keit

Eine voll­ständige Pro­dukt­doku­menta­tion stellt ein Pro­dukt in allen Facet­ten dar. Sie ent­hält eine fach­liche und tech­nische Sicht auf das IT-System, ohne sie aber strikt zu trennen. Im Gegen­teil. Die Ver­knüp­fung der Bau­steine der System­beschrei­bung und -struk­tur ist eine Stär­ke dieses Ansatzes.

Ganz­heit­lich­keit

Eine ganz­heitliche Pro­dukt­doku­men­tation beschränkt sich nicht auf das Wiki. Nicht nur die Bau­steine für System­beschrei­bung, System­struk­tur und Archi­tektur­ent­wurf im Wiki zäh­len, son­dern auch Spezifi­­kationen oder Konfi­gu­rationen im Code-Reposi­tory oder Test­pläne einer Test­pyra­mide.

Quali­tät braucht Kompe­tenz und Diszi­plin.


Kompe­tenz

Quali­tät ist Kopf­sache

Eine Pro­dukt­doku­menta­tion wird gebraucht, solange das Pro­dukt einge­setzt wird. Ist ein Pro­dukt erfolg­reich, dann sind das mög­licher­weise Jahr­zehnte. In langen Zeit­räumen ändert sich alles. Die Pro­jekt­organi­sation. Die Auf­trag­geber. Die Nutzer. Je reifer ein Pro­dukt ist, desto wich­tiger wird eine ein­fach zu pfle­gende, voll­stän­dige und vor allem rich­tige Pro­dukt­doku­menta­tion.

Pro­dukt­wissen wächst oder ändert sich laufend in einem agilen Umfeld. Es geht um die Frage der Quali­tät von Doku­menten, die schon länger exis­tieren. Sie sind von vielen kleinen Änderungen betrof­fen. Pro­dukt­doku­menta­tion und Pro­dukt dürfen sich aber nicht wider­sprechen. Können Autoren das nicht sicher­stellen, dann ver­dirbt ein Teil der Doku­mente. Das Schlimme an «ver­dor­benen» Doku­menten ist, dass Leser die «faulen Stellen» selten sofort erken­nen. Ver­dor­bene Doku­mente füh­ren ein Team, das an der Ent­wicklung des Pro­duktes arbei­tet, in die Irre. Leider gibt es kein Werk­zeug, mit dem Autoren die Quali­tät von Doku­menten bewer­ten können, so wie Ent­wick­ler bei­spiels­weise mit Sonar­Qube die Quali­tät von Soft­ware in mehreren Dimen­sionen messen können. Moderier­ten Kommen­taren sind eine ein­fache Metrik für eine Seite im Wiki. Die Seiten­vor­lagen als Proto­typ für eine Seite sorgt für einen ein­heit­lichen, formal prüf­baren Inhalt. Jede gemäß Seiten­vor­lage des Bau­steins voll­ständige Seite ohne Kommen­tare ist daher eine «gute» Seite. Und das lässt sich auf eine Blick erken­nen.

Quali­tät ist das Ergeb­nis der gemein­samen Anstren­gun­gen aller Autoren und Leser. Es ist Kopf­sache.


Diszi­plin

Quali­tät durch Beschrän­kung

Jede Per­son in der IT-Branche hat seine eigene Vor­stel­lung von guter Doku­men­tation. Diese Vor­stellung ist ganz maß­geblich von persön­lichen Schwer­punkten oder seiner Rolle bestimmt. Auch bei der Wahl des »richtigen« Werk­zeugs zum Schrei­ben der Doku­mentation gibt es unter­schied­liche Vor­lieben.

  • Ein Pro­dukt­verant­wort­licher nutzt Office-Pro­dukte oder ein Wiki (z.B. Confluence).
  • Ent­wick­ler nutze gerne Markup-Dateien, weil die sich wie Code ver­halten.
  • Tester denken in Tabellen oder Listen und nutzen Office-Pro­dukte (z.B. Excel) oder spezielle Werk­zeuge (z.B. Fitnesse).
  • Opera­toren schätzen Betriebs­anwei­sungen und Hand­bücher online in einer Wissens­daten­bank.

»Viele Köche verderben den Brei« ist ein Sprich­wort, das wahr wird, wenn jede an der Pro­dukt­ent­wick­lung beteiligte Per­son »seinen« Teil der Pro­dukt­doku­mentation so schreibt, wie sie nach persön­lichen Gesichts­punk­ten für rich­tig hält. Der Eins­atz von cards+ und die Ein­führung eines Wiki als zen­tralen Ort für die Pro­dukt­doku­mentation ändert die Situa­tion. Der Pro­dukt­verant­wort­liche und das Team arbei­ten mit Werk­zeugen, die opti­mal auf­einander abge­stimmt sind.

Eine Grund­regel bei cards+ lautet: Ein Autor erfasst nur In­halte im Wiki, für die er einen passen­den Bau­stein findet.

Ent­wick­ler schrei­ben zusätzlich Spezifi­kationen für Dienste und Objekte mit den gleichen Werk­zeugen, mit den sie auch pro­gram­mie­ren. Tester arbei­ten mit ihren Test­plänen in ihrem gewohn­ten Werk­zeug. Die Spezifi­kationen und Test­pläne werden nach ihrer Frei­gabe für das Pro­dukt­inkre­ment vom Team zum Lesen im Wiki ver­öffent­licht. Es liegt in der Verant­wortung des Teams, ein geeig­netes Format zu wählen, das im Wiki direkt nutz­bar ist oder leicht für die Ver­wendung im Wiki konver­tiert werden kann.

Quali­tät ent­steht durch Beschrän­kung der Viel­falt durch klare Regeln. Regeln, auf deren Ein­hal­tung der Gärtner ach­tet.


Diszi­plin

Quali­tät durch Simpli­zität

Das Prin­zip PLA ist eine gol­dene Regel in der Soft­ware-Ergo­nomie, Mensch-Com­puter-Inter­aktion und dem UX-Design. Das Prin­zip lässt sich gut auf Doku­men­tation über­tragen. Jeder Leser wünscht sich Infor­mationen so aufbe­reitet, dass er sie gut auf­nehmen kann. Im Wiki findet er eine Doku­menta­tion mit einer nach­voll­zieh­baren Struk­tur. In den Bau­stei­nen findet er genau die doku­mentier­ten Infor­matio­nen, die er dort erwar­tet. Er kann gezielt den Ver­knüpfun­gen zwischen den Bau­steinen fol­gen oder ein­fach suchen. Er kann jeder­zeit Feed­back als Kommen­tar abge­ben.

Ein ein­fach zu bedienen­des Wiki bringt mehr Quali­tät durch Zusam­men­arbeit. Nur ein Wiki mit ein­facher Struk­tur und ver­ständ­lichen Inhal­ten erreicht auf Dauer alle Leser.

360-Grad-Feedback für die Doku­mentation.


Kompe­tenz

Feed­back durch Provo­kation

In der Soft­ware-Ent­wicklung arbei­ten Menschen sehr inten­siv zusam­men. Über kurz oder lang ent­stehen in jedem Team Kon­flikte. Provo­zierte Kon­flikte soll­ten aller­dings die Aus­nahme sein. Provo­kation ist sehr häufig nega­tiv belegt. Eine Provo­kation ist dann erfolg­reich, wenn der Provo­zierte zu einer Reak­tion genö­tigt wurde.

Wird ein Leser im Wiki durch den Autor mit dem Wissen anderer kon­fron­tiert, dann kann der Leser auf­grund seines eigenen Wissens Fehler oder Lücken identi­fizieren. Im Wiki gibt er Feed­back dazu. Ganz ent­spannt als Kommen­tar, aber trotz­dem für alle anderen sicht­bar. Die not­wen­digen Voraus­setzun­gen für so eine posi­tiv wir­kende Provo­kation sind schnell aufge­zählt:

  1. Jeder kennt die Doku­mentation und ihre Stru­ktur.
  2. Die Doku­mentation wird von allen ver­wendet.
  3. Die Doku­mentation wird von allen ver­bessert.

Mit dem Ein­satz von cards+ erfül­len Autoren die Voraus­setzung für Punkt 1 der Liste. Die Bau­steine und die fixe Seiten­struk­tur stellen sicher, dass jeder weiß, wo wich­tige Infor­mationen zu fin­den sind. Mit Ver­knüpfungen in den Seiten führt der Autor seine Leser durch die Doku­mentation. Die Such­funk­tion erlaubt flexi­ble Recher­chen. Die konse­quente Nutzung von Schlagw­orten in den Seiten macht Zusammen­hänge mit einem Klick sicht­bar. Punkt 2 der Liste ist Teil der Kul­tur der Pro­jekt­organi­sation. Das Wiki ist ein akzep­tiertes Werk­zeug für Kommuni­kation im Team. Ganz wichtig ist, dass die Pro­dukt­doku­menta­tion als Wahr­heit gilt. Eine klare Abgren­zung zur Pro­jekt­doku­mentation ist wichtig. Mit Punkt 3 der Liste ist der Pro­zess für konti­nuier­liche Ver­besserung gemeint.

Voll­ständig­keit ist keine Voraus­setzung, die wollen Autoren neben Korrekt­heit durch das provo­zierte Feed­back bei den Lesern erreichen. Die Idee von “collective code ownership”, wie sie bei­spiels­weise Martin Fowler in seinem Bliki beschreibt, lässt sich leicht auf eine Pro­dukt­doku­mentation erwei­tern. Jeder ist Autor und ver­öffent­licht sein Wissen im Wiki. Jeder ist Leser und profi­tiert vom Wissen Anderer.

Die Quali­tät der Inhalte ist das Ergeb­nis der Gemein­schaft, getrie­ben durch Feed­back. Keinen Leser lässt es kalt, wenn in »seiner« Produkt­doku­menta­tion ein offen­sicht­licher Fehler steckt.


Diszi­plin

Feed­back ein­fach so

Eine rich­tige Doku­mentation ist immer eine große Heraus­forderung. Autoren im Wiki stellen sich dieser Heraus­forderung als Gemein­schaft und nutzen das Feed­back aller Leser. Feed­back einfach so zu geben, ohne extra aufge­for­dert zu werden, muss darum Teil der Kul­tur in einer Projekt­organi­sation sein.

Richtig­keit ist ein Ergeb­nis konti­nuier­licher Verbes­serung, getrie­ben vom Feed­back aller Beteilig­ten, moti­viert durch den von Norman L. Kerth formu­lierten Grund­satz für Retro­spek­tiven, der gerne zitier­ten prime directive.

Unab­hängig davon was wir ent­decken werden, ver­stehen und glau­ben wir auf­richtig, dass in der gege­benen Situation, mit dem verfüg­baren Wissen und Ressourcen und unseren indivi­duellen Fähig­keiten, jeder sein bestes getan hat.

Mit ande­ren Wor­ten: Auch Autoren machen Fehler. Und das dürfen sie auch. Es muss aber ein natür­licher Reflex jedes Lesers sein, einen Kommen­tar im Wiki zu hinter­lassen, wenn er einen Fehler ent­deckt. Jeder Ent­wick­ler kennt einen Teil des IT-Systems sehr gut. Hat er Kennt­nis von einer Fähig­keit in der Soft­ware, die im Wiki nicht zu finden ist, dann gibt er den Autoren mit seinem Kommen­tar einen wich­tigen Hin­weis. Ent­wick­ler ver­setzen mit ihrem Feed­back Autoren in die Lage, Lücken schnell schlie­ßen.

Konti­nuier­licher Verbes­serung ist Verbes­serung in kleinen Schrit­ten. Die Initia­tive der «clean code developer» formu­liert dieses stete Bemühen als Pfad­finder­regel.

Jede Beschäf­tigung mit einem Gegen­stand macht ihn zumin­dest ein klein wenig besser. Ganz ohne büro­kra­tische Pla­nung.

Diese im Grunde genom­men sehr ein­fache Regel ver­hindert, dass das Wiki an Akzep­tanz ver­liert, weil in den Seiten Lücken und kleine Fehler ent­halten sind. Wir kennen das Phäno­men auch als Theorie der zer­brochenen Fenster.

Wird eine zer­brochene Fenster­scheibe nicht schnell repa­riert, sind im Haus bald alle Scheiben zer­brochen.

Nach ihr beginnt der Verfall von Quali­tät im allge­meinen Sinn mit Kleinig­keiten, die nur lange genug unbe­achtet blei­ben. Darum ist es essen­tiell, dass jeder Leser weiß, dass seine Mit­arbeit wich­tig ist. Autoren sind aufge­fordert, wert­schätzend mit diesem so wert­vollen Feed­back umzu­gehen.