Agiles Projektmanagement bei Werkverträgen · Manifesto for Agile Software Development (Beck,...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]: 1.0

AgilesProjektmanagementbei Werkverträgen

2

© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen

Gliederung

• Agilität - Manifest und Prozesse - Scope• Lesson learned Extreme Programming• Lesson learned Rational Unfied Process• Lesson learned Scrum• Lesson learned V-Modell XT• Lesson learned Gegenwärtiges• Tips und Tricks

2

3


) Akademie )) Beratung )

Java, XML, Open Source und Agilität seit 1998

• Schulungen, Coaching, Weiterbildungsberatung, Train & Solve-Programme

• Methoden, Standards und Tools für die Entwicklung von offenen, unternehmens- weiten Systemen

• Schlüsselfertige Realisierung von Software• Unterstützung laufender Projekte• Pilot- und Migrationsprojekte

) Projekte )

4


Scope

• OIO– Alle Mitarbeiter Entwickler, Berater und Trainer gleichzeitig =>

Kapazitätsplanung sehr spannend.– Größenordnung der Werkverträge mit Kunden zwischen 3 und 150

Bearbeitermonaten• Durch Beratung und Projektunterstützung auch Erfahrung aus

Projekten von 6000 Bearbeitermonaten• Tlw. Entwicklungsteam gemischt mit Offshore Anteilen• Tlw. Kundenstruktur föderal (Lenkungsausschuss)

• Der Vortrag– spaziert entlang der Geschichte der OIO Software Factory– und entlang von Prozessmodellen als Metapher

• XP (1999), Scrum (2000), RUP (2003), V-Modell XT (2006)

3

5


Agiles Manifest

Manifesto for Agile Software Development(Beck, Fowler, Cockburn, uvm,. 2001)

• Einzelpersonen und Interaktionen wichtiger alsProzesse und Werkzeuge

• Laufende Systeme wichtiger alsumfangreiche Dokumentation

• Zusammenarbeit mit dem Kunden wichtiger alsVertragsverhandlungen

• Fähigkeit auf Änderungen zu reagieren wichtiger alsVerfolgen eines Plans

6


Gliederung


4

7


Fall 1: Extreme Programming mit Venture Capital

• 1999 erster großer Werkvertrag Kunde• Ziel: Reverse Auction e-procurement Plattform

– Success Story für Venture Capital erzwingt hochskalierbare Plattform– Deshalb komplettes Outsourcing an Java Spezialist

• 2 Hauptphasen im Projekt– Dienstleistungsvertrag für „Lauffähige Architektur“

• Proof of Concept für Investoren• Blue Print für technischen Entwicklung

– Umfangs-Iterationen mit maximalem Business Value• Kleine Werkverträge ohne Festpreise - Kosten unter

Wahrnehmungsschwelle• Rechtzeitig promotete Milestones für Refinanzierung• Viele Schwenks entlang der nächsten Kundenchance

8


Projektzyklus

Praktiken

Entwicklungszyklus

XP - The Big Picture

Kunde vor OrtMetapher

Gem. Verantw.

Pair Programming

Refactoring

E-Test / A-Test

Programmier-Standards

NachhaltigesTempo

Planungsspiel

KurzeInkremente

EinfachesDesign

FortlaufendeIntegration

5

9


XP - Argumentationsweg

Gem. Verantw.

„Man doch kann unmöglich zulassen, dass jeder jeden beliebigen Teil des Systems beschädigt.“

FortlaufendeIntegration

• Man hat fortlaufend integrierte Software, sodass Brüche sofort sichtbar sind.

E-Test / A-Test

• Man verfügt über ein lebendiges Testbett, sodass ständig Feedback nach Änderungen erfolgt.

Pair Programming

• Man programmiert paarweise, so dass niemandes EGO ausbricht und immer einer krank sein kann.

Programmier-Standards

• Man hält Programmierstandards ein. So bleibt der Code lesbar und wartbar für alle

Es sei denn:

10


Randbemerkung: Prozeßstrenge in XP

