PROZESSE


Pro­zesse

cards+ unter­stützt itera­tive Pro­zesse

Das Ziel agi­ler Soft­ware-Ent­wick­lung ist es, den Ent­wick­lungs­pro­zess flexi­bler und schlan­ker zu machen, als das bei den phasen­orien­tier­ten Vor­gehens­model­len der Fall ist. Man möchte sich mehr auf die zu erreichen­den Ziele kon­zen­trie­ren und auf tech­nische und soziale Prob­leme bei der Ent­wicklung ein­gehen. Moti­vation, Selbst­organi­sation, Spaß an der Sache sind Schlag­worte agiler Methoden. Eine Stärke von cards+ ist das vor­ran­gige Ziel, keine umfas­sende Doku­men­tation zu erstel­len, son­dern Pro­dukt­wissen ange­mes­sen im Wiki zu erfas­sen oder bereits exis­tie­rende doku­men­tierte Infor­matio­nen im Wiki zu ver­öffent­lichen. Beson­ders im Bereich der Pro­dukt­doku­men­tation geht es sogar um die Ver­mei­dung von Doku­men­tation durch Ver­öffent­lichung von les­baren Tei­len des Codes und von Test­plänen der Test­pyr­mide.

Agile Soft­ware-Ent­wick­lung hat uns umden­ken las­sen.

  • Wir müssen nicht mehr alles zu Beginn des Pro­jektes wissen.
  • Wir sollen mit­einander und von­ein­ander ler­nen.
  • Wir haben keine getrenn­ten Teams für Ana­lyse, Ent­wick­lung und Test.
  • Wir lieben selbst­organi­sierte cross-funktio­nale Teams.
  • Niemand arbei­tet in einer »Soft­ware-Fabrik«.
  • Wir ent­wickeln das nach unserer Mei­nung beste Pro­dukt.

Mit »Wir« ist dabei die gesamte Pro­jekt­organi­sation gemeint.

Trotz­dem gibt es in agilen Ent­wick­lungs­pro­zessen auch den Bedarf für Anfor­derungs­ana­lyse, Erwar­tungs-, Ände­rungs, Archi­tektur- und Lizenz­manage­ment. Eine agile Pro­jekt­organi­sation bewegt sich immer in einem Spannungs­feld zwischen großer Frei­heit bei der Lösungs­findung durch ein selbst­organi­siertes Team und Ein­schränkungen des Lösungs­raums auf­grund der Gesetzes­lage, inter­nationaler Nor­men und unter­nehmens­weiter Vor­gaben. Das ist immer kontro­vers!

Ziel­gruppen einer Pro­dukt­doku­men­tation.


Pro­zesse

Pro­jekt­manage­ment

Für das Pro­jekt­­manage­ment gibt es unter­schied­liche Vor­gehens­­modelle. Agile Ansätze setzen vor allem auf Flexibi­lität und Anpas­sung. Statt aus­führ­licher und umfang­reicher Planung zu Beginn eines Pro­jekts werden das adap­tive Planen in Itera­tionen, schnel­les Erkennen von Prob­lemen (engl. fail fast) sowie die effi­ziente Kommuni­kation im Team unter­stützt. cards+ kann sehr gut in agile Pro­zesse inte­griert wer­den.

Durch Fluk­tuation oder durch Ver­änderun­gen im Unter­nehmen ent­steht ein regel­mäßiger Wech­sel in der Pro­jekt­organi­sation. Damit ver­bunden ist immer die Gefahr des Ver­lus­tes von Wissen. Der Ver­lust von Wissen ist gefähr­lich. Die Pro­dukt­vision geht ver­loren. Quali­tät und Pro­duk­tivi­tät sinkt. Anpassun­gen und Erweiterun­gen der Soft­ware werden schwieri­ger. Inter­essier­ten Par­teien ist nicht klar, was die Soft­ware bereits leis­tet. Ent­wick­ler sind weni­ger moti­viert, da sie in altem Code wüh­len müssen, um zu ver­ste­hen, wie die Soft­ware »tickt«. Ihre Inno­vations­kraft sinkt. Das ist ein Risiko. Im Pro­jekt­­manage­ment geht es darum, Maß­nahmen einzu­leiten, um beim Ein­tritt eines Risikos vor­berei­tet zu sein. Der konse­quente Ein­satz von cards+ bereits beim Projekt­start ist so eine Maß­nahme.

