ein ordnungsrahmen€¦ · design test abnahme integrations-test spezifi-kation verifizierung...

Wissen 55

projektManagementaktuell | ausgabe 4.2016

Agiles Projektmanagement, wie Scrum, und traditionelle Vorgehensmodelle, wie das Was-serfall- und das V-Modell, sind in der Litera- tur gut beschrieben und werden in der Praxis seit Langem eingesetzt. Neuerdings erfolgt die Anwendung agiler und traditioneller Vor-gehensmodelle immer häufiger in Kombina- tion als sogenanntes hybrides Projektma- nagement. Für hybride Vorgehensmodelle gibt es bisher allerdings keine geschlossene Form der Darstellung.In diesem Beitrag wird ein Ordnungsrahmen aus Prozessen, Methoden und Werkzeugen sowie Rollen vorgestellt, der sowohl agile als auch traditionelle Vorgehensmodelle berück-sichtigt und dabei hilft, unternehmens- oder vorhabensindividuelle hybride Vorgehens- modelle zu konstruieren.

Traditionelle Vorgehensmodelle wie das Was- serfall- und das V-Modell bestimmten über viele Jahre das Projektmanagement und sind auch heute noch in vielen Projekten erste Wahl. Sie sind meist sequenziell aufgebaut und bilden die Grundlage für wichtige internationale Standards im Projektmanagement. Viele traditionelle Vorge-hensmodelle haben ihren Ursprung in der Mitte des 20. Jahrhunderts, als im technologischen Wettlauf zwischen Ost und West ambitionierte Vorhaben wie beispielsweise Raumfahrtprojekte effizient durchgeführt werden sollten. Auch heute schätzen noch viele Projektmanager die klaren Strukturen der Vorgehensmodelle und integrierte Mechanismen zur Qualitätssicherung, wie die geordneten Phasenübergänge beim Wasserfall-modell oder die Verifizierung und Validierung beim V-Modell.Ende des 20. Jahrhunderts fanden sich dann erste agile Ansätze, die den Kunden ins Zentrum

stellten, inkrementelles Vorgehen propagierten und eigenverantwortlich arbeitende Teams ein-setzten. 2001 mündeten diese Ideen in die Doku-mentation des agilen Manifests, das • Individuen und Interaktionen über Prozesse

und Werkzeuge,

• funktionierende Software über eine umfas-sende Dokumentation,

• Zusammenarbeit mit dem Kunden über Ver-tragsverhandlungen und

• das Reagieren auf Veränderungen über die Befolgung eines Plans

stellte [1]. Schnell kristallisierten sich konkrete Vorgehensmodelle, Abläufe, Strukturen und Rol-len heraus, wie diese Ideen in der Praxis umzu-setzen sind. Heute sind Scrum und Kanban wich-tige Vertreter agilen Projektmanagements. Gerade junge Unternehmen, aber auch dynami-sche, meist softwarelastige Projekte in größeren Unternehmen setzen gerne auf agiles Projekt- management und stoßen damit immer wieder an Grenzen bei der Zusammenarbeit mit traditionell arbeitenden Projekten von Lieferanten und Pro-jektpartnern. Und auch wenn es Stimmen gibt, die agiles Vorgehen für alle Projekte einsetzbar halten, gibt es Konstellationen, in denen viele der Stärken agilen Vorgehens nicht zum Tragen kom-men. Eine bekannte Übersicht von Boehm und Turner [2] illustriert die Eignung agiler und tradi-tioneller (plangetriebener) Vorgehen in Abhängig-keit von bestimmten Parametern (Abb. 1).

Motivation

Was geschieht nun aber, wenn es sowohl Gründe für agiles als auch für traditionelles, plange- triebenes Vorgehen gibt? Wie sollte ein Vorge- hensmodell aussehen, bei dem große verteilte Teams an sicherheitskritischen Anwendungen mit hohem Gefährdungspotenzial (beispielsweise einem Medizinprodukt), aber sehr volatilen An- forderungen arbeiten? Selbstverständlich kann ein solches Projekt bei entsprechender Sorgfalt grundsätzlich sowohl agil als auch traditionell durchgeführt werden, was aber vermutlich nicht

