Risiken der Agilen Software-Entwicklung reduzieren Ein bisschen Wasserfall muss sein

Ein bisschen Wasserfall muss sein

Sowohl agile als auch konventionelle Vorgehensweisen wollen dem Kunden eine Software liefern, die optimal dessen Anforderungen erfüllt und Nutzen erzeugt. Allerdings stehen sich diese beiden Ansätze meist kontrovers gegenüber, denn während das WasserfallmodellWasserfallmodellDas Wasserfallmodel ist ein Vorgehensmodell , bei dem der Projektablauf in sequentielle Phasen gegliedert ist, deren Teilergebnisse aufeinander aufbauend zum vorher vollständig spezifizierten Projektergebnis führen. mit einer ausführlichen SpezifikationSpezifikationSpezifikation ist die exakte, vollständige und für eine Überprüfung geeignete Beschreibung eines Gegenstands oder eines Prozesses. Innerhalb des Projektmanagements definiert die Spezifikation das Projektziel und die Werke (Liefergegenstände) des Projekts. Das Lastenheft ist die vollständige Dokumentation aller erforderlichen Spezifikationen in einem Projekt. Im Rahmen des Konfigurationsmanagements ist die Spezifikation eine Referenzkonfiguration. startet, entsteht diese bei ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. erst im Lauf des Projekts. Eva Maria Schielein und Dorian Gloski wollen hingegen die Vorteile der beiden Ansätze kombinieren. Anhand eines Beispiels, in dem ihre umfangreichen Praxiserfahrungen einfließen, zeigen sie Risiken beider Vorgehensweisen für ZeitZeitZeit ist eine der zentralen Steuerungsgrößen des Projektmanagements und bildet neben Kosten und Leistungsumfang im sog. Magischen Dreieck einen der drei Eckpunkte. Mittlerweile sind Qualität, Risiko und Nutzen als weitere Steuerungsgrößen etabliert. Je nach Projektart ist der Faktor Zeit besonders kritisch, z.B. im Veranstaltungsmanagement oder bei Wartungs- und Instandhaltungsprojekten., Budget, Umfang, QualitätQualitätQualität ist der zentrale Begriff des Qualitätsmanagements und wird dort äußerst differenziert diskutiert. Für die Praxis im Projektmanagement ist es wichtig zu verstehen, dass "Qualität" durch vier Aspekte beschrieben ist: Die Einheit (engl.: entity), d.h. der Gegenstand der Betrachtung Die konkrete Beschaffenheit der Einheit (engl.: totality of characteristics and their values) Die Anspruchsklasse, nach der die Einheit bewertet wird Die Qualitätsforderung, an der die Beschaffenheit gemessen wird und KundennutzenKundennutzenDer Kundennutzen ist die Gegenleistung für den vom Kunden bezahlten Preis. Jedes Produkt und jede Dienstleistung muss deshalb danach beurteilt werden, welchen Nutzen es bei seinen potentiellen Kunden realisiert. Beispielsweise erbringt ein PKW für sich genommen noch keinen Kundennutzen. Ohne die entsprechende Infrastruktur (Straßen, Tankstellen usw.) ist er wertlos. auf, wenn sie puristisch umgesetzt werden. Mit konkreten Handlungsempfehlungen geben sie Hinweise, wie agiles ProjektmanagementAgiles ProjektmanagementAgiles Projektmanagement bezeichnet Vorgehensweisen, bei denen das Projektteam über hohe Toleranzen bezüglich Qualität, Umfang, Zeit und Kosten verfügt und eine sehr hohe Mitwirkung des Auftraggebers bei der Erstellung des Werks erforderlich ist. Charakteristisch für Agiles Projektmanagement ist die Fokussierung auf das zu liefernde Werk und die Akzeptanz durch die Anwender. Hingegen werden geschäftliche Anforderungen, wie z.B. die Termintreue, Kostentreue oder Erfüllung eines spezifizierten Leistungsumfangs weniger oder nicht berücksichtigt. mit "ein bisschen Wasserfall" die Vorteile beider Ansätze vereinen kann.

