METHODE


Methode

cards+ ist eine agile Methode

cards+ unter­­stützt eine Pro­jekt­­­organi­­sation, Wissens­­manage­ment in einem agilen Ent­wick­­lungs­­­pro­jekt rich­­tig zu organi­­sieren. Der Pro­dukt­verant­­wort­liche setzt cards+ ein, um ziel­­­gerich­­tet und inkre­men­tell sein Pro­dukt ange­messen zu doku­men­tieren, unter­stützt durch ein selbst­organi­sier­tes Team.

Es gilt die Prä­­misse, dass eine ange­messene Pro­dukt­doku­men­tation not­­wendig ist. Eine sol­che Pro­dukt­doku­men­tation wächst mit dem Pro­dukt. Sie ist ein Ergeb­nis des agi­len Ent­wick­lungs­­pro­zesses. Sie muss daher mit dem glei­chen Maß­stab für die Quali­tät, mit dem glei­chen Ansatz für empi­­rische, inkre­men­­telle und itera­tive Arbeits­weise und mit den glei­chen Wer­ten herge­stellt wird, wie auch das Pro­dukt ent­­wickelt wird. An die­sem Punkt kommt die Methode cards+ ins Spiel.

Doku­mente wer­den agil ent­wickelt.

cards+ tritt mit dem Ver­­spre­chen an, die Erstel­lung und Pflege einer quali­tativ hoch­wer­tigen Pro­dukt­­doku­men­tation in einem Wiki zu ermög­­lichen. Viele Prinzi­­pien und Prak­­tiken der Ent­wick­ler gel­ten auch für Autoren in einem Wiki, in den meis­ten Fäl­len in nur leicht abge­wandel­ter Form.

cards+ ist kein geschlos­senes Vor­­gehens­­modell, kein iso­lier­ter Pro­zess. Aus diesem Grund kann cards+ sehr gut in beste­hende Pro­zesse inte­griert wer­den. Autoren im Wiki planen und steuern ihre Tätig­kei­ten weiter­hin mit Tech­niken aus dem Pro­jekt­­manage­ment. Sie ver­wenden die Methode ihrer Wahl für die Anfor­derungs­­ana­lyse. cards+ ist als zusätz­liches Werk­zeug für Autoren zu ver­­ste­hen, mit dem sie ihre Ergeb­nisse im Wiki organi­sieren.

Für Leser ist cards+ die Chance, im Wiki jede rele­vante doku­men­tierte Infor­mation zum Pro­dukt zu fin­den. Das Wiki unter­stützt sie durch die Ver­knüpfung von Seiten, die Kate­gori­sierung der Seiten mit Stich­wor­ten und umfang­reiche Such­funktio­nen.

Doku­­men­tation agil ent­­wickeln.


Prinzi­­pien

Pro­­fessio­nell doku­mentieren

Doku­mentieren ist ein erlern­bares Hand­werk. Prinzi­pien der Methode cards+ unter­stützen die Autoren dabei. Ihre prak­tische Umsetzung ist ein wich­tiger Teil der Methode.

Scrum oder XP haben die Arbeits­weise der Ent­wick­ler nach­hal­tig ver­ändert. Die Initia­tive der »clean code developer« bein­hal­tet einen Kata­log von Prinzi­pien und Prak­tiken für mehr Pro­fessio­nali­tät in der Soft­ware-Ent­wick­lung. Als Hilfe­stel­lung bekom­men Ent­wick­ler ein Werte­sys­tem, an dem sie sich orien­­tie­ren können. Das gilt auch für das Doku­men­tie­ren im Wiki. Die glei­chen Prinzi­pien machen auch die Arbeit von Autoren besser.

COD

»Con­vention over docu­mentation« hat das Ziel, Doku­­men­tation durch Kon­ven­­tionen zu ver­­mei­den oder zu redu­­zie­ren.

DOD

Eine »Defi­nition of done« ver­kör­pert ein expli­zites und geteil­tes Ver­­ständ­nis davon, unter wel­chen Bedin­gun­gen ein Pro­dukt fer­tig ist.

DRY

»Don´t repeat your­self« hat zum Ziel, jede unnö­tige Wieder­­holun­gen von Inhal­ten im Wiki zu ver­­mei­den.

INVEST