• Fix the process when it breaks.

• We don't say if because we already know you will need to makesome changes.

• This doesn't mean the team can do whatever they want. The rulesmust be followed until the team has changed them.

• Häufiges Missverständnis:"Ich habe seinen Schuh. Folgt seinem Schuh“

(Quelle: Leben des Brian)http://www.extremeprogramming.org/rules/fixit.html

6

11


Aufgabenplanung und -steuerung - evolutionär

• Karten, Pinwand

– dann kamen die Motten....

Plus ein paar BalkenplänePlus ein paar nachträgliche Spezifikationspapiere

für den Werkvertrag

12


Lessons learned

• XP– Continuous Integration

• Integrationsserver 1. Stunde• Autom. Testbett gepflegt

– => kurze Inkremente

– nachhaltiges Tempo• Zwischensprints erlaubt

– gemeinsame Verantwortung– Standards von Tag 1 an– Einfaches Design

– Kunde vor Ort– Gemeinsames Planungsspiel

• Business Value• Investorengetrieben• Chancengetrieben

Lesson Learned

7

13


Gliederung


14


Fall 2: RUP => das Papier bekommt seinen Platz

• 2002 erster Kunde mit RUP Zwang• Ziel: Bürgschaftsverwaltung - soll Referenz für J2EE sein

– Kunde migriert von Lotus Notes nach Java– Erste Großentwicklung wird Fremdvergeben– Kundenentwickler mit im Team bei Werkvetrag => Zwang zur

detaillierten Zeitmessung– Viele Standorte mit unterschiedlichen „Stakes“– „Sperrige Zielplattform“

• 2 Hauptphasen im Projekt– Dienstvertrag für „Lauffähige Architektur“ PLUS Grobspezifikation

• Grobspezifikation als Kalkulationsbasis etabliert „Product Owner“• Blue Print für technischen Entwicklung

– Vorab-Werkvertrag mit Umfangs-Teillieferungen• Terminzwänge durch Roll-Out Planung• gepufferte Planung und Überstunden als letzte Reserve

8

15


Rational Unified Process

16


Anfangs-planung

Planung

Anforderungen

Analyse und Entwurf

Implementierung

Test

Evaluierung

Freigabe

Jede Iteration führt zueiner konsistenten Version

IterativerinkrementellerProzeß

Heutige Softwareentwicklung ist normalerweise

weder Massenfertigung

noch überhaupt ingenieursmäßig betrieben

Kleine Kinder sollten kleine Schritte machen

Risikominimierung heißt das Ziel

Iteratives und inkrementelles Vorgehen

9

17


Starre Iterative Softwareentwicklung

Analysis

Implem

entation

Test

Analysis

Implem

entation

Test

Analysis

Implem

entation

Test

Analysis

Implem

entation

Test

1.Iteration

2.Iteration

3.Iteration

n.Iteration

Where do I put all the analysts in the blue time

18


ProjektmanagementIn dieser Arbeitsweise kann es nützlich sein,seinen Projektleiter nicht nur PMI-zertifizierenzu lassen, sondern ihm etwas von dieser Arbeitund auch ein wenig von SW-Entwicklung zu zeigen....

Parallele Iterationen - viel Freude mit Konfig-ManagementA

/A

D /I

T/D

1.Iteration

Estimated lentgth of Phases:

A/A: Analysis and Architecture 1 weeks

D/I: Design and Implementation 4 weeks

T/D: Test and Deployment 1 weeks

float 2 weeks

Release Frequency:

4 weeks / Release

2 weeks buffer time / Release

100 % load Development 50% load Customer

A/A

D /I

T/D

2.Iteration

A/A

D /I

T/D

3.Iteration

10

19


Planungsdokumente

ProjektplanLA-Sicht Iterationsplan Zielplanung

Iteration i

ArbeitsaufträgeKomponente k

Iteration i

Review-ErgebnisseIst-Daten

Direkte Nachsteuerung

(PL/TPL)

Planung ca. 2 Iterationen

im voraus (PL)

