Methode

Der Gärtner trägt Verant­wortung

Es gibt das Phäno­men, dass intelli­gente Menschen gegen Regeln ver­stoßen, obwohl sie von ihrer Wirk­sam­keit im Allge­meinen über­zeugt sind. Trotz­dem vertei­digen sie die Abweichung von der Regel mit dem Argu­ment, dass es eine not­wendige Ver­besserung oder gar Inno­vation ist. Manche tun es sogar im guten Glau­ben, dass ihr Weg besser ist, diese Änderung schon lange not­wen­dig war. Das ist eine Gefahr für die Quali­tät einer Pro­dukt­doku­men­tation. Indivi­duell gestal­tete Seiten sind prak­tisch nicht prüf­bar. Es ist schwerer, die Bearbei­tung einer Seite an einen anderen Autor zu über­geben. Die Bau­steine bilden ein abge­stimmtes Kon­zept. Abweichungen gefähr­den die Konsis­tenz. Abgren­zung ist eine hilf­reiche Methode, um diesem Prob­lem zu begeg­nen. Die gol­dene Regel der Gärtner besagt, dass eine Infor­mation, für die es keinen Bau­stein in der Pro­dukt­doku­men­tation gibt, ganz auto­matisch zur Pro­jekt­doku­men­tation gehört — und damit anderen Regeln unter­liegt. Natür­lich mit allen Konse­quenzen bezüg­lich Nach­haltig­keit und Quali­tät. Eine Heraus­forderung für einen Gärtner ist, Stärke zu zeigen. Stärke, Autoren auf die Ein­haltung der Regeln der Produkt­doku­mentation einzu­schwö­ren.

Der Gärtner ist ver­ant­wortlich für die Aus­wahl der Werk­zeuge und der tech­nischen Infra­struk­tur für das Wiki. Das ist sozu­sagen die Ent­wick­lungs­umge­bung für die die Autoren. Er ist Experte im Zusam­men­hang mit Doku­mentation. Seine Auf­gaben sind die Formu­lierung und Durch­setzung von Doku­men­tations­richt­linien, ähnlich den Pro­gram­mier­richt­linien der Ent­wick­ler. Er sorgt für die Ein­hal­tung der Regeln der Methode cards+, ver­gleich­bar dem Scrum-Master als Hüter des Scrum-Pro­zesses oder einem IT-Experten für den Archi­tektur­stil. Aus dieser Argu­men­tation heraus ergibt sich zwangs­läufig, dass für die Pflege einer Pro­dukt­doku­men­tation ein Gärtner in der Art eines IT-Experten für Doku­men­tation gebraucht wird.

Der Gärtner ist Trai­ner für die Methode cards+. Er ist greif­bar für Autoren und Leser und hilft bei der Bewälti­gung von all­täg­lichen wie auch spezi­ellen Prob­lemen im Zusam­men­hang mit der Doku­men­tation. Ähn­lich wie beim Ver­hältnis von IT-Experte und Ent­wick­ler (Stich­wort Elfen­bein­turm­archi­tekt) ist es für einen Gärtner sehr hilf­reich, selbst auch Autor zu sein. Zumin­dest muss er aktiver Leser sein.

Robert Bruckbauer beant­wor­tet Fra­gen und unter­stützt als Gärt­ner.


Methode

Schutz vor Wissens­verfall

Eine große Gefahr für die Leis­tungs­fähig­keit eines Teams sind Kopf­mono­pole und Wissens­inseln. Eine Per­son sammelt über lange Zeit wert­volles Wissen über das Pro­dukt. Er nutzt dieses Wissen, um erfolg­reich seine Auf­gaben im Team zu erfül­len. Dann ver­lässt er das Team. Wich­tiges, nicht schrift­lich erfass­tes Wissen geht unwider­bring­lich ver­loren. Selbst bei einem gut vor­berei­teten Aus­stieg mit Über­gabe oder einer schrift­lichen Nach­doku­men­tation gehen Infor­mationen ver­loren.

Ein Grund für Wissens­verfall ist die Träg­heit des mensch­lichen Gehirns und das damit ver­bun­dene Ver­gessen von Infor­mationen.

Ein Mensch erinnert sich gut an die aktu­ellen Auf­gaben. Aber an alle länger zurück­liegen­den, in der Regel abge­schlos­sene Auf­gaben kann er sich weni­ger gut erinnern. Wich­tige Details blei­ben uner­wähnt.

Die Ver­gemein­schaf­tung von Wissen (engl. shared knowledge) ist eine Maß­nahme, die diesem Ver­fall ent­gegen­wirkt. Jeder im Team teilt sofort sein Wissen. Er tut dies nach­haltig, also schrift­lich. Mit cards+ ist das Erfas­sen sehr ein­fach. Durch das Wiki gibt es keine Hür­den. Inter­net und ein Brow­ser reicht.


Methode

Fach­liche Schul­den

Das Mani­fest für agile Soft­ware-Ent­wick­lung ver­langt nicht den Ver­zicht auf Doku­mentation, sondern will, dass das eigent­liche Ziel, ein funktio­nieren­des Pro­dukt, nicht darun­ter lei­det. Doku­mentieren im All­gemei­nen wird trot­zdem von so man­chem Ent­wick­ler als Auf­gabe abge­lehnt. Sie wollen nur das doku­men­tieren, was für ihre Arbeit als Ent­wickler oder Tester einen Wert dar­stellt. Doku­men­tieren wird in beson­deren Situa­tionen gerne auch auf später ver­scho­ben. Andere Ent­wick­ler doku­men­tieren in der “heißen” Phase der Reali­sierung sehr gerne und aus­gie­big ihre aktu­elle Lösung. Es ent­stehen sehr genaue Beschrei­bungen und detail­getreue Bil­der. Sobald aber die Soft­ware eine gewisse Reife erreicht, sinkt die Moti­vation, diese Doku­mente zu aktuali­seren.

Beide Vor­gehens­weisen füh­ren zu fach­lichen Schul­den. Das Pro­dukt ist unvoll­stän­dig. Die Pro­dukt­doku­men­tation ent­hält sprich­wört­lich “ver­dor­bene” Doku­mente. Leider können Leser die “faulen” Stellen in der Doku­men­tation nicht immer erken­nen. Sie werden in die Irre geführt und ver­lieren das Ver­trauen in die Doku­men­tation. Damit beginnt ein Teu­fels­kreis. Weni­ger Leser bedeu­tet weni­ger Feed­back für die Autoren. Fehlen­des Feed­back führt zu sinkender Quali­tät. Sinkende Quali­tät ver­treibt weitere Leser.


Methode

Spezifi­kation ist Team­auf­gabe

Mit cards+ wird mit den Begriffen System­beschrei­bung, System­struktur, Spezifi­kation und Test­plan eine klare Auf­gaben­teilung zwischen Pro­dukt­verant­wort­lichen und seinem Team ange­strebt.

Der Produkt­verant­wort­liche bewegt sich im Wiki. Er nutzt die Bau­steine der System­beschrei­bung, um seine Vision bis hinunter zu einer kon­kreten Fähig­keit der Soft­ware zu doku­men­tieren. Er nutzt die Bau­steine der System­struk­tur, um Diensten und Objekten in Abstimmung mit dem Team ein­deutige Namen und einen fach­lichen Zweck zu geben. Für jede gefor­derte Fähig­keit schreibt er einen Arbeits­auf­trag (engl. story) für die Ent­wickler. Dort konkre­tisiert er einen unvoll­ständigen Bau­stein Case durch Akzep­tanz­kri­terien. Unvoll­ständig heißt in diesem Fall ohne Lösung.

Das Team nimmt ent­sprechend der Priori­sierung des Pro­dukt­verant­wort­lichen einen Arbeits­auf­trag an. Es ist voll­kommen unstrit­tig, dass Pro­gram­mieren und Testen beides Auf­gaben des Teams sind. Sie suchen eine Lösung für die gefor­derte Fähig­keit der Soft­ware im Rahmen des gewähl­ten Archi­tektur­stils. Die Akzep­tanz­kri­terien im Arbeits­auf­trag sind Grund­lage für die Test­pläne. Die Ergeb­nisse des agilen Ent­wick­lungs­pro­zesses, also Code, code-nahe Arte­fakte, Test­pläne und Spezifi­kationen, werden in einer quell­text-basier­ten Ver­sions­ver­wal­tung nach­voll­zieh­bar gespei­chert.

In der Methodik von cards+ erge­ben die Bau­steine im Wiki als auch die Ergeb­nis­doku­mente der Ent­wickler und Tester zusam­men eine voll­stän­dige Pro­dukt­doku­men­tation. Eine Doku­men­tation wirkt aber nur dann voll­stän­dig, wenn alle doku­men­tier­ten Infor­mationen in einem Medium präsen­tiert wird. Das ist im Fall von cards+ das Wiki. Dort befin­den sich bereits die Bau­steine. Durch geeig­nete Konver­tierung werden Spezifi­kationen der Ent­wickler und Test­pläne der Tester im Wiki ver­öffent­licht.