Für die Bewältigung komplexer Probleme, kann man auch ausgefallene Methoden anwenden, dieses möchte ich hier an der Brainwriting-Technik Collective-Notebook Method zeigen.

Da diese Methode recht zeitaufwendig ist, ist sie auch zur Findung schnellere Lösungen nicht geeignet und sollte dann ggf. zum Einsatz kommen, wenn das Problem groß und/oder komplex genug ist.

Kernidee ist das jeder Teilnehmer ein Notizbuch mit sich führt und das über Wochen und rund um die Uhr.

Zu Anfang wird das Problem konkret definiert und es wird festgelegt, wer zur möglichen Lösung beitragen soll. Nun bekommt jeder Teilnehmer ein Notizbuch, an dessen Anfang das Problem niedergeschrieben ist.

Dieses Notizbuch soll den Teilnehmern in der Findungsphase quasi durchgehend zugänglich sein und ihnen die Möglichkeit bieten, im Fall einer guten Idee, diese sofort im Buch festzuhalten. Aber nicht nur Geistesblitze sind dort niederzulegen, sondern auch z.B. ein mal am Tag sollte grundlegend ein Eintrag erfolgen.

Nach den (wenigstens) 2 Wochen fassen alle Teilnehmer ihre eignen Ergebnisse zusammen und in einer gemeinsamen Sitzung werden dann die Ergebnisse ausdiskutiert und im Idealfall zu einer Gesamtlösung ausgearbeitet.

Falls Sie z.B. in der Anforderungserhebung oder bei sonstigen Ideenfindungen Probleme haben, u.a. vielleicht auch durch zu dominante/schwierige Teilnehmer, gibt es Methoden bzw. Kreativitätstechniken die es dem Einzelnen ermöglichen anonymer Betrag zu leisten, um so zu neuen Ideen zu kommen.

Eine davon ist die Methode 635.

Die Methode 635
Der Name ergibt sich aus:
6 Teilnehmer
3 Ideen
5 mal weitergeben

Man setzt sich mit 6 Personen in eine Runde. Jeder der Teilnehmer notiert, auf einem gleichgroßen Blatt Papier, 3 Ideen in der ersten Zeile einer Tabelle mit 3 Spalten. Jede Spalte hat 6 Zeilen.

Nach einer vordefinierten Zeit wird gleichzeitig das Blatt nach rechts weitergereicht.

Im nächsten Zeitintervall erweitert dann jeder die 3 Ideen, die er auf seinem Blatt hat.

Dieses wird solange wiederholt, bis alle einmal jedes Blatt in der Hand hatten.

Zettel

Danach kann das Ergebnis ausgewertet werden.

Auf diesem Weg kann man bei leichten bis mittleren Problemen ggf. schnell zu neuen Ideen und Lösungen kommen.

Vor einigen Tagen hatte ich darüber geschrieben, dass die Trennung von funktionalen und nicht-funktionalen Anforderungen eigentlich problematisch ist. Diesem Gedanken möchte ich noch einmal nachgehen:

Ein Beispiel:
„Berichte in der Anwendung sollen innerhalb von 30 Sekunden bereitgestellt werden“
Ist das eine funktionale oder eine nicht-funktionale Anforderung? Viele werden argumentieren, dass dies eine nicht-funktionale Anforderung ist, da der Satz etwas über das „Wie“ der Leistungserfüllung aussagt. Aber dass die Anwendung „Berichte bereitstellen“ soll, ist eine funktionale Anforderung, und wenn die Berichte typischerweise erst ein Tag nach dem Aufruf des entsprechenden Menüpunktes bereitgestellt werden, dann ist das keine Funktionserfüllung, auch wenn alle Zahlen im Bericht korrekt sind.
Ein neuer Ansatz ist, zu sagen, dass jede Anforderung sowohl Aussagen zu der Frage, was umgesetzt werden soll als auch zu der Frage, wie es umgesetzt werden soll enthält. Anforderungen lassen sich dann generalisieren und spezialisieren, wie wir es aus der objektorientierten Sichtweise kennen.
Können wir damit die Anforderungen, die wir bisher in funktionale und nicht-funktionale unterschieden haben, komplett abbilden? Nicht ganz, ein Aspekt fehlt noch, es ist der der zeitlichen Veränderbarkeit der Anforderung. Ist zu erwarten, dass ein Bericht sich ändert, wenn ja, wie oft? Werden Datenmengen wachsen? Wird die Anforderung auch unter geänderten Bedingungen, z.B. bei neuen Infrastrukturen und Plattformen, bestehen bleiben? Dieser dynamische Aspekt von Anforderungen wird oft vernachlässigt, aber wenn wir ihn mit einbeziehen, dann haben wir quasi alles was wir brauchen, um eine gute Architektur zu entwerfen.
Dazu legen wir uns wie gesagt eine Anforderungs-Hierarchie an, eine Vererbungs-Struktur. Die Basis-Anforderungen sind das Fundament, sowohl für die abgeleiteten Anforderungen als auch für den Architektur-Entwurf der Software. Umso spezieller die Anforderungen werden, desto geringer ist ihr Einfluss auf die Architektur.

Die FAZ veröffentlichte in ihrer Samstagsausgabe einen Text von David Gelernter mit dem Titel Unser neues Bauhaus. Gelernter, der in der Zeitung als einer der entscheidenden WWW-Pioniere vorgestellt wird, verspricht nicht weniger als ein “Plädoyer für eine Software-Kritik” – ähnlich der etablierten Kunst-, Architektur- und Literaturkritik.

