IT-Connection

• About this group
• Forums

• Home
• Groups
• IT-Connection
• Forums
• Software
• Gibt es Scrum zum Festpreis?

• 
  Christian Becker    Premium Member

  The company name is only visible to registered members.

  Gibt es Scrum zum Festpreis?

  Gibt es Scrum zum Festpreis? Bisher galten agile Methoden als das Gegenmodell zu strukturierten Wasserfall- oder RUP-Konzepten, deren agiler Charakter eine Umsetzung zum Festpreis ausschloß. Gemäß einer Studie von Jeff Surtherland sollen Festpreis und Scrum dennoch kombinierbar sein. Wie sieht Ihre Erfahrung hierzu aus? Haben Sie bereits versucht, Scrum-Projekte mit einem festen Kostenrahmen umzusetzen und falls ja, welche Erfahrungen haben Sie dabei gemacht?
  
  • 06 Dec 2011, 10:54 am
  Christian Becker wrote: > Gibt es Scrum zum Festpreis? Bisher galten agile Methoden als das > Gegenmodell zu strukturierten Wasserfall- oder RUP-Konzepten, deren > agiler Charakter eine Umsetzung zum Festpreis ausschloß. Gemäß einer > Studie von Jeff Surtherland sollen Festpreis und Scrum dennoch > kombinierbar sein. Wie sieht Ihre Erfahrung hierzu aus? Haben Sie > bereits versucht, Scrum-Projekte mit einem festen Kostenrahmen > umzusetzen und falls ja, welche Erfahrungen haben Sie dabei gemacht?
• 
  Michael Hönnig    Premium Member   Group moderator

  The company name is only visible to registered members.

  Re: Gibt es Scrum zum Festpreis?

  Wenn man glaubt, dass man kaum Zeit braucht, um eine klassische Schätzung für ein Festpreisprojekt zu machen und das ein darauf basierender Plan zu 100% funkntioniert, dann funktionieren auch klassische Festpreisprojekte. Erfüllt der klassische Ansatz dies?
  
  Die Frage ist also nicht, ob man mit Scrum Festpreisprojekte durchführen kann - das kann man klassisch auch nicht wirklich. Sondern die Frage ist, was "hinten über kippt", wenn der Plan doch nicht eingehalten werden kann.
  
  Klassisch fallen dann zunächst die ersten Milenstein-Termine, in der Folge ("wir müssen aufholen") fällt die Qualität (was die Entwicklung nur noch mehr ausbremst). Im Endeffekt wird verspätet geliefert, die Kosten sind überschritten, die Qualitätsanforderungen sind nicht erfüllt, der Scope wird dann auch noch beschnitten und die (festen) Kosten im Endeffekt sowieso (ggf zu Lasten des Auftragnehmers). Zudem dann hat man ggf. noch das falsche Produkt entwickelt, weil die Anforderungen sich inzwischen geändert haben. Zum Zeitpunkt der Kostenerreichung hat man ggf. fast alle Anforderungen angefangen - zumindest mit detaillierter Analyse, fachlichem Design und technischem Grobdesign - aber nichts wirklich fertig, also kein brauchbares Produkt.
  
  Nach Scrum wird ggf. der Scope strikt priorisiert und in kleinen vertikalen Schritten abgearbeitet, ggf. werden Funktionen zunächst einfacher gehalten, oder fallen auch mal weg, dafür werden aber neue Anforderungen aufgenommen. Zum Zeitpunkt der Kostenerreichung kann ein sinnvolles Produkt geliefert werden - wenn auch nicht das Produkt, was man anfangs glaubte zu brauchen. Und die Qualität ist unantastbar, schon weil man sonst immer langsamer würde.
  
  Klar, man kann auch klassisch erfolgreiche Projekte durchführen. Doch wie viel Zeit (und Geld) muss man dann in die Vorarbeiten stecken, bevor man überhaupt ein Kostenangebot mit Hand und Fuß abgeben könnte?
  
  Grüße
  ... Michael Hönnig
  
  • 06 Dec 2011, 12:40 pm
  Michael Hönnig wrote: > Wenn man glaubt, dass man kaum Zeit braucht, um eine klassische > Schätzung für ein Festpreisprojekt zu machen und das ein darauf > basierender Plan zu 100% funkntioniert, dann funktionieren auch > klassische Festpreisprojekte. Erfüllt der klassische Ansatz dies? > > Die Frage ist also nicht, ob man mit Scrum Festpreisprojekte > durchführen kann - das kann man klassisch auch nicht wirklich. > Sondern die Frage ist, was "hinten über kippt", wenn der Plan doch > nicht eingehalten werden kann. > > Klassisch fallen dann zunächst die ersten Milenstein-Termine, in der > Folge ("wir müssen aufholen") fällt die Qualität (was die Entwicklung > nur noch mehr ausbremst). Im Endeffekt wird verspätet geliefert, die > Kosten sind überschritten, die Qualitätsanforderungen sind nicht > erfüllt, der Scope wird dann auch noch beschnitten und die (festen) > Kosten im Endeffekt sowieso (ggf zu Lasten des Auftragnehmers). Zudem > dann hat man ggf. noch das falsche Produkt entwickelt, weil die > Anforderungen sich inzwischen geändert haben. Zum Zeitpunkt der > Kostenerreichung hat man ggf. fast alle Anforderungen angefangen - > zumindest mit detaillierter Analyse, fachlichem Design und > technischem Grobdesign - aber nichts wirklich fertig, also kein > brauchbares Produkt. > > Nach Scrum wird ggf. der Scope strikt priorisiert und in kleinen > vertikalen Schritten abgearbeitet, ggf. werden Funktionen zunächst > einfacher gehalten, oder fallen auch mal weg, dafür werden aber neue > Anforderungen aufgenommen. Zum Zeitpunkt der Kostenerreichung kann > ein sinnvolles Produkt geliefert werden - wenn auch nicht das > Produkt, was man anfangs glaubte zu brauchen. Und die Qualität ist > unantastbar, schon weil man sonst immer langsamer würde. > > Klar, man kann auch klassisch erfolgreiche Projekte durchführen. Doch > wie viel Zeit (und Geld) muss man dann in die Vorarbeiten stecken, > bevor man überhaupt ein Kostenangebot mit Hand und Fuß abgeben könnte? > > Grüße > ... Michael Hönnig