Planung unmittelbar

vorher (TPL)

Soll-Ist-Vergelich

nach jeder IterationPlananpassung

(PL/LA)

Zielplanung Iteration iZielplanung

Iteration i

ArbeitsaufträgeKomponente k

Iteration iArbeitsaufträgeKomponente k

Iteration iArbeitsaufträgeKomponente k

Iteration i

Review-ErgebnisseReview-

Ergebnisse

Mikroprozessagil

Makroplanklassisch

20


Planung Makroprozess

Nr. Vorgangsname

1 MPRS First Version

2 Iteration 0

3 Overall System Analysis

4 Planning and architectural Setup

5 Review

6 MPRS 0.8

7 IT 1 UGM

8 UGM Analysis

9 UGM Review

10 UGM Correction

11 UGM Final Review

12 UGM Implementation

13 IT 2 Publication and Versioning PV

20 IT 3 EntryList Integration EL

27 Installation@LU 0.8

33 MPRS 0.9

34 IT 4 Protocol Meta Data PMD

40 IT 5 Generic GUI GG

47 IT 6Common Interface CI

54 Installation@LU 0.9

60 MPRS 1.0

61 IT 7DMS Interface DMS

68 DeploymentPlan@AP

73 Installation&Deployment 1.0

MPRS First Version

Iteration 0

13.03.

MPRS 0.8

IT 1 UGM

01.04.

IT 2 Publication and Versioning PV

IT 3 EntryList Integration EL

Installation@LU 0.8

MPRS 0.9

IT 4 Protocol Meta Data PMD

IT 5 Generic GUI GG

IT 6Common Interface CI

Installation@LU 0.9

MPRS 1.0

IT 7DMS Interface DMS

DeploymentPlan@AP

Installation&Deployment 1.0

M S D M F D S M S D M F D S M S D M F D S M S D M F D S M S D M F D S M S D M F D S M S D MDez '07 31. Dez '07 28. Jan '08 25. Feb '08 24. Mrz '08 21. Apr '08 19. Mai '08 16. Jun '08 14. Jul '08 11. Aug '08 08. Sep '08 06. Okt '08 03. Nov '08 01. Dez '08 29. Dez '08 26. Jan '09 23. Feb '09 23. Mrz '09 20. A

11

21


Rational Unified Process

22


Es gibt die „Iteration 0“ auch bei den Agilen!!

http://www.ambysoft.com/essays/agileLifecycle.htmlhttp://www.extremeprogramming.org/rules/spike.html

12

23


Faktoren zum Projektfehlschlag

Mangelnder Informationsaustausch

13%

Unvollständige Anforderungen

12%

Unrealistische Erwartungen

6%

Unklare Ziele5%

Sonstiges23%

Mangelnde Ressourcen6%

Fehlende Unterstützung durch Entschieder

8%

Technologie-Inkompetenz

7%

Knappes Zeitfenster

4%

Neue Technologien

4%

Geänderte Anforderungen & Spezifikationen

12%

Standish Group (www.standish.com)

24


Requirements - Klassifizierung

• Der Formalisierungsgrad von Requirements

– vorformal / textuell• Jeder Motor ist nach Produktion Bestandteil eines Autos. Ein Auto

hat immer einen Motor

– semiformal / grafisch

– formal / mathematisch logisch• ∀m:Motor ∃!a:Auto (teil_von(m,a))• ∀a:Auto ∃!m:Motor (teil_von(m,a) ∧ ∀mi:Motor (teil_von(mi,a) ⇒

mi=m))

1 1has aAuto Motor

Welchen würden Sie bevorzugen?

13

25


Ergebnistypen Funktionale Grobspezifikation

Nr. Name Beschreibung Prio

Auftragsmanagement

Anfragestellen

Anfragemodifizieren

Anfragezurückziehen

Anfragebewerten

Dienstleisterzuordnen

Anfrageklassifizieren

Angebotannehmen

Auftragschließen

Anfrage(Anforderungsmodell)

Experte

Auftraggeber