Management Summary

Risiken der Agilen Software-Entwicklung reduzieren Ein bisschen Wasserfall muss sein

Ein bisschen Wasserfall muss sein

Sowohl agile als auch konventionelle Vorgehensweisen wollen dem Kunden eine Software liefern, die optimal dessen Anforderungen erfüllt und Nutzen erzeugt. Allerdings stehen sich diese beiden Ansätze meist kontrovers gegenüber, denn während das WasserfallmodellWasserfallmodellDas Wasserfallmodel ist ein Vorgehensmodell , bei dem der Projektablauf in sequentielle Phasen gegliedert ist, deren Teilergebnisse aufeinander aufbauend zum vorher vollständig spezifizierten Projektergebnis führen. mit einer ausführlichen SpezifikationSpezifikationSpezifikation ist die exakte, vollständige und für eine Überprüfung geeignete Beschreibung eines Gegenstands oder eines Prozesses. Innerhalb des Projektmanagements definiert die Spezifikation das Projektziel und die Werke (Liefergegenstände) des Projekts. Das Lastenheft ist die vollständige Dokumentation aller erforderlichen Spezifikationen in einem Projekt. Im Rahmen des Konfigurationsmanagements ist die Spezifikation eine Referenzkonfiguration. startet, entsteht diese bei ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. erst im Lauf des Projekts. Eva Maria Schielein und Dorian Gloski wollen hingegen die Vorteile der beiden Ansätze kombinieren. Anhand eines Beispiels, in dem ihre umfangreichen Praxiserfahrungen einfließen, zeigen sie Risiken beider Vorgehensweisen für ZeitZeitZeit ist eine der zentralen Steuerungsgrößen des Projektmanagements und bildet neben Kosten und Leistungsumfang im sog. Magischen Dreieck einen der drei Eckpunkte. Mittlerweile sind Qualität, Risiko und Nutzen als weitere Steuerungsgrößen etabliert. Je nach Projektart ist der Faktor Zeit besonders kritisch, z.B. im Veranstaltungsmanagement oder bei Wartungs- und Instandhaltungsprojekten., Budget, Umfang, QualitätQualitätQualität ist der zentrale Begriff des Qualitätsmanagements und wird dort äußerst differenziert diskutiert. Für die Praxis im Projektmanagement ist es wichtig zu verstehen, dass "Qualität" durch vier Aspekte beschrieben ist: Die Einheit (engl.: entity), d.h. der Gegenstand der Betrachtung Die konkrete Beschaffenheit der Einheit (engl.: totality of characteristics and their values) Die Anspruchsklasse, nach der die Einheit bewertet wird Die Qualitätsforderung, an der die Beschaffenheit gemessen wird und KundennutzenKundennutzenDer Kundennutzen ist die Gegenleistung für den vom Kunden bezahlten Preis. Jedes Produkt und jede Dienstleistung muss deshalb danach beurteilt werden, welchen Nutzen es bei seinen potentiellen Kunden realisiert. Beispielsweise erbringt ein PKW für sich genommen noch keinen Kundennutzen. Ohne die entsprechende Infrastruktur (Straßen, Tankstellen usw.) ist er wertlos. auf, wenn sie puristisch umgesetzt werden. Mit konkreten Handlungsempfehlungen geben sie Hinweise, wie agiles ProjektmanagementAgiles ProjektmanagementAgiles Projektmanagement bezeichnet Vorgehensweisen, bei denen das Projektteam über hohe Toleranzen bezüglich Qualität, Umfang, Zeit und Kosten verfügt und eine sehr hohe Mitwirkung des Auftraggebers bei der Erstellung des Werks erforderlich ist. Charakteristisch für Agiles Projektmanagement ist die Fokussierung auf das zu liefernde Werk und die Akzeptanz durch die Anwender. Hingegen werden geschäftliche Anforderungen, wie z.B. die Termintreue, Kostentreue oder Erfüllung eines spezifizierten Leistungsumfangs weniger oder nicht berücksichtigt. mit "ein bisschen Wasserfall" die Vorteile beider Ansätze vereinen kann.