Ein Ordnungsrahmenfür adaptives hybrides Projektmanagementautoren: Holger Timinger, Christian seel

>> Für eilige LeserUnter hybridem Projektmanagement werden Vorgehensmodelle verstan- den, die aus traditionellen und agilen Ansätzen bestehen und diese kom-binieren. Die Motivation hierfür ist in der Regel, das Beste aus beiden Welten zu nutzen und ein unter gegebenen Rahmenbedingungen optimales Vorgehensmodell zu ent-wickeln. Bisher gab es keine etab-lierte formale Beschreibung, wie die Verbindung von traditionellen und agilen Ansätzen modelliert wer-den kann.Die Autoren entwickelten einen Ordnungsrahmen für hybrides Pro-jektmanagement, der Prozesse, Methoden und Werkzeuge sowie Rollen berücksichtigt. Anhand von Beispielen wird aufgezeigt, wie aus dem Ordnungsrahmen traditionelle, agile und hybride Vorgehensmodelle für unternehmensindividuell opti-miertes Projektmanagement abge- leitet werden können.

PM-aktuell_4-2016_Inhalt_01-88.indd 55 12.08.2016 10:31:35 Uhr


56 Wissen

• agil durchgeführte Projekte, die aufgrund branchentypischer oder gesetzlicher Vorga- ben ein transparentes und rückverfolgbares Änderungsmanagement nachweisen müssen.

Tatsächlich wenden viele Unternehmen agile Vor-gehensmodelle an, ohne sich dabei strikt an ein Lehrbuch oder einen Standard zu halten. Statt-dessen werden agile und traditionelle Vorge-hensmodelle je nach Unternehmenskonstellation kombiniert [3].

• traditionell durchgeführte Bauprojekte mit vor-hergehender agiler Planungsphase,

• traditionell durchgeführte Entwicklungspro-jekte, bei denen ein Softwareteilprojekt agil durchgeführt wird,

• agil durchgeführte Entwicklungsprojekte, bei denen die Anforderungen umfassend und rückverfolgbar dokumentiert werden und an deren Enden ausgewiesene Verifzierungs- und Validierungsphasen stehen,

ideal wäre. Stattdessen könnten in einer ersten agilen Projektphase die Anforderungen unter Einbeziehung von Anwendern konkretisiert wer-den und die dann stabileren Anforderungen in einem traditionellen V-Modell bearbeitet werden (Abb. 2). Auch andere Beispiele, in denen die Kombina- tion agiler und traditioneller Vorgehensmodelle sinnvoll sein kann, sind denkbar und in der Pra-xis erprobt:

Abb. 1:

In Abhängigkeit von den Kriterien

Mensch, Gefährdungspotenzial,

Projektteamgröße, Kultur und

Stabilität der Anforderungen lässt

sich bestimmen, ob eher agile oder

traditionelle (plangetriebene) Vor-

gehensmodelle zum Einsatz kommen

sollten in Anlehnung an Boehm und

Turner [2]. Je näher die Erfüllung

der Kriterien im Zentrum liegt, desto

eher ist ein agiles Vorgehen möglich.

Umgekehrt empfehlen Boehm und

Turner bei Projekten mit hohem

Gefährdungsgrad, großen Teams und

stabilen Anforderungen den Einsatz

traditioneller Vorgehensmodelle.

Menschen

GefährdungspotenzialStabilität der Anforderungen

Projektteamgröße Kultur

Qua

lifik

atio

nsgr

ad

Gefährdungsgrad

Team

größ

e

chaotisch geordnet

volatil stabil

traditionell

(plangetrieben)

agil

Abb. 2: Zunächst werden volatile Anforderungen im Rahmen einer ersten agil durchgeführten Projektphase (links) konkretisiert und stabilisiert.

Die dann stabilen Anforderungen werden in den folgenden Projektphasen (rechts) traditionell, beispielsweise durch Anwenden des V-Modells, bearbeitet.

Sprint

Daily Scrum

Sprint Planning

Entwicklung

Revie

w

Retro

spek

tive

Implemen-tierung

System-design

Komponenten-design

Komponenten-test

Abnahme

Integrations-test

Spezifi-kation

Verifizierung

Validierung

System-test

Schnittstelle

Volatile Anforderungenwerden durch frühe

agil umgesetzte Prototypenzu stabilen Anforderungen ...

Anforde-rungen

... und können dann risikoreduziert in einem traditionell durchgeführten Projekt

umgesetzt werden

Anzeige

Agile Ansätze in Projekten nutzen

#project #process #change

Mehr für Ihre Projekte

Jetzt anmelden unter www.nextlevelconsulting.eu, Webcode: D24


Wissen 57


Notation (BPMN) [5], erfolgt eine gegenüber natürlicher Sprache eindeutigere Darstellung. Ferner wird so auch eine Unterstützung durch Softwarewerkzeuge möglich. Da die alleinige und isolierte Darstellung von Detailprozessen jedoch

Form von Prozess- und Organisationsmodellen sowie Werkzeugbeschreibungen erfolgen. Durch die Verwendung von etablierten Modellierungs-sprachen, wie ereignisgesteuerten Prozessket- ten (EPK) [4] oder Business Process Model and

Agile und traditionelle Vorgehensmodelle sind jeweils für sich gut dokumentiert und teilweise sogar standardisiert. So bieten beispielsweise die Scrum Alliance und die Deutsche Gesell-schaft für Projektmanagement (GPM) verschie-dene Personenzertifizierungen an. Mit der DIN 69900/69901 gibt es eine Normenreihe zum (traditionellen) Projektmanagement. Allerdings existiert bisher kein in sich geschlos-senes Modell, das sowohl agiles als auch tradi-tionelles Projektmanagement berücksichtigt und als Referenz für die Anwendung und Entwick- lung hybrider Vorgehensmodelle dienen kann. Im folgenden Kapitel wird ein solches Modell in Form eines neu entwickelten Ordnungsrahmens für hybrides Projektmanagement vorgestellt.

Ordnungsrahmen

Um eine konsistente und stärker formalisierte Übersicht über das hybride Projektmanagement zu erlangen, soll die Darstellung der einzel- nen Phasen, die ein hybrides Projekt enthält, in

Abb. 3: Gestaltungsprinzipien für Ordnungsrahmen [6]

Unt

erst

ützu

ngs-

proz

ess

1

Unt

erst

ützu

ngs-

proz

ess

2

Unt

erst

ützu

ngs-

proz

ess

3

Koo

rdin

atio

ns-

proz

ess

1

Koo

rdin

atio

ns-

proz

ess

2

Um

feld

Um

feldGestaltungsfeld für die

Kernprozesse

Gestaltungsfeld für dieKoordinationsprozesse

Gestaltungsfeld für dieUnterstützungsprozesse

Kernprozess 1

Kernprozess 2

Kernprozess 3



58 Wissen

Auf Basis dieser Methodik wurde der in Abbil-dung 4 dargestellte Ordnungsrahmen entwickelt. Er besteht aus den drei Bereichen• Führung,• Projektlebenszyklus und• kontinuierliche Prozesse des Projektmanage-

mentssowie jeweils drei Sichten für • Prozesse,• Methoden und Werkzeuge sowie• Rollen.Die Anordnung des mittleren Bereichs Projekt-lebenszyklus deutet an, dass dieser mehrfach durchlaufen werden kann. Jeder Bereich be- inhaltet Elemente, die für Prozesse, Methoden

