Guerilla Projektmanagement

IT Projekte & Agilität & Zeuch

Vorgehensmodell

Zur Durchführung und Umsetzung von IT Projekten gibt es verschiedene Modelle. Klassisch ist das Wasserfallmodell: Alle Anforderungen werden in einem Lastenheft aufgeschrieben, daraus wird ein Pflichtenheft erstellt usw.

Dies hat sich jedoch als sehr problematisch erwiesen, da Projekte und Anforderungen dynamisch sind. Man kennt zum Projektstart nicht alle Anforderungen. Also gab es andere Ansätze: Unified Process, V-Modell sowie sog. leichtgewichtige Prozesse.

Diese „leichtgesichtigen Prozesse“ (Xtreme Programming, FDD, SCRUM) funktionieren eigentlich ganz gut. Meistens erlebt man bei der Einführung solcher Prozesse folgendes: Die IT Abteilung unterstützt es, die Fachabteilung ist zurückhaltend. Das liegt u.a. daran, dass die IT’ler ja gerade darunter leider, dass den Fachabteilungen ständig etwas neues einfällt.

In meinem aktuellen Projekt erlebe ich es lustigerweise genau umgekehrt. Die Fachabteilung ist einverstanden solche Methoden zu versuchen, die IT-Abteilung wehrt sich. Ihrer Meinung nach ist das ganze zu risikoreich und würde nicht funktionieren. Verkehrte Welt…