Der Auf­trag­geber und andere inter­essierte Par­teien (z.B. Nutzer) bestim­men den Umfang des Pro­duk­tes, den der Pro­dukt­verant­wort­liche mit dem Bau­stein Topic doku­mentiert. Wich­tige Begriffe aus den Gesprä­chen mit Auf­trag­geber und Domä­nen­exper­ten erfasst er sofort im Glossar. Damit und mit den Bau­steinen Epic und Case legt er allein durch den Titel der Seite im Wiki die Grund­lage für eine gemein­same Sprache im Pro­jekt. Für den Auf­trag­geber wich­tige Quali­täts­merk­male doku­men­tiert der Pro­dukt­verant­wort­liche inklu­sive Begrün­dung mit dem Bau­stein Decision.

Ein­führung in die Bau­stei­ne der Pro­dukt­doku­men­tation.


Pro­zesse

Anfor­derungs­analyse

Anfor­derungen sind Teil der Pro­jekt­doku­men­tation. Sie ent­stehen auf­grund von Anpassung an eine ver­änderte Unter­nehmens­strategie oder Organi­sations­struk­tur im Unter­neh­men. Anfor­derungen zum rich­tigen Zeit­punkt, in aus­reichen­der Tiefe und ver­ständ­lich darge­stellt, das ist die Auf­gabe der Anfor­derungs­analyse (engl. require­ments engi­neering). Wich­tige Begriffe aus den Gesprä­chen mit Auf­trag­geber und Domä­nen­exper­ten erfasst der Pro­dukt­verant­wort­liche sofort im Glossar.

Ein wicht­iges Ergeb­nis bei der Ana­lyse einer Anfor­derung ist die Abgren­zung zu ande­ren, geplan­ten oder bereits umge­setz­ten Anforder­ungen. Anforder­ungen können sich ergänzen, aber auch wider­sprechen. Es kommt auch vor, dass eine Anfor­derung bereits umge­setzt ist, also ein Dupli­kat ist. Diese Kon­flikte müssen vom Pro­dukt­verant­wort­lichen zusam­men mit den inter­essierten Par­teien geklärt werden. Wich­tig ist auch, dass der Pro­dukt­verant­wort­liche die wert­vollen Ana­lyse­ergeb­nisse sicher und schnell im Wiki erfassen kann, zum Zeit­punkt, an dem er sie zusam­men mit dem Auf­trag­geber und Domä­nen­exper­ten erzielt.

Jede Anfor­derung muss sich in den Gren­zen bewegen, die mit dem Bau­stein Topic gesetzt werden. Das ist gleich­zeitig die erste Vali­dierung einer Anfor­derung. Der Pro­dukt­verant­wort­liche nutzt eine Anfor­derung, um min­destens eine Fähig­keit der Soft­ware zu identi­fizieren, die ent­weder geändert, neu hinzu­gefügt oder sogar ent­fernt werden soll. Mit der fach­lichen Beschrei­bung in den Bau­steinen Epic und Case folgt die weitere Vali­dierung einer Anfor­derung. Erst durch die »Pro­jektion« einer Anfor­derung auf Fähig­keiten des Pro­duk­tes wird sie reali­siert und doku­men­tiert.

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Layout die Mög­lich­keit, den Ent­wurf für ein Ele­ment der Bedien­ober­fläche als Ergeb­nis der Ana­lyse zu sichern. Er kann auf Ver­änderungen durch Feed­back der Domä­nen­exper­ten rea­gieren und den Ent­wurf anpas­sen.

Eine Bedien­ober­fläche ver­folgt immer ein bestimm­tes Bedien­kon­zept. Die Größe des Bild­schirmes (z.B. Watch, Smart­phone, Tablet, Moni­tor, UHD-TV) und die Mög­lich­keiten der Ein­gabe (z.B. Maus, Tasta­tur, Stift, Berüh­rung) beein­flus­sen die Gestal­tung der Bedien­ober­fläche. Ein Bedien­kon­zept ver­folgt auch das Ziel einer Stan­dardi­sierung der Ele­mente der Bedien­ober­fläche durch eine Gestal­tungs­richt­linie (engl. style guide). Jedes Bedien­kon­zept wird mit dem Bau­stein Spec erfasst und bekommt durch den Titel der Seite im Wiki einen ein­deutigen Namen.

Bei der Ana­lyse von Anfor­derungen kommt häu­fig der Punkt, an dem sich Auf­trag­geber und Domä­nen­exper­ten für eine von mehre­ren Lösungen ent­schei­den müssen, eine Fähig­keit in der Soft­ware umzu­set­zen. So eine für die Ent­wick­lung rich­tungs­weisen­den Ent­schei­dung doku­men­tiert der Pro­dukt­verant­wort­liche inklu­sive Begrün­dung mit dem Bau­stein Decision.