Management Summary

Agile Vorgehensweisen erfreuen sich zunehmender Popularität. Sie gelten als das richtige Mittel, um in einem dynamischen Umfeld qualitativ hochwertige Software zu entwickeln, die die Anforderungen der Anwender erfüllt. Traditionelle Vorgehensweisen wie das Wasserfallmodell gelten hingegen als unflexibel, "von gestern" und den Erfordernissen moderner Softwareprojekte nicht mehr gewachsen. Wir meinen allerdings, dass in traditionellen Vorgehensweisen bewährte Mechanismen zur Einhaltung von Zeit und Budget entwickelt wurden, die auch bei agilen Vorgehensweisen vorteilhafte Anwendung finden können.

Wir geben zunächst einen kurzen Überblick über die charakteristischen Eigenschaften der Vorgehensweisen nach dem Wasserfallmodell und nach Scrum. Anschließend analysieren wir anhand eines einfachen Fallbeispiels mögliche Auswirkungen der beiden Vorgehensweisen auf Zeit, Budget und Qualität in einem Projekt. Schließlich betrachten wir die möglichen Risiken detaillierter und geben Handlungsempfehlungen, wie sich diese vermindern lassen.

Wasserfallmodell: In Phasen vom Lastenheft zum fertigen Produkt

Die Umsetzung eines Projekts nach dem Wasserfallmodell erfolgt in einzelnen Phasen, wie sie in Bild 1 beispielhaft dargestellt sind. Jede Phase kann erst begonnen werden, nachdem die vorherige erfolgreich abgeschlossen wurde.

Spezifikation als Vertragsgrundlage

Zu Beginn des Projekts legen AuftraggeberAuftraggeberDer Auftraggeber eines Projekts ist der wichtigste Projektbeteiligte (Stakeholder). Er erteilt den Auftrag und ist der Vertragspartner, der über den Erfolg des Projekts endgültig entscheidet. und AuftragnehmerAuftragnehmerDer Auftragnehmer ist Verkäufer eines Produkts oder einer Dienstleistung. Er ist Vertragspartner des Auftraggebers, der die im Lastenheft spezifizierte Leistung kauft. den LiefergegenstandLiefergegenstandFür den PMBOK(R) Guide besitzt der Begriff "deliverable" einen zentralen Stellenwert. Er bezeichnet ein "eindeutiges und überprüfbares Produkt oder Ergebnis oder eine Dienstleistung, das/die hergestellt bzw. erbracht werden muss, um einen Prozess , eine Phase oder ein Projekt abschließen zu können." in einer Spezifikation fest, die typischerweise Bestandteil eines Werkvertrags ist. Die gemeinsam von Auftraggeber und Auftragnehmer akzeptierte Spezifikation bietet eine gute Grundlage für die im Projekt zu erbringenden Leistungen. Der Auftragnehmer muss alle in der Spezifikation enthaltenen Anforderungen innerhalb der Vorgaben von Zeit, Budget und Qualität erfüllen.

Umsetzung: Entwurf, Realisierung, Test, Inbetriebnahme

Nachdem die Spezifikation von beiden Seiten abgenommen wurde, wird das IT-System entworfen, erst dann beginnt die Realisierung. Anschließend erfolgen Test und Installation in die Betriebsumgebung, d.h. die Inbetriebnahme. Der Auftraggeber bekommt die von ihm beauftragte Software erst sehr spät zu sehen, normalerweise in der Testphase. Dadurch kann er erst zu einem sehr späten Projektzeitpunkt erkennen, ob die gelieferte Software seinen Anforderungen entspricht.

Sind die Anforderungen in der Spezifikation hinreichend genau beschrieben und nur wenigen Änderungen unterworfen, so lassen sich Projekte nach dem Wasserfallmodell erfolgreich gemäß den Vorgaben umsetzen.

Bild 1: Schematische Darstellung des Wasserfallmodells. In der Regel erfolgt der Übergang von einer Phase in die nächste von oben nach unten. Der Weg zurück ist nur in Ausnahmefällen möglich.

Regelmäßig ergibt sich während der Projektdurchführung jedoch Änderungsbedarf an der Spezifikation. Möglicherweise wurden Anforderungen übersehen, wie z.B. die SchnittstelleSchnittstelleSchnittstellen sind definierte Projektmanagementprozesse zur Übergabe von Informationen und Produkten zwischen Elementen des Projekts. zu einem anderen System. Auch kommt es vor, dass Anforderungen zu Widersprüchen führen, die erst bei der Implementierung deutlich werden: Wenn zum Beispiel für eine Benutzerinteraktion sowohl eine extrem kurze Antwortzeit als auch eine aufwendige Plausibilitätsprüfung gefordert wird. Bei der Implementierung stellt sich dann möglicherweise heraus, dass die Berechnung der Plausibilitätsprüfung so lange dauert, dass die geforderte Antwortzeit nicht eingehalten werden kann.

Durch das starre Prozessmuster sind Projekte nach dem Wasserfallmodell im Anforderungsmanagement wenig flexibel. Änderungen des Leistungsumfangs können nur über formale Änderungsanträge (Request for Change = RFC) berücksichtigt werden. Es ist nicht unüblich, dass die Änderungsrate eines durchschnittlichen Projekts ca. 25% des Gesamtumfangs der Spezifikation beträgt. Bei einem traditionellen Vorgehen ist deshalb ein entsprechender AufwandAufwandAufwand (Projektmanagement) ist die Menge aller monetär quantifizierbaren Eingangsgrößen in ein Projekt, in ein Programm, in ein Projektportfolio oder in einen Teil eines Projekts. für die Erstellung und Bearbeitung von RFCs einzuplanen.

Durch die verhältnismäßig langen Phasen und die späte Auslieferung der Software wird Änderungsbedarf oft erst sehr spät erkannt. Damit ergeben sich häufig Konflikte mit Zeit- und Budgetzielen. Möglicherweise sinkt auch die Akzeptanz der Software bei den Anwendern, wenn sich erst bei der Inbetriebnahme herausstellt, dass die umgesetzten Anforderungen nicht ihren tatsächlichen Bedürfnissen entsprechen.

Download PDFDownload PDF

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
10 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 24
Kommentare 10

Alle Kommentare (10)

Steffen
Thols

