Download - AGILES PROJEKTMANAGEMENT

Do., 4. Mai 2006 VU: 050127/3 im SS 2006 Folie 1

Projektmanagement (Project Management) – 8. Agiles ProjektmanagementU

nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

AGILES PROJEKTMANAGEMENT

Einführung, Methoden und Fallbeispiel

Zielgruppe:StudentInnen der

Wirtschaftsinformatik

Vortragender: Andreas WÖBER

Winf

Lehre - VO Übung - UE

http://www.univie.ac.at/



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Überblick und Gliederung

1. Agiles Projektmanagement Definitionen, Aufgaben und Ziele Grundprinzipen, Manifesto, Artikel

2. Agile Methoden zur Software-Entwicklung Definitionen, Aufgaben und Ziele Methoden: Scrum, XP, … Kombination von Methoden

3. Fallbeispiel (zur Übung)

4. Aktuelle Literatur – eine Auswahl

rote

r Fad

en



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Aufgaben und Ziele (1/2)

• Ziel des agilen Projektmanagements ist es, die Projektaufgabe(n)– in der vorgegebenen Qualität,– innerhalb der gesetzten Frist und– ohne Überschreitung des Budgets

zu bewältigen.

• Agile Methoden zur Entwicklung von Projekten kennen, kritisch beurteilen und gezielt für eigene Projekte anwenden können.

• ein Fallbeispiel mit Hilfe agiler Methoden gezielt lösen und Ergebnisse präsentieren können.



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Aufgaben und Ziele (2/2)

• Ziel: Lösung eines Fallbeispiels mit Hilfe der 3 Einheiten• Fallbeispiel: Planung und Realisierung eines

„Content Management Systems (CMS)“ für eine Geschäftsbank

Projektteam …Webdesigner

Programmierer

z.B. CMS

z.B.… mithilfe

des agilen PM



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Übersicht: Agiles Projektmanagement

(1. Einheit)

• Einführung in die Thematik• „Wie erfolgreich sind Projekte?“• „Wann ist ein Projekt erfolgreich?“• „Was ist agiles PM?“

Definitionen, Grundprinzipien, …• Manifesto für agile Software-Entwicklung• Agilität und Ziele für Projekte

Rückschlüsse für Fallbeispiel: CMS

Ziele: Anwendung von agilen Methode(n) für Projektaufgaben und -anforderungen!

Inte

rnet

-que

llen



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Einführung in die Thematik (1/2)

Wirtschaft:

„IT-Industrie ist eine dynamische Branche“ laufend Änderungen unterworfen!

Beispiel:

Internet - Homepage eine Unternehmens Plattform für Informationen,

Übersicht über das Unternehmen, Produkte, Dienstleitungen, …

laufend Änderungen unterworfen!Quelle: Gernert, Ch. (2003): Agiles Projektmanagement - Risikogesteuerte Softwareentwicklung,

Kapitel 1: Agiles Projektmanagement, Seite 5



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Einführung in die Thematik (2/2)

• „Die sehr hohe Innovationsgeschwindigkeit im IT-Bereich erzwingt entsprechend schnelle Produktzyklen!“

• „Kunden und Markt sind nicht mehr in der Lage, eigene Anforderungen zu definieren, sondern reagieren nur noch auf die Präsentation neuer technischer Möglichkeiten und Produkte!“

• „Die Erstellung von Software ist für sich bereits ein strukturierter Prozess, so dass die Notwendigkeit von systematischem Projektmanagement für Software-Entwicklungsprojekten oftmals nicht erkannt wird!“

Quelle: Projekt Magazin: Das Fachmagazin im Internet für erfolgreiches ProjektmanagementGlossar - Agiles Projektmanagement (2005)

http://www.projektmagazin.de/

http://www.projektmagazin.de/glossar/gl-0775.html



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Diskussion: Fragen zu Projektmanagement

1. Wie erfolgreich sind Projekte?

knappe Ressourcen, Zeitdruck, …

2. Wann ist ein Projekt erfolgreich?

wenn, …

- Budget und Termin eingehalten wurden? - das vorgeschriebene Vorgehensmodell

ordnungsgemäß angewendet wurde?- der Auftraggeber mit dem Ergebnis

zu frieden ist?

„Ich muss lauter Sachen gleichzeitig machen!“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Internetquelle: Artikelauswahl

zu Erfolg und Misserfolg von Projekten

Eine (subjektive) Auswahl an (kurzen) Internet-Artikel (November 2005):

1) „Wann ist ein Projekt erfolgreich?“ (html)contentmanager.de - Autor: Fröhlich, A. (2002)

2) „Softwareprojekte meistern“ (html)Nemetschek Bausoftware GmbH (2005)

3) „Grundlagen erfolgreicher Softwareprojekte“ (pdf)Creasoft AG - Autor: Matt, S. (2002)

4) „Widerständen bei Softwareprojekten erfolgreich begegnen“ (html)perspektive:blau - Autoren: Kraus, G. & Götz, T. (2001)

5) „Können Softwareentwicklungsprojekte erfolgreich sein?“ (pdf)ERNI Consulting AG - Erfahrungsbericht Nr. 10, Juni 2001

6) „Anleitung zum Unglücklichsein für Projektmanager“ (html)Object International Software GmbH - Autor: Sterkmann, F. (2005)

7) „Ursachen für Misserfolg oder für Erfolg von IT-Projekten“ (pdf) dpunkt - Auszug (Leseprobe), Autor: Zahrnt, Ch. (2005)

…Suchanfrage an google.at: „Wie erfolgreich sind Software-Projekte?“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing 1a.) „Wie erfolgreich sind Projekte?“ –

Überblick über Studien und Umfragen (Auswahl)• Standish Group