Auftragnehmer

Fachbereichskoordinator

DVA-Dialog

Anfragesteller

Liste Use Cases

Use Case Diagramm

Akteur

Name des Akteurs, z.B. Außendienstmitarbeiter (ADM)

Beschreibung

Ein Akteur ist die Rolle, in welcher der Anwender denAnwendungsfall bearbeitet. Für jeden Anwendungsfall muß esmindestens einen Akteur geben. Akteure können sowohlPersonen als auch andere Systeme sein.

Liste Akteure A n w en d un g sfa ll

A n fra g e s te llen

A k teu r A n fra g es teller

P rio ri tä t H o ch

Z ie l

B e n utz er so lle n ein e A n frag e an d ie D ie n s tle is ter D V u nd O E s tellen k ö n ne n ,d ie zu e in e m A n ge b o t u n d A u ftra g fü h re n ka n n .

E re ig n is

N eu e Id ee o d er W u n sc h

V or au sse tz un g

V o ra uss ich tlic h er A u fw a n d > 2 S tu n d en ; A n fra g es teller m u ß für A M S b e re ch tigt se in

B eschr eibu n g

A n fra g en an d ie D ien s tle is te r D V u n d O E kö n ne n v o n a lle n fü r A M SB e re ch tig te n fo rm u liert w erd en . D ie A n frag e h at e in e n z w eiten B e s ta n d teil -d ie B ew ertu ng -, d e r v o m A n frag e ste lle r nie g eä nd ert w erd en , so n d ern im m e rnu r ein g ese he n w erd en k a n n . E rfa sse n d a rf d er A n frag es teller n u r d e n e rs ten B es tan d teil, d e r a usPflich tfe ld e rn u n d o p tio n alen F eld ern b es teh t. P flic h tfeld er s in d :

T h e m a d e r A n f rag e B esch reib u n g d er A n fra ge K o sten s telle , g g f. m it K o ste n au f te ilu ng A u ftra g g eb e r (N am e) A d re ssa t (D V o d er B O ) W ie d erke h ren d ( ja / n ein )

D as T ag esd atu m u n d d er N a m e d es A n f rag e s te lle rs w erd en v o n A M Sein ge tra ge n .

O p tio n a le Fe ld e r s in d : P rio ritä t (h o c h / m itte l / g eri n g) D e ad line (D a tu m ) A n lag e (m a n u ell / e lek tro n isch ) : e ine m an u e lle A n la g e m u ß a u f d e m

P o stw e g ve rsc h ic k t w erd en .

A M S p rüft d ie P flic htfe ld er au f fo rm ale V o lls tä n d ig k eit. Fü r d ie in h altlic h eK o rrek the it is t d er A n fra g es teller ve ra n tw o r tl ic h. W e nn d ie A n fra ge fo rm a l v o lls tä n d ig ist, w ird d ie A n frag e in A M S als1 .V ers io n g e fü h rt u nd e in e M itteilun g a n d e n A d ressate n g e g eb en . A d ressatis t d e r Fa ch b ereich sk o o rd in a to r au s D V o d e r O E . A M S leg t d ie A n fra g e m itein er n e u en A u ftr ag sn u m m e r a n.

E rg ebn is

A n fra g e g e stelltA n fra g e h a t A u ftr ag sn u m m e rM itteilu n g an A d re ssat

Nicht funktionale Anforderungen

26


Ergebnistypen Funktionale Feinspezifikation

1 besucht

1

0..1 ist Dekan von

10..* lehrt

1..*

1..*

gehört an

1

eingeschrieben

1 umfaßt

0..*

0..*

1..*Hochschule Fachbereich

LehrkraftStudent Veranstaltung

+ Klassendiagramm (+ Storyboard (Screenshots))

A n w en d un g sfa ll




Z ie l


E re ig n is


V or au sse tz un g


B eschr eibu n g







E rg ebn is






Z ie l


E re ig n is


V or au sse tz un g


B eschr eibu n g







E rg ebn is






Z ie l


E re ig n is