nungsrahmen erfüllt dabei vor allem zwei we- sentliche Funktionen. Zum einen gibt er eine Übersicht aller relevanten Teilbereiche [6, 7]. Zum anderen dient er als Markenzeichen der durch ihn beschriebenen Methode. Er ist damit oft namensgebend für die Methode und hat einen hohen Widererkennungswert, wie bei-spielsweise beim „Handels-H-Modell“ [8]. Ein Konzept zur Gestaltung von Ordnungsrahmen findet sich bei Meise [6]. Dieser schlägt explizit vor, bei der Gestaltung von Ordnungsrahmen von der Verwendung einer etablierten Modellierungs-sprache abzusehen. Stattdessen schlägt er das in Abbildung 3 dargestellte Grundschema für Ordnungsrahmen vor.

keinen Überblick zulässt und somit die Anpas-sung der hybriden Projektmanagementmethoden an die eigenen Bedürfnisse erschwert, wird im Folgenden ein Top-down-Ansatz verfolgt. Die konkrete Implikation für das weitere Vorgehen besteht darin, dass zunächst in bestehenden agilen und traditionellen Projektmanagementme-thoden die insgesamt theoretisch möglichen Teil-bereiche eines Projekts identifiziert werden müs-sen. Daraus kann dann eine Übersicht erstellt werden, die dann wiederum eine individuelle Adaption an das konkrete Projekt, den Kunden und das eigene Projektteam erlaubt.Zur Darstellung von Übersichtsmodellen haben sich Ordnungsrahmen etabliert [6]. Ein Ord-

Abb. 4:

Ordnungsrahmen für hybride

Vorgehensmodelle im Projekt-

management, bestehend aus den

drei Bereichen Führung (oben),

Projektlebenszyklus (Mitte) und

kontinuierliche Prozesse (unten)

sowie jeweils drei Sichten für

Prozesse (vorne), Methoden und

Werkzeuge (Mitte) und Rollen

(hinten).

I.1 P

roje

kt s

tarte

n

I.2 G

robz

iele

fest

lege

n

I.3 K

unde

nanf

orde

rung

en

erm

ittel

n

I.4 P

M-P

roze

ss fe

stle

gen

D.1

Org

anisa

tion

festl

egen

D.2

Rolle

n de

finie

ren

D.3 Ziel

e ana

lysier

en

D.4 Anforderungen analysieren D.5 Phasen u. Meilensteine festlegen

P.1 Inhalte planen

P.2 Aufwände schätzen

P.3 Termine planen

P.4 Ressourcen planenP.5 Kosten planen

S.1 Iterative Detailplanung

S.2 Fortschritt bestimm

en

S.3 Fortschritt analysieren

S.4 Fortschritt steuern

A.1

Proj

ektg

egen

stan

d

ab

nehm

en

A.2

Proj

ekt a

naly

sier

en

A.3

Org

anisa

tion

auflö

sen

F.4

Stak

ehol

derm

anag

emen

t

F.6

Konf

liktm

anag

emen

t

F.7

Team

entw

icklun

g

F.1 Z

usam

men

-

ar

beit u

nd

Or

ganis

ation

F.5

Kom

pete

nzen

twick

lung

F.8

Verha

ndlun

gen

F.3

Mita

rbei

terfü

hrun

g

F.2

Kom

mun

ikatio

n

F ü h r u n g

K.1 K.3

K.4

K.5

K.6

K.7

K.8

K.9

K.2

Kontinuierliche Abläufe des ProjektmanagementsQualitäts-management

Risiko-managementLieferanten-management

Vertrags-managementNachforderungs-management

Dokumenten-managementKonfigurations-management

Änderungs-management

Berichts-wesen

K.10 Wissens-management

ProzesseMethoden und WerkzeugeRollen

1. Sicht: 2. Sicht:

3. Sicht:

Projektlebenszyklus


Wissen 59