12 thoughts on “Vorgehensmodell

  • Andreas sagt:

    Ist nicht jede aktuelle Art des IT-Projektmanagement ein „Nullsummenspiel“, der Faktoren: Flexibilität, Anwenderwünsche, Anwender(minest)wissen, Kosten, Planbarkeit, Planungssicherheit, etc etc… und verschiebt daher nur die Vor-/Nachteile in unterschiedliche Richtungen?

    IT-Abteilungen neigen ja oft dazu, Technik verliebt zu sein und dabei aber auch neuen Techniken eher aufgeschlossen zu sein, während Fachabteilungen oft einfach nur ihre Probleme gelöst haben wollen, ohne jedesmal eine neue „Fremdsprache“ der IT-Abteilung lernen zu müssen.

    „risikoreich“ ist nachvollziehbar: Wenn jemand eine neue Technik nicht versteht und keine Erfahrung hat (und wenig Möglichkeit sich diese kurzfristig zu erarbeiten), dafür aber die Verantwortung, wenn etwas schiefgeht, braucht es schon Vertrauen zum Berater, etwas völlig neues auszuprobieren …

    Ich habe auch schon erlebt, dass ein (neuer) CIO einem Unternehmen Xtrem e Programming für ein Projekt „verkauft“ hat, und weil aber niemand sonst im Konzern (weil es so „neu“ war…) es beurteilen konnte, stellte man erst nach Monaten, und 50 Millionen Doller weniger, fest, dass das ganze Projekt voll gegen die Wand fährt (bzw. schon gefahren ist…).

    Nicht irgendeine Technik führt zu einem erfolgreichen Projektabschluss, sondern die kompetenten Projekt-Macher. Und „zu viel Risiko“ heisst mEn, dass man den Projekt-Machern noch nicht ausreichend vertraut…

  • Nicolas Kübler sagt:

    Eigentlich soll ein Vorgehensmodell das Risiko minimieren, indem es den oben genannten „Projekt-Machern“ mehr Zuversicht gibt, das richtige zur richtigen Zeit zu tun.
    Ob jetzt ein agiles Vorgehensmodell wie XP einen Vorteil bringt, hängt jedoch sehr stark vom Projekt, den Stakeholdern und dem ganzen Unternehmen ab.
    Eigentlich sehe ich das vorteilhaft, wenn eine Fachabteilung zu einem „Experiment“ bereit ist. Darf man erfahren, wie die momentane IT vorgeht?

  • Sven Rimbach sagt:

    >Darf man erfahren, wie die momentane IT vorgeht?

    Wasserfallmodell

    (meine sie, eigentlich arbeiten sie eher auf Zuruf bei einer N zu M Kommunikation, aber das wird wohl ein anderer Beitrag :-) )

  • Nicolas Kübler sagt:

    Ich konnte früher auch nicht glauben, dass so viele Projekte noch mit einem Wasserfallmodell arbeiten, aber das Leben lehrte mich etwas Besseres…

    Seitdem weiß ich, es gibt nichts, was es nicht gibt :D

    Der Kommentar in den Klammern gefällt mir sehr und ich bin auf den Post schon gespannt!

  • Alex sagt:

    Mich wundert, dass XP so beliebt ist, als Vorgehensmodell ist es doch eigentlich eher unflexibel – XP nimmt man so wie es ist, oder man macht kein XP (das stammt jetzt nicht von mir, hab nur grad keine Lust zu suchen). In den Projekten in denen ich in letzter Zeit gearbeitet habe, ging es eigentlich immer nach V-Modell. Find ich auch sinnvoll, da es sich gut an die Bedürfnisse anpassen lässt und auch explizit die Verwendung von agilen Methoden vorsieht.

    Aber man hat ja auch schon von Teams gehört, die Unittests gemacht haben und sich für ein XP-Team hielten… Und ein 50 M$ XP-Projekt, wow, kann ich mir jetzt so garnicht vorstellen, da gibt´s doch sicher mehr Info zu?

    In meinem aktuellen Projekt gab´s ne Zeit lang sowas wie kollektives Code-Eigentum – das ist ganz schön kompliziert, wenn man Entwickler unterschiedlichen Niveaus beschäftigt. Da macht einer die Arbeit von 2 Leuten von 2 Tagen einfach mal in nem halben Tag neu und besser, was am Ende nur zu Frust führt. Und mal ehrlich, wo gibt´s denn Team´s in denen alle auf einem Niveau arbeiten, will man das überhaupt?

    Oh, hier kommt noch ein Zitat von Martin Fowler über Kent Beck: „For either of them (DHH & Kent Beck), if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them.“

    Unbedingt lesenswert finde ich in diesem Zusammenhang die Bücher aus dem Pragmatic Bookshelf, „Der Pragmatische Programmierer“ ist ja mittlerweile schon ein echter Klassiker, aber auch die Bücher über Projekt-Automatisierung, Unit-Tests und „Ship It“ sollten auf keinem Entwickler- und Projektleiterschreibtisch fehlen.

  • Sven Rimbach sagt:

    Hallo Alex,

    ich sehe das genau so. Macht ihr klassisches V-Modell, oder V-Modell XT (oder wie das jetzt heißt)?

    > Mich wundert, dass XP so beliebt ist

    XP ist die Keimzelle gewesen. Daraus entstanden sind eine ganze Reihe von praktikablen Vorgehensweisen.

    > Unbedingt lesenswert finde ich in diesem Zusammenhang die
    > Bücher aus dem Pragmatic Bookshelf

    Definitiv!

  • Nicolas Kübler sagt:

    Naja wenn er von Anpassung (Tailoring) spricht, dann meint er wohl V-Modell XT, denn bei V-Modell 97 werden keine agilen Vorgehensweisen unterstützt.

    Naja wenn du von einem 50 M$ Projekt redest, dann ist das Projekt sicher zu groß für XP. Ich sehe XP oft als Sammlung von Best Practices, die je nach Projekt sinnvoll sind oder nicht. Selbst Kent Back ist schon gescheitert mit seinem XP.
    Das mit kollektiven Code funktioniert natürlich auch nur, wenn die Teams viel Kommunikation haben und nah beinander sind. Zudem muss, wie es Pair Programming vorsieht, auch immer ein Experte neben einem nicht so guten Programmierer sitzen, so dass das Niveau des Teams gehoben wird.

    Bisher kenne ich kein Projekt, das XP wirklich so durchgeführt hatte, wie es beschrieben wird. Oft picken sich die Projektleiter einzelne Best Practices und Methoden heraus und meinen dann, sie nutzen XP.

    Mein Favorit ist momentan auch das V-Modell XT und ich bin schon gespannt auf die Version 1.3, die eigentlich im August hätte released werden sollen, aber angeblich besteht ein Problem, da eine eine OpenSource Lizenzierung gewünscht ist

  • Alex sagt:

    Das V-Modell heißt jetzt V-Modell XT 1.3 ist (glaub ich) grade aktuell. Das XT steht dabei für eXtreme Tailoring und soll wohl insbesondere den Bezug zu den agilen Methoden hervorheben ;-)

    Und man kann ja nicht sagen, wir machen klassisches V oder XT, das ganze ist ja nur Teil von einem Process Management, in dem ISO9001, CMM(I) und Spice weitere wichtige Rollen spielen – aber da könnte man (nicht ich) sich jetzt natürlich ewig drüber auslassen – mein Lieblingsthema ist das nicht grade. Mich interessiert viel mehr, wie man sich da als Entwickler gewisse Freiheitsgrade verschaffen kann ;-)

    > XP ist die Keimzelle gewesen

    Das wollte ich eigentlich sagen, XP hat viele Praktiken hervorgebracht, die sehr gesund für die Software-Entwicklung sind und die pragmatischen Programmierer machen ja im Prinzip nix anderes, als diese Praktiken in die echte Welt (die mit den Constraints) zu übertragen. Das mit der Beliebtheit war nur auf XP als Vorgehensmodell bezogen und da funktioniert ja XP laut den Gurus nur als Ganzes…

  • Alex sagt:

    > Zudem muss, wie es Pair Programming vorsieht, auch immer ein
    > Experte neben einem nicht so guten Programmierer sitzen, so
    > dass das Niveau des Teams gehoben wird.

    Also streng genommen muss ja jeder mal neben jedem sitzen, da ein Ziel das Verbreiten des (fachlichen) Wissens ist…

    Außerdem erfordert das, wie die meisten XP-Praktiken eine eXtrem hohe Disziplin, die erfahrungsgemäß spätestens dann verloren geht, wenn der erste Zeitdruck aufkommt, und der kommt immer auf, und dann braucht es wiederrum einen sehr erfahrenen XP-Coach… Also ich glaube es ist offensichtlich woran XP (als Vorgehensmodell) scheitert ;-)

  • Nicolas Kübler sagt:

    Naja wenn Entscheider jahre lang mit Wasserfallmodell (oder was sie dafür halten) arbeiten, dann ist klar, dass ein Umstieg auf XP nicht gelingen kann.

    Mit VMXT (V-Modell XT) hat man wenigstens Tool Unterstützung vom „Hersteller“, so dass zumindest das Grobe eingehalten wird. Aber gescheiterte oder scheiternde Projekte sind doch auch Anlass, warum man externes Know How benötigt. Das schafft so gesehen wieder Arbeitsplätze und dem Sven ein Lächeln :)

  • Alex sagt:

    Ich unterstelle jetzt mal, dass der Fall, Entscheider arbeitet jahre lang mit Wasserfallmodell und steigt dann um auf XP nur konstruiert ist. Streng genommen müsste es ja auch heißen, der Entscheider lässt nach Wasserfallmodell arbeiten. Ein Umstieg auf XP ist auch quatsch – da wird allerhöchstens mal ein Projekt mit XP ausprobiert, das wächst und wächst und wächst und wird, wenn es seine kritische Masse erreicht hat, in seine Einzelteile zerlegt, dann kommen die Projekt-Fremden ins Spiel, suchen nach Specs, die nicht vorhanden sind…

    Und nochmal zum V-Modell, das ist nicht so, dass man von der „Hersteller“-Webseite was runterlädt und dann kann man danach arbeiten. So ne V-Modell Einführung (mit und ohne XT) macht erstmal viel Arbeit. Zunächst muss man sich mal überlegen, was man überhaupt durch die Einführung eines Vorgehensmodells erreichen will. Und dann gibt´s da noch den zugrundliegenden kontinuierlichen Verbesserungsprozess, durch den das Vorgehensmodell erst richtig lebt…

    Ich mach den Job jetzt auch noch nicht soooo lange und am Anfang hab ich auch immer nach XP gebrüllt, aber die Erfahrung zeigt, dass es für die allermeisten Projekte aufgrund gegebener Rahmenbedingungen als Vorgehensmodell nicht funktioniert. Und irgendwie hat sich das schon wie so ein Pattern rausgebildet: Praktikant/Diplomand/Absolvent fängt hier an, schreit nach XP und mit der Zeit reift das Veständnis dafür, warum es „nur“ eine gute Idee aus einer schöneren Welt ist.

  • Nicolas Kübler sagt:

    Mit Entscheider war nicht Executive gemeint, sondern die Person, die die Wahl des Vorgehensmodell trifft. In vielen Fällen kann das der Projektleiter selbst machen. Ob es jetzt gleich Quatsch ist, das weiß ich nicht, schließlich werden doch eine nicht all zu gerine Anzahl an Projekten mit XP geführt. Den Erfolg kenne ich nicht, hörte bisher nur davon. Natürlich ist bei XP die Dokumentation immer eine Sache des Projektleiters, d.h. manche Projekte haben es, andere nicht.
    Ich kenne bisher kein Unternehmen, das XP richtig einsetzt, noch ob es einen Umstieg auf XP wirklich gemacht hatte. Aber ich kenne ein Unternehmen, das zuvor etwas Ähnliches wie das Wasserfallmodell hatte und jetzt Scrum nutzt / nutzen will. Da XP und Scrum sich dem agilen Manifest verschworen haben, sehe ich die Situation als ähnlich an.

    Ich glaube, ein Unternehmen überlegt nur einen Wechsel des Vorgehensmodell, wenn sie davon überzeugt sind, dass es so nicht weitergehen kann mit den Projekten. Da ist dann der Anlass gegeben und man weiß genau, was man mit einem neuen Vorgehensmodell erreichen will. Dass eine Einführung nicht so einfach ist, das ist klar. Liegt aber oft nicht an der technischen Realisierung, sondern an den Betroffenen. Der Mensch mag eben keine Veränderung und schätzt Stabilität, das ist eher dann ein Kommunikationsproblem. So eines wie man hier im Blog öfters liest. :D

    Ja man sieht oft, dass gerade frische Akademiker nach neueren Vorgehensmodellen schreit. Auch wenn sonst auf die Hochschulen nicht auf dem neusten Stand sind, denke ich, dass in diesem Fall die Sache genau umgekehrt sein könnte. Wenn man an die Chaos Reports denkt und sieht, wie viele Projekte abgebrochen werden, fällt es mir schwer einfach so aufzugeben und zu sagen „die Welt ist eben so“. In manchen Unternehmen hat man leider keine andere Möglichkeit und muss die Dinge so nehmen wie es ist, das musste ich mittlerweile auch schon lernen. Umso besser meistern gerade oft kleinere Unternehmen mit aktuelleren Vorgehensmodellen solche Projekte.

    Ob XP nun das richtige Vorgehensmodelle ist, hängt wohl sehr von der eigenen Umwelt ab, aber ich glaube man kann sagen, in den meisten Fällen ist ein Wasserfallmodell einfach nicht aktuell!

Schreibe einen Kommentar zu Alex Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert