Lastenheft vs. User Stories

Im Lastenheft beschreibt der Kunde, welche Aufgaben ein zu erstellendes Softwaresystem unterstützen muss. Anscheinend gewinnt es zur Zeit eine stärkere Bedeutung, insbesondere im Verhältnis zum Pflichtenheft - im Pflichtenheft beschreibt der Softwarehersteller, wie er die Software gestalten wird.

Diese höhere Bedeutung des Lastenheftes liegt vor allem an Kommunikationsproblemen zwischen Fachabteilungen und Softwareentwicklern. Die von den Softwareentwicklern geschriebenen Pflichtenhefte sind für Fachabteilungen größtenteils unverständlich und daher keine geeignete Basis für die Vereinbarung des zu entwickelnden Systems.

Genau dieses Kommunikationsproblem adressieren auch die agilen Methoden, aber mit anderen Mitteln als dem Lastenheft. Bei den agilen Methoden wird das statische Lastenheft quasi durch
einen Lastenheft-Generator ersetzt. Dieser Lastenhaft-Generator ist ein Mitarbeiter des Kundenund heißt ja nach gewählter Nomenklatur mal Kunde (XP) und mal Produktverantwortlicher (Scrum).
Dieser Produktverantwortliche hat die Aufgabe, jeweils soviele Anforderungen zu generieren, wie zur Zeit realisiert werden können. Er generiert das Lastenheft quasi während der Projektarbeit. Dabei wird auf persönliche Kommunikation zwischen Produktverantwortlichem und Entwicklern gesetzt, um Kommunikationsprobleme zu vermeiden.

Damit übertragen agile Vorgehensweisen die Prinzipien der Just-In-Time-Production auf die
Softwareentwicklung: Die Anforderungen sind genau in dem Moment definiert, in dem sie benötigt werden.

Die Vorteile dieser Vorgehensweise liegen auf der Hand: Es wird keine lange Vorlaufphase für
die Definition des Lastenhaftes benötigt. Man kann sofort mit der Softwareentwicklung beginnen, sobald der Bedarf entdeckt wurde. Der Produktverantwortliche kann auf veränderte Rahmenbedingungen sofort reagieren - er muss ja nicht massenhaft bereits definierte Anforderungen ändern. Die Kosten auf Kundenseite sinken, weil der Produktverantwortliche immer nur genau die Anforderungen definiert, die auch realisiert werden. Es wird kein Aufwand in die Definition von Anforderungen gesteckt, die dann doch nicht realisiert werden. Erste Versionen der Software kann der Produktverantwortliche begutachten, daraus lernen und die Generierung weiterer Anforderungen mit dem Gelernten abgleichen.

Allerdings ist diese agile Vorgehenweise nicht für alle Kunden sofort umsetzbar - genau so wenig, wie es der westlichen Industrie gelungen ist, Just-In-Time-Production vom einen Tag auf den nächsten umzusetzen. Die Problematik bei der agilen Softwareentwicklung liegt in der Rolle des Produktverantwortlichen. Es ist durchaus eine Herausforderung, die Anforderungen genau zeitgerecht (eben Just-In-Time) zu definieren. Generiert der Produktverantwortliche die Anforderungen zu langsam, hat das Entwicklerteam kostenpflichtigen Leerlauf oder muss mit undurchdachten Anforderungen arbeiten. Generiert der Produktverantwortliche die Anforderungen zu schnell, liegen sie auf Halde.
Je mehr Anforderungen auf Halde liegen, desto größer die Gefahr, dass ein Teil der Anforderungen gar nicht realisiert wird. In diesem Fall hat der Produktverantwortliche seine wertvolle Arbeitszeit umsonst investiert. Anforderungen auf Halde wären in der Nomenklatur der Just-In-Time-Production Verschwendung.

Die Definition und die Realisierung von Anforderungen im Fluss zu halten entspricht genau dem Flow-Gedanken aus dem Just-In-Time-Production. Die einzelnen Produktionseinheiten in eine Fabrik entsprechend einzustellen, heißt Production Leveling. Und genau diese Herausforderung besteht auch bei agilen Softwareprojekten.

