Ich habe mich diese Woche mit den Gründern Jörg Pechau und Stefan Matthias Aust des Unternehmens ICNH getroffen. Sie sind spezialisiert auf die Entwicklung und Beratung mobiler Anwendungen. Bisher habe ich diese Welt nur durch die Brille des gemeinen Smartphones-Anwenders gesehen und mich an Apps erfreut oder mich über sie geärgert. Den Blick hinter die Kulissen fand ich sehr spannend und hat mich in vielen Punkten bestätigt.

Ich habe erfahren, dass agiles Vorgehen und interdisziplinäre Teams für eine ernsthafte Entwicklung mobiler Anwendungen unabdingbar sind. Es ist nicht ausreichend, dass die Softwareentwickler lernen, wie man eine Android- oder iOS-Anwendung programmiert. Zu einer guten Entwicklung gehört auch, dass sich das Projektmanagement und die Analysten auf die speziellen Anforderungen einstellen. Eine mobile Anwendung kann nicht einfach auf dem Papier geplant und dann umgesetzt werden. Es bedarf einer frühen Einbindung der Interaktionsdesigner, die eng mit den Analysten zusammenarbeiten bzw. werden gleich beide Rollen durch eine Person ausgeführt. Der Kunde muss frühzeitig die Anwendung in den Händen halten können, um Feedback geben zu können. Noch so gute Pläne auf dem Papier schwinden, wenn man sie in der Anwendung sieht, insbesondere da die Handhabung mobiler Anwendungen sehr speziell ist.

Ich beschäftige mich viel mit Agilität und interdisziplinären Teams. Daher ist dieses Vorgehen für mich grundsätzlich nicht neu. Es sind alles Eigenschaften, die auch für „normale“ Software oder für ganze Systeme gelten. Mobile Anwendungen bringen es aber sehr schön auf den Punkt. Ich freue mich auf weiteren spannenden Austausch mit Jörg und Stefan.

In agilen Projekten werden die Anforderungen meist in Form von Stories beschrieben und nach Priorität über das Product Backlog verteilt. Das unterstützt den Product Owner bei der Frage, was als Nächstes umgesetzt werden soll.

Diese Art, Anforderungen zu organisieren, bietet aber keine Unterstützung, wenn es darum geht, ein Gesamtbild der Anforderungen zu erzeugen. Wir setzen hierfür in Seminaren und beim Kunden schon seit einiger Zeit Story Maps ein als Ergänzung zum Product Backlog.

