IT-Projektmanagement klassisch-agil

Größe: px
Ab Seite anzeigen:

Download "IT-Projektmanagement klassisch-agil"

Transkript

1 Whitepaper IT-Projektmanagement klassisch-agil Agile Methoden in etablierte Strukturen einfügen

2 IT-Projektmanagement klassisch-agil Agile Methoden in etablierte Strukturen einfügen Autoren: Dr. Andreas Wagener und Colette Ziller für OPITZ CONSULTING Haben Sie Fragen zu diesem Thema? Dann sprechen Sie uns gerne an! Ihr Ansprechpartner: Dr. Andreas Wagener, Senior Solution Manager bei OPITZ CONSULTING Inhaltsübersicht Vorwort Einleitung Klassisches Projektmanagement Agile Methoden PRINCE2 Vorwort Agile Vorgehensmodelle sind in der IT auf dem Vormarsch. Im Management werden sie jedoch häufig noch kritisch beäugt. Zu unklar ist oft, wie sich diese neuen Methoden in die etablierten Managementstrukturen einbinden lassen. In diesem Beitrag wird am Beispiel von PRINCE2 als Vertreter des klassischen Projektmanagements und dem agilen Scrum gezeigt, wie ein Mehrwert aus der Kombination der klassischen und agilen Methoden entsteht. In diesem Whitepaper erfahren Sie: Scrum PRINCE2 und Scrum Fazit Worin sich klassisches Projektmanagement und agile Verfahren unterscheiden. Wie klassisches Projektmanagement und agile Verfahren kombiniert werden können. Welche Vorteile die Kombination beider Verfahren mit sich bringt. Literatur Texte und Abbildungen wurden mit größter Sorgfalt erarbeitet. OPITZ CONSULTING kann jedoch für eventuell verbleibende fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Das Recht an dargestellten Verfahren, Showcases, Implementierungsbeispielen und Sourcecodes liegt ausschließlich bei OPITZ CONSULTING. OPITZ CONSULTING Deutschland GmbH 2015 Seite 2

3 Einleitung Agile Vorgehensweisen in der IT haben sich in den letzten Jahren immer mehr durchgesetzt. Motiviert wurden sie nicht zuletzt durch die (scheinbar?) mangelnde Flexibilität klassischer Vorgehensmodelle. Letztere müssen sich zunehmend der Herausforderung stellen, möglichst schnell, flexibel und kostensparend auch innerhalb der Projektlaufzeit auf Veränderungen zu reagieren. Das gilt auch für Projekte, die mit agilen Verfahren umgesetzt werden. Bei letzteren ist dies aber keine Besonderheit, da die agilen Methoden genau auf den Umstand der häufigen Änderungen in Projekten eingehen und ihn zur Regel machen. Klassischerweise wird der Projektumfang, also das zu erzielende Ergebnis bzw. die Liefergegenstände, bereits sehr früh festgelegt. Immerhin rankt der Projektumfang um die wohl wichtigste Frage in einem Projekt: Was wollen wir mit dem Projekt bewirken? Anschließend werden die Ressourcen- und Zeitpläne aufgestellt, um die Projektziele zu erreichen. Stellt sich nun im Projektverlauf heraus, dass der Umfang mit den gegebenen Ressourcen und Zeitplänen nicht umzusetzen ist, wird klassischerweise versucht über Veränderungen an den Ressourcen oder Zeitplänen oder beiden korrigierend einzugreifen. Diese Maßnahmen sind in der Regel eher unpopulär, da meist die Termine schon kommuniziert und das Budget für die Ressourcen festgelegt wurde. Ein in Deutschland sehr populärer Vertreter des agilen Vorgehens ist Scrum. Scrum hat bedeutend dazu beigetragen, das Verständnis über und für agile Methoden zu verbessern und hat diese damit sehr populär gemacht. In vielen Unternehmen wird deshalb über den Einsatz agiler Vorgehensweisen in IT-Projekten nachgedacht. Jedoch bestehen oft Bedenken, in wie weit sich diese agilen Methoden mit bestehenden Unternehmensvorgaben zu Vorgehensmodellen, Projektmanagement etc. vereinbaren lassen. Dieser Beitrag spricht die aus unserer Sicht wichtigsten Aspekte an, die bei der Kombination agiler und klassischer Methoden berücksichtigt bzw. diskutiert werden sollten. Er kann somit auch als Argumentationsgrundlage für eine geplante Einführung von agilen Methoden im klassischen Projektmanagement-Umfeld dienen. Im Folgenden soll gezeigt werden, dass sich agile Vorgehensmodelle mit klassischen Anforderungen an das Projektmanagement sehr gut vereinbaren lassen. Dabei sind die angesprochenen Verknüpfungspunkte und Verbindungsmöglichkeiten des klassischen und agilen Vorgehens nur Vorschläge, die jedoch auf langjährigen Erfahrungen beruhen. Ändern sich die Rahmenbedingungen eines Projektes, so können sich auch andere Verknüpfungsmöglichkeiten ergeben. Klassisches Projektmanagement Eine klare Abgrenzung oder gar Definition, wann ein Projekt klassisch durchgeführt oder gemanagt wird, gibt es nicht. Vielmehr ist der Begriff klassisch im Zusammenhang mit Projektmanagement eher als nicht agil zu verstehen. Primär liegt der Unterschied eher in der Denk- und Herangehensweise der Projektbeteiligten. In allen Projekten gibt es in erster Linie drei zentrale Rahmenparameter, die für jedes Projekt bestimmt werden müssen. Diese Rahmenparameter sind der Projektumfang (Ziele), die verfügbaren Ressourcen (und Kosten) und die gesetzten Termine. Abbildung 1: Stellschrauben des klassischen Projektmanagements Der Projektumfang als dritte Stellgröße wird in klassischen Umgebungen oft nicht gern und damit zuletzt verändert. Diesen Sachverhalt stellt Abb. 1 mit dem Dreieck des Projektmanagements dar. Die Anforderungen und damit der Umfang sind oft festgelegt. Steuermöglichkeiten liegen eher im Bereich Termine und Ressourcen. Genau an dieser Stelle steigen nun die agilen Methoden ein. Agile Methoden In vielen Projekten, die mit den klassischen Methoden durchgeführt wurden, gab es nach der frühzeitigen Festlegung des Projektumfanges nachträgliche Änderungen an den Anforderungen und Spezifikationen. Diese führten meist auch zu erhöhtem Aufwand im Projekt. Eine schlechte oder oft auch gar nicht vorhandene Kommunikation zwischen den Entwicklern des Produkts und den Auftraggebern führte durch Missverständnisse häufig auch zu erhöhten Aufwänden. Zudem war für die Auftraggeber der Projektfortschritt nicht transparent, denn die Aussagen der Produktentwickler zum Fortschritt konnten nicht wirklich oder nachhaltig überprüft werden. Dazu kam, dass in größeren und länger dauernden Projekten oftmals an den zu Beginn festgelegten Planungen festgehalten wurde, auch wenn sich das Geschäftsumfeld während des Projekts geändert hatte. Seite 3