Beurteilung on IT-Firmen und Investments

• CHAOS-Report Fehlschläge von Software-Projekten (pdf)

• Datamonitor Business Information Center Britisches Marktforschungsinstitut Datamonitor-Studie (März 2002)

• GULP – Das Portal für IT-ProjekteUmfrage: „Woran scheitern IT-Projekte?“ (2002)

• Bourton Group-Studie

• Software Engineering Institute

http://www.standishgroup.com/

http://www.standishgroup.com/

http://www.ipd.uka.de/mitarbeiter/padberg/clausthal/swt1/CHAOS_3.pdf

http://www.ipd.uka.de/mitarbeiter/padberg/clausthal/swt1/CHAOS_3.pdf

http://www.gulp.de/

http://www.gulp.de/kb/it/projekt/umfragescheitern.html

http://www.gulp.de/kb/it/projekt/umfragescheitern.html

http://www.bourton.co.uk/



http://www.sei.cmu.edu/



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing 1b.) „Wie erfolgreich sind Software-Projekte?“ –

Studien und Ergebnisse

Beispiel: Termineinhaltung [Quelle: Standish Group Survey, 1999]

Werte von 1999• 29% abgebrochene Projekte• 45% über Kosten-/Zeitplan• 26% im Zeit- und Kostenplan

Werte von 2001• 23% abgebrochene Projekte• 49% über Kosten-/Zeitplan• 28% im Zeit- und Kostenplan

Gründe?

„Ich muss lauter Sachen gleichzeitig machen!“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1c.) Erfolgsfaktoren (Standish Group, 2001)

Quelle: Standish Group (Studien von 1994 und 2000)Umfrage des Managements von 365 Unternehmen nach den wesentlichen Erfolgsfaktoren für Software-Projekte

Unterstützung durch die Geschäftsleitung Executive support 18%Einbeziehung der Nutzer Involvement 16%Erfahrene Projektleiter Experienced project

manager14%

Eindeutige Geschäftsziele und Verantwortung Clear business objectives 12%Minimierung der Projektgröße Minimized scope 10%Standardisierte Software-Infrastruktur Software infrastructure 8%Stabile grundlegende Anforderungen Firm basic requirements 6%Angemessenes Vorgehensmodell Formal methodology 6%Verlässliche Schätzungen Reliable estimates 5%Kompetente und motivierte Mitarbeiter Other 5%



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing „Welcher Weg führt zum agilen Projektmanagement?“

anhand des Beispiels: Software-Entwicklung

Agiles Vorgehen

Objektorientierung

Software Engineering

Funktionen und Daten

Software-Krise

2000

1990

1980

1970

„Perfektionismus oder Vertrauen auf Erfahrung?“Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing „Was ist Agiles Projektmanagement?“ (1/3)

Definition, Grundprinzip und Methoden

• Definition:„Agiles Projektmanagement ist ein (branchen-spezifisch für Projekte entwickeltes) Handlungsmodell.“

• Grundprinzip: weitgehende Verzicht auf umfangreiche Vorgehensmodelle. „welche Gefahren sind damit verbunden?“

• Methoden: im Baukastenprinzip, die je nach Anforderungen eingesetzt werden.

• Komponenten:Team - Werkzeug - Prozess zur Erreichung der Ziele

Quelle: Projekt Magazin: Das Fachmagazin im Internet für erfolgreiches ProjektmanagementGlossar - Agiles Projektmanagement (2005)

http://www.projektmagazin.de/

http://www.projektmagazin.de/glossar/gl-0775.html



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer


Eigenschaften und Merkmale

• agil: (adj.) flink, gewandt, beweglich, rege, felxibel [Latein - agilis]

• der (Arbeits-) Prozess beinhaltet schnelle (Arbeits-) Methoden

• Definiert Aufgaben und Ziele für Team(s) und MitarbeiterInnen

Quelle: Chin, G. (2004): Agile Project Management — How to Succeed in the Face of Changing Project Requirements – Chapter 2: Determining When to Use Agile Project Management (Grundlagen)

FußballspielerIn

Eigenschaften

Diskussionspunkte Brainstorming:

„Welche Voraussetzungen und Eigenschaften müssen TrainerIn bzw. SpielerInnen mitbringen, um ein Fußballspiel zu gewinnen?“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer


Ziele

Ziele des agilen Projektmanagement ist es, die Projektaufgabe(n)

• in der vorgegebenen Qualität,• innerhalb der gesetzten Frist und• ohne Überschreitung des Budgets

zu bewältigen.

optimal minimal

maximal

Ressourcen Zeit

Funktionalität / Qualität

Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Übersicht:

„Manifesto for Agile Software Development“ (2001)

öffentliche Erklärung von Zielen und Absichten für die Erstellung von Softwareprodukten

Internetquelle: http://agilemanifesto.org/ (2001)

• Beteiligte Personen (in der Klammer die Methode): Kent Beck (XP), Jim Highsmith (ASD), Mike Beedle (Scrum), Ken Schwaber (Scrum), Jeff Sutherland (Scrum), Alistair Cockburn (Crystal), …