zelnen Sprints verteilt. Die Elemente P.1.8 bis S.4.10 werden für jeden Sprint des Scrum-Pro-jekts durchlaufen. Die beiden Beispiele verdeutlichen, dass sich aus dem Ordnungsrahmen sowohl agile als auch traditionelle Vorgehensmodelle ableiten lassen. Zur Illustration der Ableitung eines hybriden Vor-gehensmodells wird nun die aus Abbildung 2 bekannte Kombination eines agilen Scrum-Pro-jekts mit einem traditionellen Projekt, das nach dem V-Modell arbeitet, betrachtet (Abb. 8). Die bekannte typische Darstellung von Scrum- und V-Modell-Phasen des Projekts ist im oberen Teil der Abbildung wiederholt. Sie dient dem Wieder-erkennen der jeweiligen Vorgehensmodelle, erlaubt aber keine integrierte Modellierung des Gesamtprojekts. In Abbildung 8 unten ist das gleiche aus Scrum und V-Modell bestehende Vorgehen illustriert – nun aber direkt in einer aus dem Ordnungsrahmen abgeleiteten Darstel-lung. Das Ergebnis der agilen Phase, ein Product Backlog mit gut definierten stabilen Anforderun-gen, wird an der Schnittstelle von agilem zu tra-

den und später beim Aufbau eines individuellen Vorgehensmodells abgerufen werden.

Anwendung und Beispiele

Die Anwendung des Ordnungsrahmens soll nun anhand mehrerer Beispiele illustriert werden. Zu- nächst wird die Methoden- und Werkzeugsicht des Bereichs Projektlebenszyklus des Ordnungs-rahmens anhand von Abbildung 7 diskutiert. Die Elemente eines traditionellen V-Modells sind in Abbildung 7 oben dargestellt. Zunächst wird der Projektgegenstand spezifiziert, traditionelle Pläne, wie der Projektstrukturplan erstellt und der Projektgegenstand am Ende verifiziert und validiert. Am Ende erfolgen eine Nachkalkulation, die Freigabe der Ressourcen und eine Abschluss-feier. Das gleiche Ordnungsmodell auf ein einfaches Scrum-Projekt abgebildet ist in Abbildung 7 unten illustriert. Statt Lasten- und Pflichtenheft werden User Stories für das Product Backlog erstellt und mittels Sprint Backlog auf die ein-

und Werkzeuge sowie Rollen zu einem bestimm-ten Zeitpunkt des Projektlebenszyklus stehen. Der Bereich Projektlebenszyklus wurde in die fünf Phasen I: Initialisierung, D: Definition, P: Pla-nung, S: Steuerung und A: Abschluss unterteilt. Für jedes Element sind agile und traditionelle Prozesse, Methoden und Werkzeuge sowie Rol-len hinterlegt. Somit kann für jedes Element indi-viduell entschieden werden, wie das Gesamt- vorgehensmodell aufgebaut wird. Dies soll am Beispiel des Planungselements P.1: Inhalte pla-nen, siehe Abb. 4, illustriert werden.In traditionellen Projekten erfolgt die Inhaltspla-nung über den Projektstrukturplan. Hierfür sind im Ordnungsrahmen ein entsprechender Prozess und passende Methoden sowie involvierte Rollen hinterlegt (Abb. 5).Alternativ kann die Inhaltsplanung auch agil erfolgen. Hierfür ist unter anderem die Aktualisie-rung des initialen Product Backlog im Ordnungs-rahmen hinterlegt (Abb. 6). Weitere Vorgehen zur inhaltlichen Planung, beispielsweise für Kanban, können in den Ordnungsrahmen integriert wer-

Abb. 5: Element P.1 in traditioneller Ausführung als Prozess der Projekt-

strukturplanung mit Methoden der Darstellung, Gliederung sowie Formu-

laren als Werkzeuge und Rollen.

P.1: InhaltsplanungP.1.1: ProjektstrukturplanProzess:

ProjektzieleGrobplanungMeilensteine

Projekt-strukturplan

Methoden und Werkzeuge:Grafisch-hierarchische oder tabellarische DarstellungGliederungsprinzip (phasenorientiert,funktionsorientiert, objektorientiert etc.)Eindeutige Kodierung der ArbeitspaketeArbeitspaketformular

Arbeitspakete

Rollen:Verantwortung: ProjektmanagerMitwirkung: Projektteam

Auftraggeber (optional)Information: Auftraggeber

Inpu

t

Out

put

Abb. 6: Element P.1 in einer (von mehreren) agilen Ausführung als

Prozess der Aktualisierung des Product Backlog mit Methoden der

Darstellung, Priorisierung sowie Formularen als Werkzeuge und Rollen.

P.1: InhaltsplanungP.1.2: Aktualisierung Product BacklogProzess:

Initiales ProductBacklog

User Stories

Methoden und Werkzeuge:Visualisierung als Liste oder grafischan PinnwandPriorisierung der User Stories nach Kundenwert, mit MuSCoW-Prinzip, nach Punkten etc.Formulierungsschablone User Stories

AktualisiertesProductBacklog

Rollen:Verantwortung: Product OwnerMitwirkung: Entwicklerteam

Auftraggeber (optional)Information: Auftraggeber

Inpu

t

Out

put



60 Wissen

Abb. 7:

Methoden- und Werkzeugsicht

des Bereichs Projektdurchführung

des Ordnungsrahmens anhand der

Elemente eines V-Modells (oben)

und von Scrum (unten).

I.1.1

Ste

ckbr

ief

I.2.1

SM

ARTe

Z

ielfo

rmul

ieru

ng

I.3.2

Las

tenh

eft

I.4.1

V-M

odel

l wäh

len

D.3.1 Z

ielhie

rarch

ie

D.5.1 Phasenplan

P.1.1 Projektstrukturplan

P.2.1 Expertenschätzung

P.3.2 BalkenplanP.4.2 Zeitaufgelöster

RessourcenplanP.5.1 Zeitaufgelöster Kostenplan

S.1.2 Aktionspunktliste

S.3.1 Earned-Value-Analyse

I.2.1

SM

ARTe

Z

ielfo

rmul

ieru

ng

I.4.4

Scr

um w

ähle

n

D.3.1 Z

ielhie

rarch

ieD.4.5 Product Backlog

P.1.8 Aktualisierung

Product Backlog

P.2.2 Planning Poker

P.3.5 Sprint Backlog

S.1.3 Aktualisierung

Sprint Backlog

S.2.14 Burndown ChartS.4.10 Umsetzung Ergebnisse

der Sprint-Retrospektive

A.3.

2 Ab

schl

uss

feie

rn

Abbildung eines V-Modells

Abbildung eines einfachen Scrum-Projekts

D.1.1

Orga

nisati

onsfo

rm

D.2.1

Roll

enbe

schr

eibun

gD.

1.2 O

rganig

ramm

D.1.x

... D.2.2

RAC

I

D.2.5

Esk

alatio

nspfa

d

D.2.x

...

D.4.1 PflichtenheftD.4.3 Rückverfolgbarkeit

S.2.4 Statusschrittmethode

S.2.10 Verifizierung

S.2.11 Validierung

S.4.2 Veränderung der Ressourcen

S.4.x ...

A.1.

1 Le

istun

gswü

rdigu

ng

A.2.

1 Na

chka

lkulat

ions-

e

rste

llung

A.3.1

Res

sour

cen f

reige

ben

A.3.2

Abs

chlus

s feie

rn

I.3.4

Use

r Sto

ries

I.3.5

Initi

ales

Pr

oduc

t Bac

klog

S.3.7 Sprint Review

S.3.8 Sprint-Retrospektive

Abb. 8:

Oben: Typische getrennte

Darstellung des Vorgehens

in einem Scrum- und einem

folgenden V-Modell-Projekt.