4 Dies sind nur einige Faktoren, die in vielen Fällen dazu führten, dass Projekte zwar planmäßig beendet wurden, aber für den Auftraggeber trotzdem nicht erfolgreich und zufriedenstellend waren. Das íst der Grund, warum die agilen Methoden mit ihren veränderten Projektannahmen mehr und mehr an Bedeutung gewinnen. Die Kernidee agiler Methoden besteht dabei aus iterativ-inkrementellen Prozessen, um durch häufige Rückkopplungen Fehlentwicklungen frühzeitig zu erkennen. Möglichkeiten der Umplanung und Anpassung sollen auf natürliche Art im Prozess vorgesehen und als Chancen genutzt werden. Dabei spielt die maximale Transparenz der angewendeten Lösungsansätze und des jeweiligen Status der Umsetzung eine primäre Rolle. Der Fokus liegt auf den zu erreichenden Ziele und es wird auf Probleme bei der Produktentwicklung eingegangen. Die Werte agiler Methoden bilden das Fundament und wurden im Februar 2001 als agiles Manifest von den führenden Vertretern der agilen Methoden verabschiedet: Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. [5] Wie Planung, Durchführung und Steuerung eines agilen Prozesses auszugestalten sind, dazu sind seit vielen Jahren zahlreiche Vorschläge gemacht worden. Ob Extreme Programming, Test- und Feature Driven Development, Agile Unified Process, Crystal oder Scrum alle sind bemüht, die Grundprinzipien Flexibilität und Transparenz ins Zentrum aller Tätigkeiten zu stellen. Dabei wird akzeptiert, dass die Anforderungen an das Produkt zu Beginn des Projektes nur teilweise oder grob bekannt sind. Eine Detaillierung oder Ergänzung der Anforderungen erfolgt erst während der Projektlaufzeit. Ebenso wird von Beginn an mit Änderungen an den Anforderungen gerechnet. Solche Änderungen gelten als Standard in agilen Methoden und sind keine Ausnahme. Durch die regelmäßige und zeitnahe Auslieferung von Produktinkrementen ist der Projektfortschritt für den Auftraggeber transparent und nachvollziehbar. Und mit dem frühen Feedback der Auftraggeber kann Verschwendung im Projekt vermieden werden. Bezogen auf das Dreieck des Projektmanagements ergibt sich bei den agilen Methoden ein verändertes Bild im Vergleich zu den klassischen. Wie in Abb. 2 dargestellt, sind die Kosten und die Dauer des Projektes festgelegt, während der Umfang flexibel und veränderbar ist. PRINCE2 PRINCE2 gilt als der De-facto-Standard für Projektmanagement in Großbritannien, kommt aber auch verstärkt im übrigen Westeuropa zum Einsatz. Ursprünglich Ende der 1980er Jahre für IT-Projekte entwickelt wurde die Methodik Mitte der 1990er Jahre erstmals unter dem Namen PRINCE2 (PRojects IN Controlled Environments) als universelle Projektmanagementmethodik vorgestellt. Die Methodik basiert auf sieben Grundprinzipien, aus denen die Projektmanagement-Themen und Prozesse motiviert werden. Während die Grundprinzipien die grundsätzliche Philosophie der Methodik repräsentieren, beschreiben die Themen die Bereiche bzw. Aspekte eines Projekts, die fortlaufend betrachtet werden müssen. Die Prozesse wiederum geben eine Leitlinie für die Durchführung eines Projekts. Mit den Prozessen werden Aktivitäten, Produkte und Verantwortlichkeiten definiert. Da es nicht eine Methodik geben kann, die auf alle Projekte perfekt passt, fordert PRINCE2 explizit eine Anpassung der Methodik auf das Projektumfeld. Diese Anpassung geschieht in der Regel primär bei den Prozessen. Wichtig bei jeder Anpassung ist, dass die Grundprinzipien von PRINCE2 durchgehend berücksichtigt und eingehalten werden. Grundprinzipien PRINCE2 basiert auf sieben universell anwendbaren Grundprinzipien. Die Grundprinzipien stellen das Fundament eines jeden PRINCE2-Projektes dar. Sie nicht die Prozesse und Artefakte machen die Projektmanagement- Methodik PRINCE2 aus. Im Folgenden werden die sieben Grundprinzipien vorgestellt: Abbildung 2: Stellschrauben des agilen Projektmanagements Fortlaufende geschäftliche Rechtfertigung Jedes Projekt braucht einen Grund für seine Durchführung. Dieser Grund liefert die Rechtfertigung für den Start und damit auch für die Durchführung des Projekts. Der Grund ist aber nicht nur für den Projektstart besonders wichtig, sondern auch für den weiteren Projektverlauf. In jedem Projekt muss regelmäßig geprüft werden, ob die Grundlage für das Projekt und dessen Genehmigung weiterhin gültig ist. Seite 4

5 PRINCE2 fordert, dass die geschäftliche Rechtfertigung auch Business Case genannt zum Projektstart hinreichend bekannt und dokumentiert ist. Allerdings heißt dies nicht, dass der Business Case, wenn er einmal beschrieben wurde, nicht mehr geändert werden kann. Im Laufe eines Projektes können sich immer wieder Rahmenbedingungen ändern oder neue Aspekte in den Vordergrund rücken. Diese müssen fortlaufend begutachtet und das Projekt auf diese abgestimmt werden. Lernen aus Erfahrung Jedes Projekt ist einzigartig. Das bedeutet, dass die Beteiligten nicht einfach ein Projekt aus der Vergangenheit nehmen und das neue Projekt exakt genauso durchführen können. Dennoch gibt es in jedem Projekt Aspekte und Erfahrungen, die im weiteren Verlauf des Projekts oder auch in anderen Projekten hilfreich sein können. Dazu müssen sowohl negative als auch positive Erfahrungen dokumentiert werden, damit diese später verfügbar sind. PRINCE2 fordert diese Konservierung von Erfahrungen und den Rückgriff auf dieselben explizit ein. Bereits zu Projektstart sollen Erfahrungen aus anderen Projekten oder Umgebungen berücksichtigt werden. Während des Projektverlaufs wird immer wieder auf Erfahrungsberichte (sog. Lessons Learned ) gesetzt und zum Projektabschluss werden diese Lessons Learned noch einmal gesammelt für Folgeprojekte zur Verfügung gestellt. Definierte Rollen und Verantwortlichkeiten In einem Projekt arbeiten häufig Personen aus unterschiedlichsten Bereichen miteinander. Ein wichtiger Erfolgsfaktor für das Projekt ist, dass alle Projektmitarbeiterinnen und mitarbeiter genau wissen, was in dem Projekt von ihnen erwartet wird, was also ihre Aufgabe ist. Was für die Projektmitarbeiterinnen und mitarbeiter gilt, gilt aber genauso auch für das Projektmanagement. PRINCE2 definiert drei Parteien, die im Projektmanagement im sogenannten Lenkungsausschuss vertreten sein müssen. Mit dieser Forderung soll sichergestellt werden, dass die Interessen aller Projektbeteiligten (Stakeholder) gleichermaßen Gehör finden. Diese drei Parteien sind die Unternehmensvertreter, die Benutzervertreter und die Lieferantenvertreter. Die Unternehmensvertreter sind in erster Linie daran interessiert, dass das Projekt als Investition sinnvoll und zielgerichtet ist. Sie vertreten also eher die geschäftlichen Interessen. Die Benutzervertreter interessieren sich in erster Linie für den Einsatz der Projektergebnisse nach Abschluss des Projekts. Sie haben also primär ein Augenmerk auf die Nutzbarkeit der Ergebnisse. Die Lieferantenvertreter sind für die Bereitstellung des Know-hows und der benötigten Ressourcen für das Projekt zuständig. Sie können sowohl intern als auch extern besetzt sein. Steuern über Managementphasen PRINCE2 untergliedert ein Projekt in mindestens zwei Managementphasen. Diese Managementphasen dienen dazu, an definierten Entscheidungspunkten über den Projektfortschritt zu entscheiden. Grundlage dieser Entscheidung am Ende einer jeden Phase ist der aktuelle Projektstatus, der Business Case des Projekts und die aufgestellten weiteren Pläne. Anhand dieser Informationen kann bewertet werden, ob sich das Projekt und insbesondere die Weiterführung noch lohnt. Die Anzahl der Phasen kann in jedem Projekt frei gewählt werden. Voraussetzung ist, dass eine Projektinitiierungsphase und mindestens eine Durchführungsphase vorhanden ist. Die Anzahl der Phasen im Projekt sind ein Indiz für die Granularität der Steuerung. Je mehr Phasen im Projekt vorhanden sind, desto enger verläuft die Steuerung. Auf diese Weise kann das Unternehmens- bzw. Projektmanagement Aspekte wie Projektpriorisierung, Risiken und Komplexität in die Projektsteuerung mit einfließen lassen und den Planungshorizont überschaubar halten. Steuern nach dem Ausnahmeprinzip In Projekten, die nach PRINCE2 durchgeführt werden, wird das Prinzip Management by Exception angewendet. Nach diesem Prinzip steht jedem Projektbeteiligten ein definierter Handlungsspielraum zur Verfügung, in dem er oder sie frei entscheiden kann und soll. Dieser Handlungsspielraum bezieht sich auf die sechs Dimensionen Zeit, Kosten, Qualität, Umfang, Risiko und Nutzen. Einerseits werden so Entscheidungen auf einer bestimmten Ebene innerhalb zuvor definierter Toleranzen selbstständig getroffen. Andererseits wird aber die nächst höherer Ebene einbezogen, sobald absehbar ist, dass Abweichungen über die Toleranzen hinaus eintreten oder zu erwarten sind. Auf diese Weise werden die Ressourcen sehr effizient eingesetzt, Führungskräfte entlastet und Entscheidungen auf der Ebene gefällt, auf der sie sinnvollerweise zu treffen sind. Produktorientierung Eine der Kernforderungen in einem PRINCE2 Projekt ist, dass erfolgreiche Projekte immer ergebnisorientiert und nicht aktivitätsorientiert durchgeführt werden müssen. Die Ergebnisse des Projekts werden Produkte genannt. Ergebnis- oder Produktorientierung bedeutet, dass in einem Projekt zuerst geklärt wird, was erstellt werden bzw. zum Schluss herauskommen soll. Erst wenn das Was geregelt ist, wird geplant, wie diese Produkte erstellt werden können, welche Aktivitäten dafür also notwendig sind. PRINCE2 fordert, dass zu jedem Produkt klar definiert wird, wie es aussehen soll und wie die Vollständigkeit des jeweiligen Produkts geprüft werden kann. Solche Qualitätskriterien können beispielsweise in einer Produktbeschreibung neben weiteren Informationen wie Zweck, Zusammensetzung und Herkunft aufgeführt werden. Mittels hinreichend detailliert beschriebener Produktbeschreibungen kann sichergestellt werden, dass alle Projektbeteiligten ein einheitliches Verständnis von den Liefergegenständen haben und somit schleichende Zuwächse beim Lieferumfang oder Diskussionen um Produktabnahmen vermieden werden. Seite 5