• Agile Alliance (http://www.agilealliance.com/)

http://agilemanifesto.org/



http://www.agilealliance.com/





nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Aufgaben und Ziele: Manifesto … (2001)

• Aufgaben

Vereinfachung und Verbesserung der Software-Entwicklung

• Ziele

gezielter (sinnvoller) Einsatz und Kombination vonagilen Methoden zur (erfolgreichen) Software-Entwicklung

„Manifesto for Agile Software Development“

(2001)

agilemanifesto.org

Aufgabe und Ziele



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing „Manifesto for Agile Software Development“ (2001)

Übersicht und Ziele (1/2)

• Agile Alliance 2001:„Wir entdecken bessere Wege zur Entwicklung von Software, in dem wir Software entwickeln und anderen bei der Entwicklung helfen.

Dadurch haben wir gelernt, dass ...


We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: …



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing „Manifesto for Agile Software Development“ (2001)

Übersicht und Ziele (2/2)

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

Working software over comprehensive documentation

Responding to change over following a plan

„Menschen und Zusammenarbeit“ vor Prozessen und

Werkzeugen „Funktionierende

Software“vor umfassender Dokumentation

„Zusammenarbeit mit den Kunden“ vor vertraglicher

Verhandlung„Reaktion auf Veränderung“ vor Einhaltung

eines Plans

„We are uncovering better ways of developing software by doing it and

helping others do it.“ value

Quelle: http://agilemanifesto.org/ (2001) – Stand: 17.10.2005






nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Agile Prinzipien und Werte zur Software-Entwicklung

• Nichts ist Beständiger als der Wandel – Es gibt keine 100% fertigen Anforderungen

• Kurze Entwicklungszyklen – Release und Iterationen– Feedback vom Kunden – Lernen aus Erfahrung

• Kontinuierliche und gute Kommunikation und Information als grundlegende Erfolgsbasis

• Team und Kunde bilden Maßstab für Erfolg • Lauffähige Software ist Bezugspunkt für Bewertung des

Projektfortschritts • Erfahrung und Erfolg vor Regeln und Vorschriften • Schlanke Prozesse und Methoden




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Übersicht: Agile Methoden (Auswahl)

• Folge von ca. 30-tägigen Sprints, • Produkt-Backlog, Sprint-Backlog, • Tägliches Meeting.

• Einfache, aber strenge Regeln, • kurze Iterationen, Kontinuierliche Planung, • Pair-Programming, ...

• Mensch steht im Mittelpunkt, • Kooperative Zusammenarbeit mit Hauptziel

lauffähige Software, Nebenziel: für das nächste Projekt vorbereitet sein.

• Adaptive Software Development • Ziele als Ausgangspunkt, kein Plan • Spekulieren, Zusammenarbeiten, Lernen.

Crystal

ASD

Scrum

XP

…Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Übersicht: Agile Anforderung(en) …

gegenüber

… 1. Projektmanager und

… 2. Projektteam und

… 3. Entwicklungsprozess.

Ziel: Rückschlüsse für z.B. Software-Entwicklung



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1a)„Was wird vom Projektmanager erwartet?“

Aufgaben des Projektmanagements

PlanenÜberwachen

Steuern

OrganisierenPersonal führen

Entscheiden

Informieren

Ziele setzen




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1b) Ein agiles Projekt(team) managen bedeutet …

• Projektziele und Projektergebnisse klar zu definieren,• deren Umsetzung planen (Projektaktivitäten),• die Durchführung der Projektaktivitäten und damit die

Zielerreichung überwachen,• bei Abweichungen oder Änderungen steuernd eingreifen,• Projektprozesse, Teams und Infrastruktur optimal organisieren,• Mitarbeiter führen,• alle Stakeholder optimal informieren,• Entscheidungen vorbereiten und treffen.

Es heißt darüber hinaus:• Risiken, Qualität und Änderungen aktiv managen




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

2) Merkmale eines agilen Projektteams

• Motiviertes Team,• Vertrauern statt Kontrolle,• Angemessenen Vorgehen,• Gute Kommunikation,• Das Ergebnis zählt,• „Best Practices“,• Veränderung ist ok,• Risikoorientiert.

„Erlaubt ist alles, was den Erfolg des Projektes fördert und Risikopotenziale senkt!“


„Wieviel Freiraum?“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

3) „Was ändert sich im Entwicklungsprozess?“

Anforderungen • Anwender formuliert Anforderungen• Richtigkeit und Vollständigkeit wird

frühzeitig durch Testen lauffähiger Software geprüft

• Spezifikation weniger formal

Implementieren• Kurze Entwicklungszyklen• Implementieren vor Spezifizieren,

dafür regelmäßiges Refactoring

Design / Architektur• Testen als Designansatz

(Test-First)• Regelmäßiges Refactoring

Vorschriften verlieren• Angemessenheit vor• Architektur wächst

Test• Basis für Feedback und Lernen• Akzeptanztest: effiziente Form der

Anforderungsformulierung • Unit-Tests: beste Form der

Dokumentation von Sourcecode• Sicherheitsnetz für Refactoring

und Einbau neuer Feature




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing 4) Rückschlüsse:

Anforderung(en) an agile Software-Entwicklung

Beispiel: Methoden auswählen, anwenden, umsetzen, kombinieren, anpassen, .. reflektieren, aus Fehlern lernen

„Hilfe, geben wie wieder alles

auf?“

„Nein, keineswegs!Rückbesinnung auf das

Wesentlich!“


Agile Projekte – „Was ist anders?“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Übersicht: Agile Projekte – Was ist anders?

1) Agilität und Ziele2) Grundsätze der Planung für agile Projekte3) Was verändert sich in der Dokumentation?4) Was verändert sich im Projektcontrolling?5) Was verändert sich im Team?6) Verantwortungsverteilung verändert sich7) Erfolgsfaktor Mensch

– Jeder braucht ein anderes Maß an Freiheit– Ohne Wissen und Disziplin funktioniert es nicht– Menschen formen Prozesse– Agilität benötigt Freiraum




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1. Agilität und Ziele für Projekt(e)

Agile Projektmanager achten• auf Freiräume

Eigenverantwortlichkeit und Motivation setzen eine klare Ziel-orientierung voraus

• auf Ergebnisorientierung um Ergebnisse vereinbaren zu können, müssen Ziele und Richtung bekannt sein