Eine große Hürde ist dabei häufig die Organisationsstruktur des Kunden. Muss der Produktverantwortliche sehr viele Parteien einbeziehen, ohne dass es sehr klare Strukturen gibt, gleicht seine Aufgabe dem sprichwörtlichen Hüten von Flöhen. Es besteht ein hohes Risiko, dass ein ziemlich inkonsistentes System entsteht.

Tatsächlich mag in solchen Fällen das Lastenheft doch die bessere Variante sein. Das gilt
allerdings nur, wenn der Lastenheft-Autor auch ausreichend Zeit für all die Abstimmungen
zur Verfügung hat. Unter Zeitdruck erstellte Lastenhefte neigen zu undurchdachten Anforderungen. Da sie statisch festgeschrieben sind, ist der Kunde dann mit dem Lastenheft wiederum schlechter bedient als mit dem agilen Produktverantwortlichen.

Zwischen dem Produktverantwortlichen im Sinne von Scrum oder XP und dem klassischen Lastenheft gibt es aber auch Zwischenstufen. FDD liefert mit der vorgeschalteten gemeinsamen Modellierungsphase einen guten Ansatzpunkt. Das Projekt wird dabei in Abschnitte von maximal 6 Monaten unterteilt. Für jeweils einen solchen Abschnitt findet eine Upfront-Analyse/-Modellierung statt. Dadurch wird die Gefahr von Inkonsistenzen reduziert. Natürlich bezahlt man das, indem man nicht mehr so schnell auf neue Erkenntnisse reagieren kann, wie mit XP oder Scrum. Man ist aber immer noch schneller und leichtgewichtiger unterwegs als mit dem klassischen Lastenheft.

Post bewerten

SEE 2007: eine andere Welt

Letzte Woche war ich auf der SEE 2007-Konferenz in München. Die Konferenz sagt das zwar nicht offen im Namen, aber sehr deutlich durch das Programm: Es geht um klassische Vorgehensmodelle a la V-Modell.

Irgendwie war ich selbst als Vortragender zur Geschichte der agilen Methoden auf die Konferenz geraten. Der Vortrag war gut besucht und meine kleine Umfrage am Anfang ergab, dass ca. 95% der Teilnehmer xUnit benutzt, ca. 90% XP kennen und ca. 70% Scrum. Am Ende des Vortrags hatten wir eine angeregte, aber keine kontroverse Diskussion - ich hatte das anders erwartet.

Am Ende gab es dann noch eine Podiumsdiskussion über reichhaltige (cooler Marketinggag das Wording, Respekt) vs. agile Vorgehensweisen. Das Podium war mit 5 Klassikern und Christian Weiss von oose als Agilisten besetzt. Christian Weiss hat darüber im Blog von Bernd Oesterreich berichtet.

Dort schreibt er:

Mir fiel es jedenfalls schwer, Sinn und Zweck von Agilität überzeugend zu verdeutlichen. Vielleicht liegt hier aber auch das eigentliche Problem: Mein Eindruck war, dass beide Fraktionen im Grunde ihres Herzens dieselben Ziele verfolgen.


Letzteres glaube ich nicht so recht, denn: Auf der Podiumsdiskussion gab es eine kurze Phase, in der sich reichhaltig und agil anzunähernd drohten. Das hat der Moderator glücklicherweise unterbunden. Glücklicherweise, weil es nicht darum geht, ob man alle 3 Monate ein Stück Software ausliefert oder ob man auch in agilen Projekten Dokumentation schreibt (wenn es einen Sponsor dafür gibt). Es geht um die Geisteshaltung bei der Softwareentwicklung und um die Perspektive auf Kundenwert, Verschwendung (Lean, Kaizen), Verantwortung, Ehrlichkeit, Menschen und Teams. Und diese Sichtweisen scheinen mir mind. bei den Podiumsteilnehmern (ausgenommen Christian Weiss) gänzlich anders zu sein, als sie in agilen Projekten gelebt werden.

Ich kann mir aber durchaus vorstellen, dass ein Teil der Konferenzzeilnehmer wirklich gerne agil vorgehen würde und nur nicht so recht weiß, wie. Das habe ich jedenfalls aus einigen Diskussionen mitgenommen.

In diesem Sinne arbeiten wir weiterhin daran, Möglichkeiten zu finden, wie man agil vorgehen kann, auch wenn man nach außen nach V-Modell aussehen muss - V-Modell XS.

Post bewerten