Agiles Projektmanagement bei Werkverträgen

Transkript

1 Agiles Projektmanagement bei Werkverträgen Orientation in Objects GmbH Weinheimer Str Mannheim Version: Java, XML und Open Source seit 1998 ) Projekte ) ) Beratung ) ) Akademie ) Schlüsselfertige Realisierung von Software Unterstützung laufender Projekte Pilot- und Migrationsprojekte Methoden, Standards und Tools für die Entwicklung von offenen, unternehmensweiten Systemen Schulungen, Coaching, Weiterbildungsberatung, Train & Solve-Programme 2

2 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 3 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) 4

3 Agiles Manifest Manifesto for Agile Software Development (Beck, Fowler, Cockburn, uvm,. 2001) Einzelpersonen und Interaktionen wichtiger als Prozesse und Werkzeuge Laufende Systeme wichtiger als umfangreiche Dokumentation Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen Fähigkeit auf Änderungen zu reagieren wichtiger als Verfolgen eines Plans 5 Agiler Prozeßmetzger: Darfs noch ein bißchen mehr sein? Bedürfnispyramide mal umgekehrt: Bevor man die kleine Spitze nicht hat, braucht man die große Basis nicht zu versuchen Team lernt Effizienzregeln Adaptive Software Development Scrum Rahmenprozess, vernetze Praktiken Extreme Programming Vorgehensmodell mit konkreter Methodik Rollen, Aktivitäten, Artefakte, Methoden Universales Vorgehensmodell Verständnis als Baukasten für ein Vorgehensmodell RUP V-Modell (XT) 6

4 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 XP - The Big Picture Praktiken Projektzyklus Metapher Kunde vor Ort Planungsspiel Nachhaltiges Tempo Entwicklungszyklus Refactoring Einfaches Design Kurze Inkremente E-Test / A-Test Pair Programming Gem. Verantw. Programmier- Standards Fortlaufende Integration 8

5 A build a day... Continuous Integration! Entwicklerarbeitsplatz JBoss hsql Entwicklung Eclipse IDE XMLbuddy ANT Axis generator SVN JUnit JfcUnit dbunit SVN Integrationsserver ANT Tests Tests QA The Grinder DB Server Cruise Control Application Server Oracle 9 Randbemerkung: Prozeßstrenge in XP Fix the process when it breaks. We don't say if because we already know you will need to make some changes. This doesn't mean the team can do whatever they want. The rules must be followed until the team has changed them. Häufiges Missverständnis: "Ich habe seinen Schuh. Folgt seinem Schuh (Quelle: Leben des Brian) 10

6 Lessons learned - Agilität Management View Lesson Learned XP Continuous Integration!! nachhaltiges Tempo gemeinsame Verantwortung Standards (Tag 1) Einfaches Design Kunde vor Ort 11 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 12

7 Scrum - Product and Sprint Backlog - Dayly Scrum 13 Scrum: Burn Down Remaining Hours 14

8 Scrum - Artefacts and Roles 15 Aufgabenplanung und -steuerung - evolutionär Karten, Pinwand dann kamen die Motten... Arbeitsauftragsliste, Excel kannste mal das Excel zumachen?... 16

9 Aufgabenplanung und -steuerung - evolutionär Arbeitsauftragsdatenbank die Bugs sind woanders - Bitte nochmals abschreiben... Achtung: MIT verbrauchten Zeiten, im Ggs. zu Scrum 17 Aufgabenplanung und -steuerung - heutiger Stand 18

10 Lessons learned - Agilität Management View - Mikrokosmos Lesson 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 19 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 20

11 Vorgehensbausteine 21 Inhalt eines Vorgehensbausteins 22

12 Beispiel Baustein SW-Entwicklung 23 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 zur Implementierung hat sich an den Vorgaben im Implementierungs-, Integrations- und Prü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- und Integrationstest unterzogen werden. Als Grundlage kann die Prüfspezifikation Systemelement 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. 24

13 Demo Tailoring mit Projektassistent 25 Tailoring wählt Durchführungsstrategie Fazit - Tailoring ist einfach: Das typische Individualsoftwareprojekt mit enger Zusammenarbeit zwischen AG und AN wählt zwischen Inkrementeller und Agiler Strategie Inkrementell Agil 26