6 Anpassen an die Projektumgebung Eine der wohl wichtigsten Prinzipien, die PRINCE2 mit sich bringt, ist das sogenannte Tailoring, das Anpassen der Methodik. PRINCE2 gibt kein starres Korsett als Methodik vor, sondern fordert explizit mit diesem Grundprinzip, dass die Methodik immer auf die jeweilige Projektsituation angepasst werden muss. PRINCE2 erhebt für sich den Anspruch, eine allgemeingültige Projektmanagementmethodik zu sein. Diese wird in der Regel nicht direkt auf die jeweils gegebene Umgebung anwendbar sein. Vielmehr ist es in der Regel notwendig, die Methodik beispielsweise auf bestehende Prozesse auszurichten und die Projektsteuerungsmittel in Umfang und Ausgestaltung auf die Projektgröße anzupassen. Durch Tailoring wird verhindert, dass die Methodik stur nach Lehrbuch durchgeführt wird. Allerdings muss dieses Tailoring aktiv angegangen werden, damit das Pendel nicht zu stark in die andere Richtung ausschlägt und die Methodik gar keine Anwendung mehr findet. Themen PRINCE2 bedient sich zur Befriedigung der sieben Grundprinzipien sogenannter Themen, die eines oder mehrere Grundprinzipien aufgreifen und konkretisieren. Zusammen mit den Prozessen (s. u.) geben sie ein rundes Bild der Methodik wieder. PRINCE2 fordert, dass alle sieben Themen in einem Projekt Anwendung finden und damit die sieben Grundprinzipien erfüllt werden. Da die Themen bei den weiteren Betrachtungen zur Kombination von klassischen und agilen Verfahren eine tragende Rolle spielen, sollen sie hier vorgestellt werden. Business Case Bereits bei der Vorstellung des Prinzips der fortlaufenden geschäftlichen Rechtfertigung wurde der Business Case eingeführt. Mit dem Prinzip wird gefordert, dass kein Projekt angegangen wird, dessen Durchführungsgrund nicht eindeutig geklärt ist. Dies geschieht in PRINCE2 Projekten (wie generell in Projekten) mittels eines Business Case. In einem Business Case werden Kosten und Nutzen eines Projekts gegenüber gestellt und auch Risiken betrachtet. Der Business Case wird zum Projektbeginn erstellt. Er stellt den Lackmustest eines Projekts für Veränderungen dar. Bei jeder Veränderung muss geprüft werden, ob der Business Case noch gültig ist, also die Projektziele unter den initialen Annahmen erreicht werden können. Natürlich kann sich der Business Case im Laufe eines Projekts auf Grund veränderter Rahmenbedingungen ebenfalls verändern. In diesem Fall ist der Business Case neu zu definieren und das Projekt gegen den neuen Business Case zu prüfen. Die wiederholte Prüfung des Projekts gegen den Business Case soll verhindern, dass ein Projekt zum Selbstzweck wird. Mit jedem Projekt wird ein bestimmter Zweck unter bestimmten Rahmenbedingungen verfolgt, der in dem Business Case festgehalten wird. Stellt sich im Laufe des Projekts heraus, dass der Zweck nicht mehr unter den angenommenen Bedingungen erfüllt werden kann, ist das Projekt grundsätzlich in Frage zu stellen und gegebenenfalls zu beenden. Organisation Eine effiziente Organisationsstruktur ist essentiell für ein erfolgreiches Projekt. In einer Organisationsstruktur wird festgelegt, wer für was in einem Projekt zuständig ist. Mit der Organisation wird das Grundprinzip der definierten Rollen und Verantwortlichkeiten bedient. Wie bei der Vorstellung des eben genannten Grundprinzips schon eingeführt, geht PRINCE2 von einem definierten Kunden-Lieferanten-Verhältnis aus. Das bedeutet, es gibt eine Partei, die Anforderungen an das Projektergebnis stellt und wahrscheinlich auch bezahlt, und eine Partei, die diese Anforderungen erfüllt und entsprechende Produkte liefert. Beide Parteien sind geeignet in die Projektorganisation zu integrieren und zusammenzuführen. Dazu ist es notwendig, nicht nur für klare Verantwortlichkeiten zu sorgen, sondern auch eine klare Kommunikationsstruktur und damit einen geordneten Informationsfluss zu definieren. PRINCE2 macht hierfür Vorschläge, die allerdings entsprechend des Tailorings auf die jeweiligen Gegebenheiten angepasst werden können und sollen. Qualität Das Thema Qualität wurde bereits mit dem Grundprinzip der Produktorientierung eingeführt. Damit lässt sich auch der erste Aspekt des Themas motivieren. Da PRINCE2 produktorientiert ist, muss sichergestellt werden, dass alle erstellten Produkte, seien es nun Management- oder Spezialistenprodukte (Projektzwischen- und Endergebnisse), eine vorher definierte Qualität erfüllen. Dies geschieht beispielsweise über die Qualitätskriterien in Produktbeschreibungen, die auch als Abnahmekriterien dienen können. Ein weiterer Aspekt der Qualität ist das Qualitätsmanagement. PRINCE2 gibt einige Hinweise, auf welche Weise Qualität mithilfe von Qualitätsplanung, -steuerung und sicherung über die Produkte hinaus in ein Projekt eingeplant werden kann. Da dieses Thema sehr umfangreich ist, sei hier auf die einschlägige Literatur verwiesen (siehe [3]). Der dritte Aspekt des Qualitätsthemas ist die kontinuierliche Verbesserung im Projekt und darüber hinaus. Mit diesem Aspekt wird ein weiteres Grundprinzip, das Prinzip Lernen aus Erfahrung, angesprochen. Bereits innerhalb des Projekts soll beispielsweise über regelmäßige Retrospektiven ein Verbesserungsprozess angestoßen bzw. unterstützt werden. Pläne Die Steuerung eines Projekts basiert in der Regel auf einem oder mehreren Plänen. Ein Plan ist dabei nicht nur eine Zeitskala mit einer Liste von Meilensteinen und Arbeitspaketen. Vielmehr ist ein Plan eine Dokumentation, die beschreibt wie, wann und von wem ein oder mehrere Ziele erreicht werden. Zu diesen Zielen gehören die Produkte des Projekts, Termine, Kosten, Qualität und Nutzen. [3] Ein Plan ist somit eine Simulation von dem, was in der Zukunft passieren sollte. Diese Simulation kann die Basis für die Betrachtung von Alternativen, Chancen und Risiken sein. Pläne dienen aber nicht nur der Beantwortung der Frage, was in der Zukunft passieren soll. Vielmehr bieten sie auch die Möglichkeit einer Vergleichsbasis für die Vergangenheit, um beispielsweise den Projektfortschritt zu beurteilen. Seite 6

7 Pläne adressieren mehrere PRINCE2 Grundprinzipien. Sie unterstützen grundlegend die fortlaufende geschäftliche Rechtfertigung. Zusätzlich sind sie ein Mittel, um Verantwortlichkeiten zu definieren und auch wie eingangs erwähnt zur Steuerung des Projekts. Risiken Jedes Projekt birgt gewisse Unsicherheiten, die sich beispielsweise in Annahmen manifestieren. Diese Unsicherheiten können sowohl positive als auch negative Einflüsse auf das Projekt haben. Bereits beim Business Case wurde darauf eingegangen, dass er auch die Projektrisiken berücksichtigen muss. Eine Risikobetrachtung ist essentiell für jedes Projekt und unabdingbar für den Projekterfolg. Nur wenn die Risiken im Projekt bekannt sind, ist man vor Überraschungen sicher. Risiken werden in der Regel über ein gezieltes Risikomanagement betrachtet. Ziel des Risikomanagements ist weniger, alle Risiken auszuschließen, als vielmehr, diese und deren potentiellen Folgen aufzuzeigen. Auf diese Weise soll sichergestellt werden, dass alle notwendigen Informationen bei einer Entscheidung vorliegen. Ein gezieltes Risikomanagement unterstützt das Prinzip der fortlaufenden geschäftlichen Rechtfertigung essentiell. Prozesse PRINCE2 ist, wie die Kapitelüberschrift schon vermuten lässt, prozessorientiert. Insgesamt definiert PRINCE2 sieben Prozesse, die sich sowohl mit der Vorbereitung als auch mit der Durchführung eines Projekts beschäftigen. In Abbildung 3 ist eine Übersicht über alle sieben Prozesse zu sehen. Hier soll noch einmal betont werden, dass nicht die Prozesse oder deren Dokumentation die Projektmanagementmethodik PRINCE2 ausmachen. Änderungen Kaum ein Projekt kommt ohne Veränderungen aus. Irgendwann kommt immer der Zeitpunkt, wo Änderungen an den ursprünglichen Anforderungen und Gegebenheiten auftreten. Dies lässt sich nicht verhindern, und das ist auch gar nicht das Ziel. Vielmehr bietet PRINCE2 einen geeigneten Ansatz zur Behandlung von Änderungen im Projekt. Änderungen haben oft Auswirkungen auf den Business Case und müssen in dessen Kontext betrachtet werden. Damit dies auch geschieht und Änderungen nicht unkontrolliert auf das Projekt eintreffen, bietet PRINCE2 Mechanismen zur Steuerung dieser Änderungen. Dieser Ansatz betrachtet Änderungen im Kontext des Business Case und stellt sicher, dass Änderungen weder ignoriert oder verloren gehen noch einfach durchgewunken werden. Sie sollen vielmehr von den Verantwortlichen freigegeben werden. Abbildung 3: PRINCE2 Prozessmodell PRINCE2-Konformität erreicht man durch die Beachtung und Einhaltung der sieben Grundprinzipien. Die sieben Prozesse stellen vielmehr einen Vorschlag dar, der auf langjähriger Erfahrung darüber basiert, wie ein Projekt auf Basis der Grundprinzipien durchgeführt werden kann. Eines der Grundprinzipien ist die Anpassung der Methodik (Tailoring). Diese Anpassung findet in der Regel hauptsächlich bei den Prozessen statt und ist häufig auch unabdingbar, um die Prozesse an die Projektumgebung anzupassen. Aus diesem Grund stehen die PRINCE2 Prozesse bei den weiteren Betrachtungen nicht im Vordergrund. Sie werden hier nur kurz und sicherlich nicht voll umfassend beschrieben. Eine umfassende Beschreibung ist in [3] zu finden. Fortschritt Damit überhaupt beurteilt werden kann, ob sich ein Projekt weiterhin lohnt, und damit die geschäftliche Rechtfertigung noch vorliegt, bedarf es einer Überwachung des Projektfortschritts. Unter Fortschritt wird der Vergleich der tatsächlich erbrachten Leistungen mit den Planzielen verstanden [3]. Der Fortschritt wird in der Regel für eine Managementebene durch die jeweils höhere bewertet. Hier greift das Grundprinzip Mangement by Exception. Jeder Managementebene werden gewisse Toleranzen gewährt, in denen eigenständig entschieden wird, ohne die jeweils höhere Ebene einzubeziehen. Bei der Betrachtung des Fortschritts wird nun von der jeweils höheren Ebene überprüft, ob die gesteckten Ziele innerhalb der genehmigten Toleranz erreicht wurden. Vorbereiten eines Projekts Bevor ein Projekt überhaupt starten kann, muss es geeignet vorbereitet werden. Das Ziel dieses Prozesses ist, zunächst zu klären, ob das Projekt überhaupt durchführbar ist, und sofern der Befund positiv ist, die Grundlage für die spätere Durchführung zu erarbeiten. Insbesondere werden hier in Form eines vorläufigen Business Case bereits erste Kosten-Nutzen- Betrachtungen angestellt und die Verantwortlichkeiten für den Projektstart geklärt. Initiieren eines Projekts Nachdem das Projekt hinreichend vorbereitet und zum Start freigegeben wurde, beginnt die Initiierungsphase. Hier werden nun die Ergebnisse aus der Vorbereitung, die bislang i. d. R. Entwurfscharakter hatten, konkretisiert und auf ein stabiles Fundament gestellt. Neben einigen organisatorischen Aspekten, wie beispielsweise der Besetzung von Rollen und der Zuteilung von Verantwortlichkeiten, wird in der Initiierungsphase unter anderen Seite 7

