Software Expedition. Seminar Systems Engineering extreme Programming

Größe: px

Ab Seite anzeigen:

Download "Software Expedition. Seminar Systems Engineering extreme Programming"

Götz Kalb
vor 8 Jahren
Abrufe

1 Software Expedition Seminar Systems Engineering extreme Programming

2 Übersicht (1) Einleitung Von der klassischen Expedition zur Software-Expedition Software-Expedition als Vorgehensweise in einem instabilen Umfeld XP als Vorgehensmodell für die Software- Expedition (c) Andreas BUBLA 2

als Vorgehensweise in einem instabilen Umfeld XP als

3 Übersicht (2) Ausrüstung einer Software Expedition Vor- und Nachteile Punkte aus den Kriterienkatalog Diskussion (c) Andreas BUBLA 3

4 Einleitung Erstmals 1999 von Julian Mack erwähnt Ein Softwareentwicklungsprozess der sich leichter an Veränderungen im organisatorischen Umfeld anpasst Das Team und das Ziel steht im Mittelpunkt Anstelle von Meilensteine werden Etappen als Zielpunkte gesetzt Aktives Risikomanagement (c) Andreas BUBLA 4

organisatorischen Umfeld anpasst Das Team und das Ziel steht im Mittelpunkt

5 von der klassischen Expedition zur Software-Expedition (1) Stellt eine zeitlich begrenzte Reise dar Das Team bewegt sich in eine ihm unbekannten Raum Nur der Start und das Ziel sind bekannt Das Team muss sich gegenseitig ergänzen Teambildung (c) Andreas BUBLA 5

ihm unbekannten Raum Nur der Start und das Ziel sind bekannt Das

6 von der klassischen Expedition zur Software-Expedition (2) Die Teambildung Multifunktionales Team zusammenzustellen Personalsuche: Team stellt sich selber zusammen Die Expeditionsteilnehmer müssen sich freiwillig melden und vom Team akzeptiert werden (c) Andreas BUBLA 6

Team stellt sich selber zusammen Die Expeditionsteilnehmer müssen

7 von der klassischen Expedition zur Software-Expedition (3) Das Team bricht auf Das Team ist sich selbst überlassen Das Team plant die Aufgaben der Etappen und versucht diese zu erreichen Nach jeder Etappe wird aktuelle Position eruiert und das Risiko abgeschätzt Ist das Ziel erreicht beginnt der Rückzug (c) Andreas BUBLA 7

versucht diese zu erreichen Nach jeder Etappe wird aktuelle Position eruiert und

8 von der klassischen Expedition zur Software-Expedition (4) Vorbereitung Anreise Ausrüstung persönliche Vorbereitungen Aufbruch Unterwegs Anheuern Planung u. Logistik Point of of no return erste Auftragsklärung Evakuierung Unterwegs Idee Folgetätigkeiten Durchführung am Ziel Endspurt Nachbereitung Auswertung Rückkehr Rückzug Legende Zeitraum Zeitpunkt (c) Andreas BUBLA 8

Logistik Point of of no return erste Auftragsklärung Evakuierung Unterwegs Idee

9 Software Expedition als Vorgehensweise in einem instabilen Umfeld (1) Das Anwendungsgebiet als Territorium Konkurrenten Gesetzgeber externe Lieferanten externe Kunden Ausgangspunkt der Softwareentwickl ung Mitarbeitervertretung Behörden Anwendungsorganisation interne Standards und Normen Interessengruppen Geschäftsführung Mitarbeiter Abteilungen andere Standorte Geschäftsprozesse konkurrierende Führungskräfte Auftraggeber Projekte sonstige SystemlandschaftAnwendungsgebiet Meinungsführer Berater Anwender Fürsprecher abzulösende Key user Gegner interne Altsysteme Infrastruktur Lieferanten Entscheider betroffene Fachabteilungeninterne Kunden Tochter-, Schwester- und Mutterunternehmen Ziel der Softwareentwickl ung externe Standards und Normen Vorgehen der Softwareentwickl ung (c) Andreas BUBLA 9

konkurrierende Führungskräfte Auftraggeber Projekte sonstige SystemlandschaftAnwendungsgebiet Meinungsführer Berater Anwender Fürsprecher abzulösende Key user Gegner interne Altsysteme Infrastruktur