V or au sse tz un g


B eschr eibu n g







E rg ebn is


Szenario für Regelfall Anfrage stellen Annahmen Keine Suche nach Anfragen

Pflichtfelder vollständig Schritte Wer Was

1 AMS baut leeres Formular auf 2 Anfragesteller Füllt Pflichtfelder der Anfrage aus:

Thema, Problem, Auftraggeber, Kostenstelle 3 Anfragesteller Übernimmt aus Auswahl die Pflichtfelder der Anfrage:

Adressat (DV oder BO) W iederkehrend (ja oder nein)

4 AMS Trägt Tagesdatum und Namen des Anfragestellers in die Anfrage ein 5 Anfragesteller Kann optional

die Priorität hoch, mittel oder gering auswählen, das Datum für eine Deadline vorgeben (Datum), Anlage manuell oder elektronisch auswählen.

6 Anfragesteller W ählt „W eiterleiten“ aus 7 AMS Prüft, ob alle Pflichtfelder der Anfrage vollständig sind vollständig 8 AMS Vergibt Auftragsnummer für Anfrage 9 AMS Trägt in Anfrage Status „Anfrage gestellt“ ein

10 AMS Ruft Anwendungsfall „Interessenten benachrichtigen“ Mitteilung an Adressat Fachabteilungskoordinatoren DV oder BO

Ergebnis Anfrage gestellt,Mitteilung an Adressat,AMS bereit für neue Aktion





















Detaillierte Beschreibung

der Use Cases Szenarien (1 oder mehrere je UseCase)

= Feinspezifikation

14

27


Subversion

Gemeinsame Baselines

KM: Quellcodes und Dokumente gemeinsam

Minimal-Lösung für

28



• Arbeitsauftragsliste, Excel

– kannste mal das Excel zumachen?...

15

29


Entwicklerarbeitsplatz

A build a day keeps the doctor away!

SVNEntwicklung

QA

hsql

Eclipse

XMLbuddyXMLbuddy

ANTANT

Axisgenerator

Axisgenerator

SVNSVN

JUnit

JfcUnit

dbUnit

JBoss

Integrationsserver

Cruise Control

TestsTestsTestsTests

DB Server

Oracle

WebSphereApplication Server

ANTANT

The Grinder

IDEIDE

30


Lessons learned

• XP– Continuous Integration!!

• nachhaltiges Tempo• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort

• RUP– Es gibt einen Makroprozess

• Projektpläne im SVN• Ressourcenplanung!!• Namen für immer gleiches

– Es gibt eine Iteration 0 / Phasen• Das rechte Maß Specs hilft

rein und raus aus dem Vertrag• Architectural Spike

– Spätestens ab hier• Sind „Story Points“ zu wenig• Hilft echte Zeitschätzung und -

erfassung

Lesson Learned

16

31


Gliederung


32


Fall 3: Kleinere Startanwendung mit Ausbaustufen

• 2004 Spring Times begin• Ziel: Pharma Forschungsprozesssteuerung

– Kunde macht mit bei „Reduce to the max“– Selbst keine Entwicklungsabsichten– Kunde vor Ort mit „Product Owner“ wird vom Kunden akzeptiert!!

• 3 Hauptphasen im Projekt– Dienstvertrag für „Lauffähige Architektur“ PLUS Grobspezifikation

• Grobspezifikation als Kalkulationsbasis etabliert „Product Owner“• Blue Print für technischen Entwicklung

– 1. Werkvertrag für erstes nützliches Inkrement• Feines Kostencontrolling für verbesserte Schätzungen im Nachgang

– Weitere Werkverträge bauen in Etappen aus

17

33


Scrum - Product and Sprint Backlog - Dayly Scrum

34


Scrum - Artefacts and Roles

http://scrumforteamsystem.com

18

35


Scrum: Burn Down Remaining Hours

http://www.controlchaos.com/

36



• Arbeitsauftragsliste, Excel– kannste mal das Excel zumachen?...

• Karten, Pinwand– dann kamen die Motten....