14 Wieviel Prozeß reduziert der Schneider? VM komplett Inkrementell Agil Rollen Produkte Aktivitäten Entscheidungspunkte Fazit - Tailoring zeigt Unterschiede im Prozeßübergewicht 27 Inkrementelle vs. Agile Systementwicklung Inkrementelle Systementwicklung?? Agile Systementwicklung!! 28

15 Inkrementelle vs. Agile Systementwicklung Inkrementelle Systementwicklung i.e. Top down Entwicklung Agile Systementwicklung i.e. Bottom up Entwicklung 29 Agiles Manifest Manifesto for Agile Software Development (Beck, Fowler, Cockburn, uvm,. 2001) Einzelpersonen und Interaktionen wichtiger als Prozesse und Werkzeuge - Menschen müssen wichtiger sein als 58 Prozeßschritte :-) => V-Modell per se auch Agil nicht leichtgewichtig - Prozeß darf noch weiter angepaßt werden. Werkzeugauswahl frei Laufende Systeme wichtiger als umfangreiche Dokumentation - 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 30

16 Agiles Manifest Manifesto for Agile Software Development (Beck, Fowler, Cockburn, uvm,. 2001) Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen - erstmalig überhaupt Vertragsmanagement im Prozeß Fähigkeit auf Änderungen zu reagieren wichtiger als Verfolgen eines Plans - Großer Minimalumfang - => man möchte ein SEHR SEHR gutes Konfigurationssmanagement 31 KM: Quellcodes und Dokumente gemeinsam Minimal-Lösung für Gemeinsame Baselines Subversion 32

17 Lessons learned - Konfigurationsmanagement Lesson 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 VM XT Konfiguration Management!! Baselining sehr wichtig Normales Wiki untauglich 33 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 34

18 Rational Unified Process 35 Iteratives und inkrementelles Vorgehen Heutige Softwareentwicklung ist normalerweise weder Massenfertigung noch überhaupt ingenieursmäßig betrieben Anfangsplanung Planung Anforderungen Kleine Kinder sollten kleine Schritte machen Risikominimierung heißt das Ziel Analyse und Entwurf Evaluierung Iterativer inkrementeller Prozeß Implementierung Test Freigabe Jede Iteration führt zu einer konsistenten Version 36

19 Starre Iterative Softwareentwicklung 1. Iteration 2. Iteration 3. Iteration n. Iteration Test Implementation Analysis Test Implementation Analysis Test Implementation Analysis Test Implementation Analysis Where do I put all the analysts in the blue time 37 Parallele Iterationen - viel Freude mit Konfig-Management Estimated lentgth of Phases: A/A 1. Iteration D /I T/D A/A: Analysis and Architecture D/I: Design and Implementation T/D: Test and Deployment float 1 weeks 4 weeks 1 weeks 2 weeks A/A 2. Iteration D /I A/A T/D 3. Iteration D /I T/D Release Frequency: 4 weeks / Release 2 weeks buffer time / Release 100 % load Development 50% load Customer Projektmanagement In dieser Arbeitsweise kann es nützlich sein, seinen Projektleiter nicht nur PMI-zertifizieren zu lassen, sondern ihm etwas von dieser Arbeit und auch ein wenig von SW-Entwicklung zu zeigen... 38

20 Planungsdokumente Planung ca. 2 Iterationen Planung unmittelbar Projektplan LA-Sicht Iterationsplan im voraus (PL) Zielplanung Iteration Zielplanung i Iteration Zielplanung i Iteration i vorher (TPL) Arbeitsaufträge Komponente Arbeitsaufträge k Komponente Iteration Arbeitsaufträge i k Komponente Iteration Arbeitsaufträge i k Komponente Iteration i k Iteration i Plananpassung (PL/LA) Direkte Nachsteuerung (PL/TPL) Soll-Ist-Vergelich nach jeder Iteration Makroplan woher kommt der? Ist-Daten Review- Ergebnisse Review- Ergebnisse Review- Ergebnisse Mikroprozess Construction Phase 39 Es gibt die Iteration