Ein­führung in das stra­te­gi­sche Design.


Pro­zesse

Pro­dukt­entwick­lung

Für eine effek­tive, ziel­gerich­tete Ent­wick­lung ist es essen­tiell, dass das Team alle Prob­leme voll­stän­dig ver­steht, damit es eine passende und wirt­schaft­lich ver­tret­bare Lösung fin­den kann. Mit den Bau­steinen der System­beschrei­bung kann der Pro­dukt­verant­wort­liche den Prob­lem­raum des Pro­duktes dar­stel­len. Die vom Team gewählte Lösung beschreibt er oder ein Ver­tre­ter des Teams in Bau­steinen der Systems­truk­tur. Mit dem Abschluss einer Imple­men­tierung durch das Team wird die Spezi­fika­tion im Wiki aktuali­siert. Die Ver­bindung zwischen System­beschrei­bung und Systems­truk­tur bildet der Bau­stein Case.

Agili­tät schafft Vor­teile für alle Pro­zesse. Hier herrscht mittler­weile große Einig­keit. Scrum ist eine Methode, die eine prakti­kable Lösung für agile Pro­dukt­ent­wick­lung anbie­tet, für andere Pro­zesse aber keine Aus­sagen trifft. Das gilt beson­ders für den Bereich Doku­mentation. Das Mani­fest für agile Soft­ware-Ent­wick­lung for­dert, dass ein fer­tiges Pro­dukt einen höhe­ren Wert hat als eine umfang­reiche Doku­men­tation. Das ist rich­tig. Aber es bedeu­tet nicht den Ver­zicht auf Doku­men­tation. Eine ange­messene Doku­mentation ist exakt im Sinn des Mani­fests. Das ist eine wicht­ige Erkennt­nis.

Wissens­manage­ment ist ein Thema, dass in agilen Ent­wick­lungs­pro­zessen immer wieder zu wenig oder gar nicht beach­tet wird. Wissen muss erar­beitet, gesam­melt, geprüft und ver­öffent­licht wer­den. Niemand wünscht Kopf­mono­pole. Kommuni­kation alleine kann Wissens­inseln nicht ver­hin­dern. Eine ange­messene Pro­dukt­doku­men­tation kann die Lücke schlie­ßen. Ein inkre­men­telles Vo­rgehen wie bei cards+ macht die Erstel­lung und Pflege einer Pro­dukt­doku­men­tation in hoher Quali­tät zu einer leist­baren Auf­gabe.

Beson­ders im Zusam­men­hang mit verteil­ter Ferti­gung ist eine Pro­dukt­doku­men­tation ein ganz wich­tiger Faktor für den Erfolg des Pro­jektes. Es ist ein Vor­teil, eine gemein­same Sprache in der Pro­jekt­organi­sation zu eta­blie­ren, die auch im Code und in den Test­plänen Ver­wendung findet. Dabei geht es um ein­deutige Begriffe, die auch von inter­essierten Par­teien gespro­chen und ver­standen wird. Ein gut gepflegtes Glossar unterstützt dieses Vorhaben.

Ein­führung in das tak­ti­sche Design.


Ziel­grup­pen

Doku­men­tation betrifft jeden

Die Be­trof­fen­heit einer Per­son von einer Sache lässt sich sehr schön durch die Fabel vom Huhn (engl. chicken) und vom Schwein (engl. pig) erklä­ren. Eine Par­tei ist betei­ligt (engl. committed), die andere inter­essiert (engl. involved).

The Chicken says: » Hey Pig, I was thin­king we should open a restau­rant! «
Pig replies: » Hm, maybe, what would we call it? «
The Chicken responds: » How about ‘ham-n-eggs’? «
The Pig thinks for a moment and says: » No thanks. I’d be commit­ted, but you’d only be involved. «

Wikipedia

Beteiligt sein bedeutet, von einer Sache über­zeugt zu sein, sich persön­lich dafür einzu­setzen, etwas zu tun. Inter­essiert sein hin­gegen bedeutet, sich ledig­lich mit einer Sache zu befassen. Agile Soft­ware-Ent­wick­lung ver­stärkt die Bedeu­tung beteilig­ter Per­sonen und schützt sie vor dem nega­tiven Ein­fluß inter­essierter Par­teien. Feed­back zum Pro­dukt will ein Pro­dukt­verant­wort­liche aber von allen Ziel­gruppen, ohne Ein­schränkung und immer wert­schätzend.