19

37



• Arbeitsauftragsdatenbank

Achtung: MIT verbrauchtenZeiten, im Ggs. zu mancher Scrum

Lektüre

– die Bugs sind woanders -bitte nochmals abschreiben...

38


Lessons learned


• nachhaltiges Tempo• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort

• Scrum– Buttom up Controlling

• tägliche Restschätzung• kleine Aufgaben• gutes elektr. Tooling für

Issues PLUS Zeit

Lesson Learned






erfassung

20

39


Gliederung


40


Vorgehensbausteine

21

41


Inhalt eines Vorgehensbausteins

42


Beispiel Baustein SW-Entwicklung

22

43


SW Modul realisieren

• Produkt– SW-Modul

• Sinn und Zweck– Ein SW-Modul ist entsprechend den Anforderungen seiner SW-Spezifikation oder der

Spezifikation eines übergeordneten SW-Elements zu implementieren. Das Vorgehen zurImplementierung hat sich an den Vorgaben im Implementierungs-, Integrations- undPrüfkonzept SW zu orientieren. Falls in der Prüfstrategie gefordert, ist das fertige SW-Modul einer Prüfung durch einen externen Prüfer zu unterziehen.

– SW-Module sollten nach der Implementierung grundsätzlich einem Entwickler- undIntegrationstest unterzogen werden. Als Grundlage kann die PrüfspezifikationSystemelement dienen.

– Die Realisierung von SW-Modulen beinhaltet beispielsweise folgende Aspekte:• Programmierung unter Einhaltung der im Projekthandbuch festgelegten Standards und

Richtlinien,• Erstellung von Compile-, Binde-, Lade-, Installations- und Generierprozeduren,• Korrekturen bis zur Fehlerfreiheit des Compilierens und Bindens,• Gegebenenfalls Programmierung von Test- und Simulationsläufen.

44


Demo „Tailoring mit Projektassistent“

23

45


Tailoring wählt Durchführungsstrategie

Inkrementell

Agil

Fazit - Tailoring ist einfach:Das typische Individualsoftwareprojekt mit enger Zusammenarbeit zwischenAG und AN wählt zwischen Inkrementeller und Agiler Strategie

46


Wieviel Prozeß reduziert der Schneider?

VM komplett Inkrementell Agil• Rollen 31 19 19• Produkte 107 58 56• Aktivitäten 101 58 56• Entscheidungspunkte 21 15 15

Fazit - Tailoring zeigt Unterschiede im “Prozeßübergewicht“

24

47


Inkrementelle vs. Agile Systementwicklung

Inkrementelle Systementwicklung

Agile Systementwicklung

??

!!

48


Inkrementelle vs. Agile Systementwicklung

Inkrementelle Systementwicklung

Agile Systementwicklung

i.e. „Top down“ Entwicklung

i.e. „Bottom up“ Entwicklung

25

49


Agiles Manifest


• Einzelpersonen und Interaktionen wichtiger alsProzesse und Werkzeuge

• Laufende Systeme wichtiger alsumfangreiche Dokumentation

=> V-Modell per se auch Agil nicht „leichtgewichtig“

- Laufende System müssen wichtiger sein als 58 Dokumente :-)

- „Deutlicher Hinweis “ auf den Weg vom Ergebnis zur Forderung

=> Grundgedanke gut getroffen. Im Detail etwas platt

- Menschen müssen wichtiger sein als 58 Prozeßschritte :-)

- Prozeß darf noch weiter angepaßt werden. Werkzeugauswahl frei

50


Agiles Manifest


• Zusammenarbeit mit dem Kunden wichtiger alsVertragsverhandlungen

• Fähigkeit auf Änderungen zu reagieren wichtiger alsVerfolgen eines Plans

- Großer Minimalumfang

- erstmalig überhaupt Vertragsmanagement im Prozeß

- => man möchte ein SEHR SEHR gutes Konfigurationssmanagement

26

51


Lessons learned


• nachhaltiges Tempo• kurze Inkremente• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort / Planspiel