Unten: Ableitung eines hybri-

den Vorgehensmodells mit

Scrum- und V-Modell-Phasen

aus dem Ordnungsrahmen.I.3.3

Las

tenh

eft a

us

P

rodu

ct B

ackl

og

I.4.1

V-M

odel

l wäh

len

D.5.1 Phasenplan

P.1.1 Projektstrukturplan

P.2.1 Expertenschätzung

P.3.2 BalkenplanP.4.2 Zeitaufgelöster

RessourcenplanP.5.1 Zeitaufgelöster Kostenplan

S.1.2 Aktionspunktliste

S.3.1 Earned-Value-Analyse

D.4.1 PflichtenheftD.4.3 Rückverfolgbarkeit

S.2.4 Statusschrittmethode

S.2.10 Verifizierung

S.2.11 Validierung

S.4.2 Veränderung der Ressourcen

S.4.x ...

A.1.

1 Le

istun

gswü

rdigu

ng

A.2.

1 Na

chka

lkula

tions

-

ers

tellu

ng

A.3.1

Res

sour

cen f

reige

ben

A.3.2

Abs

chlus

s feie

rn

I.2.1

SM

AR

Te

Zie

lform

ulie

rung

I.4.4

Scr

um w

ähle

n

D.3.1 Z

ielhie

rarch

ieD.4.5 Product Backlog

P.1.8 Aktualisierung

Product Backlog

P.2.2 Planning Poker

P.3.5 Sprint Backlog

S.1.3 Aktualisierung

Sprint Backlog

S.2.14 Burndown ChartS.4.10 Umsetzung Ergebnisse

der Sprint-Retrospektive

I.3.4

Use

r Sto

ries

I.3.5

Initi

ales

P

rodu

ct B

ackl

og

S.3.7 Sprint Review

S.3.8 Sprint-Retrospektive

I.1.1

Ste

ckbr

ief

D.1.1

Org

anisa

tions

form

D.1.2

Org

anigr

amm

D.1.x

...

D.2.

1 Ro

llenb

esch

reibu

ng

D.2.2

RAC

I

D.2.5

Esk

alatio

nspfa

d

D.2.x

...

Sprint

Daily Scrum

Sprint Planning

Entwicklung

Revie

w

Retro

spek

tive

Implemen-tierung

System-design

Komponenten-design

Komponenten-test

Abnahme

Integrations-test

Spezifi-kation

Verifizierung

Validierung

System-test

Schnittstelle

Anforde-rungen


Wissen 61


[7] vom Brocke, J.: Referenzmodellierung. Gestaltung und Verteilung von Konstruktions-prozessen. Logo-Verlag, 2003[8] Becker, J./Schütte, R.: Handelsinformations- systeme. Domänenorientierte Einführung in die Wirtschaftsinformatik. mi-Wirtschaftsbuch, 2004

Schlagwörteragiles Projektmanagement, hybrides Projekt-management, Ordnungsrahmen, Phasenmodelle,Referenzmodell, Vorgehensmodelle

Kompetenzelemente der ICB 4.01.02 Governance, Strukturen und Prozesse, Ablauf und Termine

Autoren Holger Timinger ist Pro-

fessor für Projektma-nagement und Gründer des Instituts für Projekt- management und Infor-mationsmodellierung (IPIM) an der Hochschule Landshut. Dort ist er

unter anderem Studiengangsleiter des berufs-begleitenden MBA-Studiengangs „Systems and Project Management“. Sein wissenschaftliches Interesse gilt insbesondere hybriden Vorgehens-modellen.Kontakt: [email protected], http://timinger.ipim.institute

Christian Seel ist Profes-sor für Wirtschaftsinfor-matik an der Hochschule Landshut und Leiter des Instituts für Projektma-nagement und Informa- tionsmodellierung (IPIM). Seine Tätigkeitsschwer-