Vielen Dank Fr. Schielein und Herr Gloski für den interessanten Artikel! Den nach meiner Meinung wichtigsten Aspekt hinsichtlich erfolgreicher Projektdurchführung haben Sie am Ende aufgegriffen, nämlich das Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer. Solange dieses nicht besteht, kann jedes Projekt mit welcher Vorgehensweise auch immer sehr schnell in Schieflage geraten, denn unvorhergesehene Dinge treten in einem Projekt immer auf. Und da nun einmal Menschen zusammen arbeiten (keine Ressourcen, wie viele Projektmanager annehmen!) ist das gegenseitige Verständnis und Vertrauen das A und O. Agile Vorgehensweisen versuchen ja durch die Konzentration auf die entsprechenden Werte diese Art der Zusammenarbeit zu betonen. Noch ein paar Gedanken zu den dargestellten Ereignissen in dem Fallbeispiel: Fall 1: Umstellung der Entwicklungsplattform Das Problem der mangelnden Abstimmung zwischen Entwicklung und Betrieb konnte in der Vergangenheit häufig angetroffen werden. Hier hat sich eine Lösung entwickelt, die unter der Bezeichnung „DevOps“ mittlerweile einen großen Bekanntheitsgrad erreicht hat. Der Grundgedanke ist hier das Zusammenrücken der beiden in der traditionellen Wahrnehmung grundverschiedenen Bereiche Softwareentwicklung und IT-Betrieb. Ich habe selbst erlebt, wie erfolgreich ein direktes Mitwirken eines Kollegen aus dem Betrieb in einem Scrum-Team sein kann, um unangenehme Überraschungen hinsichtlich Rollout zu vermeiden. Fall 2: Aufnahme neuer Anforderungen während der Entwicklung Wie Sie später in dem Artikel ausführen, ist ein Relaseburndown-Chart ein wichtiges Werkzeug, um den möglichen Releasetermin in Abhängigkeit von neu hinzugekommenen oder geänderten Funktionalitäten anzuzeigen. Darüber hinaus ist es sehr wichtig, dass der Product Owner in der Lage ist, den Zeithorizont versus Features im Auge zu behalten und gemeinsam mit dem Entwicklungsteam die Auswirkungen von Änderungen im Product Backlog auf „sein“ Produkt/Projekt abzuschätzen. Hier ist das gesamte Projektteam, d.h. das Entwicklungsteam und der Product Owner gefordert! Fall 3: Komplexe Anforderungen umsetzen Bislang war die Auffassung von „puren Agilisten“ ja so, dass die Architektur nicht mehr vor Beginn der Entwicklung festgelegt wird, sondern sich im Laufe der Programmierung „emergent“ entwickelt. Aber wie Sie in Ihrem Fallbeispiel dargestellt haben, benötigen auch agile Projekte in komplexeren Umfeldern und je nach Erfahrungsstand des Entwicklungsteams und der weiteren Beteiligten einen Architekten. Zu diesem Thema zitiere ich mal einen Kollegen von mir aus einer Publikation: „Die Hauptaufgabe eines Architekten ist es, alle diese unterschiedlichen Interessen und Anforderungen gegeneinander abzuwägen und auszubalancieren sowie Widersprüche aufzulösen und geeignete Kompromisse zu finden. Das ist in erster Linie keine technische oder konzeptionelle Aufgabe, sondern hat sehr viel mit dem Verstehen der verschiedenen Anforderungsdomänen sowie mit Kommunikation, Moderation und Konfliktmanagement zu tun, also mit dem Umgang mit Menschen und ihren Bedürfnissen.“ Und diese Aufgaben sind erst einmal mit keinem Vorgehensmodell verbunden… In diesem Sinne Steffen Thols

 

Andreas
Heilwagen

Für mich beruhen die genannten Schwächen der agilen Welt auf der Annahme dass ein Product Owner nur eine sehr schwache Rolle hat. Dies stimmt nicht mit dem Scrum Guide und der gelebten Praxis erfolgreicher agiler Organisationen nicht überein. Mit Übernahme vieler Projektmanagementaufgaben durch den Product Owner in Scrum und seiner Aufgabe den Grundwert von Scrum "Transparenz" umzusetzen, u.a. durch proaktive Information des Auftraggebers über Risiken, löst man die meisten Schwächen ohne Anleihen im klassischen Projektmanagement. Ich sehe keinen wirklichen Bezug zum Wasserfallmodell im Artikel, vielmehr sollen agile Methoden um Elemente des klassischen Projektmanagements angereichert werden. Meine Lösungsvorschläge für die genannten Schwächen sprengen den Umfang eines Kommentars an dieser Stelle so dass die Details in meinem Blog zu finden sind: http://unlocking-potential.de/2012/04/18/scrum-mit-ein-bisschen-wasserfall-klar-und-popeye-wird-stark-dank-spinat

 

Dorian
Gloski

