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 mmer 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 Pro­dukt­doku­men­tation in 45 Minu­ten.


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 Back­log-Manage­ment in 45 Minu­ten.


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.

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.