• auf Angemessenheit ohne eine inhaltliche Zielsetzung lassen sich Alternativen nicht bewerten

Agiles Projektmanagement benötigt klare, eindeutige und verbindliche Ziele!




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

2. Grundsätze der Planung für agile Projekte

• Wichtigste Bezugspunkte für Planung sind Anforderungsmodell und Systemarchitektur,

• Planung erfolgt stufenweise (Produkt, Release, Iterationen), Details zur richtigen Zeit,

• Planung orientiert sich strikt an prüfbaren Ergebnissen • Prinzipien des Timeboxing werden konsequent angewandt,• Schnelles, konsequentes Feedback wird gezielt zur

Verbesserung von Planungsprozess und Planungsqualität genutzt,

• Adaptive Planung (kontinuierlicher Prozesse).

Realisierung im Kleinen – Denken im Ganzen Planung ist flexibler, aber aufwendiger,

Offen sein für Änderungen statt festhalten an starren Vorgaben!Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

3. Was verändert sich in der Dokumentation?

• Dokumentation im Entwicklungsprozess – Ziel ändert sich:

Unterstützung der Kommunikation ist wichtiger als Wissenstransfer, daher weniger und nicht zwingend vollständige Dokumentation.

– Weniger Dokumentation möglich durch schnelle Realisierung, sofortige Ableitung von Testfällen und unmittelbare Einbeziehung des Kunden.

• Daher– Dokumente nicht mehr als Instrument zur Verfolgung des

Projektfortschritts geeignet. – Zurückfahren von Dokumentation erfordert Zunahme der

direkten Kommunikation Wissenstransfer sichern.

Doku




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

4. Was verändert sich im Projektcontrolling?

• Kurze überschaubare Etappen ermöglichen schnelle Reaktion• Fortschrittskontrolle basiert aus Inspektion von lauffähiger

Software– In der Mitte der Iteration Interview– Am Ende der Iteration Reflektions-Workshop

• Aktive Manager sind gefordert – Regelmäßiges aktives Nachfragen

• Entscheidungen dort treffen, wo Wissen vorhanden ist– Manager Team– Partizipative und kollaborative Entscheidungsprozesse

Mangel an Entscheidungsfreudigkeit eines der größten Risiken in Projekten




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

5. Was verändert sich im Team?

• Agile Prozesse brauchen Teams mit gleichwertigem Wissen– Vom Spezialwissen zum Allgemeinwissen – Spezialisten mehr Generalisten – Kopfmonopole vermeiden – Big Picture sollte jeder verinnerlicht haben – Leistung und nicht Rollen führen zu Anerkennung

• Teamsprecher vs. Teamleiter:– Kontaktperson– koordiniert wer an einem bestimmten Meeting teilnimmt

„Führungsaufgaben müssen jederzeit im Projekt übernommen werden, jede Minute, von jedem im Team“ [Kent Beck 2001]




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

6. Verantwortungsverteilung verändert sich

• Jeder ist für seine Aufgabe gesamtverantwortlich

• Jeder trägt Verantwortung für das gesamte System

• Jeder trägt Verantwortung für Prozesse im Projekt Beispiel: Collective Ownership

• Fazit:– Jeder steuert mit dies bedeutet in der Regel für alle im

Projekt Umdenken und Lernen – Nicht jeder nimmt die übertragende Verantwortung an




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

7. Erfolgsfaktor Mensch

• Die größten Probleme bei unserer Arbeit sind keine technologischen Probleme, sondern soziologische Probleme.

• Software- und Systementwicklung ist ein kreativer Prozess, bei dem Menschen (unter Ausnutzung professioneller Hilfsmittel) Lösungen für vorhandene Probleme suchen.

„Meine Idee ist besser

als Deine!“

„Was gefällt ihm jetzt

wieder nicht!“


Inputs



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

7a. Jeder braucht ein anderes Maß an Freiheit

Unerfahrene Projektbeteiligte• Benötigen Unterstützung durch

Erfahrene• Benötigen klare Vorgaben &

Regeln

Eingearbeitete Projektbeteiligte• Benötigen Unterstützung in

Teilbereichen• Nutzen Vorgaben als

Orientierung

Erfahrenen Projektbeteiligte• Benötigen weniger Vorgaben,

aber eindeutige, verbindliche Rahmenbedingungen

• Möglichkeit des individuellen Spielraums bieten

„Achten Sie bei der Auswahl Ihres Vorgehens auf alle Facetten Ihrer Mitarbeiter!“




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

7b. Ohne Wissen und Disziplin funktioniert es nicht

• Wissen– Werte und Prinzipien müssen allen bekannt sein

• gute Kenntnis der Organisation & der eigenen Rolle • Denken im Ganzen

– Agiles Management erfordert Charakter • Ehrlichkeit, Vertrauen, Mut, Konsequenz

– Agiles Management erfordert Erfahrung• Disziplin

– Denken Sie an Sport oder Musik – ohne Disziplin und Übung kein Erfolg

– Erst wenn die Grundregeln beherrscht werden, entsteht Raum für Flexibilität, Kreativität und Innovation

Auswählen, Kombinieren, Anpassen, Umsetzen, Zurückschauen, Reflektieren und Lernen




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

7c. Menschen formen Prozesse

Kommunikation

AugenmaßUnternehmens-Kultur

Wissen und Disziplin

Das Team




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1) „Was macht agile Projekte erfolgreich?“ (1/2)

• schätzen ein motiviertes Team höher ein als perfekt ausgeklügelte Regeln;

• legen mehr Wert auf gute Kommunikation im Team als auf ein formalisiertes Berichtswesen;