»Invest in good stories« defi­­niert sechs Kri­­terien, die uns hel­fen, fach­­liches Wissen so kom­pakt und voll­­stän­dig wie mög­­lich zu ver­­mitteln.

KISS

»Keep it simple, stupid« besagt, dass wir eine mög­­lichst ein­­fache Beschrei­­bung für Inhalte wäh­len sollen. »Weniger ist mehr« sagt schon ein Sprich­­wort. Ein­fach­heit ist die Kunst, die Menge nicht geta­ner Arbeit zu maxi­mieren.

PLA

»Prin­ciple of least astonish­ment« spie­gelt sich im Auf­bau der Seiten im Wiki wider. Jeder Bau­stein hat genau einen Zweck, fest­gelegte Abschnitte und ist das Ergeb­nis eines bestimm­ten Pro­zesses.

SLA

»Single level of abstraction« spie­gelt sich in der Struk­­tur des Wiki wider. Für jede Seite ist klar defi­­niert, was in einer Seite beschrie­ben wird und was nicht in diese Seite gehört.

SOC

»Sepa­ration of con­cerns« führt dort zu einer Tren­nung fach­­licher und tech­­nischer Doku­­men­tation, wo es Sinn macht.

SRP

»Single responsi­bility prin­ciple« regelt die Ver­antwor­tung für den Inhalt im Wiki. Eine Seite hat immer genau einen Autor. Er ist für den Inhalt der Seite ver­ant­wort­lich, bis sie “fertig” ist.

Kommen­tare erfol­greich moderie­ren.


Prak­­tiken

Konti­nuier­lich ver­bessern

Wie beim Pro­gram­­mieren gehört die Anwen­­dung der Pfad­finder­regel auch beim Doku­men­tieren zum Funda­ment pro­­fessio­neller Arbeit. Leser können jeder­­zeit einen ent­spre­chen­­den Hin­­weis als Kommen­­tar in der Seite hin­ter­lassen. Autoren grei­­fen diese Hin­weise wert­schätzend auf. Nach dem Abschluss der Ver­­besse­­rung wird der Kommen­­tar gelöscht.

Jeder Autor im Wiki kann bereits beim aktiven lesen einer beliebigen Seite kleine, aber wich­­tige Korrek­turen durch­füh­ren. Kleine Korrek­turen sind bei­spiels­weise die Ver­besse­rung von Recht­schreib­­feh­lern oder die Ver­knüpfung von Begriffen im Text mit Ein­trägen im Glossar. Durch diese eben­falls recht ein­fache Maß­nahme erkennt der Autor auto­matisch wieder­holt auf­tre­tende Erklärun­gen im Text, die er ohne Ver­lust von Wissen­ aus der Seite ent­fernen kann. Gege­­benen­falls ergänzt er Schlag­worte in der Seite. Schlag­worte sind Begriffe aus einem kontrol­lier­ten Voka­bular. Bei cards+ wird dieses Voka­bular durch das Glossar defi­niert. Mit dieser Maß­nahme wird die Suche im Wiki für Leser deut­lich ver­bessert.


Prak­­tiken

Ziel­gerich­tet ver­bessern

Code-Reviews sind beim Pro­gram­­mieren nicht mehr weg­zuden­ken. Das Vor­gehen eig­net sich nicht nur dazu, die Quali­tät der Soft­ware zu ver­bessern. Es unter­stützt auch den Wissens­trans­fer inner­halb des Teams. Das Gesagte gilt auch für das Doku­men­tieren mit cards+. Bei der Durch­führung eines Reviews einer Seite im Wiki prüft der Reviewer sowohl die Richtig­keit als auch die Voll­ständig­keit der Inhalte.

Die Rich­tig­keit der Seite schätzt der Reviewer anhand seines eigenen Wissens ein. Die Ver­knüpfung von Begrif­fen im Text mit Ein­trä­gen im Glossar unter­stützt ihn dabei. Beim Lesen korri­giert er offen­sicht­liche Feh­ler in der Recht­schrei­bung. Der Editor des Wiki hilft dabei. Bei allen anderen Feh­lern oder Lücken nutzt er die Kommen­tar­funk­tion, um Hin­weise für den Autor in der Seite zu hinter­lassen.