Eine Beschreibung dieses Werkzeugs habe ich in der aktuellen Ausgabe der iX (5/2011) veröffentlicht (http://www.heise.de/ix).

Mein Vortrag auf der REConf 2011 zum Zickzack-Muster für Anforderungen ist angenommen worden. Das Zickzack-Muster stellt den Zusammenhang zwischen Anforderung und Lösung dar und erklärt, warum Anforderungen nicht lösungsfrei sind.

Ich habe das Muster im Rahmen meiner Systementwicklungsmethodik SYSMOD entwickelt und setze es seit vielen Jahren erfolgreich in Projekten ein. Es ist ein theoretisches Modell, dass immer wieder zu Aha-Effekten führt und viel Transparenz in die praktische Arbeit bringt. Die Kernaussage ist: Jeder Anforderung wohnt eine Annahme inne. D.h., es gibt eigentlich keine lösungsfreien Anforderungen. Die strikte Trennung zwischen dem Was? und dem Wie?, wie sie gerne in der Literatur gefordert wird, muss man viel differenzierter betrachten.

Werfen Sie mal einen Blick auf die Anforderungen in Ihrem Projekt. Sind sie lösungsfrei?

Immer wieder höre ich in Gesprächen mit Teilnehmern und Kunden Sätze, die dem Sinn nach lauten, dass Teams zwar gern nach agilen Vorgehensweisen arbeiten möchten, doch dass die Kunden dieser Teams das nicht zulassen. “Das macht mein Kunde nicht mit!”

Nun verstehe ich das Arbeiten nach agilien Prinzipien so, dass es in diesen Vorgehensweisen eben genau darum geht: höhere Kundenzufriedenheit, engere Zusammenarbeit, schnellere Releases, größeres Vertrauen, besser funktionierende Software, mehr Sicherheit, etc. Die ganze Liste eben. Das steht doch im klaren Wiederspruch zu der Aussage: “da machen wir nicht mit”.
Was ich nun gern wüsste ist, wie es zu solchen Aussagen kommt. Wieso “machen Kunden Agilität nicht mit”? Mit anderen Worten: was genau brauchen Ihre Kunden um “Agilität mitmachen” zu können? Was sind also die größten Hindernisse, nach agilen Vorgehensweisen zu arbeiten?
Ich freue mich auf Ihre Antworten!

In der ix 8/2010 wurde ein Artikel von mir zum Thema “Agiles Requirements-Engineering” unter dem Titel “Aufgespalten” veröffentlicht. Hierzu habe ich von einem Leser noch eine Frage bekommen und beantwortet – und die Essenz dieser Korrespondenz möchte ich hier kurz wiedergeben.

Die Frage war: “Am Ende des Projekts zerfällt das Scrumteam und wird ggf. für spätere Releases neu zusammengestellt. Geht nicht viel Know how verloren, was ‘nur’ in den Köpfen steckt, wenn es nicht auch festgehalten wird (über das notwendigste hinaus)? Ist es dann nicht sinnvoll, die stetig entwickelten Anforderungen auf ein gewisses Niveau anzuheben, dass eine Nachhaltigkeit sichert? Nur allzuoft steht man doch vor der Situation (insbesondere nach längeren Release-Pausen), nicht mehr zu wissen, was das System eigentlich kann. ”

Eine ähnliche Frage hatte ich schon mal in einer Diskussion auf der ReConf in diesem Jahr gehört: “Produzieren wir mit Scrum nicht ein unmittelbar unwartbares und nicht mehr erweiterbares System (also ein Legacy-System), weil nur sehr wenig Anforderungswissen explizit (also außerhalb der Köpfe) gesichert wird?”

Ich persönlich glaube, dass dieser Punkt in Scrum nicht vollständig befriedigend beantwortet ist. Generell gibt es aber die folgenden Erwiderungen auf diesen Einwand:

1. Testautomatisierung und -abdeckung
   Wenn alle wichtigen Anforderungen durch Tests abgedeckt sind, sind sie damit auch dokumentiert. Das ist natürlich nur eingeschränkt hilfreich, weil automatisierte Tests formal spezifizierte Tests sind. Letztendlich ist der Code auch eine formale Spezifikation und in dem Sinne wäre das Programm also, wenn der Quellcode zu 100% vorliegt auch formal spezifiziert und dokumentiert. Solche formalen Spezifikationen/Dokumentationen helfen nur insoweit, wie sie für die an der Weiterentwicklung Beteiligten das richtige Abstraktionsniveau haben. Quellcode ist weitgehend unbrauchbar, formal spezifizierte Tests sind besser, aber eben auch selten optimal.
2. Explizit (Nach-)Dokumentation
   Wenn die Weiterentwickelbarkeit eine explizite Anforderung ist, die der Auftraggeber bezahlen möchte, ihm es also etwas wert ist, dann bekommt das Scrumteam eine explizite Aufgaben, die notwendige Dokumentation zu erstellen. Interessant ist dabei jedoch, dass wir jetzt unterscheiden müssen, zwischen den Anforderungen, die wir VOR der Realisierung erheben und beschreiben, um überhaupt programmieren zu können und denen die NACHHER beschrieben werden. Der Zweck und der Zeitpunkt ist also jeweils an anderer. Der Vorteil der nachfolgenden Anforderungsbeschreibung ist, dass sie auf eine fertige Lösung und Ist-Situation aufsetzt, also viel konkreter, stabiler und weniger spekulativ ist, also auch weniger schnell veraltet. Der beste Zeitpunkt ist wahrscheinlich ein Kompromiss zwischen ausreichender inhaltlicher Stabilität (möglichst spät) und noch gut genug bei den Beteiligten in Erinnerung (also möglichst früh), auf jeden Fall aber NACH der Realisierung.

Bernd Oestereich

Ich arbeite gerade ein neues Seminar aus mit dem Titel “Kommunikation im Requirements Engineering”, kurz KoRE.

Eben habe ich die Produktbeschreibung dazu erstellt, sie wird in kürze auf unserer Web-Seite verfügbar sein.

Worum geht es in KoRE?

Wir werden uns in dem Erlebnis-Seminar typische Kommunikationsfallen im RE ansehen und Wege kennen lernen, damit umzugehen und sie zu vermeiden.

Ein ganz zentrales Thema wird die gewaltfreie Kommunikation nach Marshall  Rosenberg sein. Ich selbst habe mit dieser sehr wertschätzenden und absolut ehrlichen Art der Kommunikation sehr schöne Erfahrungen gemacht, wenn es darum geht, auch kritische Kommunikationssituationen nachhaltig zu klären und um Konflikten entgegen zu wirken. So entsteht eine wirklich nachhaltige Basis, die es ermöglicht, auf wertschätzende Art und Weise gemeinsam mit dem Kunden Lösungen für Problemstellungen zu identifizieren und zu einem Konsens zu kommen – auch im Requirements Engineering.

Im KoRE Seminar möchte ich Sie gern von meinen Erfahrungen profitieren lassen und Ihnen neue Wege aufzeigen offen zu kommunizieren und zu klaren, konsensbasierten Anforderungen zu kommen.