Eine Analyse

Was ich in den letzten Jahren persönlich erlebt habe und was man darüber hinaus in der Geschichte der Softwareentwicklung immer wieder beobachtet, ist die „Flucht ins Extreme“. Damit meine ich, dass immer wieder gerne versucht wird, entweder schwarz oder weiß zu sein. An dieser Stelle will ich darauf hinweisen, dass es für solche Extreme durchaus notwendige Anwendungsfälle gibt. Aber die Erfahrung zeigt, eine Vielzahl von Entwicklungsprojekten liegen im „grauen“ Bereich.

Sehen wir uns beispielsweise mal Vorgehensmodelle in der Softwareentwicklung an. Da ist aus meiner Sicht ein Extrem, die Umsetzung des Wasserfallmodells in den Entwicklungsprojekten. Der Gegenpol ist die Anwendung von Scrum als agiles Vorgehensmodell. Damit man das Schwarze und das Weiße besser erkennt, ignorieren wir die in vielen Aspekten (Scope, Terminologien, Methoden) sehr unterschiedlich gestalteten Vorgehensmodelle. Vielmehr ist die Anwendung der Grundideen (Konstruktionsprinzipien) relevant, welche sich hinter den Vorgehensmodellen verbergen.

(a) Ein Konstruktionsprinzip im Wasserfallmodell ist, dass erst ein vollständiger „freigegebener“ Input vorhanden sein muss, bevor eine weitere wertschöpfende Bearbeitung erfolgt. Eine sehr vereinfachtes Beispiel soll diese Prinzip veranschaulichen: Zuerst müssen alle Anforderungen vollständig spezifiziert sein, bevor das System und das Systemdesign beschrieben werden kann. Erst wenn das System und das Systemdesign vollständig spezifiziert sind, werden die Komponenten implementiert usw. [Siehe auch] (http://de.wikipedia.org/wiki/Wasserfallmodell#Probleme_und_Nachteile)

(b) Ein Konstruktionsprinzip im Scrum ist, dass nur die Inhalte detailliert beschrieben werden, die zuverlässig planbar geliefert werden können. Eine sehr vereinfachtes Beispiel soll diese Prinzip veranschaulichen: Es werden nur die Inhalte konkretisiert und definiert, die nach den folgenden 10 bis 20 Tagen (Sprint) geliefert werden können. [Siehe auch] (http://de.wikipedia.org/wiki/Scrum#Product_Backlog)

Die Extreme entstehen nun durch die Anwendung dieser Prinzipien.

In Beispiel (a) erleben wir häufig, dass sich Menschen zurückziehen, wenig kommunizieren, ein Sicherheitsdenken entwickeln – erst wenn ich etwas als vollständig freigebe, stehe ich dazu oder nur wenn etwas vollständig geliefert wurde, fange ich an damit zu arbeiten. Es entwickeln sich Mauern in den Köpfen der Menschen, über diese dann Ergebnisse geworfen werden. Welche Folgen das für die meisten Entwicklungsprojekte hatte, ist im Chaos Report von 1995, der Standish Group, gut zu sehen. (http://www.projectsmart.co.uk/docs/chaos-report.pdf)

In Beispiel (b) erleben wir aktuell, dass Menschen viel kommunizieren, weniger dokumentieren, die schwierigen Themen wie Architektur und Systemtests leicht ausgeblendet werden, schnell neue Begriffe ohne semantisches Verständnis eingeführt werden und Organisationen Schwierigkeiten haben mit ihren Entwicklungsprojekten Erwartungen und Budgets für die nächsten Quartale und Geschäftsjahre festzulegen. Welche Folgen das für viele Entwicklungsprojekte hat, ist in der aktuellen Studie „Softwaretest in der Praxis“ zu sehen. (http://www.softwaretest-umfrage.de/)

Warum wir Menschen dazu neigen Schwarz und Weiß zu denken, und letztlich damit unser Handeln bestimmen, liegt auch an dem Bedürfnis nach einem positiven Selbstbild und dem Bedürfnis nach einem realistischen Weltbild. [Siehe auch](http://de.wikipedia.org/wiki/Denken#Sozialpsychologie)

Um diesen Bedürfnissen nachzukommen, versuchen wir unter anderen:

  1. Widersprüche zwischen unserem Verhalten und unserer Einstellung herunterzuspielen
  2. Unser Verhalten als erzwungen darzustellen
  3. Unser Unwohlsein auf andere Ursachen zurückzuführen

[Siehe auch](http://de.wikipedia.org/wiki/Kognitive_Dissonanz#Dissonanzaufl.C3.B6sung)

Dadurch werden die persönlichen Bedürfnisse befriedigt und wir finden unser seelisches Gleichgewicht. Die durch diese sozialpsychologischen Prozesse beeinflussten Arbeitsergebnisse in der Softwareentwicklung widersprechen aber oft den Arbeitsergebnissen, die durch die Konstruktionsprinzipien der benannten Vorgehensmodelle beabsichtigt sind.

Eine Lösung

Was also tun? Wir brauchen also Konstruktionsprinzipien für Vorgehensmodelle, die auf solche sozialpsychologische Prozesse Rücksicht nehmen. Prinzipien, die bei den Menschen wenige Widersprüche zwischen ihrem Verhalten und ihrer Einstellung auslösen, die die soziale Integrität der Mitarbeiter weitgehend erhalten und die dennoch eine höhere Qualität der Arbeitsergebnisse ermöglichen.

Ein auf solchen Prinzipien basierendes Vorgehensmodell sind die „Value-oriented Practices“. (http://www.sigs.de/publications/newsletter/2010/10/donig_kuenzle_OS_06_10_m_pw.pdf) Es werden bei diesem Vorgehen die fachlichen Ergebnisse und deren Reifestufen in den Mittelpunkt gestellt. Vorgaben für beispielsweise anzuwendende Arbeitsweisen, Methoden, Rollen, Aufbau der Entwicklungsorganisation etc. sind sekundär und werden in passenden Practices optional referenziert. Dadurch werden kognitive Dissonanzen bei den Menschen reduziert bis vermieden.

Ein Erfolgsfaktor und Konstruktionsprinzip der „Value-oriented Practices“ sind die essentiellen Reifestufen der Engineering-Ergebnisse (Artefakte), die in einem Lebenszyklusmodell (Lifecycles) definiert sind. Damit werden die Reifestufen beschrieben, die eine Wertschöpfung am Artefakt erfordern.
(http://de.wikipedia.org/wiki/Wertsch%C3%B6pfung#Allgemeine_Formel)
Es werden damit nur wertschöpfungsrelevante Reifestufen beschrieben. Reifestufen, in denen beispielsweise formale Kriterien wie ein Qualitäts-Audit und/oder eine Freigabe erreicht werden sind nicht essentiell, da die Wertschöpfung hier schon im Voraus erfolgt sein sollte.

Artefakte haben in der Regel mehrere Reifestufen, die im Lebenszyklus, dem so genannten Artifact Lifecycle, in einer sachlogischen Reihenfolge beschrieben sind. Bei einer Anforderung gestaltet sich der essenzielle Lebenszyklus wie folgt:

Lifecycle für eine Anforderung

Lifecycle für eine Anforderung

Bedeutung der Reifestufen:
Created: Eine Anforderung ist Initial und Identifizierbar erstellt. Dies ist kein essentieller Zustand. Es wird der Start definiert, nach dem nun erst die Wertschöpfung erfolgen kann.
Defined (essential): Eine Anforderung hat den Zustand „Defined“, wenn die Spezifikation der Anforderung so vollständig ist, dass ein gemeinsames Verständnis der Stakeholder erreicht werden konnte. Dazu muss sichergestellt sein, dass die relevanten Qualitätskriterien eingehalten wurden bzw. mit Abweichungen bewusst umgegangen wird. Die Anforderung ist für die Umsetzungsplanung bereit.
Analyzed (essential): Der Umfang des Lösungsvorschlages und eine Skizze wurde definiert und von den Beteiligten akzeptiert. Das Hand-Over zur Umsetzung der Anforderung (downward-trace) ist erfolgt. Beispielsweise wurden mit Prototypen Lösungskonzepte bewertet und eine Alternative zur inkrementellen Weiterentwicklung ausgewählt.
Covered (essential): Die abgeleiteten Inhalte wurden von allen Stakeholdern als die Lösung akzeptiert, die zur weiteren Realisierung verwendet wird. Hier ist wenn notwendig, auch eine Traceability inbegriffen, die abgeleitete Ergebnisse mit ihren Anforderungen nachvollziehbar macht. Beispielsweise ist das Inkrement auf Basis des Prototyps weiterentwickelt worden. Das Hand-Over über die erfolgte Anforderungsumsetzung (upward-trace) ist erfolgt.
Verified (essential): Wenn die Verifikationstests auf Basis der Anforderung erfolgreich waren, ist der Zustand „Verified“ erreicht. Eine Validierung des Entwicklungsergebnisses ist jetzt möglich. Werden die Verifikationstests nicht bestanden, wird die Anforderung zur erneuten Realisierung in einem nachgelagerten Entwicklungszyklus für die Umsetzungsplanung bereitgestellt – die Anforderung ist dann im Zustand „Analyzed“
Terminated: Der Lebenszyklus der Anforderung ist beendet.

Die Reifestufen für eine Anforderung sind allgemeingültig. Sie bleiben gültig für natürlich-sprachliche Anforderungen, für Features, für User Storys, Szenarien, Use Cases und weitere Notationen. Die Reifestufen beziehen sich auf die Inhalte des Erfordernisses und dem Verständniss der berechtigten Stakeholder, unabhängig von der verwendeten Notation oder Abstraktion. (http://de.wikipedia.org/wiki/Stakeholder#cite_note-0)

Ein Ausblick

Mit den Value-oriented Practices konnten wir in der Vergangenheit viele gute Erfahrungen sammeln. Vor allem mit der Semantik, die hinter dem Konzept der Reifestufen steht, wurde ein schnelles Verständnis mit verschiedenen Rollen-Vertretern erreicht. Die Diskussionen hatten fast immer ein sachliches und konstruktives Niveau.

Die Erwartungen an die Ergebnisqualität sind durch dieses Konzept nachvollziehbar. Gleichzeitig lassen sich die Lebenszyklen der Artefakte gleichermaßen auf unterschiedliche Vorgehensmodelle und Rahmenbedingungen für die Produktentwicklung übertragen. Damit entsteht kein Zwang die bisherigen Paradigmen revolutionär zu wechseln – wie es bei Scrum-Einführungen in einigen Bereichen (etablieren von Product Owner und Scrum Master) oft notwendig ist.

Die Value-oriented Practices machen eine Veränderung in kleinen Schritten möglich. Sie lassen den Menschen genügend Raum, ihr Bedürfnisse nach einem positiven Selbstbild und einem realistischen Weltbild langsam an die neuen Herausforderungen anzupassen.

Wollen Sie noch mehr über die Value-oriented Practices erfahren? Treffen Sie uns gerne auf der REConf und sprechen Sie mich auch persönlich am 14. März 2012 an unserem Ausstellungsstand an. (http://2012.reconf.de/)

 

Kontakt zu HOOD:

Jens.Donig (at) HOOD-Group.com