• achten darauf, dass ein erreichtes Ergebnis mehr zählt als die sture Abarbeitung einer vorgeschriebenen Aufgabe;

• akzeptieren kontinuierliche Änderungen im Projekt und halten nicht an Planvorgaben starr fest;

Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 2



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

2) „Was macht agile Projekte erfolgreich?“ (2/2)

• wenden für die Verbesserung des Vertrauens im Team mehr Zeit auf als für Kontrollverfahren;

• schätzen die Erfahrungen aus vorigen Projekten wertvoller ein als die Aussagen in Prozessmodellen oder Lehrbüchern (inklusive diesem Smile☺);

• geben angemessenen Vorgehensweisen den Vorzug gegenüber extremem Handeln;

• managen aktiv die Risiken Ihres Projekts statt Krisen zu bewältigen.

Quelle: Gernert, Ch. (2003): Agiles Projektmanagement — Risikogesteuerte Softwareentwicklung, Kapitel 1: Agiles Projektmanagement, Seite 2



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

3) Checkliste für (erfolgreiche) agile Projekte

für ein erfolgreiches Projekt• ist ein motiviertes Team wichtiger als perfektes Management;• ist selbstständiges Denken und Handeln entscheidender als

ein bis ins Detail vorgegebenes Prozessmodell;• ist eine funktionierende Kommunikation im Team und mit dem

Kunden bedeutsamer als ein formalisiertes Berichtswesen;• sind kontinuierliche Anpassungen an veränderte Situationen

wichtiger als das Festhalten an Planvorgaben;• sind wenige, für jeden verständliche und überschaubare

Regeln hilfreicher als umfangreiche, ellenlange Vorgehensvorschriften;

• ist das Wissen um die Sache eine wesentliche Voraussetzung.Quelle: Gernert, Ch. (2003): Agiles Projektmanagement - Risikogesteuerte Softwareentwicklung,

Kapitel 1: Agiles Projektmanagement, Seite 24



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Wiederholung: Einzelarbeit

Kontrollfragen zur Wiederholung (1/2)

Handout (Multiple Choice Test, 5/2006)

Homepage zur Lehrveranstaltung: SS 2006

Projektmanagment (Bakk.), 050.127 (VU)

URL: http://www.pri.univie.ac.at/courses/inf-pm/ss06/index.php

Agiles Projektmanagement



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

II. AGILE METHODEN

Projektmanagement zur (erfolgreichen) Softwareentwicklung




Winf




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Übersicht: Agile Methoden zur Software-Entwicklung

• Scrum• XP (eXtreme Programming)

• RUP (Rational Unified Process), • DSDM (Dynamic Systems Development Method)• Crystal Methodolgies,• FDD (Feature-Driven Development)• Lean Development, • Pragmatic Programming• TDD (Test-driven development)• Adaptive Software Development

Welche Methode(n)

soll ich wählen?

Quelle: Highsmith, J. (2001): Manifesto for Agile Software DevelopmentHistory: The Agile Manifesto

http://www.agilemanifesto.org/





http://www.agilemanifesto.org/history.html







nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Übersicht

• Einleitung• „Was ist ein Scrum?“• Definitionen• Ziele von Scrum• Der Scrum Prozess• Beteiligte Personen

– Product Owner– Scrum Master– Scrum Team

• Scrum Funktionen• Literaturquellen



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: „Was ist ein Scrum?“ (1/2)

• Begriff aus dem Rugby-Spiels• Ein Scrum ist die Besprechung des Teams

(bestehend aus acht Spielern) auf dem Spielfeld, bevor ein Durchbruch durch die gegnerischen Linien versucht wird.

• Ziel: Ball über die Torlinie zu bringen• Merkmale:

– keine zuvor eingeübten Spielzüge oder Anweisungen des Trainers

– Spieler entscheiden spontan und individuell



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: „Was ist ein Scrum?“ (2/2)

„Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices.“

Quelle: Schwaber, K. (2005): „What ist Scrum?“ unter der URL: http://www.controlchaos.com/ (Mo., 17.10.2005)

„Wrapping existing engineering practices, including eXtreme Programming (XP) and RUP,

Scrum generates the benefits of agile development with the advantages of

a simple implementation.“

„Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.“

http://www.controlchaos.com/



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: „Die Philosophie“ – Vergleich

„Scrum-Prozess“

Spielzüge, etc.

„Scrum-Prozess“

Fußballspiel(erInnen)

Aufgabe(n) und Ziel(e)

Rugbyspiel(erInnen) TrainerIn, Coach

Aufgabe(n) und Ziel(e)„parallelen“

Sprint



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Bestandteile eines Scrums (Begriffe)

Product Backlog

Sprint Planning Meeting

Scrum Team

Product Owner

Sprint Backlog

Daily Scrum

• Was habe ich seit gestern erledigt?

• Was hat mich dabei behindert?

• Was habe ich mir bis morgen vorgenommen?



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Vorgehensweise (1/2)

Agiler Prozess zur Software-Entwicklung• Wie?

mit Hilfe eines Scrums werden die Projekte in Serien von 30-tägigen Zyklen, den so genannten Sprints, bearbeitet.

• Wofür?für Projekte, bei denen sich die Anforderungen schnell ändern (können) oder dazukommen,

Ziele: „Iterativen Umsetzen von Anforderungen nach bestimmten Prioritäten, wobei laufend kontrolliert und adaptiert werden muss.“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Vorgehensweise (2/2)

Quelle: Mountain Goat Software, abgefragt am 15.11.2005 http://www.mountaingoatsoftware.com/scrum/index.php



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Der Entwicklungsprozess (1/2)

• Pre-Game (Vorbereitungen)

– Architecture – Develop Backlog list – High-level design– Address open questions in Backlog list