8 festgelegt, wie das gesamte Projekt organisiert und gesteuert wird, welche Projektergebnisse erwartet werden und wann und wie die gesamte Methodik auf die jeweiligen Gegebenheiten angepasst (Stichwort Tailoring) wird. Lenken eines Projekts Der Prozess Lenken eines Projekts erstreckt sich, wie in Abbildung 3 zu sehen war, über die gesamte Projektlaufzeit. Dieser Prozess dient in erster Linie dem Lenkungsausschuss dazu, seinen Beitrag zum Projekterfolg zu erbringen und seiner Verantwortung gerecht zu werden. Hier werden der Projektstart und auch der Abschluss genehmigt, sowie die einzelnen Phasenpläne freigegeben. Weiterhin dient der Prozess auch als Schnittstelle des Lenkungsausschusses zum Programm- oder Unternehmensmanagement. Nicht Bestandteil dieses Prozesses ist die Arbeit des Projektmanagers. Diese wird mit den folgenden Prozessen abgebildet. Steuern einer Phase Der Prozess Steuern einer Phase stellt das Kern- und Tagesgeschäft des Projektmanagers dar. In diesem Prozess werden die anstehenden Arbeiten koordiniert, Risiken und offene Punkte verwaltet, der Fortschritt erfasst und anfallende Berichte für den Lenkungsausschuss erstellt. Das Ziel des Prozesses ist, dafür zu sorgen, dass alle laufenden Aktivitäten im Projekt zielgerichtet sind. Managen eines Phasenübergangs Am Ende einer jeden Phase (Initiierungsphase und Durchführungsphasen) wird dieser Prozess angestoßen. Auch für diesen ist der Projektmanager verantwortlich. Ziel des Prozesses ist es, den Lenkungsausschuss zu jedem Phasenende mit ausreichenden Informationen zu versorgen, so dass über die Weiterführung des Projekts oder eventuelle Korrekturen entschieden werden kann. Ebenfalls wird spätestens innerhalb dieses Prozesses die nächste Phase feingeplant. Hier wird zudem noch einmal deutlich, dass der Grad der Steuerung durch den Lenkungsausschuss über die Anzahl der Phasen im Projekt beeinflusst wird. Ebenfalls Bestandteil ist die Retrospektive der vergangenen Phase, um aus Erfahrungen bereits in der nächste Phase zu profitieren. Abschließen eines Projekts Der letzte Prozess in einem PRINCE2 Projekt ist Abschließen eines Projekts. Hintergrund dieses Prozesses ist es, einen definierten Projektabschluss zu gewährleisten. Innerhalb des Prozesses werden die Projektergebnisse final abgenommen und der Projektverlauf mit der ursprünglichen Planung verglichen, um daraus beispielsweise Schlüsse für andere Projekte zu ziehen. Auch die Übergabe der Endprodukte z. B. an den Betrieb wird in diesem Prozess betrachtet. Kurz gesagt, sorgt dieser Prozess dafür, dass ein definiertes Projektende existiert und keine losen Enden übrig bleiben. Scrum Das Managementframework Scrum ist derzeit einer der präsenteren und häufig eingesetzten Vertreter in der Gruppe der agilen Methoden. Scrum besteht aus einem einfachen Satz von Regeln, Rollen, Prozessen und Werkzeugen und eignet sich auch sehr gut für den Einsatz in komplexen Projekten. Die Kernidee von Scrum besteht darin, den Auftraggeber von Beginn an aktiv in das Projekt einzubeziehen und ebenso frühzeitig wie regelmäßig funktionsfähige Anteile der Projektliefergegenstände bereitzustellen. Prozess Die Anforderungen des Projekts werden, wie in Abbildung 4 dargestellt, im sogenannten Product Backlog gesammelt, welcher während der gesamten Projektlaufzeit gepflegt wird. Die Anforderungen im Product Backlog werden alle priorisiert, um eine Reihenfolge der Bearbeitung im Projekt festzulegen. Managen der Produktlieferung Managen der Produktlieferung beschreibt die eigentliche Erstellung der Projektergebnisse. Der Prozess an sich ist sehr kompakt gehalten und macht keine Aussagen darüber, wie die Produkte zu erstellen sind. Lediglich die Schnittstelle zum Prozess Steuern einer Phase und damit die Schnittstelle zum Projektmanagement wird definiert. Hier wird beschrieben, welche Mindestinformationen die Arbeitsbeschreibung enthalten muss wie die Produktbeschreibungen inklusive der Qualitätskriterien. Aber auch Maßnahmen, die bei der Übergabe des fertigen Ergebnisses durchzuführen sind, werden empfohlen (z. B. Abnahmedokumentation, Qualitätsprüfungen). Dieser Prozess wird in der Regel vom Projektteam durchgeführt. Je nach Projektgröße kann ein Teammanager eingesetzt werden, der für diesen Prozess zuständig ist und als Schnittstelle zum Projektmanager fungiert. Bei kleineren Projekten übernimmt in der Regel der Projektmanager diese Funktion. Abbildung 4: Der Scrum Prozess Die Umsetzung der Projektziele findet in sogenannten Sprints statt. Diese werden im Rahmen von festgelegten Timeboxes mit bis zu 30 Tagen Dauer durchgeführt. Ein Projekt erstreckt sich über eine Reihe von Sprints. Jeder Sprint beginnt mit einem Planungsmeeting, in dem der Umfang des Sprints anhand des Sprintziels, des priorisierten Product Backlogs und des Aufwands der einzelnen Anforderungen festgelegt wird. Die für den Sprint aus dem Product Backlog entnommenen Anforderungen werden im Sprint Backlog festgehalten. Der Sprint Backlog definiert die Anforderungen für das Team im Rahmen des Sprints. Seite 8