Issues PLUS Zeit

• VM XT– Für Agile nix neues

Lesson Learned






erfassung

52


Gliederung


27

53


Unterschied Festpreis und Werkvertrag

• BGB § 633 Sach- und Rechtsmangel(1) Der Unternehmer hat dem Besteller das Werk frei von Sach- und Rechtsmängeln zu verschaffen.(2) Das Werk ist frei von Sachmängeln, wenn es die vereinbarte Beschaffenheit hat.

• Vereinbarte Beschaffenheit für Abnahme:– „die körperliche Hinnahme des Werkes im Wege der

Besitzübertragung und die gleichzeitige Billigung des Werkes als imwesentlichen vertragsgemäß“ (Bundesgerichtshof)

• Wenn es dabei Fragen gibt, suchen wir dann unsere Story Cardsvon der Pinwand?

• Tip: Manchmal wird nur eins aus Festpreis/Werkvertrag benötigt– Nur Werkstück: Nur Spezifikationsdisziplin– Nur Festpreis: Nur Exploration nötig

54


Vertragsmodelle nach Preisbindung

• Starrer Festpreis– Klassisches Vorgehen

• GMP– Guaranteed Maximum Price– Baubranche

• Serien Werkvertrag– Rahmenvertrag / Einzelvertrag– Einzelv. Immer neu abgeschlossen je Stufe– Variante: Gesamtbudget steht fest, man

baut was man sich leisten kann

• Agiler Werkvertrag– transparentes Schätzverfahren– Tausch von Features in Construction

– AG Budgetsicherheit, AN Chancen auf Gewinn– Anforderungen initial vollständig und starr, Change Request

immer Vertragsänderung, Beidseitiges Risiko, Qualität stirbtals erstes, Preise typischerweise überhöht

– AG Budgetsicherheit plus Chance, unterstützt kooperativeDenkweise

– Qualität stirbt als erstes AN weniger Chancen auf Gewinn trotzRisiko, unpassend (selbst in Baubranche kritisch diskutiert)

– Schrittweise Budgetsicherheit, bekannte Jura, Kompatibel mitEinkauf, Spätere Anforderungen dürfen sich noch ändern,Abbruch möglich, weniger Risiko für beide

– AN hat u.U. kleineren Auftrag, Vertragsaufwand steigt immens

– Gute Änderungsmöglichkeit, Gesamtbudget stabil– Kalkulationsverfahren u.U. nicht „perfekt“, mangels

vertrauensvoller Zusammenarbeit konfliktträchtig,hervorragender Umgang mit Change Management notwendig.

Tlw. Objektspektrum 01/06 - B. Oesterreich - Der Agile Festrpeis

28

55


Werkzzeugidee: Issue Tracker für Projektmanagement

• 2 Hauptmotive:– XPlanner Tasks für Bugzilla Issues als Problem– Sind nicht Wartungsverträge der ideale Ersatz für den Werkvertrag?

Also braucht man sehr gutes Change Management

• Erkenntnis: Warum nicht auf Issues planen• Vorteile:

– Aufgabenpakete unterliegen einem Workflow– Aufgabenpakete können diskutiert werden– Issues sind automatisch Aufgabenpakete– Issues können auch Risiken und Forschrittsberichte sein.

• Kühne Idee:– Der Agile IT Dienstleister managed auch kaufmännische Prozesse

mit Scrum

56


Aufgabenplanung und -steuerung - heutiger Stand

29

57


Der Agile Festpreis - Planning Game im Werkvertrag

Features 0.0.7-feat. 1-feat. 2-feat. 3-.....-feat 7-feat. n

Features 0.1--feat. 4-feat. 5-feat. 6-.....-feat. m

Non-Features-feat. n1-feat. n2-feat. n3-.....-feat. nn

Währung??

Widget PointsUse Case StepsFunction Points

„außer bei Wettersimulation“

58


Lessons learned


• nachhaltiges Tempo• kurze Inkremente• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort / Planspiel



Issues PLUS Zeit

