agiles projektmanagement bei werkverträgen · manifesto for agile software development (beck,...
Post on 18-Oct-2020
2 Views
Preview:
TRANSCRIPT
1
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.deVersion: 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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
) 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
© 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 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
© 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
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
4
7
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 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
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 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
14
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Rational Unified Process
16
© 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
9
17
© 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
18
© 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
10
19
© 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
Mikroprozessagil
Makroplanklassisch
20
© 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
11
21
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Rational Unified Process
22
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Es gibt die „Iteration 0“ auch bei den Agilen!!
http://www.ambysoft.com/essays/agileLifecycle.htmlhttp://www.extremeprogramming.org/rules/spike.html
12
23
© 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)
24
© 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?
13
25
© 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
26
© 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
14
27
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Subversion
Gemeinsame Baselines
KM: Quellcodes und Dokumente gemeinsam
Minimal-Lösung für
28
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - evolutionär
• Arbeitsauftragsliste, Excel
– kannste mal das Excel zumachen?...
15
29
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 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
32
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum - Product and Sprint Backlog - Dayly Scrum
34
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum - Artefacts and Roles
http://scrumforteamsystem.com
18
35
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Scrum: Burn Down Remaining Hours
http://www.controlchaos.com/
36
© 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....
19
37
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - evolutionär
• Arbeitsauftragsdatenbank
Achtung: MIT verbrauchtenZeiten, im Ggs. zu mancher Scrum
Lektüre
– die Bugs sind woanders -bitte nochmals abschreiben...
38
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned
• 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
• 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
20
39
© 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
40
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Vorgehensbausteine
21
41
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Inhalt eines Vorgehensbausteins
42
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Beispiel Baustein SW-Entwicklung
22
43
© 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.
44
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Demo „Tailoring mit Projektassistent“
23
45
© 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
46
© 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“
24
47
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Inkrementelle vs. Agile Systementwicklung
Inkrementelle Systementwicklung
Agile Systementwicklung
??
!!
48
© 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
25
49
© 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
50
© 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
26
51
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned
• XP– Continuous Integration!!
• nachhaltiges Tempo• kurze Inkremente• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort / Planspiel
• Scrum– Buttom up Controlling
• tägliche Restschätzung• kleine Aufgaben• gutes elektr. Tooling für
Issues PLUS Zeit
• VM XT– Für Agile nix neues
Lesson Learned
• 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
52
© 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
27
53
© 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
54
© 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
28
55
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Aufgabenplanung und -steuerung - heutiger Stand
29
57
© 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“
58
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
Lessons learned
• XP– Continuous Integration!!
• nachhaltiges Tempo• kurze Inkremente• gemeinsame Verantwortung• Standards (Tag 1)• Einfaches Design• Kunde vor Ort / Planspiel
• Scrum– Buttom up Controlling
• tägliche Restschätzung• kleine Aufgaben• gutes elektr. Tooling für
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
© 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
60
© 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? 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
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 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 leichter geht Agil• C3 war ein Werkvertrag aber wurde gestoppt in the end ;-)
32
63
© 2008 Orientation in Objects GmbHAgiles Projektmanagement bei Werkverträgen
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
© 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
33
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.deVersion: 1.0
Vielen Dank für IhreAufmerksamkeit !
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.deVersion: 1.0
? ?
???
Fragen ?
top related