Gelernters Ansatz ist interessant: Er meint, für Software, die im Leben wenigstens der Menschen in den westlichen Zivilisationen eine ebenso große Rolle spielt wie die verschiedenen Erzeugnisse des Bauwesens, ist eine kritische Architektur- und Designdebatte ebenso notwendig wie die, die zu Beginn des 20. Jahrhunderts vom Bauhaus angestoßen wurde. Eine Besinnung auf die Grundwahrheiten der Informationsstrukturen sei notwendig, ihre Basiselemente müssen identifiziert und Konsequenzen für die Gestaltung der Software daraus abgeleitet werden.

Gelernter macht zwei “orthogonalen Grundelemente der Cyberwelt” aus: die räumliche Struktur und die zeitliche, wobei die zeitliche Sicht wie in alten Vor-Software-Zeiten auf eine Raum-Struktur abgebildet werden muss. Räumliche Strukturen sind, so Gelernter, an der Erfahrungswelt des Schreibtisches, des Schaufensters oder des Bücherschranks orientiert, während zeitliche Strukturen “wie Partituren, Skripte, Drehbücher oder Tagebücher” arbeiten. So weit so gut.

Leider löst Gelernter im Folgenden sein Versprechen einer Software-Design-Kritik nicht ansatzweise ein. Statt dessen führt er eine Reihe kleiner Detail-Wünsche auf, von denen er meint, dass Software dann gut strukturiert sei, wenn sie diese Wünsche erfüllt. Bei den meisten dieser Wünsche sagt sich der Leser: “Gut, so wird es sicher bald sein, aber was hat das mit Software-Kritik zu tun?”

Kritik muss sicherlich ein ganzes Stück grundsätzlicher sein, als Gelernter hier Glauben macht. Sie muss beim Verhältnis von Architektur und Design anfangen und muss zunächst mal die Frage beantworten, was diese Begriffe für Software eigentlich wirklich bedeuten. Alles, was die einschlägige Literatur dazu bisher zu bieten hat, ist nebulös und sicher keine Basis für eine Kritik die den Anspruch hätte, das Bauhaus in der Softwareindustrie zu sein.

Sodann ist die Frage nach der Funktionalität zu bestimmen: Wie wirken Design und Funktion zusammen? Spannend ist sicherlich, die Kontinuität zwischen der Bücherregal- und Schreibtisch-Organisation und der Bildschirmorganisation unter den Bedingungen von Cloud Computing und SaaS wirklich zu Ende zu denken.

Am Ende fragt Gelernter rhetorisch: “Was täte wohl ein neues Bauhaus? Es machte sich daran, zunächst einmal einen ordentlichen MP3-Player zu entwerfen.” – Sicher nicht. Vielleicht würde es aber die Frage aufwerfen: was “ordentlich” in der Software-Welt ist.

Aus guten Gründen werden große Softwareprojekte nach Vorgehensmodellen abgewickelt, die Informatiker, die gerade frisch von der Uni kommen, gern als angestaubt und konservativ bezeichnen. Dem Wasserfall- und V-Modell wollen sie gern agile Methoden, Scrum und Extreme Programming entgegensetzen.

Aber Auftraggeber von kommerziellen Großprojekten erwarten Budget- und Terminsicherheit bei gleichzeitig klar definierten funktionalen und nicht-funktionalen Anforderungen, abgesichert in eindeutigen und verbindlichen Verträgen – und diese Sicherheit erwartet man eher von einfach und linear strukturierten Prozessen als von einer ungewissen Anzahl von Iterationen mit unbekanntem Ergebnis.

Allerdings können auch noch so gut vorbereitete Projekte mit erstklassig vordefinierten Phasen und Ergebnistypen selten die ursprünglichen Termin- und Kostenvorgaben einhalten. Ausgerechnet die zielgenaue und dosierte Anwendung agiler Methoden kann hier helfen – unter dem (wieder etwas konservativ klingenden) Begriff “Prototyp”.

Es gibt zwei Arten von Prototypen: Der eine ist vor allem unter dem Begriff “Klickprototyp” bekannt: Er modelliert bestimmte Aspekte des zukünftigen Systems ohne wirklich zu “funktionieren” – z.B. die Benutzeroberfläche oder die Verhaltensweise einer Schnittstelle.

Die andere Art von Prototyp wird oft als “Durchstich” bezeichnet – dabei wird ausprobiert, ob eine konzipierte Lösung wirklich funktioniert, d.h., der Prototyp liefert “echte” Ergebnisse.

Prototypen werden in der Konzeptionsphase des Softwareentwicklungsprozesses eingesetzt um Unsicherheiten über die Erfüllbarkeit funktionaler oder nicht-funktionaler Anforderungen auszuräumen. Sie kosten selbst allerdings Zeit und Ressourcen. Deshalb wird oft darauf verzichtet, insbesondere, weil Prototypen nach ihrem Einsatz oft weggeworfen werden und nicht in die endgültige Lösung eingehen.

Wenn die Prototypen nach agilen Methoden entwickelt werden, kann man aber dafür sorgen, dass sie zum Kern der späteren Lösung werden. Einfach gesagt kommt es darauf an, dass beim Erstellen des Prototypen nicht “quick and dirty” gearbeitet wird, sondern entsprechende Programmier-, Dokumentations- und Testrichtlinien angewendet werden.

Das hilft nicht nur, Doppelentwicklungen zu vermeiden, es wird auch sicher gestellt, dass die Ergebnisse der Arbeit am Prototyp wirklich in der Entwicklung berücksichtigt werden.