9 Während des Sprints organisiert sich das Team selbst und verteilt die Aufgaben untereinander selbstständig. Täglich stattfindende Kurzmeetings, Daily Scrum genannt, geben dem Team die Möglichkeit über den Arbeitsfortschritt zu reflektieren, Probleme anzusprechen und die Arbeitsorganisation anzupassen. Wie diese im Detail auszusehen hat, ist nicht vorgegeben. Der Teammanager kann, solange er sich an die Vorgaben der Projektleitung hält, beliebige Methoden und Vorgehensmodelle für die Produkterstellung einsetzen. Dass sich PRINCE2 für die Kombination mit agilen Verfahren grundsätzlich eignet, hat bereits Keith Richards mit dem agilen DSDM Atern in [1] gezeigt. Am Ende eines Sprints stehen ein Review Meeting, in welchem das aktuelle Produktinkrement vorgestellt wird, und eine Sprint-Retrospektive, in welcher die Durchführung des Sprints besprochen wird. Scrum verzichtet auf eine tiefe Detailplanung zu Projektbeginn, wie man sie aus dem klassischen Projektmanagement kennt. Es wird lediglich eine Grobplanung mit einer Abfolge von Sprints vorgenommen. Die Phasen Analyse, Entwurf, Umsetzung und Test werden in jedem Sprint einzeln durchlaufen. Am Ende eines Sprints soll dem Kunden stets ein nutzbares Produkt präsentiert werden. Rollen Im Mittelpunkt von Scrum steht das selbstorganisierte Team. Das Team ist gemeinsam für die Aufwandschätzungen, die Aufgabenverteilungen und die Umsetzung der Anforderungen verantwortlich und zuständig. Um dem Team eine störungsfreie Arbeit zu ermöglichen, gibt es den Scrum Master, der als Methodenfachmann dafür sorgt, dass sich jeder an die Scrum- Regeln hält. Außerdem stellt der Scrum Master die Produktivität des Teams sicher, indem er Hürden, die das Team bei der Arbeit behindern würden, aus dem Weg räumt. Der Product Owner trägt die Verantwortung für das Produkt in Bezug auf Umfang, Release-Datum usw. Er pflegt den Product Backlog, indem er die Anforderungen der Auftraggeber sammelt, konsolidiert und priorisiert. Dadurch ist der Product Owner auch verantwortlich für den Nutzen und den Business Value (ROI) des Projekts. Im Review Meeting nimmt der Product Owner das Produktinkrement ab. PRINCE2 und Scrum Die Vorteile agiler Methoden insbesondere bei der Produktentwicklung liegen klar auf der Hand. Jedoch gibt es häufig Rahmenbedingungen, die ein rein agiles Vorgehen nicht zulassen. Insbesondere bei größeren Projekten wird es schwer vermittelbar sein, dass viel Geld für etwas ausgegeben wird, dass nicht durchgängig spezifiziert ist. Die Stärken agiler Vorgehensweisen lassen sich nur schwer in einem Geschäftsbericht präsentieren [4]. Auf den ersten Blick erscheinen PRINCE2 und Scrum aus zwei verschiedenen Welten zu kommen und nur schwer miteinander vereinbar zu sein. Beim zweiten Blick jedoch zeigt sich, dass beide Methoden nicht wenige Gemeinsamkeiten haben. Sie ergänzen sich sehr gut zu einem modernen Projektmanagementvorgehen, das sowohl klassisches als auch agiles Vorgehen unterstützt. PRINCE2 konzentriert sich primär auf das eigentliche Projektmanagement. Die Produkterstellung im eigentlichen Sinne wird im Prozess Managen der Produktlieferung gekapselt. In vielen Unternehmen sind Projektmanagementmethoden bereits eingeführt. Somit stehen Verfechter agiler Methoden oft vor der Herausforderung, zu zeigen, dass mit der Einführung agiler Verfahren die bereits etablierten Methoden und Schnittstellen nicht (gravierend) verändert werden müssen. Um beispielsweise mit PRINCE2 konform zu bleiben, müssen die Grundprinzipien eingehalten werden. Diese werden wie bereits erläutert durch die Themen umgesetzt. Deshalb wird die Integration von PRINCE2 und Scrum im Folgenden anhand dieser Themen und Grundprinzipien demonstriert. Business Case Gemäß des Grundprinzips der fortlaufenden geschäftlichen Rechtfertigung wird für jedes Projekt ein Business Case gefordert. In diesem Business Case wird die Durchführung des Projekts gerechtfertigt. Im Business Case wird dargelegt, inwieweit der Zeit- und Kostenaufwand im Hinblick auf den Nutzen gerechtfertigt ist. Aus ihm wird ersichtlich, welche Nutzen und somit Ergebnisse aus dem Investment von Zeit, Kosten und Ressourcen gezogen werden können. Klassischerweise wird die Kalkulation des Business Case ausgehend vom erwarteten Projektergebnis getrieben. Da es in jedem Projekt Annahmen und Unsicherheiten gibt, lässt sich der Business Case in der Regel nicht exakt berechnen. Diese Annahmen und Unsicherheiten spiegeln sich in Toleranzen wieder, die sich beispielsweise in Unterund Obergrenzen für Kosten, Zeiten etc. manifestieren. Oft lässt sich eben noch nicht genau vorhersagen, wie viel Zeit und Aufwand in die Bereitstellung eines definierten Projektergebnisses investiert werden muss. Übertragen auf das eingangs dargestellte Dreieck stellen also die Toleranzen die Bewegungsräume der drei Dimensionen (Kosten, Zeit, Umfang) dar. Wie bereits erläutert, wird bei Scrum bevorzugt der Umfang und weniger die Zeiten (Termine) oder Kosten geändert. Diese Forderungen im agilen Umfeld widersprechen aber keineswegs dem Prinzip der fortlaufenden geschäftlichen Rechtfertigung und der Idee eines Business Case. Lediglich der Betrachtungswinkel wird geändert. Scrum legt sehr viel Wert auf den eigentlichen Nutzen des Ergebnisses und geht schon von vorneherein davon aus, dass sich die Ansichten über den Nutzen und damit das Endergebnis des Projekts im Laufe des Projekts noch ändern werden. Damit der Business Case nun nicht mit jeder neuen oder geänderten Anforderung umgeschrieben werden muss, wird dieser Aspekt aktiv berücksichtigt, indem der Business Case mehr auf die Akzeptanz und den Nutzen des Endprodukts abhebt als beispielsweise auf Feature-Listen. Gleichzeitig bekommt man durch die Fixierung der eingesetzten Ressourcen und das Prinzip des Time-Boxing sehr genaue Vorhersagen für Zeit- und Ressourceneinsatz. Seite 9

10 Ein weiterer Aspekt, der bei der Berechnung des Business Case berücksichtigt werden sollte, ist die frühzeitige Nutzung von Zwischenergebnissen in Scrum. Durch die regelmäßige Auslieferung von verwendbaren Produktinkrementen beginnt die Berechnung des Nutzens nicht erst nach Fertigstellung des Endproduktes. Diese Nutzung von Zwischenergebnissen kann nachfolgende Projektschritte bereits (mit)finanzieren. Grundsätzlich spricht auch bei PRINCE2 nichts dagegen, Agilität progressiv auch auf höherer Ebene einzusetzen. Ein solcher Ansatz kann bereits vor der eigentlichen Projektinitiierung vorbereitet werden. In der Projektvorbereitung eines PRINCE2-Projekts wird der Business Case des Vorhabens entworfen. Organisation PRINCE2 geht beim Thema Organisation von einem definierten Kunden- Lieferanten-Verhältnis aus. Ein Kunde (oder auch Benutzer oder Anwender) definiert seine Anforderungen bzw. beschreibt sein gewünschtes Projektendergebnis in Form von Produktbeschreibungen. Der Lieferant wiederum ist für die Herstellung bzw. Lieferung der Produkte zuständig. Beide Parteien entsenden Vertreter in den Lenkungsausschuss des Projekts, der für das Projekt zuständig ist. Im Lenkungsausschuss sitzt ebenfalls der Auftraggeber, der letztendlich für das Projekt gesamtverantwortlich ist. Der Benutzervertreter ist weiterhin für die Definition der Anforderungen, die Abnahme der Produkte und die Überwachung des Business Cases zuständig. Weiterhin koordiniert er die Zusammenarbeit zwischen den eigentlichen Anwendern und dem Projektmanagementteam. Der Lieferantenvertreter wiederum ist für die Lieferung der Produkte zuständig, für Aufwandsschätzungen und Machbarkeitsaussagen und für die Bereitstellung der entsprechenden Ressourcen. Weiterhin gibt es einen definierten Projektmanager, der für den ordnungsgemäßen Ablauf des Projekts verantwortlich ist und im Auftrag des Lenkungsausschusses das Tagesgeschäft koordiniert. Für größere Projekte bietet PRINCE2 noch die weitere Rolle des Teammanagers an, der für die eigentliche Produkterstellung verantwortlich zeichnet und das Team führt. Eine mögliche Organisationsform wäre beispielsweise, den Benutzervertreter mit dem Product Owner gleichzusetzen und den Teammanager als Scrum Master einzusetzen, wie es unter anderem auch in [4] vorgeschlagen wird. Das Team wäre gemäß Scrum für die eigentliche Produktlieferung verantwortlich, würde aber einen Vertreter in der Rolle des Lieferantenvertreters in den Lenkungsausschuss entsenden. Auf diese Weise ergänzen sich die einzelnen Rollen aus Scrum und PRINCE2 vorteilhaft, ohne dass es zu Widersprüchen oder Lücken kommt. Planung Bei der Kombination von PRINCE2 und Scrum ist der Projektplan in besonderer Weise zu behandeln. Während ein klassischer Projektplan unter anderem die Zeitpunkte enthält, an denen ein bestimmtes Projektergebnis zu erwarten ist, ist das mit Scrum nicht mehr möglich. Das Potential von Scrum rührt unter anderem ja auch daher, dass Änderungen an den Anforderungen spätestens zum nächsten Sprint berücksichtigt werden und auch Änderungen der Priorisierung nach sich ziehen können. Zwar lässt sich mit Scrum sehr genau vorhersagen, wann ein Sprint beendet und damit eine Release-fähige Produktversion fertig sein wird, welchen Feature-Umfang dieses Release haben wird, steht endgültig aber erst nach dem Ende eines Sprints fest. Der Projektplan kann also demnach zwar im Detail die Dauer bzw. Fälligkeit einzelner Phasen, eventuelle Release-Termine, Termine für Reports etc. enthalten, die Produktentwicklungsplanung selbst jedoch muss nach Prioritätenliste erfolgen. Das ist der Philosophie von Scrum geschuldet, dem wenige Produktfeatures von definierter Qualität zu einem definierten Termin mehr wert sind als viele minderwertige Produktfeatures, die nicht vollumfänglich einsetzbar sind oder an den Kundenanforderungen vorbeigehen. Dem gegenübergestellt definiert Scrum zwar weniger Rollen, die Tätigkeitsfelder kommen jedoch größtenteils auch vor. Als Pendant zum Benutzervertreter definiert Scrum den Product Owner, der nahezu die gleichen Aufgaben wie ersterer hat. Dafür kennt Scrum keinen definierten Lieferantenvertreter. Dessen Aufgaben und Verantwortlichkeiten übernimmt das Team. Ebenfalls gibt es bei Scrum keinen definierten Projektleiter oder manager. Seine Aufgaben sind auf die drei Rollen Scrum Master, Product Owner und Team verteilt. Wie bereits beim Thema Planung vorgestellt, bietet es sich an, Scrum primär bei der Produkterstellung einzusetzen und PRINCE2 als Managementüberbau darüber anzusiedeln. Klar wird damit, dass es in der Regel weiterhin einen Lenkungsausschuss und einen Projektmanager geben muss, die die etablierten Schnittstellen im Unternehmen bedienen können. Abbildung 5: PRINCE2 und Scrum mögliche Ausprägung Da PRINCE2 einen hierarchischen Planungsansatz vorschlägt, bestehend aus Managementphasen auf oberster Ebene bis hinunter zu Arbeitspaketen, Scrum aber nur Iterationen vorgibt, stellt sich natürlich die Frage, auf welcher Ebene eben genau diese Iterationen angesiedelt werden können. Ein Ansatz, der gut mit der Organisation und den Prozessen harmoniert, ist in Abbildung 5 dargestellt. Hierbei wird eine beliebige Anzahl an Iterationen in eine Managementphase aus PRINCE2 eingebettet. Seite 10