Die Ziel­grup­pen der Pro­dukt­doku­mentation sind ganz all­gemein inter­essierte Par­teien sowie die Pro­jekt- und Betriebs­organi­sation. Für das Gelingen einer Pro­dukt­doku­men­tation muss der Pro­dukt­verant­wort­liche es schaffen, das sich alle Ziel­grup­pen (oder deren Ver­tre­ter) mindes­tens als Leser beteili­gen. cards+ unter­stützt ihn bei diesem Ver­such.


Ziel­grup­pen

Inter­essierte Par­teien

Ein Auf­trag­geber ist eine inter­essierte Par­tei mit einem star­ken wirt­schaft­lichen und stra­tegischen Inter­esse am Pro­dukt. Der Auf­trag­geber ist erster Ansprech­part­ner für den Pro­dukt­verant­wort­lichen. Er ist Leser der Pro­dukt­doku­men­tation. Die Bau­steine der System­beschrei­bung ver­wen­det der Auf­trag­geber für seine Gespräche mit Fach­abtei­lungen. Sie hel­fen ihm, die Fach­abtei­lungen als Ver­treter der Nutzer und als Geld­geber zu moti­vieren, Ver­besse­rungen oder Erweite­rungen an der Soft­ware zu beauf­tra­gen. Sie disku­tie­ren in einer gemein­samen Sprache und profi­tie­ren dabei vom Glossar. Bei Ver­hand­lungen ist es sehr prak­tisch, wenn eine Pro­dukt­doku­men­tation exis­tiert, die einen Über­blick (engl. big picture) über das Pro­dukt ver­mitteln kann. Das Wissen über bereits reali­sierte Fähig­keiten der Soft­ware hilft bei einer schnellen Ein­schätzung einer Anfor­derung an das IT-System.

Nutzer sind inter­essierte Par­teien und Exper­ten für das IT-System. Indivi­duelle Soft­ware wird in der Regel produ­ziert, um Geschäfts­prozesse im Unter­nehmen zu unter­stützen. Nutzer arbei­ten effi­zienter und machen weni­ger Fehler, weil unter­nehmens­spezi­fische Abläufe und damit ver­bundene beson­dere Fähig­keiten in der Soft­ware abge­bildet werden. Nutzer sind auf jeden Fall Leser für Hand­bücher und Online-Hil­fen. Nutzer sind aber auch Leser der Pro­dukt­doku­men­tation, wenn sie der Pro­dukt­verant­wort­licher als Domä­nen­exper­ten für die Anfor­derungs­ana­lyse hinzu­zieht.


Ziel­grup­pen

Pro­jekt­organi­sation

Ein Pro­jekt ist nach üblicher Defini­tion ein Vor­haben mit min­des­tens einem Ziel, einem Anfang und einem Ende. Eine Pro­jekt­organi­sation umfasst alle Per­sonen, die an diesem Vor­haben mit­wir­ken. Im Zusam­men­hang mit agiler Soft­ware-Ent­wicklung reden wir kon­kret von einem Pro­dukt­verant­wort­lichen und einem Reali­sierungs­team. Das Team setzt sich zusam­men aus Ana­lysten, Ent­wick­lern, Testern und Redak­teuren. Ana­lysten unter­stützen den Pro­dukt­verant­wort­lichen im Pro­jekt­manage­ment und in der Anfor­derungs­ana­lyse. Ent­wick­ler und Tester ent­wickeln die Soft­ware. Redak­teure kümmern sich um pro­fessio­nelle Hand­bücher und unter­stützen den Pro­dukt­verant­wort­lichen beim Marke­ting für das Pro­dukt. In einem Scrum-Pro­zess kommt noch der Scrum-Master dazu. Ein Pro­jekt­leiter ist immer dann not­wendig, wenn nur das Ent­wick­lungs­pro­jekt agil ist, der Auf­trag­geber aber eher klassisch unter­wegs ist.

Der Pro­dukt­verant­wort­liche ist Autor der Bau­steine der System­beschrei­bung. Er nutzt die Bau­steine für sein Back­log-Manage­ment. Ent­wickler und Tester im Team sind damit auto­matisch Leser der System­beschrei­bung.

