Unter dem Titel «Knigge für Software-Architekten» haben Peter Hruschka und Gernot Starke bereits im Jahr 2012 typisches Verhalten in der IT analyisert. Ihr Ergebnis hat nach meiner Meinung nichts an Aktualität verloren. Agile Software-Entwicklung braucht Transparenz bei Entscheidungen. Mit dem Baustein Decision gibt es die Möglichkeit, eine Entscheidung genau dann zu dokumentieren, wenn sie getroffen wird. Vertreter der Projektorganisation formulieren das Problem und betrachten mindestens zwei Lösungsoptionen. Sie bewerten Chancen und Risiken. Sie wägen Stärken und Schwächen gegeneinander ab. Am Ende treffen sie gemeinsam mit dem Produktverantwortlichen eine Entscheidung und begründen sie.
Dokumentierte Entscheidungen müssen bei der Realisierung berücksichtigt werden. Sie sind Vorgaben, die vom Realisierungsteam einzuhalten sind. Natürlich heißt das nicht, dass eine einmal getroffene Entscheidung nie mehr korrigiert wird. Ganz im Gegenteil. Gerade wenn ein Team während der Entwicklung feststellt, dass eine Entscheidung Probleme verursacht, muss diese Entscheidung hinterfragt und über Alternativen nachgedacht werden. Aber eine dokumentierte Entscheidung hat den Vorteil, dass die gewählte Lösung begründet wurde und die schon einmal betrachteten Alternativen bekannt sind. Das ist besonders wichtig, wenn die Personen, die an der ursprünglichen Entscheidung beteiligt waren, gar nicht mehr im Team sind.
Projektmanagement
Der Produktverantwortliche hat mit dem Baustein Decision die Möglichkeit, eine Vorgabe des Auftraggebers, z.B. Qualitätsmerkmale, zu dokumentieren. Gerade bei jenen Entscheidungen eines Auftraggebers, die etwas ausschließen, ist ein Nachweis besonders wichtig.
Anforderungsanalyse
Der Produktverantwortliche hat mit dem Baustein Decision die Möglichkeit, eine Prämisse oder Regel der Anwendungsdomäne zu dokumentieren, die große Auswirkung auf die Realisierung hat.
Produktentwicklung
Der Produktverantwortliche oder Vertreter des Teams haben mit dem Baustein Decision die Möglichkeit, eine abgestimmte Entscheidung für den Einsatz bestimmter Werkzeuge, Programmiersprachen, Bibliothekn, Technologien, Plattformen, u.s.w. zu dokumentieren. Der Baustein Decision verschafft jedem Leser (z.B. Entwickler oder Tester) einen sehr kompakten Überblick über eine Entscheidung, die seine Arbeit an dem Produkt beschränkt.
Das Wiki.
Ein Erfolgsfaktor.
-
Neustart auf „grüner Wiese“.
Nehmen Sie an, Sie werden beauftragt, ein völlig neues Software-Produkt zu entwickeln. Sie bekommen die Chance, eine individuelle Lösung mit einer agilen Projektorganisation auf der „grünen Wiese” zu entwerfen.
Jetzt lesen -
Zurück auf Anfang.
Stellen Sie sich ein Szenario vor, in dem ein Auftraggeber ein individuell entwickeltes IT-System durch eine Lösung mit einem Standardprodukt ersetzen will. Sie bekommen den Auftrag, die Migration zu planen und umzusetzen.
Jetzt lesen -
Leistungsbeschreibung für den Auftraggeber
Aufgrund der noch immer fehlenden Rechtssicherheit bei Gewerken mit agiler Software-Entwicklung besteht regelmäßig der Bedarf an einem Lastenheft. Arbeiten Auftraggeber und Produktverantwortlicher konsequent mit cards+, dann besteht die Möglichkeit, die Leistungsbeschreibung für das Lastenheft zu großen Teilen aus dem Wiki zu exportieren.
Jetzt lesen