• Mid-Game: Development (Spiel)

• Post-Game (Nachbearbeitung)– Closure of questions



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Aufgaben und Eigenschaften des Teams

• Aufbauorganisation:self-directed, self-organizing teams

• no external addition of work to an underway iteration• Ablauforganisation:

daily stand-up meeting with special questions• Zeitplan: usually 30-calendar day iterations• demo to external stake holders at each iteration end• each iteration: client-driven adaptive planning



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Werte (Values)

• „Commitment“ (Engagement, Verpflichtung, Bindung)– Definde goal for an iteration

• „Focus“ (sein Hauptaugenmerk richten auf …)– „Product Backlog“

• „Openness“ (Offenheit)• „Respect“ (zu achten, respektieren, Beziehung)• „Courage“ (Mut, Herz)

Quelle: Schwaber, K. & Beedle, M. (2002): Agile Software Development wirth Scrum – Scrum values, Prentice-Hall

Ziele: gemeinsam an seiner Sache arbeiten, miteinander anstatt gegeneinander (sich damit identifizieren können)!



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Scrum: „Common Mistakes and Misunderstandings“

(1/2)

• Error: Not a self-directed team; managers or Scrum Master direct or organize the team

• Error: No daily update of the Sprint Backlog by members or daily tracker

• Error: New work added to iteration or individual• Error: Product Owner isn't involved or doesn't

decide• Error: No Sprint Review



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Scrum: „Common Mistakes and Misunderstandings“

(2/2)

• Error: Many masters • Error: Documentation is bad • Error: Design or diagramming is bad • Full team (including customers and management)

not briefed in Scrum and its values • Error: Scrum Meeting too long or unfocused• Error: Iteration doesn't end in an integrated and

tested partial product



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Scrum: Background

Schwaber, K / Beedle, M. (2002): Agile Software Development with SCRUM, Figure 28-1: A System Representation of Scrum, Prentice Hall



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing XP: „eXtreme Programming“

Übersicht über Methode

• Kent Beck 4 Grundwerte

– Kommunikation (Communication)Pair programming, task estimation, iration planning

– Einfachheit (Simplicity)– Rückmeldung (Feedback)

Testing, customer stories, small irations/frequent deliversies, pair programming/cinstant code reviews

– Mut (Courage)– (Respekt)

Wolf, H. / Roock, St. / Lippert, M. (2005): eXtreme Programming, 2. Auflage, dpunkt.verlag



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

XP: Werte

XP beruht auf die folgenden vier Werten:

Wolf, H. / Roock, St. / Lippert, M. (2005): eXtreme Programming, 2. Auflage, dpunkt.verlag

Einfachheit (Simplicity)

Kommunikation (Communication)

Mut (Courage)

Feedback



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

XP-Techniken (1/3)

Pair Programming (Programmieren in Paaren)



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

XP-Techniken (2/3)

13 XP-Techniken, auf denen die Grundwerte aufbauen

• Planning Game (Planungsspiel), User Storys• Kleine Release, kurze Releasezyklen• System-Metapher• Einfachstes Design• Testen• Refactoring (Kontinuierliche Verbesserung)• Pair Programming (Programmieren in Paaren)



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

XP-Prinzipien (3/3)

• Fortlaufende Integration (Continuous Integration)• Gemeinsamer Codebesitz und Verantwortlichkeit• Kunde im Projekt involviert• 40-Stunden-Woche• Offene Arbeitsumgebung• Einfache Richtlinien

• Voraussetzungen: Kommunikation, Teamgeist• Grenzbereiche• Fazit: kleine Projekte



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

XP: Softwarewerkzeug (Open Source)

• XPlanner URL: http://www.xplanner.org/• AgilePlace• XPWeb http://xpweb.sourceforge.net/

Weitere • SCM (Source Control Management)• BUILD• TEST• BUGTRACKING



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Beispiel: Kombination von Methoden (aus der Praxis)

• XBreed: Scrum und XP (eXtreme Programming)– Komination von management-orientierten Scrum

mit dem technisch-orientierten XP Mike Beedle, URL: http://www.xbreed.net/

• UPXS: UP, XP und Scrum– UP für die Phasen vor und nach der Software-Entwicklung

(z.B. Logistik, Vertrieb) – XP als Sammlung von ingenieurmäßigen Disziplinen für

hochqualitative Softwareentwicklung– Scrum als Management-Rahmen für die Entwicklung Roman Pichler, Siemens AG (auf der OOP 2005 in München

Abkürzung: Objekt-orientiertes Programmieren)



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Beispiel: Scrum und „eXtreme Programming (XP)“

Raumausstattung für tägliches Scrum-Meeting

Quelle: Larman, C. (2003): Agile and Iterative Development: A Manager´s Guide, Addison Wesley Chapter 11: Practice Tips – Environment, Figure 11.12: sample room elements



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Beispiel: Scrum und „eXtreme Programming (XP)“

Raumausstattung für tägliches Arbeiten (Entwicklung)

Quelle: Larman, C. (2003): Agile and Iterative Development: A Manager´s Guide, Addison Wesley Chapter 11: Practice Tips – Environment, Figure 11.10: agile project common room with walls

exposed



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Wiederholung: Einzelarbeit

Kontrollfragen zur Wiederholung (2/2)

Handout (Multiple Choice Test, 2. Seite, 05/2006)

Homepage zur Lehrveranstaltung: SS 2006 Projektmanagment (Bakk.), 050.127 (VU)

URL: http://www.pri.univie.ac.at/courses/inf-pm/ss06/index.php

Agiles Projektmanagement



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Weitere Methoden: Crystal Methodologies

• Kein Prozess, eher ein Framework• Alistair Cockburn befragte Anfang der 1990er-Jahren