• Post visible to registered members
• 
  Christian Becker    Premium Member

  The company name is only visible to registered members.

  Re^3: Gibt es Scrum zum Festpreis?

  Hallo
  
  und vielen Dank für Ihre Beiträge.
  
  Was ich in der Praxis als relativ schwierig ansehe ist folgendes Problem:
  Ein wesentlicher Aspekt von Scrum ist, das zu Beginn des Projektes keine meterlangen Spezifikationen geschrieben werden, sondern man einen Backlog mit relativ grob gefaßten User Stories zusammenträgt. Wenn man nun auf dieser Ausgangsbasis eine mehr oder weniger feste Aufwandschätzung macht, muß das nicht viel mit der Realität im folgenden Projekt zu tun haben.
  
  Das kennen wir alle aus der Praxis: Sobald eine Anforderung an die Reihe für einen Sprint kommt und genauer spezifiziert wird, ergeben sich Änderungen, werden die Details komplexer, undundund.
  
  Es gibt natürlich in Scrum das Konzept, das Budget anfangs zu definieren und konstant zu halten, und dem Auftraggeber bei jedem Sprint mitzuteilen, was im Budgetrahmen machbar ist und was nicht. Aber ist das wirklich ein Festpreis? Eigentilch doch nur eine beiderseitige Vereinbarung, ein bestimmtes Budget einzuhalten, ohne aber wirklich am Anfang zu wissen, was man für das Geld am Ende bekommt.
  
  Sehen Sie das anders?
  
  Gruß
  
  Christian Becker
  
  • 07 Dec 2011, 10:48 am
  Christian Becker wrote: > Hallo > > und vielen Dank für Ihre Beiträge. > > Was ich in der Praxis als relativ schwierig ansehe ist folgendes > Problem: > Ein wesentlicher Aspekt von Scrum ist, das zu Beginn des Projektes > keine meterlangen Spezifikationen geschrieben werden, sondern man > einen Backlog mit relativ grob gefaßten User Stories zusammenträgt. > Wenn man nun auf dieser Ausgangsbasis eine mehr oder weniger feste > Aufwandschätzung macht, muß das nicht viel mit der Realität im > folgenden Projekt zu tun haben. > > Das kennen wir alle aus der Praxis: Sobald eine Anforderung an die > Reihe für einen Sprint kommt und genauer spezifiziert wird, ergeben > sich Änderungen, werden die Details komplexer, undundund. > > Es gibt natürlich in Scrum das Konzept, das Budget anfangs zu > definieren und konstant zu halten, und dem Auftraggeber bei jedem > Sprint mitzuteilen, was im Budgetrahmen machbar ist und was nicht. > Aber ist das wirklich ein Festpreis? Eigentilch doch nur eine > beiderseitige Vereinbarung, ein bestimmtes Budget einzuhalten, ohne > aber wirklich am Anfang zu wissen, was man für das Geld am Ende > bekommt. > > Sehen Sie das anders? > > Gruß > > Christian Becker