Der Pro­dukt­verant­wort­liche und Ver­treter des Teams sind Autoren der Bau­steine der System­struktur. Sie teilen sich die Arbeit. Der Pro­dukt­verant­wort­liche arbeitet im Wiki. In Abstim­mung mit dem Team legt er Bau­steine für Dienste und Objekte an. Ver­treter des Teams ver­öffent­lichen Teile vom Code, code-nahe Arte­fakte oder Spezifi­kationen im Wiki, sobald sie ihrer Imple­men­tie­rung an den Diensten und Objekten abge­schlos­sen haben. Tester aus dem Team ver­öffent­lichen Test­pläne im Wiki. Außer­dem unter­sützen das Team den Pro­dukt­verant­wort­liche bei der Formu­lierung der Essenz­schritte der Lösung im Bau­stein Case — min­destens mit ihrem Feed­back als Leser.

Der Pro­dukt­verant­wort­liche und Ver­treter des Teams sind Autoren der Bau­steine für den Archi­tektur­entwurf. Sie nutzen den Bau­stein Decision für die Erfas­sung und Begrün­dung wich­tiger Ent­schei­dungen. Den Bau­stein Spec ver­wenden sie, um ein wieder­kehren­des Ent­wurfs­muster bei der Imple­men­tierung (engl. software pattern) oder ein über­greifen­des Kon­zept pro­dukt­spezi­fisch zu beschrei­ben.

Das Kon­zept der DevOps, also die Kombi­nation von Ent­wick­ler (engl. developer) und Betrei­ber (engl. operator) von Soft­ware, ist aus einem agilen Ent­wick­lungs­pro­jekt nicht mehr wegzu­denken. Ent­wick­ler beglei­ten die Soft­ware bis zur kunden­wirk­same Pro­duktions­umge­bung. Als Autoren der Hand­lungs­anwei­sungen haben sie die Auf­gabe, bereits während der Ent­wick­lung der Soft­ware über Instal­lation und Betrieb nachzu­denken.


Ziel­grup­pen

Betriebs­organi­sation

Die Betriebs­organi­sation umfasst als Ziel­gruppe alle Per­sonen, die Verant­wortung für den kunden­wirks­amen Betrieb tragen. Ein Betrei­ber (engl. operator) ist not­wendig, um ein IT-System unter­brechungs­los und störungs­frei zu betrei­ben. Dazu muss ein Unter­nehmen spezielles Per­sonal haben, das einem Schicht­betrieb einen täg­lich ver­füg­baren 24-stündigen Bereit­schafts­dienst dauer­haft auf­recht­erhal­ten kann. Diese Ziel­gruppe hat natur­gemäß sehr hohe Erwar­tungen an die Quali­tät der Soft­ware.

Betrei­ber sind Leser der gesam­ten Pro­dukt­doku­mentation. Sie brauchen ein grund­legendes Ver­ständ­nis der Soft­ware. Die Bau­steine der System­struk­tur ver­mitteln genau dieses Wissen. In den Spezifi­kationen finden sie Infor­mationen über die einge­setzten Techno­logien und Quali­täts­merk­male der Kate­gorien Sicher­heit Zuver­lässig­keit. Der Bau­stein Service zeigt die Zusammen­hänge zwischen einem abstrak­ten Dienst und der Infra­struk­tur, in der die Pro­zesse betrie­ben werden. Die Bau­steine Event und Entity helfen ihnen beim Ver­stehen von Daten­flüssen im IT-System.

Das Kon­zept der DevOps, also die Kombi­nation von Ent­wick­ler (engl. developer) und Betrei­ber (engl. operator) von Soft­ware, ist aus einer effi­zienten Betriebs­organi­sation nicht mehr wegzu­denken. Betrei­ber sind min­destens Co-Autoren der Hand­lungs­anwei­sungen für das IT-System. Sie kümmern sich um die Ver­öffent­lichung der Hand­lungs­anwei­sungen und geben es als Betriebs­hand­buch frei.

Geschichten aus der Praxis

Der Reise-Butler ist eine Geschichte über ein fik­tives Soft­ware-Ent­wick­lungs­pro­jekt mit dem Ziel, eine intelli­gente Smart­phone-App für die Beglei­tung eines Reisen­den zu reali­sie­ren. Der Reise-Butler ist gleich­zeitig ein Fall­beispiel für den Ein­satz von cards+.

Jetzt lesen

Die fol­genden Kurz­geschich­ten ent­halten gedank­liche Experi­mente und Visi­onen im Zusam­men­hang mit cards+. Wie in einer Fabel steckt in jeder Kurz­geschichte min­destens ein Körn­chen Wahr­heit, ein Stück persön­lich erleb­ter Reali­tät.

Pro­dukt­idee. Neu­start auf “grüner Wiese”.

Standard­pro­dukt. Zurück auf Anfang.

Pro­jekt­krise. Wie geht es weiter?

Pro­dukt­pflege. War­tung auf Spar­flamme.