agiles projektmanagement bei werkverträgen...• agilität - manifest und prozesse - scope •...
TRANSCRIPT
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
) Akademie )) Beratung )
Java, XML und Open Source 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 )
2
3
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
4
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scope
• OIO– Alle Mitarbeiter Entwickler, Berater und Trainer gleichzeitig =>
Kapazitätsplanung sehr spannend.– Größenordnung der eigenen Werkverträge 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 ein wenig 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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
4
7
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
8
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Praktiken
Entwicklungszyklus
Projektzyklus
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Entwicklerarbeitsplatz
A build a day... Continuous Integration!
SVN
Entwicklung
QA
hsql
Eclipse
XMLbuddyXMLbuddy
ANTANT
Axisgenerator
Axisgenerator
SVNSVN
JUnit
JfcUnit
dbUnit
JBoss
Integrationsserver
Cruise Control
TestsTestsTestsTests
DB Server
Oracle
Application Server
ANTANT
The Grinder
IDEIDE
10
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned - Agilität Management View
• XP– Continuous Integration!!
• nachhaltiges Tempo• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort
Lesson Learned
12
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
7
13
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum - Product and Sprint Backlog - Dayly Scrum
14
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum: Burn Down Remaining Hours
http://www.controlchaos.com/
8
15
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum - Artefacts and Roles
http://scrumforteamsystem.com
16
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - evolutionär
• Arbeitsauftragsliste, Excel– kannste mal das Excel zumachen?...
• Karten, Pinwand– dann kamen die Motten....
9
17
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - evolutionär
• Arbeitsauftragsdatenbank– die Bugs sind woanders -Bitte nochmals abschreiben...
Achtung: MIT verbrauchtenZeiten, im Ggs. zu Scrum
18
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - heutiger Stand
10
19
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned - Agilität Management View - Mikrokosmos
• XP– Continuous Integration!!
• 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
20
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
11
21
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Vorgehensbausteine
22
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Inhalt eines Vorgehensbausteins
12
23
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Beispiel Baustein SW-Entwicklung
24
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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.
13
25
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Demo „Tailoring mit Projektassistent“
26
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
14
27
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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“
28
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Inkrementelle vs. Agile Systementwicklung
Inkrementelle Systementwicklung
Agile Systementwicklung
??
!!
15
29
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Inkrementelle vs. Agile Systementwicklung
Inkrementelle Systementwicklung
Agile Systementwicklung
i.e. „Top down“ Entwicklung
i.e. „Bottom up“ Entwicklung
30
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Agiles Manifest
Manifesto for Agile Software Development(Beck, Fowler, Cockburn, uvm,. 2001)
• 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
16
31
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Agiles Manifest
Manifesto for Agile Software Development(Beck, Fowler, Cockburn, uvm,. 2001)
• 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
32
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Subversion
Gemeinsame Baselines
KM: Quellcodes und Dokumente gemeinsam
Minimal-Lösung für
17
33
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned - Konfigurationsmanagement
• XP– Continuous Integration!!
• 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
• VM XT– Konfiguration Management!!
• Baselining sehr wichtig• „Normales“ Wiki untauglich
Lesson Learned
34
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
18
35
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Rational Unified Process
36
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
19
37
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
38
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
20
39
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
MikroprozessConstruction Phase
Makroplanwoher kommt der?
40
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Es gibt die „Iteration 0“
http://www.ambysoft.com/essays/agileLifecycle.htmlhttp://www.extremeprogramming.org/rules/spike.html
21
41
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
42
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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)
22
43
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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?
44
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
23
45
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
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
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
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
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
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
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
46
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned - Makroprozess
• XP– Continuous Integration!!
• 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
• VM XT– Konfiguration Management!!
• RUP– Es gibt einen Makroprozess
• Projektpläne im SVN• Ressourcenplanung!!
– 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
24
47
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
48
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
25
49
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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“
50
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
26
51
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned - Verträge
• XP– Continuous Integration!!
• 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
• VM XT– Konfiguration Management!!
• RUP– Es gibt einen Makroprozess
• Projektpläne im SVN• Ressourcenplanung!!
– 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
• Verträge– Volles Vertrauen:
• Werkvertrag mit var. Preisen– Vertrauen:
• Agiler Werkvertag– Wenig Vertrauen
• Serien Werkvertrag mitGesamtpreis
– Gutes Changemanagement!!
Lesson Learned
52
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Gliederung
• Agilität - Manifest und Prozesse - Scope• Lesson Extreme Programming• Lesson Scrum• Lesson V-Modell XT• Lesson Rational Unfied Process• Lesson Werkvertrag und Festpreis• Tips und Tricks
27
53
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Tips aus der Praxis - Vertragstechnik Kunde
• Einkäufer mögen Werkverträge– Qualität, Kosten, Zeit, Umfang– raten Sie was zuerst stirbt?
• Wichtig ist, daß es wenig „Stress“ gibt => 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
• Festpreis „Long run“– AN wenig Interesse an Wartbarkeit– Maßnahmen:
• Direkt auf Wartungsvertrag verpflichten• Bei transparenten Schätzverfahren
54
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Tips aus der Praxis - Vertragstechnik Lieferant
• Geklärter Festpreis– „Vorprojekt“ (Explorationsphase (XP))
• Nicht selten Dienstvertrag– transparentes Schätzverfahren– 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
28
55
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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 Agil
• C3 war ein Werkvertrag aber wurde gestoppt in the end ;-)
• Tägliche Vollzeiterfassung– Agile Ethik kennt Mut und 40h Woche, das kann man sichern– Es hilft dem Team, wirklich schätzen schätzen lernen– Die Lage wird dem ganzen Team transparent– Man lernt dadurch erst aus Burn-Downs, WARUM sie nicht sinken– Die „velocity“ ist oft ein Faktor der Kapazitätsplanung
• es hilft dem PL zu beweisen, WARUM er sein Team nicht hatte
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
[email protected]: 1.0
Vielen Dank für IhreAufmerksamkeit !
29
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
[email protected]: 1.0
? ?
???
Fragen ?