Herr Heilwagen, ich denke unsere Meinungen sind gar nicht so verschieden. Wir sind uns offenbar einig, das gute Product Owner und Scrum Master ihre agilen Projekte auch durch die Verwendung klassischer Projektmanagementmethoden zum Erfolg führen werden. Darüber, ob man hier lieber von "klassischem Projektmanagement" oder "traditionellen Vorgehensweisen" sprechen, brauchen wir nicht zu diskutieren: Nennen wir es halt "klassisches Projektmanagement". Uns geht es in den Artikel darum aufzuzeigen, wo die Risiken liegen, wenn die Rollen des Scrum Masters und des Product Owners nicht so stark genug besetzt sind. Soll das Projekt dann in agiler Schönheit sterben? Oder kann man die dadurch enstehenden Risiken durch klassische Projektmanagementmethoden verringern? Wir tendieren zu Letzterem. Uns liegt die erfolgreiche Umsetzung von Projekten am Herzen. Dabei glauben wir dem Autor Winston Royce die Aussage "Das Wasserfallmodell hat noch nie funktioniert" genauso wenig wie einem Autor, der behauptet, dass "Agil noch nie funktioniert hat".

 

Guest

Der Artikel enthält leider einige grundlegende und weit verbreitete Missverständnisse über agile Entwicklung, die dann anschließend als Problem erkannt werden. Die gravierendsten Missverständnisse möchte ich hier richtig stellen. 1. „Die Kontrolle von Zeit und Budget für das Gesamtprojekt spielt eine geringere Rolle“ Richtig ist, dass Zeit und Budget für das Gesamtprojekt spätestens nach jeder Iteration auf Basis der aktuellen Anforderungslage verfolgt wird. 2. „Zu Konflikten kommt es regelmäßig dann, wenn Anforderungen nicht umgesetzt wurden, die für die Inbetriebnahme der Software essenziell sind.“ Richtig ist, für die Inbetriebnahme der Software essenzielle Anforderungen zuerst und mit höchster Priorität umgesetzt werden. 3. Das Entwicklungsteam kann ohne Rücksprache von einer vertraglich festgeschrieben technischen Anforderung abweichen. Das Entwicklungsteam ist darauf verpflichtet alle Vorgaben einzuhalten. Änderungen dieser Vorgaben sind nur durch den Auftraggeber (Product Owner) möglich. 4. „Das Zusammenspiel von Software und Produktivumgebung trägt, führt unserer Erfahrung nach bei agilen Projekten häufig zu Projektrisiken“ Das Zusammenspiel von Software und Produktivumgebung wird nach jeder Iteration sichergestellt. 5. „Technische und nicht funktionale Anforderungen können [..] aus dem Blickfeld geraten“ Technische und nichtfunktionale Anforderungen sind Bestandteil der Vorgaben und werden genauso verfolgt. 6. „Ob ein Team einen hohen Qualitätsstandard vertritt oder einen eher laxen Umgang mit Softwarequalität pflegt, kann der Auftraggeber den bei einem Sprintreview präsentierten Features in der Regel nicht ansehen.“ Der Qualitätsstandard wird bei Projektbeginn festgelegt („Definition of Done“) und mit allen Beteiligten abgestimmt. Dabei sind z.B. Testabdeckungsgrad, Dokumentation, Betriebsvorgaben, Codequalität, Regressionstests etc. Bestandteile. Iterative Prozesse dienen dazu, die Frequenz der Qualitäts- und Fortschrittskontrollen sehr hoch zu halten, um so die Zielerreichung sicherzustellen. Insofern möchte ich mich dem Fazit der Autoren nicht anschließen.

 

Dorian
Gloski

Herr Dahlke, wir behaupten in unserem Artikel nicht, dass Zeit, Budget und Qualität in agilen Projekten keine Rolle spielen. Natürlich werden diese Aspekte bei agilen Vorgehensweisen adressiert. Und wenn die Vorgehensweise genau erfüllt wird, so lässt sich ein agiles Projekt in Zeit, Budget und Qualität umsetzen. Dies gilt allerdings genauso für ein Projekt nach traditioneller Vorgehensweise. Leider entspricht die Wirklichkeit nicht immer der Theorie (was ja mit ein Grund für die Entstehung agiler Vorgehensweisen ist). In der Praxis kann die Festlegung eines "Definition of Done" genauso wenig Qualitätsprobleme verhindern wie die Festlegung, dass sich eine Spezifikation nicht ändern darf Change Requests verhindert. Bei einem gut laufenden Projekt spielen die hier beschriebenen Risiken keine Rolle. Uns geht es darum aufzuzeigen was passieren kann, wenn es nicht so gut läuft und welche Gegenmaßnahmen man treffen kann.

 