Teammitglieder erfolgreicher Projekte„Welche Methoden, welche Techniken?“

• Ergebnis: unterschiedliche Projekte benötigen unterschiedliche Prozesse

• Lösung: Klassifizierung von Projekten Matrix mit verschiedenen Kriterien

• Erkenntnis:– Je geringer die Größe des Teams ist, umso weniger Dokumente

müssen verwendet werden– Je kritischer das Softwareprojekt, desto formaler müssen die

Dokumente seinQuelle: Cockburn, A. (2002): Agile Software Development, Boston (MA), Addison Wesley

http://alistair.cockburn.us/crystal/crystal.html





nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

FDD: Feature Driven Development

• Gründer: Jeff DeLuca, Peter Coad• Mitte der 1990er-Jahre erfolgreich

bei der Verwendung in sehr großen Projekten• Nach einer kurzen Initialisierungsphase werden

iterativ ausgewählte Anforderungen geplant und umgesetzt.– stark kundenorientierte Methode mit kleinen Teilresultaten,– Einschränkungen durch die Bedingung, dass ein Feature in

maximal zwei Wochen entwickelt werden sollte,– Lösung: Aufteilung der Feature bis die Vorgabe erfüllt

werde kann.Quelle: Palmer, S & Felsing, J. (2002): A Practical Guide to Feature Driven Development, London, Prentice Hall

http://www.featuredrivendevelopment.com/

http://www.featuredrivendevelopment.com/



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

ASD: Adaptive Software Development

• Jim Highsmith Rapid Application Development (RAD)• Seit 1992 wurde ASD in über 100 Projekten erfolgreich

verwendet• Regeln für die Zusammenarbeit zwischen Team, Kunden und

Organisation dar• Softwareprojekt wird als komplexes System gesehen• Anforderungen: Team muss flexibler sein, aufgrund weniger

Regeln• ASD-Lebenszyklus: Ende jeder Iteration: neue Version

– Anfang: Initialisierungsphase – Zyklen von Adaptive „Cycle Plannings“, „Concurrent Feature