• VM XT– Für Agile nix neues

Lesson Learned

• RUP– Es gibt einen Makroprozess– Es gibt eine Iteration 0 / Phasen– Spätestens ab hier

• Sind „Story Points“ zu wenig• Hilft echte Zeitschätzung und -

erfassung

• Verträge– Volles Vertrauen:

• Werkvertrag mit var. Preisen– Vertrauen:

• Agiler Werkvertag– Wenig Vertrauen

• Serien Werkvertrag mitGesamtpreis

– Gutes Changemanagement!!

30

59


Gliederung


60


Tips aus der Praxis - Vertragstechnik Kunde

• Einkäufer mögen Werkverträge– Qualität, Kosten, Zeit, Umfang– raten Sie was zuerst stirbt? 2 Scheinargumente:

• Wichtig ist, daß es wenig „Stress“ gibt => also TRUGSCHLUSS:Kosten, Zeit, Umfang fix

• Qualität ist schwer zu definieren und zu messen (ISO, FCM)– warum nicht einfach mal machen ;-)– http://www.oio.de/m/konf/node2004/oio-nod04-productivity.pdf

– Versuch: Zeit fix, Kosten fix, Qualität fix, Umfang teilvariabel– Versuch: Werkvertrag ohne Festpreis

• Festpreis „Long run“– AN wenig Interesse an Wartbarkeit– Maßnahmen:

• Direkt auf Wartungsvertrag verpflichten• Bei transparenten Schätzverfahren

31

61


Tips aus der Praxis - Vertragstechnik Lieferant

• Geklärter Festpreis– „Vorprojekt“ (Explorationsphase (XP), Elaborationsphase (RUP))

• Nicht selten Dienstvertrag– transparentes Schätzverfahren– Werbung: „Prima Grundlage um nochmals den Lieferanten zu

wechseln“.

• Große Kunden- / Anwendernähe– wenn schon Werkvertrag, dann kann man diese bindend regeln

• DIN 69901 hilft ;-)– Projekte sind „im Wesentlichen durch Einmaligkeit gekennzeichnet“– Potentiell verlangte unnötige Prozessmodellaufwände separat

kalkulieren

62


Trost und Plädoyer

• Der agile Reinstraum spricht Smalltalk im Dienstvertrag

– überwiegend kein Interesse bei Gurus an (Management-) Tools

– in Java ist immer alles so neu (vor allem das Web Framework)

– die Entwickler sind nur „so so“ - je besser desto leichter geht Agil• C3 war ein Werkvertrag aber wurde gestoppt in the end ;-)

32

63


Trost und Plädoyer

• Tägliche Vollzeiterfassung– Agile Ethik kennt Mut und 40h Woche, darüber wird’s erträglich– Es hilft dem Team, wirklich schätzen schätzen zu lernen– Die „velocity“ ist oft ein Faktor der Kapazitätsplanung

• es hilft dem PL zu beweisen, WARUM er sein Team nicht hatte

• Ansonsten: Eigentlich geht es hier um Werte– Feedback– Einfachheit– Kommunikation– Mut

64


Agiler Prozeßmetzger: Darfs noch ein bißchen mehr sein?

Universales VorgehensmodellVerständnis als Baukasten für ein Vorgehensmodell

Vorgehensmodell mit konkreter MethodikRollen, Aktivitäten, Artefakte, Methoden

Rahmenprozess,vernetze Praktiken

Effizienzregeln

Teamlernt

V-Modell (XT)

RUP

Extreme Programming

Scrum

Adaptive Software Development

Bedürfnispyramide malumgekehrt: Bevor man die kleine Spitze nichthat, braucht man diegroße Basis nicht zuversuchen

33




Vielen Dank für IhreAufmerksamkeit !




? ?

???

Fragen ?

Agiles Projektmanagement bei Werkverträgen · Manifesto for Agile Software Development (Beck,...

Documents

Transcript of Agiles Projektmanagement bei Werkverträgen · Manifesto for Agile Software Development (Beck,...