Agile Software Development

Größe: px

Ab Seite anzeigen:

Download "Agile Software Development"

Gregor Rosenberg
vor 8 Jahren
Abrufe

1 Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1

2 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation. Zusammenarbeit mit Kunden statt Vertragsverhandlung. Auf Veränderungen reagieren statt einem Plan folgen. 6-2

3 Individuen und Interaktion statt Prozessen und Tools. Einsicht, daß Programmierer nicht austauschbar sind. Funktionierende Software statt umfangreicher Dokumentation. Kunden haben keine Zeit eine umfangreiche Dokumentation zu lesen. Solange alles funktioniert braucht man keine Dokumentation. Zusammenarbeit mit Kunden statt Vertragsverhandlung. Zufriedene Kunden zahlen und bleiben Kunden. Auf Veränderungen reagieren statt einem Plan folgen. Bei komplexen Problemen ist ein Plan sowieso unvollständig. 6-3

Solange alles funktioniert braucht man keine Dokumentation. Zusammenarbeit mit Kunden statt Vertragsverhandlung.

4 Aufgabenplanung/ Planning Poker Team diskutiert Einzelaufgaben. Alle Teammitglieder schätzen spontan den Aufwand wenn sie diese Aufgabe durchführen würden. Höchste und niedrigste Schätzung wird vom jeweiligen Schätzer erklärt. Erneute Schätzung aller Teammitglieder. Mittelwert dieser Schätzwerte wird gebildet und ist die Punktzahl der Aufgabe. Aufgaben werden grob nach Relevanz sortiert. Im Scrum Meeting erklärt jeder an welcher Aufgabe er arbeitet. Abschätzen wieviele Punkte pro Monat abgearbeitet werden können. Guter Schätzwert was wann implementiert sein kann. 6-4

Höchste und niedrigste Schätzung wird vom jeweiligen Schätzer erklärt. Erneute Schätzung aller Teammitglieder.

5 Maßeinheiten Anzahl Zeilen Vorteile Leicht messbar Nachteile Refactoring ist sehr wichtig, wirkt sich aber negativ auf die Anzahl Zeilen aus. Ineffiziente Programmierung erzeugt hohe Werte. 6-5

6 Maßeinheiten Ideale Tage Zeit, die eine Aufgabe benötigen würde wenn man ausschließlich daran arbeitet. Vorteile Leicht erklärbar Nachteile Ein Idealer Tag wird gerne mit einem realen Tag gleichgesetzt und der Unterschied übersehen. Eine typische Arbeitswoche hat nur 2-3 Ideale Tage. Mit zunehmender Erfahrung benötigt man weniger Ideale Tage für eine Aufgabe. Ideale Tage sind je nach Person unterschiedlich lang. 6-6

der Unterschied übersehen. Eine typische Arbeitswoche hat nur 2-3 Ideale Tage.

7 Maßeinheiten Story Points Maßeinheit für die Komplexität einer Aufgabe. Vorteile Schätzungen sind stabil. Mit zunehmender Erfahrung steigt die Geschwindigkeit. Es ist leichter die Komplexität von Aufgaben zu vergleichen statt absolute Werte zu bestimmen. Nur die relative Komplexität ist relevant für die Berechnung. Leicht summierbar. Nachteile Schwierig zu erklären. Keine anschauliche Erklärung. 6-7

Es ist leichter die Komplexität von Aufgaben zu vergleichen statt absolute Werte zu bestimmen.

8 Extreme programming Abkürzung XP: XP Team, XP Methode, Zwei Programmierer arbeiten als Team und Programmieren jeweils gemeinsam an einem Bildschirm und einer Tastatur. Vier Augen sehen mehr als zwei. 6-8

9 Extreme programming Den Wald vor lauter Bäumen nicht sehen. Beim Programmieren löst man viele Probleme sehr schnell und einige wenige dauern sehr lange. Der Aufwand pro Problem ist nicht normalverteilt. Die meiste Zeit steckt in wenigen Problemen die lange dauern und nicht in den vielen die kurz dauern. Wenn zwei Programmieren bei jeweils anderen Problemen lange brauchen, dann sind sie unter Umständen mehr als doppelt so schnell wenn sie zusammenarbeiten. 6-9

Der Aufwand pro Problem ist nicht normalverteilt.

10 Extreme programming Die Teams müssen aus etwa gleich guten Software Entwicklern bestehen. Die Software Entwickler müssen sehr eng zusammenarbeiten ohne sich auf die Nerven zu gehen. Es ist nicht leicht zu vermitteln wieso zwei Leute an ein Problem gesetzt werden. Programmieren wird in XP primär als kreative Tätigkeit und nicht als Ingenieurstätigkeit gesehen. Effizienter Erfahrungsaustausch zwischen Entwicklern. 6-10

Es ist nicht leicht zu vermitteln wieso zwei Leute an ein Problem gesetzt werden.

11 Übung Body Controller Body Controller requirements gegeben. Work Items aus Requirements ableiten Framework 6-11

12 Übung Szenario Body Controller Motorelektronik Zündung Sensoren Amaturenbrett Licht Klima Entertainment System Navigationssystem 6-12

13 Übung Work Items Armaturenbrett Tacho Blinker Werkstattanzeige Lüftung Entertainment System Tempomat Fernlichtanzeige 6-13

14 Übung Work Items mit Karten schnell bewerten. Verdeckt auswählen und gleichzeitig aufdecken. Karten 1-10 oder typische auch 1,3,6,10. Höchster und niedrigster Schätzer muss die Einschätzung erlären. Erneute Schätzung des Aufwandes des Work Items. Mittelwert der Schätzung bilden und verwenden. Anordnen der Work Items nach Priorität (z.b. vom Marketing) 6-14

Höchster und niedrigster Schätzer muss die Einschätzung erlären.

15 Übung Sprint Thema bestimmen Work Items die zu dem Thema passen angehen Oder der Priorität nach Work Items angehen. Etwas Flexibilität möglich, damit man Work Items aus seinem Spezialgebiet auswählen kann. Absprechen. 6-15

16 Übung Einen Sprint später gibt es erledigte Work Items. Anzahl der erledigten Story Points bestimmen. Geschwindigkeit (Velocity) pro Sprint. 6-16

17 Übung Schätzung, wann ist alles abgearbeitet? Schätzung, wieviel ist bis zu einem bestimmten Termin abgearbeitet? 6-17

18 Übung 6-18

19 Übung 6-19

Ähnliche Dokumente

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was