Eine Seite ist voll­stän­dig, wenn

  • die vor­bereitete Seiten­vor­lage des Bau­­steins ver­wen­det wurde.
  • alle Abschnitte aus der Seiten­vor­lage des Bau­­steins ausge­füllt sind.
  • passende Schlag­worte in der Seite gesetzt sind.

Diese rein for­malen Prüfun­gen sind mög­lich, weil die Seiten­vor­lagen einen festen Rah­men für jeden Bau­stein vor­geben.


Prak­­tiken

Konti­nuier­lich ver­öffent­lichen

Ein Wiki ist opti­mal geeig­net für die Erfas­sung, Pflege und vor allem Präsen­tation von Pro­dukt­wissen. Die Pflege von Seiten direkt im Wiki kommt dort an seine Gren­zen, wo regel­mäßig und in kurzen Abstän­den Ver­ände­rungen gemacht werden. Das ist vor allem dort der Fall, wo eine Lösung für eine Fähig­keit der Soft­ware von den Ent­wick­lern sehr genau beschrie­ben wird. Diese Art doku­men­tier­ter Infor­mationen sind ganz eng an die Imple­men­tierung gekop­pelt und werden in der Konse­quenz zusam­men mit dem Code ver­sio­niert.

In einer Spezifi­kation halten Ent­wick­ler die Struk­tur eines Objek­tes, Geschäfts­regeln und Algo­rith­men eines Dienstes oder den Auf­bau und das Ver­hal­ten einer Bedien­ober­fläche fest. cards+ macht keine Vor­gaben für eine Spezifi­kation. Mit der Frei­gabe der Soft­ware für das Pro­dukt­inkre­ment wird jede damit ver­bun­dene Spezifi­kation im Wiki in den Bau­steinen Service, Entity, Event oder Layout ver­öffent­licht.

Eine ähn­liche Situa­tion gibt es bei den Test­plänen in einer Test­pyra­mide. Die Test­fälle eines System­tests sind sehr gut als zusätz­liche Doku­men­tation geeig­net, wenn sie sich an den Fähig­keiten der Soft­ware orien­tie­ren. cards+ macht keine Vor­gaben für einen Test­plan. Mit der Frei­gabe der Soft­ware für das Pro­dukt­inkre­ment werden die durch­geführ­ten Test­fälle im Wiki ver­öffent­licht. Abhän­gig vom Auf­bau der Test­pläne bieten sich die Bau­steine Epic oder Case an.

Sowohl Spezifi­katio­nen als auch Test­pläne sind wie Code Teil des Pro­dukt­inkre­men­tes und damit ein Ergeb­nis des Teams. Es ist Auf­gabe des Teams, für die doku­men­tier­ten Infor­matio­nen ein geeig­netes For­mat zu wäh­len, das im Wiki ver­öffent­licht werden kann. Am besten auto­mati­sier­bar.

Pro­gram­mie­ren ist Doku­men­tie­ren.


Methode

Pro­fessio­nell zusamm­men­arbei­ten

Jede an einem IT-System inter­essierte Par­tei hat ihre eigene Vor­stel­lung von guter Doku­men­tation. Diese Vor­stellung ist ganz maß­geblich von ihren per­sön­lichen Schwer­punk­ten bestimmt. »Viele Köche ver­derben den Brei« ist ein Sprich­wort, das wahr wird, wenn jede an der Pro­dukt­doku­men­tation beteilig­te Per­son so schreibt, wie sie es aus persön­licher Sicht für rich­tig hält. Autoren brau­chen ein Grund­gerüst, an dem sie sich orien­tie­ren können. cards+ bietet dafür die feste Struktur mit den Bereichen System­beschrei­bung, System­struk­tur und Archi­tekur­ent­wurf. In jedem Bereich gibt es vor­defi­nierte Bau­steine mit festem Auf­bau.

cards+ unter­schei­det drei Rollen, die wesent­lich zum Gelin­gen einer Pro­dukt­doku­men­tation bei­tra­gen. Auf­grund der Tren­nung von Doku­men­tation im Wiki und Spezifi­kation durch das Team im Code-Reposi­tory bezieht sich die Defi­niton der Rollen von cards+ nur auf die Per­sonen, die direkt im Wiki arbei­ten.

Leser