10 Software Expedition als Vorgehensweise in einem instabilen Umfeld (2) Die Anwendungsorganisation als Territorium aktueller Planungshorizont unerschlossenes Gelände aktuell geplantes Ziel vorgesehener Kurs aktuelle Position Problem, welches ein Verweilen erfordert Meilenstein wiederholte Passage eines Meilensteins Sackgasse Hindernis Abkürzun g Spur: tatsächliches Vorgehen geplantes Vorgehen Ende einer Etappe Umweg, der durch Hindernis erforderlich wird (c) Andreas BUBLA 10

welches ein Verweilen erfordert Meilenstein wiederholte Passage eines Meilensteins Sackgasse Hindernis Abkürzun g Spur:

11 Punkte die eine Software-Expedition beinhalten muss [Mack_2000] Teamorientierung Selbstorganisation des Expeditionsteams Light weight software development Routenmanagement Ressourcenmanagement Risikomanagement (c) Andreas BUBLA 11

Expeditionsteams Light weight software development

12 XP als Vorgehensmodell für die Pair Programming Software-Expedition Integriert wird nur Code der sicher läuft Die Testklassen als erstes erstellen, dann die zu testende Klasse Code-sharing Coding-Standard Kunde vor Ort Aktives Risikomanagement (c) Andreas BUBLA 12

Testklassen als erstes erstellen, dann die zu testende Klasse

13 Schritte zwischen zwei Etappen (1) Anforderungsdefinition durch User-Storys Der Kunde entscheidet über die Priorität der User-Storys Das Expeditions-Team wählt max. Anzahl der User-Storys für die nächste Etappe aus Die restlichen User-Storys werden in der nächsten Etappe behandelt (c) Andreas BUBLA 13

14 Schritte zwischen zwei Etappen (2) Kunde spezifiziert die Testfälle Implementierung der User-Storys Nach erreichen des Etappenziels beginnt der Ablauf von vorne bis das Ziel erreicht ist Der Kunde kann die Spezifikation nur am Anfang der nächsten Etappe ändern (c) Andreas BUBLA 14

beginnt der Ablauf von vorne bis das Ziel erreicht ist Der Kunde kann

15 Ausrüstung einer Software-Expedition (1) Multifunktionell einsetzbar Die Einrichtung soll mobil sein Einfache Bedienung der Entwicklungsumgebung (c) Andreas BUBLA 15

16 Kriterien zur Anschaffung der Ausrüstung Vertrautheit Verwendbarkeit Beweglichkeit Individualität (c) Andreas BUBLA 16

17 Vorteile (1) Das Team ist für sich selbst verantwortlich Die Mitarbeiter identifizieren sich mit den Aufgaben Der Entwickler ist vor Ort beim Kunden Aktives Risikomanagement (c) Andreas BUBLA 17

18 Vorteile (2) Fehler werden nicht bis ans Ende des Projektes mitgeschleppt Pair Programming Coding Standard 40 Std. Woche Kurze Etappen (c) Andreas BUBLA 18

19 Nachteile Bei Light Weight Prozessen ist das Ziel schwer zu kalkulieren Kosten und Ende des Projektes sind schwer abzuschätzen Unternehmen sind nicht gewillt Personal für das Projekt abzustellen Die Mobilität der Software-Entwickler (c) Andreas BUBLA 19

abzuschätzen Unternehmen sind nicht gewillt Personal für das

20 Kriterienkatalog (1) Mitarbeiter werden angeheuert Anforderungsanalyse erfolgt durch User- Storys Konzeption und Design werden auf Grund der User-Storys vorgeschlagen Implementierung erfolgt durch Pair Programming (c) Andreas BUBLA 20

und Design werden auf Grund der User-Storys vorgeschlagen

21 Kriterienkatalog (2) Tests, werden von Kunden spezifiziert und vom Entwickler als erstes implementiert Dokumentation, dazu führt der Expeditionsleiter das Logbuch. Dieses beinhaltet die Top-10 Risiken Produkt und Fehlermanagement: Fehler müssen spätestens bei der nächsten Etappe behoben sein (c) Andreas BUBLA 21

22 Kriterienkatalog (3) Risiko Management, erfolgt durch ein aktives Risikomanagement. Top-10 Risiken werden am Anfang des Projektes herausgearbeitet Projekt und Teamorganisation: Das Team ist eine eigenständige Gruppe, die der Expeditionsleiter koordiniert. Es finden täglich ein STAND UP Meeting statt. (c) Andreas BUBLA 22

23 Kriterienkatalog (4) Projektplanung, findet vor jeder Etappe durch das gesamte Team statt. (c) Andreas BUBLA 23

24 DISKUSSION Quelle: maps/ (c) Andreas BUBLA 24

Ähnliche Dokumente

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development