11 Eine Managementphase könnte dabei beispielsweise ein Software-Release darstellen, auf das mittels mehrerer Iterationen hingearbeitet wird. Scrum definiert zwar, dass jede Iteration Release-fähig sein muss, schreibt aber nicht vor, dass die Iteration dann auch als Release freigegeben wird. Bei diesem Ansatz können die einzelnen Iterationen in PRINCE2 als Arbeitspakete abgebildet und die Anforderungen in Form von Produktbeschreibungen übergeben werden. Diese Form der Integration hat auch positive Effekte auf die Zusammenführung der Prozesse, wie im folgenden Abschnitt gezeigt wird. Auf diese Weise erhält man eine Sprintplanung auf Arbeitspaketebene nach Scrum, die sehr gut mit den bekannten Teamplänen aus PRINCE2 harmonisieren, und eine Masterplanung auf Phasenebene (oder Release-Ebene) nach PRINCE2. Prozesse Sowohl PRINCE2 als auch Scrum bringen von Haus aus definierte Prozesse mit. Während PRINCE2 sich bei den Prozessen primär auf die des Projektmanagements fokussiert und sich bei der eigentlichen Produktlieferung mehr oder weniger auf die Schnittstellen konzentriert, gibt Scrum einen klaren Prozess für die Produktlieferung vor. Da ist es naheliegend, beide Prozesswelten so miteinander zu koppeln, dass der Scrum-Prozess auf Ebene der Produktlieferung in die PRINCE2 Prozesslandkarte eingebaut wird (siehe Abbildung 6). Damit erreicht man, dass das agile Vorgehen nach Scrum vom Team getrieben wird. Das eigentliche Projektmanagement in der Art, wie es PRINCE2 vorschlägt, muss im Zweifelsfall im Rahmen des Tailoring nur minimal angepasst werden. Schnittstellen zum Management (Lenkungsausschuss) bleiben nahezu unberührt. Risikomanagement Klassischer Weise ist Risikomanagement in erster Linie Aufgabe des Projektmanagers. Er wird sich jedoch nicht nur auf seine eigene Wahrnehmung und Erfahrung verlassen, sondern auch auf die Mitwirkung aller Projektbeteiligten stützen. PRINCE2 definiert für das Risikomanagement einen eigenen Prozess, der stark an das Framework Management of Risk der OGC angelehnt ist (siehe [6]). Risikomanagement in Scrum ist in der Verantwortlichkeit auf die einzelnen Rollen aufgeteilt. In Scrum sind sowohl Product Owner als auch Teammitglieder und Scrum Master für das Risikomanagement in ihren jeweiligen Bereichen verantwortlich. Kombiniert man nun beides, so empfiehlt es sich, die Gesamtverantwortung für das Risikomanagement beim Projektmanager zu belassen. Alle weiteren Projektbeteiligten arbeiten ihm zu und unterstützen ihn entsprechend ihrer Kompetenzen. Qualität Das Thema Qualität steht sowohl bei Scrum als auch bei PRINCE2 hoch im Kurs. Beim Thema Qualität kann man nach der Qualität im Kleinen und der Qualität im Großen (bzw. im Gesamten) unterscheiden. Scrum konzentriert sich besonders auf die Qualität im Kleinen. Vor Beginn der ersten Iteration wird bei Scrum empfohlen, gemeinsam im Team festzulegen, wann eine Aufgabe komplett fertiggestellt ist und was hierfür von den einzelnen Teammitgliedern getan werden muss (Definition of Done). Wie bereits beschrieben werden die Ergebnisse einer jeden Iteration intensiv getestet, auf die Einhaltung der Definition of Done und auf die Einhaltung der Anforderungen geprüft. Dadurch wird sichergestellt, dass auch das Gesamtergebnis, das inkrementell entsteht, von hoher Qualität ist. Aus qualitativ hochwertigen Einzelergebnissen entsteht somit auch ein qualitativ hochwertiges Gesamtergebnis. Man kann hier auch von konvergierender Qualität sprechen, da mit der Anzahl der Iterationen auch die Qualität des Endergebnisses immer besser wird. Abbildung 6: Prozesssicht Bei dieser Art der Integration darf allerdings nicht unberücksichtigt bleiben, dass die Kommunikation auf Team-Ebene ein Stückweit informeller werden kann. Sind die Team-Mitarbeiter eine solche Kommunikation jedoch nicht gewohnt, kann dies einen Umstellungs- und Lernprozess für die Team-Mitarbeiter zur Folge haben. PRINCE2 geht eher den Ansatz der vorausschauenden Qualitätsplanung. Bereits zu Projektbeginn werden die konkreten Qualitätsmaßnahmen geplant und die Projektplanung mit aufgenommen. Im Zuge der produktbasierten Planung werden die Qualitätskriterien für jeden Liefergegenstand festgelegt. Diese werden jeweils zum Ende einer Produktlieferungsphase überprüft. Hierin unterscheiden sich PRINCE2 und Scrum nicht. Änderungen Der sicherlich augenfälligste Unterschied beider Vorgehensweisen ist der Umgang mit Änderungen. Wie alle agilen Vorgehen geht auch Scrum davon aus, dass Änderungen im Laufe eine Projektes selbstverständlich sind. Der gesamte Prozess ist darauf ausgelegt, mit diesen Änderungen umzugehen und sie möglichst schnell und effizient zu berücksichtigen. Damit einher geht auch eine Anpassung des Steuerungsgrads insbesondere für den Projektmanager. Ist eine Iteration erst einmal gestartet, so gibt es wenig bis keine Einflussmöglichkeiten seitens des Projektmanagers auf die eigentliche Umsetzung. PRINCE2 ist da eher klassisch orientiert. Über einen eigenen Prozess werden Änderungen behandelt. Sie werden standardmäßig eher als Ausnahme denn als Regel gesehen. Trotzdem ist PRINCE2 so flexibel, dass auch eine Änderungsbehandlung à la Scrum möglich ist. Seite 11