Developments“ und „Quality Reviews“ werden durchgeführt– Team liefert alle 4 Wochen viele Features wie möglich (aufgrund

einer Prioritätenliste

http://www.adaptivesd.com/





nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

MSF: Microsoft Solutions Framework

• Merkmal: Framework Rahmen• Bestandteile

– Teammodell (6 Rollen sind Development-, Test-, Logistic-, User-, Costumer- und Program Manager Communication)

– MSF Prozessmodell– Prinzip der lebendigen Dokumente– Application-Architekturmodell– Proaktives Risikomanagement

• Flexibilität• Vorgehensmodell bietet ein Vorgehensmodell zur Bewältigung

von Projekten• Kleine Projekte Gleichberechtigung der 6 Hauprollen



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Zusammenfassung: Agile Methoden (1/2)

• Agile Methoden unterscheiden sich untereinander ganz erheblich in Umfang und Detaillisierungstiefe.

• Scrum, ASD und Crystal Methodologies Meta-Prozesse Prozesse als Rahmenbedingungen

• Verzicht auf detaillierte Vorgaben in der täglichen Arbeit

• XP und FDD sind dazu konkrete, detaillierte Verfahren für Software-Entwicklung

Quelle: OCG Journal - Ausgabe 5/2004, Agile Software Entwicklung auf der Seite 6



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Zusammenfassung: Agile Methoden (2/2)

• Agile Softwareentwicklungsmethoden sind nicht neu• Verwenden Strategien und Methoden von anderen

Methoden Kombination• Vorteile: Schlankheit der Prozesse,

Übersichtlichkeit und der Möglichkeit die Kundenwünsche umzusetzen.

• Nachteile: Kollision des stark iterativen Vorgehens, kompetenter Ansprechpartner auf Kundenseite (Fachwissen und Entscheidungsbefugnisse), konkrete Anforderungsdefinition

• Nicht jedes Projekt eignet sich für die Anwendung agiler Methoden

Quelle: OCG Journal - Ausgabe 5/2004, Agile Software Entwicklung auf der Seite 6



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Aufgabenstellungen: Gruppenarbeit

1. Überprüfen Sie zunächst die Anwendbarkeit der beiden agilen Methoden: Scrum und XP auf Ihr eigenes Projekt!

Gehen Sie dabei auf die jeweiligen Grundbegriffe, Werte, Prinzipien, … ein!

Vor- und Nachteile der beiden Methoden im Praxiseinsatz

2. „Welche weitere(n) agile Methode(n) können bei Ihrem Projekt sinnvoll miteinander kombiniert werden?“

3. „Wo sehen Sie Schwierigkeiten bei der Anwendbarkeit agiler Methoden gegenüber Vorgehensmodelle (RUP, V-Modell, …)?“



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

III. FALLBEISPIEL





Winf




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Übersicht: Fallbeispiel zur Software-Entwicklung

(Aufgaben und Ziele zur 3. Einheit)

• Erstellung eines „Content ManagementSystems“ (CMS) für eine Geschäftsbank Ressourcen unter Contentmanager.de,

• Agiles Projektmanagement und Methoden für Planung, Umsetzung, … anwenden,

• Aufgaben für Projektmanager und –team gezielt anwenden können.



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing CMS: Erstellung eines Content Management Systems

für eine Geschäftsbank

Was ist ein CMS?„Softwaresystem für das Administrieren von Web-inhalten mit Unterstützung des Erstellungsprozesses basierend auf der Trennung von Inhalten und Struktur.“

Input Output

Inhalte, Vorgaben,

Struktur, …

CMS



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

CMS: Planung (und Erstellung)

Aufgabenstellung(en) für Planung von …

• Webdesign,• Datenbanken,• Programmierung,• Multimedia,• …

mithilfe des Agilen Projektmanagements und Methoden

Geschäftsbank



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

CMS: Aufgabe(n) und Ziel(e) für Fallbeispiel

Aufgaben: Planung mithilfe der agilen Methoden (Gruppenarbeit)

Aufbau- und Ablauforganisation des Projekts

1. XP (eXtreme Programming),2. DSDM,3. EVO,4. Crystal Clear,5. MSF (Microsoft Solutions Framework),6. …

Ziele: Ausarbeitung des Fallbeispiels und Präsentation der Gruppenarbeit(inkl. aufgetretene Schwierigkeiten, … )

Scrum



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

IV. LITERATUR





Winf




nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing Übersicht: Literaturquellen – eine Auswahl

(zur 1. bis 3. Einheit)

• Agiles Projektmanagement

• Agile Methoden

• Fallbeispiel: CMS



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

1. Agiles Projektmanagement

• [Gern2003] Gernert, Ch.: Agiles Projektmanagement – Risikogesteuerte Softwareentwicklung, ISBN: 3-44-621995-1, Hanser Fachbuch Verlag.

• [Hrus2003] Hruschka, P. & Rupp, Chr. & Starke, G. (2003): Agility kompakt, ISBN: 3-82-741483-0, Spektrum Akademischer Verlag.

• [Stro2003] Strohmeier, H. (2003): Architektur erfolgreicher Projekte - Objekte und agile Strukturen statt Aktivitäten und Phasen, ISBN: 3-44-622313-4, Hanser Fachbuch Verlag.

• [Gras2004] Grasl, O. & Rohr, J. & Grasl, T. (2004): Prozessorientiertes Projektmanagement, ISBN: 3-44-622271-5, Hanser Fachbuch Verlag.

http://www.amazon.de/exec/obidos/ASIN/3446219951/qid=1130580722/sr=1-2/ref=sr_1_10_2/028-5777815-1768537

http://www.amazon.de/exec/obidos/ASIN/3827414830/ref=ase_bagilede-21/028-5777815-1768537

http://www.amazon.de/exec/obidos/ASIN/3446223134/qid%3D1130580980/028-5777815-1768537

http://www.amazon.de/exec/obidos/ASIN/3446222715/ref=pd_sim_dp_1/028-5777815-1768537



nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

2. Agile Methoden

• Schwaber, K. & Beedle, M. (2002): Agile Software Development with SCRUM, ISBN: 0-13-067634-9, 1st Edition, Upper Saddle River, New York, Prentice-Hall.

• Schwaber, K. (2004): Agile Project Management with Scrum, ISBN: 0-73-561993-x, Redmond, Washington, Microsoft Press.

• [Cock2004] Cockburn, A. (2004): Crystal Clear – A Human-Powered Methodology for Small Teams, ISBN: 0-20-169947-8, Addison-Wesley Professional.

• [Popp2003] Poppendieck, M. & Poppendieck, T. (2003): Lean Software Development – An Agile Toolkit, ISBN: 0-32-115078-3, Addison-Wesley Professional.





nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Internetquellen: Addons für MS Project 2003

• Add-On für Microsoft Project 2003 (Std. oder Prof.)

“Scrum Solution Starter”

• 1. URL: http://www.microsoft.com/downloads/details.aspx?FamilyID=81daab54-6701-4fbc-b3d0-7f261383f371&displaylang=en (Abfrage am 19.10.2005)

• 2. URL: http://msdn.microsoft.com/office/default.aspx?pull=/library/en-us/odc_pj2003_ta/html/OfficePJScrumToolSolStarter.asp (Abfrage am 19.10.2005)

http://www.microsoft.com/downloads/details.aspx?FamilyID=81daab54-6701-4fbc-b3d0-7f261383f371&displaylang=en






http://msdn.microsoft.com/office/default.aspx?pull=/library/en-us/odc_pj2003_ta/html/OfficePJScrumToolSolStarter.asp
















nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

3. Fallbeispiel: CMS – Content Management System

• Nix, M. (2005): Web Content Management, CMS verstehen und auswählen, ISBN: 3935042647, 1. Auflage, Software & Support

• Schröer, M. (2004): Web Content Management mit PHP und MySQL,ISBN: 389842524X, 1. Auflage, Galileo Press

• Friedrichs, M / Portwich, G. / Thoss (2005):CMS in der Praxis,ISBN: 3446404457, 1. Auflage, Hanser Verlag

• Meyer, R. (2005):Praxiswissen TYPO3,ISBN: 389721394X, 1. Auflage, OReilly Verlag

• Hauser, T / Wenz Ch. (2005):Mambo und Joomla!, ISBN: 3446404465, 1. Auflage, Hanser Fachbuchverlag




http://www.amazon.de/exec/obidos/ASIN/389842524X/qid=1133734050/sr=2-2/ref=sr_2_11_2/028-5777815-1768537










nive

rsitä

t Wie

n –

Dep

artm

ent f

ür K

now

ledg

e un

d B

usin

ess

Engi

neer

ing

Internetquellen

• Kommerzielle SoftwareIBM.com Software – DB2 Content Management

• Open-Source Software (Auswahl) Joomla.de – Joomla! 1.0.x Mamboserver.com – Mambo 4.5.xopensourceCMS.com typo3.com - TYPO3

• UnterlagenContentmanager.de oder Contentmanager.net – Das Content Management Portal

• …

http://www-306.ibm.com/software/data/cm/




http://www.joomla.de/

http://www.mamboserver.com/

http://www.opensourcecms.com/

http://www.typo3.com/

http://www.contentmanager.de/

http://www.contentmanager.net/