punkte liegen in den Bereichen Geschäftspro-zessmanagement, Informationsmodellierung und agiles Projektmanagement. Er ist Certified Scrum Master (CSM) der Scrum Alliance.Kontakt: [email protected], http://seel.ipim.institute

ditionellem Vorgehen über das Element „I.3.3 Lastenheft aus Product Backlog“ übergeben. Die Beispiele zeigen, dass der Ordnungsrahmen die Ableitung agiler, traditioneller und hybrider Vorgehensmodelle erlaubt. Die Elemente des Ordnungsrahmens können Prozesse, Methoden und Werkzeuge sowie Rollen darstellen und somit individuell auf besondere Abläufe und Struk-turen eingehen.

Ausblick

Der hier vorgestellte Ordnungsrahmen stellt erst-mals eine in sich geschlossene Übersicht zur Ableitung agiler, traditioneller und hybrider Vor-gehensmodelle dar. Er berücksichtigt Prozesse, Modelle und Werkzeuge sowie Rollen. Durch seine generische und dennoch strukturierende Auslegung kann er flexibel an neue Situatio- nen angepasst werden und hilft bei der unter-nehmensindividuellen Konstruktion optimierter hybrider Vorgehensmodelle. Am Institut für Projektmanagement und Informa-tionsmodellierung (IPIM) der Hochschule Lands-hut erfolgt derzeit die Konstruktion von Pro- zess- und Organisationsmodellen für alle Teil- bereiche des Ordnungsrahmens sowie die Kon- zeption geeigneter Werkzeuge zur Unterstützung der jeweiligen Teilbereiche. Die so entstehenden Modelle werden kontinuierlich mit Praxispartnern evaluiert.

Literatur[1] Beck, K., et al.: Manifest für Agile Soft- wareentwicklung. 2001, http://agilemanifesto. org/iso/de[2] Boehm, B. W./Turner, R.: Balancing Agility and Discipline: A Guide for the Perplexed. Pearson Education, 2003[3] Komus, A./Kuberg, M.: Status Quo Agile. GPM, 2015[4] Seel, C./Vanderhaeghen, D.: Meta-Model based Extensions of the EPC for Inter-Organisa- tional Process Modelling. In: 4. GI-Workshop „EPK 2005 – Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten“, 2005[5] Allweyer, T.: BPMN 2.0 – Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung. 3. Auf-lage, Books on Demand, 2015[6] Meise, V.: Ordnungsrahmen zur prozess-orientierten Organisationsgestaltung. Modelle für das Management komplexer Reorganisa-tionsprojekte. Verlag Dr. Kovac GmbH, 2001

[email protected] | www.strategyex.de

Business Analyse – EinführungDie zentrale Bedeutung des Business Analysten während der verschiedenen Projektphasen

10.-12.10.2016 in Frankfurt/MainMehr Infos unter www.strategyex.de/dj9

Erfassung und Dokumen-tation von AnforderungenIdentifizieren Sie die Anforderungen in Ihren Projekten von Anfang an

09.-11.11.2016 in Frankfurt/MainMehr Infos unter www.strategyex.de/cyj

Moderationstechniken zur Ermittlung von AnforderungenLernen Sie Stakeholder zu unterstützen, ih-ren Bedarf zu definieren und daraus konkrete Anforderungen abzuleiten

03.-04.11.2016 in Frankfurt/MainMehr Infos unter www.strategyex.de/djb

Melden Sie sich jetzt an!

+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

Besuchen Sie zwei der drei oben

genannten Trainings sowie einen

weiteren Kurs aus unserem um-

fangreichen Trainingsangebot

und erwerben Sie ein Associate‘s

Certificate in Business Analysis von

der George Washington University!

Mehr unter www.esi-intl.de/gwu








+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University

















+49 (0)69 244 327-3795

Business Analyse

Training

Zertifikat von der

George Washington

University










ein ordnungsrahmen€¦ · design test abnahme integrations-test spezifi-kation verifizierung...

Documents