Posts tagged ‘V-Modell’

Festpreise, Ausschreibungen, das V-Modell und Scrum

Vor wenigen Tagen war ich auf der ReConf und habe zusammen mit Markus Reinhold einen Vortrag darüber gehalten, wie man mit Scrum das V-Modell leichtgewichtiger gestalten kann. Fazit: Man kann und sollte das V-Modell auf diese Weise agilisieren. Es ist dann aber immer noch nicht richtig agil – das liegt vor allem an der Ausschreibung und dem Festpreis, die in der Regel mit dem V-Modell einhergehen.
Man müsste von dem Lastenheft und dem darauf basierenden Festpreis wegkommen, wenn man richtig agil werden wollte. Das ist aber mind. im Behördenumfeld nicht so einfach. Dem steht das deutsche Vergaberecht im Weg. Die Behörden müssen eine nachvollziehbare Anbieterbewertung durchführen – sonst haben sie sofort das Verwaltungsgericht bzw. die Vergabekammer im Haus. Und diese Anbieterbewertung erfolgt heute auf Basis der Festpreisangebote. Und folgerichtig darf man in diesem Kontext nur beschränkt an dem ursprünglichen Funktionsumfang herumdrehen. Sonst läuft man Gefahr, die Basis für den Anbietervergleich zu invalidieren. “Money for Nothing, Change for Free” nützt da also auch nur bedingt etwas.

Also blieb da erstmal eine etwas resignierte Stimmung. Aber sollte das wirklich der Fall sein, dass es an dieser Stelle keinen Fortschritt geben kann? Wohl kaum. Nach etwas Nachdenken kam ich auf ein Function-Point-basiertes Modell. Der Auftraggeber würde einfach eine Produktvision mit High-Level-Backlog zur Verfügung stellen, damit der Anbieter weiß, wo es im Prinzip hingeht. Weiterhin würde der Auftraggeber die Anforderungen für den ersten Sprint fein granular beschreiben. Der Auftragnehmer würde die Anforderungen des ersten Sprints in Function-Points schätzen und ein Angebot auf Basis Euro/Function-Point abgeben. Auf diesen Preis würde er sich für einen gegebenen Zeitraum (z.B. 2 Jahre) verpflichten.

Damit hätte der Auftraggeber seine Basis für den Anbietervergleich, ohne dass man ein komplettes fein-granulares Lastenheft vorher braucht. Und zu allem Überfluss würde diese Art der Ausschreibung Ärger vermeiden, der heute durchaus an der Tagesordnung ist: jemand kauft sich das Projekt über einen Dumpingpreis und refinanziert es dann über überteuerte Change-Requests.

Ganz berauscht von meiner Idee habe ich mich etwas umgehört und konnte es kaum glauben: So innovativ ist meine Idee gar nicht. In den Behörden gibt es solche Überlegungen schon länger. Und anscheinend, ist das auch alles kompatibel mit dem deutschen Vergaberecht. Es findet sich nur auf Behördenseite kein Projektleiter, der bereit wäre, seine Ausschreibung so zu gestalten. Das finde ich aus agiler Sicht total schade und es hört sich so an, als würde hier eine Chance verschenkt, effektiver mit unseren Steuergeldern umzugehen.

March 21, 2010 at 10:10 am 1 comment

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.

June 26, 2007 at 5:54 pm Leave a comment

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.

June 12, 2007 at 3:00 pm Leave a comment