• 
  Michael Hönnig    Premium Member   Group moderator

  The company name is only visible to registered members.

  Re^4: Gibt es Scrum zum Festpreis?

  Ein wesentlicher Aspekt von Scrum ist, das zu Beginn des Projektes keine meterlangen Spezifikationen geschrieben werden, sondern man einen Backlog mit relativ grob gefaßten User Stories zusammenträgt. Wenn man nun auf dieser Ausgangsbasis eine mehr oder weniger feste Aufwandschätzung macht, muß das nicht viel mit der Realität im folgenden Projekt zu tun haben.
  Das ist exakt genau so, wie in klassischen (Software-)Entwicklungs Projekten auch. Eine Schätzung ist entweder eigentlich eine "Ratung" (je nach Erfahrung der Schätzer mehr oder weniger gut) oder man muss das gesamte Projekt bereits durchdenken und eigentlich schon komplett entwicklen, um genaue Schätzungen zu haben. Das gibt es auch, da bleibt dann nur noch das reine Kodieren in einer Computerlesbaren Programmiersprache und das Testen des Codes, vorher wurde aber das gesamte System schon (unglaublich ineffizient) "auf Papier" entwickelt.
  
  Das kennen wir alle aus der Praxis: Sobald eine Anforderung an die Reihe für einen Sprint kommt und genauer spezifiziert wird, ergeben sich Änderungen, werden die Details komplexer, undundund.
  Wenn man nicht 50% der Projektzeit schon für die Analyse und Schätzung verbracht hat, dann ist das klassisch kein bischen besser. Nur glauben viele, dass es doch besser wäre.
  
  Es gibt natürlich in Scrum das Konzept, das Budget anfangs zu definieren und konstant zu halten, und dem Auftraggeber bei jedem Sprint mitzuteilen, was im Budgetrahmen machbar ist und was nicht. Aber ist das wirklich ein Festpreis?
  Der Preis ist doch fest, also ist es Festpreis im engeren Sinne. Der Preis der Elphilarmonie war dagegen alles andere als fest.
  
  Relevant ist doch nur, was hinten über fällt und was nicht. Klassisch ist das die Qualität und der Termin. Eigentlich auch die Kosten, nur dass ggf. der Aufragnehmer die Differenz als Verlust verbuchen muss - und sich das dann durch teure CR wieder reinholt. Und im Endeffekt leidet auch eben teilweise der Scope, auch wenn man klasssiche oft bis zum letzten Moment daran festhält - das ist auch alles, was beim klassischen Vorgehen "fest" ist.
  
  Eigentilch doch nur eine beiderseitige Vereinbarung, ein bestimmtes Budget einzuhalten, ohne aber wirklich am Anfang zu wissen, was man für das Geld am Ende bekommt.
  Weiß man klassisch eben auch nicht wirklich, nur der Glaube daran ist vorhanden.
  
  Der Kunde muss wählen:
  
  - Will er Qualität und benutzbare Software zu einem festen Preis und lässt es zu, dass der Scope an den Erkenntnisstand angepasst wird. Dann agil.
  
  - Will er unbedingt einen festen Preis und festen Scope, dann kann er klassiche Projektabwicklung verlangen. Die Qualität und damit Folgeprojekte auf demselben Produkt werden dann aber zwangsweise leiden.
  
  Zuaubern können wir Software-Entwickler nämlich nicht.
  
  Alles Gute wünscht
  ... Michael Hönnig
  
  P.S. Termin und Kosten hängen bei Software-Entwicklungs-Projekten eh eng zusammen. Mit mehr Manpower kann man zwar - wenn es rechtzeitig eingeplant wird - für höhere Kosten schneller fertig werden, nachträglich lässt sich da aber meist wenig machen: Adding Manpower to a late project makes it even later.
  
  • 07 Dec 2011, 11:34 am
  Michael Hönnig wrote: > > Ein wesentlicher Aspekt von Scrum ist, das zu Beginn des Projektes > > keine meterlangen Spezifikationen geschrieben werden, sondern man > > einen Backlog mit relativ grob gefaßten User Stories zusammenträgt. > > Wenn man nun auf dieser Ausgangsbasis eine mehr oder weniger feste > > Aufwandschätzung macht, muß das nicht viel mit der Realität im > > folgenden Projekt zu tun haben. > > Das ist exakt genau so, wie in klassischen (Software-)Entwicklungs > Projekten auch. Eine Schätzung ist entweder eigentlich eine "Ratung" > (je nach Erfahrung der Schätzer mehr oder weniger gut) oder man muss > das gesamte Projekt bereits durchdenken und eigentlich schon komplett > entwicklen, um genaue Schätzungen zu haben. Das gibt es auch, da > bleibt dann nur noch das reine Kodieren in einer Computerlesbaren > Programmiersprache und das Testen des Codes, vorher wurde aber das > gesamte System schon (unglaublich ineffizient) "auf Papier" > entwickelt. > > > Das kennen wir alle aus der Praxis: Sobald eine Anforderung an die > > Reihe für einen Sprint kommt und genauer spezifiziert wird, ergeben > > sich Änderungen, werden die Details komplexer, undundund. > > Wenn man nicht 50% der Projektzeit schon für die Analyse und > Schätzung verbracht hat, dann ist das klassisch kein bischen besser. > Nur glauben viele, dass es doch besser wäre. > > > Es gibt natürlich in Scrum das Konzept, das Budget anfangs zu > > definieren und konstant zu halten, und dem Auftraggeber bei jedem > > Sprint mitzuteilen, was im Budgetrahmen machbar ist und was nicht. > > Aber ist das wirklich ein Festpreis? > > Der Preis ist doch fest, also ist es Festpreis im engeren Sinne. Der > Preis der Elphilarmonie war dagegen alles andere als fest. > > Relevant ist doch nur, was hinten über fällt und was nicht. Klassisch > ist das die Qualität und der Termin. Eigentlich auch die Kosten, nur > dass ggf. der Aufragnehmer die Differenz als Verlust verbuchen muss - > und sich das dann durch teure CR wieder reinholt. Und im Endeffekt > leidet auch eben teilweise der Scope, auch wenn man klasssiche oft > bis zum letzten Moment daran festhält - das ist auch alles, was beim > klassischen Vorgehen "fest" ist. > > > Eigentilch doch nur eine beiderseitige Vereinbarung, ein bestimmtes > > Budget einzuhalten, ohne aber wirklich am Anfang zu wissen, was man > > für das Geld am Ende bekommt. > > Weiß man klassisch eben auch nicht wirklich, nur der Glaube daran ist > vorhanden. > > Der Kunde muss wählen: > > - Will er Qualität und benutzbare Software zu einem festen Preis und > lässt es zu, dass der Scope an den Erkenntnisstand angepasst wird. > Dann agil. > > - Will er unbedingt einen festen Preis und festen Scope, dann kann er > klassiche Projektabwicklung verlangen. Die Qualität und damit > Folgeprojekte auf demselben Produkt werden dann aber zwangsweise > leiden. > > Zuaubern können wir Software-Entwickler nämlich nicht. > > Alles Gute wünscht > ... Michael Hönnig > > P.S. Termin und Kosten hängen bei Software-Entwicklungs-Projekten eh > eng zusammen. Mit mehr Manpower kann man zwar - wenn es rechtzeitig > eingeplant wird - für höhere Kosten schneller fertig werden, > nachträglich lässt sich da aber meist wenig machen: Adding Manpower > to a late project makes it even later.
• Post visible to registered members