21 Planung Makroprozess Nr. Vorgangsname 1 MPRS First Version Dez ' Dez ' Jan ' Feb ' Mrz ' Apr ' Mai ' Jun ' Jul ' Aug ' Sep ' Okt ' Nov ' Dez ' Dez ' Jan ' Feb ' Mrz ' A 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 M MPRS First Version 2 Iteration 0 Iteration 0 3 Overall System Analysis 4 Planning and architectural Setup 5 Review MPRS 0.8 MPRS IT 1 UGM IT 1 UGM 8 UGM Analysis 9 UGM Review 10 UGM Correction 11 UGM Final Review UGM Implementation 13 IT 2 Publication and Versioning PV IT 2 Publication and Versioning PV 20 IT 3 EntryList Integration EL IT 3 EntryList Integration EL 27 Installation@LU 0.8 Installation@LU MPRS 0.9 MPRS IT 4 Protocol Meta Data PMD IT 4 Protocol Meta Data PMD 40 IT 5 Generic GUI GG IT 5 Generic GUI GG 47 IT 6Common Interface CI IT 6Common Interface CI 54 Installation@LU 0.9 Installation@LU MPRS 1.0 MPRS IT 7DMS Interface DMS IT 7DMS Interface DMS 68 DeploymentPlan@AP DeploymentPlan@AP 73 Installation&Deployment 1.0 Installation&Deployment Faktoren zum Projektfehlschlag Sonstiges 23% Mangelnder Informationsaustausch 13% Unvollständige Anforderungen 12% Neue Technologien 4% Knappes Zeitfenster 4% Mangelnde Ressourcen 6% Technologie- Inkompetenz 7% Fehlende Unterstützung durch Entschieder 8% Unrealistische Erwartungen 6% Unklare Ziele 5% Geänderte Anforderungen & Spezifikationen 12% Standish Group ( 42

22 Auftragsmanagement Anfragesteller Experte Fachbereichskoordinator Auftragnehmer Auftraggeber Anfrage (Anforderungsmodell) Anfrage stellen Anfrage modifizieren Anfrage zurückziehen Anfra ge bewerten Dienstleiste r zuordnen Anfrage klassifizieren Angebot annehmen Auftrag schließen DVA-Dialog Anwendungsfall Anfrage stellen Akteur Anfragesteller Priorität Hoch Ziel Benutzer sollen eine Anfrage an die Dienstleister DV und OE stellen können, die zu einem Angebot und Auftrag führen kann. Ereignis Neue Idee oder Wunsch Voraussetzung Voraussichtlicher Aufwand > 2 Stunden; Anfragesteller muß für AM S berechtigt sein Beschreibung Anfragen an die Dienstleister DV und OE können von allen für AMS Berechtigten formuliert werden. Die Anfrage hat einen zweiten Bestandteil - Ergebnis Erfassen darf der Anfragesteller nur den ersten Bestandteil, der aus Pflichtfeldern und optionalen Feldern besteht. Pflichtfelder sind: Optionale Felder sind: Anlage (manuell / elektronisch): eine manuelle Anlage muß auf dem Postweg verschickt werden. AM S prüft die Pflichtfelder auf form ale Vollständigkeit. Für die inhaltliche 1.Version geführt und eine M itteilung an den Adressaten gegeben. Adressat Mitteilung an Adressat Requirements - Klassifizierung Der Formalisierungsgrad von Requirements Welchen würden Sie bevorzugen? vorformal / textuell Jeder Motor ist nach Produktion Bestandteil eines Autos. Ein Auto hat immer einen Motor semiformal / grafisch Auto 1 has a 1 Motor formal / mathematisch logisch m:motor!a:auto (teil_von(m,a)) a:auto!m:motor (teil_von(m,a) m i :Motor (teil_von(m i,a) m i =m)) 43 Ergebnistypen Funktionale Grobspezifikation Nr. Name Beschreibung Prio Liste Use Cases Use Case Diagramm Liste Akteure Nicht funktionale Anforderungen Akteur Name des Akteurs, z.b. Außendienstmitarbeiter (ADM) Beschreibung Ein Akteur ist die Rolle, in welcher der Anwender den Anwendungsfall bearbeitet. Für jeden Anwendungsfall muß es mindestens einen Akteur geben. Akteure können sowohl Personen als auch andere Systeme sein. die Bewertung -, der vom Anfragesteller nie geändert werden, sondern immer nur eingesehen werden kann. Thema der Anfrage Beschreibung der Anfrage Kostenstelle, ggf. mit Kostenaufteilung Auftraggeber (Nam e) Adressat (DV oder BO) W iederkehrend (ja / nein) Das Tagesdatum und der Name des Anfragestellers werden von AMS eingetragen. Priorität (hoch / m ittel / gering) Deadline (Datum) Korrektheit ist der Anfragesteller verantwortlich. Wenn die Anfrage formal vollständig ist, wird die Anfrage in AMS als ist der Fachbereichskoordinator aus DV oder OE. AMS legt die Anfrage mit einer neuen Auftragsnummer an. Anfrage gestellt Anfrage hat Auftragsnummer 44

23 Akteur Anfragesteller Ereignis Neue Idee oder Wunsch Anwendungsfall Priorität Anfrage stellen Hoch Voraussetzung Voraussichtlicher Aufwand > 2 Stunden; Ziel Benutzer sollen eine Anfrage an die Dienstleister DV und OE stellen können, Akteur Anfragesteller Anfragesteller muß für AM S berechtigt sein die zu einem Angebot und Auftrag führen kann. Priorität Beschreibung Hoch Anfragen an die Dienstleister DV und OE können von allen für AMS Ereignis Neue Idee oder Wunsch Ziel Benutzer sollen eine Anfrage Berechtigten an die Dienstleister formuliert DV werden. und OE Die stellen Anfrage können, hat einen zweiten Bestandteil - die zu einem Angebot und die Auftrag Bewertung führen -, kann. der vom Anfragesteller nie geändert werden, sondern immer Voraussetzung Voraussichtlicher nur eingesehen Aufwand > werden 2 Stunden; kann. Anfragesteller Erfassen muß für AM darf S berechtigt der Anfragesteller sein nur den ersten Bestandteil, der aus Ereignis Neue Idee oder Wunsch Pflichtfeldern und optionalen Feldern besteht. Pflichtfelder sind: Beschreibung Anfragen an die Thema Dienstleister der Anfrage DV und OE können von allen für AMS Voraussetzung Voraussichtlicher Berechtigten Aufwand formuliert > 2 Beschreibung Stunden; werden. der Die Anfrage hat einen zweiten Bestandteil - Anfragesteller die muß Bewertung für AM S -, berechtigt der Kostenstelle, vom Anfragesteller sein ggf. mit Kostenaufteilung nie geändert werden, sondern immer nur eingesehen werden Auftraggeber kann. (Nam e) Beschreibung Anfragen an Erfassen die Dienstleister darf der Adressat DV Anfragesteller und (DV OE oder können nur BO) den von ersten allen für Bestandteil, AMS der aus Berechtigten Pflichtfeldern formuliert werden. und Woptionalen Die iederkehrend Anfrage Feldern hat (ja einen / besteht. nein) zweiten Pflichtfelder Bestandteil sind: - die Bewertung -, der Thema vom der Anfragesteller Das Tagesdatum nie geändert und der werden, Name sondern des Anfragestellers immer werden von AMS nur eingesehen werden Beschreibung kann. eingetragen. der Anfrage Erfassen darf der Kostenstelle, Anfragesteller ggf. mit nur Kostenaufteilung den ersten Bestandteil, der aus Pflichtfeldern und Auftraggeber optionalen Optionale Feldern (NamFelder e) besteht. sind: Pflichtfelder sind: Thema der Anfrage Adressat (DV Priorität oder BO) (hoch / m ittel / gering) Beschreibung Wder iederkehrend Anfrage Deadline (ja / nein) (Datum) Kostenstelle, Das ggf. Tagesdatum mit Kostenaufteilung Anlage und der (manuell Name / des elektronisch): Anfragestellers eine werden manuelle von Anlage AMSmuß auf dem Auftraggeber eingetragen. (Nam e) Postweg verschickt werden. Adressat (DV oder BO) W iederkehrend Optionale (ja / Felder nein) AM S sind: prüft die Pflichtfelder auf form ale Vollständigkeit. Für die inhaltliche Das Tagesdatum Priorität und der (hoch Korrektheit Name / m ittel des ist / Anfragestellers der gering) Anfragesteller werden verantwortlich. von AMS eingetragen. Deadline Wenn (Datum) die Anfrage formal vollständig ist, wird die Anfrage in AMS als Anlage (manuell 1.Version / geführt elektronisch): und eine eine M itteilung manuelle an Anlage den Adressaten muß auf gegeben. dem Adressat Optionale Felder sind: Postweg ist verschickt der Fachbereichskoordinator werden. aus DV oder OE. AMS legt die Anfrage mit Priorität (hoch / m ittel einer / gering) neuen Auftragsnummer an. Deadline AM (Datum) S prüft die Pflichtfelder auf form ale Vollständigkeit. Für die inhaltliche Anlage (manuell Korrektheit / elektronisch): ist der Anfragesteller eine manuelle verantwortlich. Anlage muß auf dem Ergebnis Anfrage gestellt Postweg Wenn verschickt die werden. Anfrage Anfrage formal hat Auftragsnummer vollständig ist, wird die Anfrage in AMS als 1.Version geführt Mitteilung und eine an Adressat M itteilung an den Adressaten gegeben. Adressat AM S prüft die ist Pflichtfelder Fachbereichskoordinator auf form ale Vollständigkeit. aus DV oder Für OE. die AMS inhaltliche legt die Anfrage mit Korrektheit ist einer der neuen Anfragesteller Auftragsnummer verantwortlich. an. Wenn die Anfrage formal vollständig ist, wird die Anfrage in AMS als Ergebnis 1.Version geführt Anfrage und gestellt eine M itteilung an den Adressaten gegeben. Adressat ist der Fachbereichskoordinator Anfrage hat Auftragsnummer aus DV oder OE. AMS legt die Anfrage mit einer neuen Auftragsnummer Mitteilung an Adressat an. Ergebnis Anwendungsfall Anfrage stellen Akteur Priorität Hoch Anwendungsfall Ziel Benutzer sollen eine Anfrage an die Dienstleister DV und OE stellen können, Anfrage stellen die zu einem Angebot und Auftrag führen kann. Mitteilung an Adressat Anfragesteller Ergebnistypen Funktionale Feinspezifikation Anfrage gestellt Anfrage hat Auftragsnummer Detaillierte Beschreibung der Use Cases = Feinspezifikation Szenario für Regelfall Anfrage stellen Annahmen Keine Suche nach Anfragen Pflichtfelder vollständig Szenario für Regelfall Schritte Wer Anfrage stellen Was 1 Annahmen AMS Szenario für Regelfall Keine baut leeres Formular Anfrage Suche aufstellen nach Anfragen 2 Anfragesteller Annahmen Pflichtfelder Füllt Pflichtfelder Keine vollständig der Anfrage Suche aus: nach Anfragen Schritte Wer Was Thema, Problem, Pflichtfelder Auftraggeber, vollständig Kostenstelle 1 AMS baut leeres Formular auf 3 Anfragesteller Schritte Wer 2 1 Anfragesteller AMS Übernimmt aus Was Auswahl die Pflichtfelder der Anfrage: Füllt Pflichtfelder baut leeres Formular der Anfrage aufaus: Adressat (DV oder BO) 2 Anfragesteller Thema, Wiederkehrend Füllt Problem, (ja Pflichtfelder Auftraggeber, oder nein) der Anfrage Kostenstelle aus: 3 AMS Anfragesteller Übernimmt Tagesdatum Thema, aus und Problem, Auswahl Namen des Auftraggeber, die Pflichtfelder Anfragestellers Kostenstelle der Anfrage: in die Anfrage 4 Trägt ein 5 Anfragesteller Adressat Kann optional Übernimmt (DV oder aus BO) Auswahl die Pflichtfelder der Anfrage: 3 Anfragesteller Wiederkehrend (ja oder nein) die Priorität Adressat hoch, (DV mittel oder oder BO) gering auswählen, 4 AMS Trägt Tagesdatum und Namen des Anfragestellers in die Anfrage ein das Datum Wiederkehrend für eine Deadline (ja oder vorgeben nein) (Datum), 5 Anfragesteller Kann optional 4 AMS Anlage manuell Trägt Tagesdatum oder elektronisch und Namen auswählen. des Anfragestellers in die Anfrage ein 5 Anfragesteller die Kann Priorität optional hoch, mittel oder gering auswählen, Anfragesteller Wählt Weiterleiten aus 6 das Datum die Priorität für eine hoch, Deadline mittel vorgeben oder gering (Datum), auswählen, 7 AMS Prüft, ob alle Pflichtfelder der Anfrage vollständig sind vollständig Anlage das manuell Datum oder für elektronisch eine Deadline auswählen. vorgeben (Datum), 8 AMS Vergibt Auftragsnummer für Anfrage 6 AMS Anfragesteller Wählt Weiterleiten aus in Anfrage Status Anlage Anfrage manuell gestellt oder elektronisch ein auswählen. 9 Trägt 7 6 AMS Prüft, ob alle Pflichtfelder der Anfrage vollständig sind vollständig Anfragesteller 10 AMS 8 Ruft Anwendungsfall Wählt Weiterleiten Interessenten aus benachrichtigen Vergibt Prüft, Auftragsnummer ob alle Pflichtfelder für Anfrage der Anfrage vollständig 7 AMS AMS Mitteilung an Adressat Fachabteilungskoordinatoren DV oder BOsind vollständig 8 AMS AMS Trägt in Vergibt Anfrage Auftragsnummer Status Anfrage für gestellt Anfrage ein 9 Anfrage gestellt, Ergebnis10 9 AMS Ruft Anwendungsfall Trägt in Anfrage Interessenten Status Anfrage benachrichtigen gestellt ein Mitteilung an Adressat, AMS 10 AMS Mitteilung an Adressat Fachabteilungskoordinatoren DV oder BO AMS bereit für Ruft neue Anwendungsfall Aktion Interessenten benachrichtigen Ergebnis Anfrage Mitteilung gestellt, an Adressat Fachabteilungskoordinatoren DV oder BO Ergebnis Mitteilung Anfrage an Adressat, gestellt, AMS bereit Mitteilung für neue an Adressat, Aktion AMS bereit für neue Aktion Szenarien (1 oder mehrere je Use Case) + Klassendiagramm (+ Storyboard (Screenshots)) Hochschule 1 umfaßt 1..* Fachbereich 0..1 ist Dekan von 1 1..* eingeschrieben gehört an 0..* 1..* 1 Student 1 besucht 0..* Veranstaltung 0..* lehrt 1 Lehrkraft 45 Lessons learned - Makroprozess Lesson 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 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 46

24 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 47 Vertragsmodelle nach Preisbindung Tlw. Objektspektrum 01/06 - B. Oesterreich - Der Agile Festrpeis Starrer Festpreis Klassisches Vorgehen GMP Guaranteed Maximum Price Baubranche AG Budgetsicherheit, AN Chancen auf Gewinn Anforderungen initial vollständig und starr, Change Request immer Vertragsänderung, Beidseitiges Risiko, Qualität stirbt als erstes, Preise typischerweise überhöht AG Budgetsicherheit plus Chance, unterstützt kooperative Denkweise Qualität stirbt als erstes AN weniger Chancen auf Gewinn trotz Risiko, unpassend (selbst in Baubranche kritisch diskutiert) Serien Werkvertrag Rahmenvertrag / Einzelvertrag Einzelv. Immer neu abgeschlossen je Stufe Variante: Gesamtbudget steht fest, man baut was man sich leisten kann Schrittweise Budgetsicherheit, bekannte Jura, Kompatibel mit Einkauf, 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 Agiler Werkvertrag transparentes Schätzverfahren Tausch von Features in Construction Gute Änderungsmöglichkeit, Gesamtbudget stabil Kalkulationsverfahren u.u. nicht perfekt, mangels vertrauensvoller Zusammenarbeit konfliktträchtig, hervorragender Umgang mit Change Management notwendig. 48

25 Der Agile Festpreis - Planning Game im Werkvertrag Features feat. 1 -feat. 2 -feat feat 7 -feat. n Währung?? Features feat. 4 -feat. 5 -feat feat. m Non-Features -feat. n1 -feat. n2 -feat. n feat. nn Widget Points Use Case Steps Function Points außer bei Wettersimulation 49 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 im wesentlichen vertragsgemäß (Bundesgerichtshof) Wenn es dabei Fragen gibt, suchen wir dann unsere Story Cards von der Pinwand? Tip: Manchmal wird nur eins aus Festpreis/Werkvertrag benötigt Nur Werkstück: Nur Spezifikationsdisziplin Nur Festpreis: Nur Exploration nötig 50

26 Lessons learned - Verträge Lesson 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 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 mit Gesamtpreis Gutes Changemanagement!! 51 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 52

27 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 ;-) Festpreis Long run AN wenig Interesse an Wartbarkeit Maßnahmen: Direkt auf Wartungsvertrag verpflichten Bei transparenten Schätzverfahren 53 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 hilft ;-) Projekte sind im Wesentlichen durch Einmaligkeit gekennzeichnet Potentiell verlangte unnötige Prozessmodellaufwände separat kalkulieren 54

28 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 55 Vielen Dank für Ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim Version: info@oio.de

29 ??? Orientation in Objects GmbH Weinheimer Str Mannheim? Fragen?? Version: