Projekte oder das Management von Vorhaben

Projekte oder das Management von Vorhaben

Posts 11-18 of 18
  • JUERGEN REIMOLD
    JUERGEN REIMOLD    Premium Member
    The company name is only visible to registered members.
    Re^2: Agile IT-Projekte und Ausschreibungen
    Hallo Herr Schindler,

    das ist auch meine Erfahrung, die meisten Kunden haben ein fixes Budget und einen unverrückbaren Endtermin. Wenn es dann während der Realisierungsphase auch noch zu mehreren Änderungswünschen kommt, kann der Termin nur gehalten werden, wenn man auf Funktionalität oder Qualität verzichtet.

    Bei traditionellen Projekten (Wasserfall-Modell) mit unverrückbaren Terminen, sind wir mit Change Requests bisher so umgegangen, dass der Kunde entscheidet, welche bisher nicht realisierte Funktionalität aus der Anforderungsliste gestrichen wird. An der Qualität wollten wir auf keinen Fall sparen. Dieses Vorgehen würde ich jedoch nicht als agil bezeichnen.

    In einem agilen Projekt, sind Änderungen oder Erweiterungen keine störenden Ausnahmen, sondern die Regel. Denn gerade durch das Konzept der kurzen Iterationen (Sprints) zusammen mit der Liste der User Stories, die während der gesamten Projektlaufzeit erweitert, überarbeitet und immer wieder neu priorisiert werden können, erzielt man dieses hohe Maß an Flexibilität, dass das Wasserfall-Modell nicht bieten kann.

    Vielen Dank auch für die interessanten Internet-Links.
    • 30 Apr 2009, 11:52 am
  • Guenter Nolte
    Guenter Nolte    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^3: Agile IT-Projekte und Ausschreibungen
    Hallo allerseits,

    ich weiss nicht so recht ... vielleicht ist es abhängig von der Branche und dem Umfeld. Bei den meisten Projekten, die ich kenne, sind die Termine fix (sogar mit bis zu 10% Pönale bei Überschreitung) und die Preise erst recht. Das hindert die Kunden nicht daran, recht "agil" neue Wünsche zu formulieren und zu argumentieren, das habe man "eigentlich" schon immer so gewollt, es sei wohl falsch verstanden worden.

    Hier hilft nur ein rigides Change Management und hartes Verhandeln. Es kommt halt immer sehr darauf an, ob das Projekt als "Krieg" des AG gegen den AN verstanden wird oder ob eine gewisse Vertrauensbasis gegeben ist.

    In einem meiner Projekte konnte ich erhebliche technische Änderungen ohne Mehrkosten und Zeitbedarf "unterbringen", weil der Kunde auf meine Umsetzungsvorschläge eingegangen ist. Im anderen Fall hätte es am Ende einfach nicht funktioniert, und dann hätte man _dann_ verhandelt.

    Ich habe mich immer für ein offenes Miteinander-Umgehen ausgesprochen, bin damit aber nicht immer auf Verständnis gestossen. Oft wird dem Kunden auch bis zum letzten Tag vorgemacht, alles sei termingerecht fertig, und am Tag der geplanten Abnahme muss der AN dann "die Hosen runterlassen". Auch die weiteren Termine werden dann sehr oft absolut unrealistisch festgelegt, so dass dieses Ereignis des "Hosen runterlassens" im Projekt durchaus mehrfach auftreten kann.

    Am schönsten sind die Projekte, wo immer neue Änderungen gefordert und dann auch vom AN akzeptiert werden, der Endtermin um Jahre überschritten ist, die Kosten das 5-10-Fache des Verkaufspreises ausmachen und die Pönale im übrigen schon fällig geworden ist. Das sind oft die Fälle, wo ich dann "einsteigen" darf ;-) Das Schöne daran, Geld spielt dann keine Rolle mehr ...

    Beste Gruesse
    Guenter Nolte
    • 03 May 2009, 11:49 am
  • Post visible to registered members
  • Vit Rudovich
    Vit Rudovich    Premium Member
    The company name is only visible to registered members.
    Re: Agile IT-Projekte und Ausschreibungen
    Hallo Herr Reimold,

    Aus welchen Gründen sollte sich nun ein Kunde darauf einlassen, den bewährten Pfad zu verlassen, um auf etwas zunächst Unbekanntes und Unsicheres wie Scrum zu setzen?
    Das Wort "Unbekanntes" ist schlimm. Das Wort "Unsicheres" ist fatal.

    Von Seite des Auftraggebers würde ich jede Agilität vermeiden, weil dann der AG alle Fehler bezahlen muss. AN hat auch keine Interesse "unbezahlte" Qualität zu produzieren.


    Mit Grüß aus Potsdam,

    Vitaly Rudovich
    • 05 May 2009, 8:25 pm
  • Hans-Peter Korn
    Hans-Peter Korn    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^5: Agile IT-Projekte und Ausschreibungen
    @Herr Reimhhold:
    Unter "agil" verstehe ich, dass auch die detaillierten Requirements während während der Softwareentwicklung entstehen. Ja - das bedeutet aber nicht, das bei agilen Projekten keine vernünftigen Aussagen zu Aufwand und Dauer des Projektes schon zu Beginn gemacht werden können.
    So etwa wird bei Scrum zu Beginn des Projektes ein KOMPLETTES Product Backlog (jedoch noch ohne detaillierte tasks!) erstellt und es werden dafür die story points geschätzt. Und auf Grund der Erfahrung, wieviel story points das Team pro sprint (mit einer Dauer von z.B. 2 Wochen) implementieren kann, kann eine "überraschungsfreie Prognose" über Aufwand und Dauer gemacht werden. Die Genauigkeit davon bewegt sich erfahrungsgemäss im üblichen Rahmen.
    Wenn es zu Beginn des Projekts nicht möglich ist, ein product backlog für das ganze Projekt zu erstellen und seine items zu priorisieren und (relativ zueinander) zu schätzen, dann ist das auch kein Projekt sondern ein "open ended program". Möglich wäre dann z.B., die beschreibbaren und schätzbaren items zu einem Projekt zu bündeln und parallel dazu einen Prozess zur fortlaufenden Sammlung weiterer items (= unser stories) vorzusehen. Die dringlichsten items könnten dann in das Projekt einfliessen und die anderen items könnten dann ein product backlog für ein weiteres Projekt bilden.

    Wichtig ist, dass beim agilen Vorgehen der Kunde (und das Projektteam) anerkennt , dass Änderungen des initialen Product Backlogs im Projektverlauf nicht nur möglich sind sondern dass das agile Vorgehen sogar spezifisch darauf ausgerichtet ist, mit solchen Veränderungen rasch, geordnet und kontrolliert umzugehen.
    Und es können zu Projektbeginn und zwischendurch auch "Simulationen" gemacht werden, welche zeigen, welche Auswirkung es auf die Projektdauer hat, wenn pro Sprint sich die Anzahl der noch zu implementieren story points um 5% erhöht oder um 10% oder um 15%.

    ALSO: Für Fälle, bei welchen zu Projektbeginn die "Features" oder user stories zwar "mehr oder weniger" definierbar sind, aber nicht im Detail, und wenn Veränderungen zu erwarten sind und wenn mit ihnen rasch, geordnet und kontrolliert umgegangen werden soll, dann ist das agile Vorgehen angemessen - und jeder AG wird das dann auch unterstützen.

    Dann aber, wenn der AG sicher ist, dass zu Projektbeginn die "Features" oder user stories und Details dazu voll definierbar sind und keine Veränderungen zu erwarten sind (und er das auch vertraglich so festhält), dann führt das agile Vorgehen zu einer unangemessenen Komplexität und Dynamik.
    Und der AG wird dann das agile Vorgehen vernünftigerweise ablehnen.
    Und wenn ein AG eine derartige Vorausplanbarkeit und Stabilität auch dann fordert, wenn der AN weiss, dass das im gegebenen Kontext undenkbar ist, dann muss der AN das Risiko des Scheiterns dem AG überbinden - oder den Auftrag ablehnen.

    Zu dem:
    Aus welchen Gründen sollte sich nun ein Kunde darauf einlassen, den bewährten Pfad zu verlassen, um auf etwas zunächst Unbekanntes und Unsicheres wie Scrum zu setzen? Ich denke, dass die Wahrnehmung von Scrum als etwas "Unbekanntes und Unsicheres" sich derzeit stark in die Richtung verändert, dass es als Option gesehen wird für Projekte, für welche zu Projektbeginn die "Features" oder user stories zwar "mehr oder weniger" definierbar sind, aber nicht im Detail, und bei welchen im Projektverlauf geschäftserfolgsentscheidende Veränderungen zu erwarten sind, die rasch, geordnet und kontrolliert im Projekt zu handhaben sind.

    Beste Grüsse
    Hans-Peter Korn
    • 07 May 2009, 12:03 pm
  • JUERGEN REIMOLD
    JUERGEN REIMOLD    Premium Member
    The company name is only visible to registered members.
    Re^6: Agile IT-Projekte und Ausschreibungen
    Hallo an Alle!

    Ich möchte hier noch ergänzen, dass ich schon miterlebt habe, dass bei einem Kunden, bei dem ständig mehrere Projekte durchgeführt wurden und es dafür auch einen definierten Prozess gab (V-Modell, im Rahmen von Product Lifecycle Management (PLM)), ein einziges Projekt nach Scrum durchgeführt wurde. Das Vorgehen nach Scrum war dabei eher gedultet als gewünscht, zumindest solange das umschließende PLM dadurch nicht gestört wurde.

    Es war aufgrund der konkreten Projektsituation schwer zu beurteilen, ob der Einsatz von Scrum in diesem Kontext wirklich vorteilhaft war.

    Mein Eindruck ist nach wie vor, dass agile Methoden häufig von einzelnen IT-Leitern, Projekt-Leitern oder Entwickern als bessere Alternative zum Wasserfall-Modell wahrgenommen werden, jedoch gibt es diesbezüglich bei den Verantwortlichen noch ein großes Know-how-Defizit und viele falsche Vorstellungen. Hier muss bei den Verantwortlichen sicherlich noch ein konkretes Bild entstehen, was agile Methoden sind, was sie leisten und was auch nicht. Erst dann wird auch die Bereitschaft zunehmen, agile Methoden wirklich einzusetzen.

    Viele Grüße aus Hamburg

    Jürgen Reimold
    • 07 May 2009, 12:49 pm
  • Post visible to registered members
  • JUERGEN REIMOLD
    JUERGEN REIMOLD    Premium Member
    The company name is only visible to registered members.
    Re^8: Agile IT-Projekte und Ausschreibungen
    Sehr geehrter Herr Aleks A.-Lessmann,

    sie haben vollkommen Recht damit, dass bestimmte Methoden und auch Technologien nur dann eingesetzt werden sollen, wenn es auch sinnvoll ist. Das bedeutet immer mit Augenmaß und nie nur um ihrer selbst willen.

    Ich habe jedoch auch die Erfahrung gemacht, dass von den Entscheidern agile Methoden grundsätzlich abgelehnt werden, auch wenn diese in einer konkreten Situation deutliche und auch greifbare Vorteile mit sich bringen würden. Grund ist vielfach eine gewisse Skepis gegenüber agilen Methoden, die auf falschen oder unvollständigen Informationen beruht.

    Die beste Möglichkeit einen Kunden für die Vorteile und die Chancen die agile Methoden mit sich bringen zu sensibilisieren, sehe ich immer noch darin, den Kunden umfassend und sachlich darüber zu informieren und einzelne agile Techniken auch beim wasserfall-artigen Vorgehen einzuführen. So hat man zumindest eine bessere Basis, um bei weiteren Projekten wirklich zwischen agilen und wasserfall-artigen Vorgehensmodellen wählen zu können.

    Viele Grüße aus Hamburg

    Jürgen Reimold
    • 12 May 2009, 1:59 pm