Leser ist jede am Pro­dukt inter­essierte Par­tei. Ein Leser nutzt das Wiki als Hilfs­mittel zur Erfül­lung seiner Auf­gaben im agilen Ent­wick­lungs­pro­zess. Das Wiki ist für ihn eine unver­zicht­bare Quelle für Pro­dukt­wissen. Jeder Leser ist berech­tigt, im Wiki Sei­ten zu lesen und zu kommen­tie­ren.

Autor

Der Pro­dukt­verant­wortliche ist Autor. Analys­ten, IT- und UX-Exper­ten, Redak­teure und Ver­treter des Teams unter­stützen ihn als Co-Autoren. Ein Autor ist berech­tigt, neue Seiten im Wiki anzu­legen und beste­hende Seiten zu ändern oder zu löschen. Seine Auf­gabe ist es, Seiten im Wiki inkre­mentell mit Pro­dukt­wissen zu füllen.

Gärtner

Ein Gärtner ist Experte für Doku­men­tation und Adminis­tra­tor für das Wiki. Er ist ver­ant­wort­lich für die Aus­wahl der Werk­zeuge für die Autoren. Als Trainer für cards+ ist er für Autoren und Leser greif­bar und hilft ihnen bei der Bewälti­gung von all­täg­lichen wie auch spezi­ellen Prob­lemen im Zusam­men­hang mit Doku­men­tation.

 

Alle Gärtner und Ver­tre­ter der Autoren sind außer­dem Teil einer Exper­ten­runde (engl. community of practice) und Spre­cher der Ziel­gruppen der Pro­dukt­doku­men­tation.

Doku­men­tation nach­hal­tig organi­sie­ren.


Prak­­tiken

Konti­nuier­lich schät­zen

Der Pro­dukt­verant­wort­liche hat eine Vision des Pro­duk­tes. Den Bau­stein Epic gibt einer ange­­for­der­ten Funktio­­nali­tät des Pro­duk­tes einen ein­­deu­tigen Namen und grup­piert die neuen Fähig­keiten der Soft­ware. Den Bau­stein Case legt er an, um jeder neuen Fähig­keit der Soft­ware einen Titel zu geben und die Aus­gangs­lage kurz zu beschrei­ben. Die Lösung bleibt auf jeden Fall offen. Kann der Pro­dukt­verant­wort­liche mit seiner Vision einen Auf­trag­geber begeis­tern, bekommt er häu­fig die Frage gestellt, was das den unge­fähr kos­tet. Agil hin oder her, er braucht eine realis­tische Zahl, an die er selbst glaubt. Für eine Exper­ten­schät­zung durch sein Team muss er sehr viel Arbeit in das Back­log inves­tieren. Und selbst dann ist die Schät­zung in der Regel mit einer hohen Unge­nauig­keit ver­bun­den.

cards+ eröff­net eine neue Option mit dem Ein­satz der Schätz­methode »Use-Case-Points« von Stephan Frohnhoff. Der Bau­stein Case erfüllt alle Bedin­gungen als Ein­gangs­größe für die Schätz­methode. Jeder Case wird auf einer Skala von ein­fach, nor­mal oder kom­plex mit Punk­ten bewer­tet. Die Punkte aller Fähig­keiten der Soft­ware werden addiert und mit Fak­toren gewich­tet. Es gibt Fak­toren für tech­nische Kom­plexi­tät, das Pro­jekt­umfeld und die Pro­duktivi­tät des Teams. Das Ergeb­nis sind Per­sonen­stunden. Der geschätzte Wert ist natür­lich mit einer Unge­nauig­keit ver­bun­den. Mit der Reali­sierung von Fähig­keiten kann die Schät­zung kali­briert werden.

Der Pro­dukt­verant­wort­liche wird in die Lage ver­setzt, die die Schätzung konti­nuier­lich zu aktuali­sie­ren. Fügt er einen neuen Bau­stein Case hinzu, ergänzt er die Schätzung um eine Bewer­tung der neuen Fähig­keit der Soft­ware. Er orien­tiert sich dabei an den bereits vor­hande­nen Fähig­keiten. Der Auf­trag­geber bekommt in sehr kur­zer Zeit eine erste grobe Indi­kation der Kos­ten für die Reali­sierung.