Thomas
Pleschinger

Ein sehr schöner Artikel, der mich unmittelbar zu einer alten, zentralen Frage führt. Ist es überhaupt sinnvoll sich einer einzigen Methode zu Unterwerfen? Alle Projektmanagementmethoden gemeinsam, dass sie unzureichend sind, um alle Umweltbedingungen und Befindlichkeiten abzudecken. Ihr Artikel greift das gut auf. Ein komkretes Ziel muss bereits zu Beginn eines Vorhabens anvisiert werden. Allerdings gibt es kaum eine Umgebung, die so stark kontrolliert wird, dass die Planung ápriori deterministisch sein könnte. Die so unweigerlich auftretende Notwendigkeit Plan, Vorgehen oder Methode anzupassen, wird aber in den wenigsten Methoden vorgesehen. Agiles Projektmanagement wid praktiziert, seit es Projekte giebt. Erst seit kurzer Zeit ist es salonfähig geworden, weil es Methoden giebt, die explizit Agilität auf der Fahne. Daran ist wie gesagt nur neu, dass Anpassungsfähigkeit zur Methode erhoben wurde. Projekterfolge erzielen wir aber nicht durch die Methode, Sondern mit und durch die Menschen, die die Projekte erarbeiten.Beginn Insofern bin und war ich immer ein Freund davon, Methoden als Werkzeuge zu sehen, die den jeweiligen Bedürfnissen entsprechend gewechselt werden. Würden Sie eine Schraube mit dem Hammer anzehen, weil sie damit ihr Vorhaben begonnen Hatten?

 

Guest

„Endlich ein Artikel, der auch mir als Marketing-Fachfrau klar macht, was denn Scrum und Wasserfall eigentlich wirklich bedeutet. Und vor allem: Exzellent ausgesuchte Fotos, die auf den Punkt veranschaulichen.“

 

Janko
Böhm

Vielen Dank Fr. Schielein und Herr Gloski. Aus meiner Sicht ein sehr gelungener Artikel. Ich bin selbst ein großer Anhänger einer Mischform von Agilen und "traditionellem" Vorgehen. Mit einem Kollegen habe ich vor kurzem einen Guide für den Einsatz Agiler Methoden in einem speziellen Unternehmen entwickelt und wir sind auf genau auf den Fakt gekommen dass spezielle Fakten mit großer Tragweite (Architektur, Anzahl-/Unfang von Schnittstellen, Entwicklungsumgebung, Sprache, ..) auch bei einem Agilen Ansatz festgelegt werden müssen. Somit ergibt sich ein "abgestecktes" Spielfeld für den Agilen Teil des Projektes an den Teilen wo das Team agil auf Veränderungen des Product Owners eingehen kann - z.B. Abläufe, Farben, Grafik .. Aber eben nicht mal eben ein ganz neues System einzubeziehen oä. Das würde dann zu einem RFC führen und klassisch auch zusammen mit dem Betrieb bewertet.

 

Janko
Böhm

Guter Artikel - ich habe die Bewertung vergessen.

 

Janko
Böhm

Eine Zusammenstellung wann ein Scrum Projekt in der Praxis gut funktioniert hat Roland Baldenhofer im folgenden Beitrag von Open PM gut herausgearbeitet https://www.openpm.info/display/openPM/Projekte+mit+Scrum+zum+Festpreis Auszug: "Die wichtigsten Architekturentscheide, Frameworkdefinitionen und Businessprozesse waren bekannt" Das passt meiner Meinung auch gut zu den Erfahrungen und Thesen von Fr. Schielein und Herr Gloski in diesem Projekt Magazin Artikel.