12 Bei Scrum werden die Änderungen in erster Linie vom Product Owner verwaltet und in den Product Backlogs priorisiert eingestellt. Bei PRINCE2 werden Änderungen, die außerhalb der Entscheidungskompetenz des Projektleiters liegen, vom Lenkungsausschuss entschieden. Wird die oben unter Organisation vorgestellte Variante des Rollenmappings verwendet, nach der der Product Owner mit dem Benutzervertreter gleichgesetzt wird, so ist der Product Owner auch Mitglied des Lenkungsausschusses. Somit kann er die Entscheidungen über anstehende Änderungen direkt beeinflussen. Das widerspricht keineswegs der Philosophie von Scrum. Da Scrum keine Vorgaben macht, nach welchen Kriterien der Product Owner die Änderungen bewertet und mit wem er sich abzustimmen hat, kann auch das beschriebene Verfahren im Einklang mit PRINCE2 genutzt werden. Fortschritt und Reporting Bei Scrum gibt es für die Überwachung des Fortschritts zwei Instrumente. Der Fortschritt innerhalb einer Iteration lässt sich mittels eins Sprint- Burndown-Charts ermitteln. Der Gesamtprojektfortschritt kann über den Projekt-Burndown-Chart ermittelt werden, der auch die Restaufwände aus dem Produkt-Backlog indiziert. Da Scrum mit möglichst gleichbleibenden Teamgrößen arbeitet und Time-Boxing eingesetzt wird, treten Ressourcenund Zeitaspekte beim Controlling eher in den Hintergrund. Dies ist auch bei der Kombination von PRINCE2 und Scrum zu berücksichtigen. Bereits bei der Projektinitiierung müssen die Rahmenparameter für ein regelmäßiges und adäquates Reporting bestimmt werden. Dabei sind die genannten Aspekte zu berücksichtigen. Kontinuierliche Verbesserung Ein Aspekt, der mit der Überarbeitung von PRINCE2 im Jahr 2009 mehr Gewicht bekommen hat, ist die kontinuierliche Verbesserung (Grundprinzip Lernen aus Erfahrung ). Dieser Aspekt manifestiert sich bei PRINCE2 in zwei Bereichen: Zum einen fordert PRINCE2 ein, das bei der Projektvorbereitung und -initialisierung auf die Erfahrungen bereits durchgeführter Projekte zurückgegriffen wird. Damit geht natürlich einher, dass positive als auch negative Erfahrungen in Projekten dokumentiert und auch verfügbar gemacht werden. Zum anderen wird mindestens zum Ende einer jeden Phase die Dokumentation von Lessons Learned eingefordert. Auf diese Weise soll gewährleistet werden, dass Erfahrungen aus den Phasen eines Projekts in den folgenden bereits berücksichtigt werden. In der etwas älteren Version von PRINCE2 (2005) wurde die Dokumentation der Lessons Learned nur zum Ende eines Projekts durchgeführt. Fazit Agile Vorgehensweisen in Projekten müssen nicht zwangsläufig den hergebrachten Projektmanagement-Verfahren widersprechen. Am Beispiel von PRINCE2 und Scrum wurde gezeigt, dass beide Methoden nicht nur mit wenig Aufwand kombiniert werden können, sondern sich auch gut ergänzen. Es wurde anhand der Grundprinzipien und Themen von PRINCE2 dargestellt, wie sich Scrum mit PRINCE2 kombinieren lässt, ohne dass die Prinzipien der klassischen Methode verletzt werden oder Scrum zu sehr verbogen werden muss. Oftmals kommt es nur auf die richtige Kombination von Werkzeugen und Methoden an, um ein bestehendes Problem zufriedenstellend zu lösen. Literatur [1] Richards, Keith: Agile Project Management: Running PRINCE2 projects with DSDM Atern. The Stationery Office (TSO), London, 2007 [2] Oestereich, Bernd und Weiss, Christian: APM - Agiles Projektmanagement. dpunkt.verlag, Heidelberg, 2008 [3] Office of Government Commerce (OGC): Erfolgreiche Projekte managen mit PRINCE2. s.l The Stationery Office (TSO), London, 2009 [4] Müller, Thomas: Welcome to Reality! Agil vs. Klassisch. OBJEKTSpektrum, Sonderbeilage Agilität, Troisdorf, 2010 [5] Kent Beck, Mike Beedle, et al.: [6] Office of Government Commerce (OGC): Management of Risk: Guidance for Practitioners. The Stationery Office (TSO), London, 2007 Auch bei Scrum wird die kontinuierliche Verbesserung groß geschrieben. Jedoch ist sie bei Scrum viel stärker präsent und in den Prozess eingebettet als bei PRINCE2. Während PRINCE2 im äußersten Fall mit einer Lessons- Learned-Runde am Ende der Ausführungsphase auskommt, wird bei Scrum nach jedem Sprint eine Retrospektive der Iteration durchgeführt. Damit kann Scrum extrem schnell auf notwendige Veränderungen noch innerhalb des aktuellen Projekts und der aktuellen Projektphase reagieren. In der Kombination mit PRINCE2 bleibt die hohe Taktrate der Retrospektiven erhalten. Sie ersetzen bzw. ergänzen die bekannten Lessons Learned aus PRINCE2. Seite 12

13 Über OPITZ CONSULTING Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Unser Leistungsspektrum umfasst IT- Strategieberatung, individuelle Anwendungsentwicklung, System- Integration, Prozessautomatisierung, Business Intelligence, Betriebsunterstützung der laufenden Systeme sowie Aus- und Weiterbildung im hauseigenen Schulungszentrum. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. OPITZ CONSULTING wurde 1990 gegründet und beschäftigt heute an zehn Standorten mehr als 400 Mitarbeiter. Zu unserem Kundenkreis zählen ¾ der DAX30-Unternehmen sowie branchenübergreifend mehr als 600 bedeutende Mittelstandsunternehmen. Folgen Sie uns: youtube.com/opitzconsulting xing.com/net/opitzconsulting Seite 13

Klassisches Projektmanagement und agil

Klassisches Projektmanagement und agil Klassisches Projektmanagement und agil (K)ein Widerspruch!? OPITZ CONSULTING GmbH 2011 Seite 1 Klassisches Projektmanagement und agil (K)ein Widerspruch!? Dr. Andreas Wagener, Project Manager OPITZ CONSULTING

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Was ist PRINCE2 und was nicht?

Was ist PRINCE2 und was nicht? Was ist PRINCE2 und was nicht? Vortrag zur Projektmanagement Methode PRINCE2 beim 34. Meeting der Local Group Hamburg des PMI Frankfurt Chapter e.v. Referent: Marco Ramm (Ramm Consulting) Fr. 17.09.2010

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt Scrum undprojektmanagement à la GPM Markus Schramm compeople AG Frankfurt GPM scrum ed GPM, Scrum, warum? Projektablauf koordinieren Einheitliches Vorgehen Gemeinsames Verständnis Gemeinsame Sprache Freestyle

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA PM WBS Sprint Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA Über den Vortragenden IT-Leiter der Austrian Gaming Industries (Novomatic Group of Companies) MBA in

Mehr

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Raphael Leiteritz, raphael@leiteritz.com, 22. April 2002 1 Inhalt 1 Was

Mehr

Management großer Projekte Ein modellbasierter Ansatz

Management großer Projekte Ein modellbasierter Ansatz Management großer Projekte Ein modellbasierter Ansatz Dr. Dehla Sokenou Herausforderungen des Projektmanagements Projekt Initialisierung Aufgaben sinnvoll planen/partitionieren Projekt Monitoring Arbeitsergebnisse/Status

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Inhalt 1. Was ist Scrum und wofür wird es

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH

Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH Was ist ein Projekt? Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Unternehmensberatung H&D GmbH AFCEA Mittagsforum M. Sc. Dipl. Ing. (FH) Matthias Brechmann Agenda Unternehmensberatung H&D GmbH Anforderungen

Mehr

Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH

Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH Strukturiertes Projektmanagement nach PRINCE2! Frank Steinseifer UWS Business Solutions GmbH Was ist ein Projekt? Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

PRINCE2 2009 Edition Auf einen Blick

PRINCE2 2009 Edition Auf einen Blick PRINCE2 2009 Edition Auf einen Blick Definierte Rollen und Verantwortlichkeiten Aus Erfahrung lernen Fortlaufende geschäftliche Rechtfertigung Steuern über Managementphasen Steuern nach dem Ausnahmeprinzip

Mehr

Agile Softwareverträge

Agile Softwareverträge Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

Mehr

Projektmanagement mit PRINCE2 ein Schnappschuß

Projektmanagement mit PRINCE2 ein Schnappschuß Projektmanagement mit PRINCE2 ein Schnappschuß Peter Siepermann Copyright 2009 by Peter Siepermann 2 Inhalt PRINCE2 Einführung PRINCE2 Historisch PRINCE2 das Prozeßmodell Literatur Bewertung. 3 Einführung

Mehr

5.3.2 Projektstrukturplan

5.3.2 Projektstrukturplan 5.3.2 Der ist eine der wichtigsten Planungs- und Controllingmethoden und das zentrale Kommunikationsinstrument im Projekt. Er bildet die Basis für sämtliche weitere Projektmanagement- Pläne sowie für die

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

Mehr

Was ist PRINCE2, wenn es kein. milestone consultancy gmbh prince2.milestone.at

Was ist PRINCE2, wenn es kein. milestone consultancy gmbh prince2.milestone.at Was ist PRINCE2, wenn es kein Computerspiel ist? Hans Peter Ritt milestone consultancy gmbh il t In drei Abschnitten zeigen wir Ihnen die Grundzüge der weltweit meist verbreiteten Projektmanagement Methodologie:

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

Inhaltsverzeichnis Projektmanagement und PRINCE2 Über dieses Buch Projektmanagement PRINCE2-Grundlagen PRINCE2 im Überblick

Inhaltsverzeichnis Projektmanagement und PRINCE2 Über dieses Buch Projektmanagement PRINCE2-Grundlagen PRINCE2 im Überblick Inhaltsverzeichnis Projektmanagement und PRINCE2... 11 Über dieses Buch... 13 1 Projektmanagement... 15 1.1 Was ist ein Projekt?... 16 1.2 Was bedeutet Projektmanagement?... 18 1.2.1 Erfolgreiches Projektmanagement...

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Vortrag PMI Chapter Frankfurt, Eschborn am 7. April 2015 00. Agenda Agenda 1. Projektmanagement 2. Probleme und Erkenntnisse

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

oose. Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie

oose. Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie München, 06.05.2009 Markus Wittwer, oose GmbH 2009 by de GmbH Markus Wittwer Berater und Trainer Coach für agile Projekte

Mehr

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen Agile Prozessverbesserung Im Sprint zu besseren Prozessen Ziel und Agenda Ziel: Wir wollen zeigen, wie Prozesse durch den Einsatz einer agilen Vorgehensweise noch projektfreundlicher verbessert werden

Mehr

Agiles Projektmanagement

Agiles Projektmanagement Agiles Projektmanagement A B U S I N E S S P E R S P E C T I V E Christian Setzwein Agenda Rahmenbedingungen für Projekte Der Umgang mit Unsicherheit im klassischen PM Agiles PM: Techniken, Prinzipien,

Mehr

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

Mehr

POCKET POWER. Projektmanagement. 3. Auflage

POCKET POWER. Projektmanagement. 3. Auflage POCKET POWER Projektmanagement 3. Auflage 3 Inhalt 1 Einleitung.................................... 5 2 Grundlagen des Projektmanagements................... 8 2.1 Projektdefinition..............................

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Grundlagen der Web-Entwicklung Wintersemester 2009/2010 Lösung zu Aufgabenblatt 9

Grundlagen der Web-Entwicklung Wintersemester 2009/2010 Lösung zu Aufgabenblatt 9 Zentrum für Datenverarbeitung WSI Arbeitsgruppe Informationsdienste Prof. Dr. Thomas Walter Grundlagen der Web-Entwicklung Wintersemester 2009/2010 Lösung zu Aufgabenblatt 9 26. Der technische Produktentwicklungszyklus

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Seminar Softwareentwicklung in der Wissenschaft

Seminar Softwareentwicklung in der Wissenschaft Seminar Softwareentwicklung in der Wissenschaft Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Betreuer: Christian

Mehr

Toolset Projektmanagement

Toolset Projektmanagement Toolset Projektmanagement» praxisnah, flexibel, einfach «Kirchner + Robrecht GmbH management consultants: info@kirchner-robrecht.de; www. kirchner-robrecht.de Büro Frankfurt: Borsigallee 12, 60388 Frankfurt,

Mehr

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG Über uns... Carsten Sahling Leitung GeschäGsfeld Agil Cer3fied Scrum Professional Projektmanagement- Fachmann Level

Mehr

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer Definition 2 Was ist Scrum? Scrum ist ein schlanker, agiler Prozess für Projektmanagement u. a. in der Softwareentwicklung. Woraus besteht Scrum? Einfache Regeln Wenige Rollen Mehrere Meetings Einige Artefakte

Mehr

Soft Skills als Erfolgsfaktoren im anforderungsorientierten, agilen Projektmanagement am Beispiel der IT- Softwareentwicklung

Soft Skills als Erfolgsfaktoren im anforderungsorientierten, agilen Projektmanagement am Beispiel der IT- Softwareentwicklung Soft Skills als Erfolgsfaktoren im anforderungsorientierten, agilen Projektmanagement am Beispiel der IT- Softwareentwicklung Moderatorin: Sabine Bernecker- Bendixen sof- IT & Personal Best! www.sof- it.de

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Saarbrücker Reihe Projekt Management an der Scheer Management Academy Praxisbericht: Projektmanagement mit PRINCE2 und agilen Elementen

Saarbrücker Reihe Projekt Management an der Scheer Management Academy Praxisbericht: Projektmanagement mit PRINCE2 und agilen Elementen Saarbrücker Reihe Projekt Management an der Scheer Management Academy Praxisbericht: Projektmanagement mit PRINCE2 und agilen Elementen Markus H. Götz, PMP Agenda Projekt Zentrale Leitstelle Polizei Thüringen

Mehr

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006 Überleben mit Scrum Andrea Schulz Hintergrund Projektmanager, Scrummaster, SW-Entwickler Siemens Healthcare Webbasierte Software Produkte (Releases als Projekte) Teilweise Medizinprodukt Scrum seit 2006

Mehr

Initiierung von Projekten. CINCIOGLU Ayten SAHIN Sümeyye Selcen

Initiierung von Projekten. CINCIOGLU Ayten SAHIN Sümeyye Selcen Initiierung von Projekten CINCIOGLU Ayten SAHIN Sümeyye Selcen 1 Übersicht Initiierungsphase Projekt-Lebenszyklus Kriterien für Projektplanung Business Case Erfolgskriterien und Aufbau des Business Case

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs IT-Projektmanagement bei basecom Manuel Wortmann, Patrick Rolefs Vorstellrunde Mein Name ist, ich bin Jahre alt und mache meine Ausbildung bei. Übersicht wir sprechen internet Wasserfall - schön linear

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Bernd Oestereich (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Christian Weiss (Geschäftsführer) Copyright by oose GmbH 2006 Das Wasserfallmodell ein historisches Mißverständnis. Der Wasserfallprozess-

Mehr

Projektmanagement Basistraining

Projektmanagement Basistraining Projektmanagement Basistraining adensio GmbH Kaiser-Joseph-Straße 244 79098 Freiburg info@adensio.com www.adensio.com +49 761 2024192-0 24.07.2015 PM Basistraining by adensio 1 Inhalte Standard 2-Tage

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

Mehr

Kapitel 2: Projektmanagement Umsetzung

Kapitel 2: Projektmanagement Umsetzung 1. Projektmanagement-System 2. Projektphasen 3. Aufbauorganisation 4. Menschen im Projekt und ihre Rollen 5. Excurs: Gruppendynamik 6. Methoden und Werkzeuge Dr. Ulrich Meyer 22 Kapitel 2: PM-Umsetzung

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

PRINCE2 -eine kompakte

PRINCE2 -eine kompakte PRINCE2 -eine kompakte Vorstellung Jürgen Lackinger München, 12. März 2012 PRINCE2 is a registered trade mark of the Cabinet Office Agenda Vorstellung Was ist PRINCE2? Wie funktioniert PRINCE2? Pause Einordnung

Mehr

Zielvereinbarung. Team JAMT.

Zielvereinbarung. Team JAMT. Ziele des Projektes. Wer benötigt das Ergebnis des Softwareprojektes? Gruppenprozessleiter, welche keine Expertise auf dem Gebiet der Gruppenprozesserstellung haben Teams, die computergestützte Gruppenarbeit

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

PRINCE2 Zertifizierung & Best Practices. In dieser Rubrik stellen wir Ihnen unser Ausbildungsangebot rund um PRINCE2 und MSP vor.

PRINCE2 Zertifizierung & Best Practices. In dieser Rubrik stellen wir Ihnen unser Ausbildungsangebot rund um PRINCE2 und MSP vor. PRINCE2 Zertifizierung & Best Practices In dieser Rubrik stellen wir Ihnen unser Ausbildungsangebot rund um PRINCE2 und MSP vor. Triple Constraint ist Affiliate der Insights International B. V. und somit

Mehr

Der Grüne Faden des Projektmanagements

Der Grüne Faden des Projektmanagements Behrens Projektmanagement GmbH Hasenberg 6 35041 Marburg Tel.: 06421 / 294 93 26 E-Mail: info@behrens-pm.de Der Grüne Faden des Projektmanagements Planungsphase Die Weichen für ein erfolgreiches Projekt

Mehr

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit.

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit. Mi 2.3 Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases Tom Krauß Agenda Motivation Use Case orientiertes Projektmanagement Grundsätzliche Idee Variationsmöglichkeiten Integration in

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Organisatorische Einbindung eines Risikomanagementsystems in mittelständische Unternehmen

Organisatorische Einbindung eines Risikomanagementsystems in mittelständische Unternehmen Organisatorische Einbindung eines Risikomanagementsystems März 2002 Andreas Henking www.risk-sim.de 1 Einleitung Wichtiger Erfolgsfaktor bei der Einführung von Risikomanagementsystemen ist die richtige

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Lehrplan: Projektmanagement

Lehrplan: Projektmanagement Lehrplan: Projektmanagement Tobias Brückmann Volker Gruhn Gliederung 1 Grundlagen der industriellen So?ware Entwicklung 2 Grundprinzipien und Aufgaben im Projektmanagement 3 Stakeholder- Management 4 Ziel-

Mehr

Grundprinzipien der agilen Softwareentwicklung

Grundprinzipien der agilen Softwareentwicklung Grundprinzipien der agilen Softwareentwicklung Marie Claire Dzukou 38539 Natali Brozmann 40464 Wintersemester 14/15 1 Inhaltsverzeichnis 1 Agile Softwareentwicklung 3 2 Entstehung der agilen Softwareentwicklung

Mehr

Teamaufstellung - Zwischen Dream und Nightmare

Teamaufstellung - Zwischen Dream und Nightmare Teamaufstellung - Zwischen Dream und Nightmare Vom Versuch aus einem Referat ein Scrum-Team zu machen Michael Schäfer Unterföhring, September 2011 Inhalt 1 2 3 4 5 6 Warum Scrum? So haben wir begonnen

Mehr

Seminar: ITIL Service Capability Stream Modul Release, Control & Validation Prince II Foundation

Seminar: ITIL Service Capability Stream Modul Release, Control & Validation Prince II Foundation Seminar: ITIL Service Capability Stream Modul Release, Control & Validation Prince II Foundation Block I - ITIL Service Capability Stream Modul Release, Control & Validation Ziele des Seminars: Sie lernen

Mehr