Agile Softwareentwicklung: Extreme Programming (XP) erklärt
4.2 (33 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
312 students enrolled

Agile Softwareentwicklung: Extreme Programming (XP) erklärt

Eine echte Alternative zu SCRUM und KANBAN. Jeder, der agil arbeitet, sollte XP kennen! So modern wie eh und je.
4.2 (33 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
312 students enrolled
Created by Thorsten Diekhof
Last updated 11/2019
German
Current price: $51.99 Original price: $74.99 Discount: 31% off
5 hours left at this price!
30-Day Money-Back Guarantee
This course includes
  • 3.5 hours on-demand video
  • 3 articles
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Du kennst Extreme Programming!
  • Du kannst besser agil Denken.
  • Du kennst viele tolle Werte und Prinzipien des Extreme Programmings
  • Du hast Spaß daran, extremer zu programmieren!
Requirements
  • Kein Vorwissen.
  • Interesse am agilen Arbeiten wünschenswert.
  • Grundkentnisse im agilen Arbeiten helfen weiter.
Description

Agiles Arbeiten ist in aller Munde. SCRUM und Kanban werden in immer mehr Firmen erfolgreich (und weniger erfolgreich) eingeführt. Es scheint fast so, als wäre agiles Arbeiten "der neuste Schrei".

Dabei gibt es erste Ansätze des agilen Arbeitens schon recht lange. Auch agile Methoden zum Entwickeln von Software gab es schon im letzten Jahrhundert. Einer der besten Ansätze hier ist XP - Extreme Programming wurde kurz vor der Jahrtausendwende von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt und benutzt.

Trotzdem ist es enorm modern! Ja, in vielerlei Hinsicht, ist es moderner, als z.B. Scrum.

Jeder, der sich mit agiler Softwareentwicklung auseinandersetzt, sollte Extreme Programming kennen. Alleine schon, da hier Agilität so richtig pur daherkommt und extrem genutzt wird. Diese Einfachheit macht es so spannend. Sie ermöglicht auch viele gute Erkenntnisse über das agile Arbeiten.

Extreme Programming bedeutet, man nehme agiles Denken und funktionierende Techniken der Softwareentwicklung und nutze diese EXTREME.

Du musst diesen Kurs belegen, wenn du Agilität wirklich verstehen willst!

Dabei steht der Entwickler komplett im Mittelpunkt. Anders, als z.B. in Scrum, wo sich immer mehr Coaches und "Fachfremde" tummeln, ist Extreme Programming von Entwicklern, für Entwickler.

In diesem Kurs geht es vordergründig nicht darum, zu verstehen, was Agilität ist. Trotzdem wird dieses einem durch XP enorm schnell klar.

Also, schreib dich ein, wenn du wirklich extrem gute Software entwickeln willst oder deine Skills in agiler Entwicklung auf einen neuen Stand heben willst!

Who this course is for:
  • Entwickler.
  • Agile Coaches
  • Menschen, die agil arbeiten. Zum Beispiel mit Scrum oder Kanban.
  • Programmierer.
Course content
Expand all 64 lectures 03:18:45
+ Einleitung
8 lectures 52:21

Das Grundproblem des Softwareentwicklung ist, dass sie Risiko beinhaltet. Terminverzögerungen, Projektabbruch, Unrentables System, Fehlerrate, Falsch verstandenes Geschäftsziel, Sich änderndes Geschäftsziel, Falsche Funktionsfülle, Personalwechsel usw.

Risiko!
10:36
  1. Aufwand fest, Zeit und Umfang variable.

  2. Selbstorganisiertes Team

Grundlagen des agilen Arbeitens
09:47

Es ist eine agile Methode, die verschiedenste Verfahren aufzeigt, die zusammen dazu da sind, Software zu entwickeln. Jedes Verfahren kann für sich genutzt werden - zusammen sind sie jedoch besonders effektiv.

Preview 08:42

Das System wird in einfachen Stories unterteilt und so beschrieben. Eine Story ist ein textliches, beschreibendes Verhalten des Systems. Beispiel: Der Kunde sieht immer, wie viele Produkte sich schon in seinem Einkaufskorb befinden.

Diese Stories werden so lange besprochen, bis jeder Beteiligte weiß, was damit gemeint ist. Dann werden sie geschätzt. Die wertvollsten geschätzten Stories bilden die Grundlage für die erste Version der Software.

Diese wird in Iterationen (1-3 Wochen) erstellt. Hierzu werden aus den Stories Tasks erstellt. Diese werden testgetrieben und in Pair Programming umgesetzt.

Wichtig hierbei ist ein einfaches Design und eine kontinuierliche Integration der Aufgaben ins Gesamtsystem.

Am Ende einer Iteration steht immer ein funktionierendes System.

Das Leichtgewichtige am XP wird erreicht, indem Planung, Anweisungen, Arbeitsteilung, Dokumentation und Architektur ersetzt werden durch einen Werte- und Prinzipienkatalog, Teamarbeit, das Streben nach gemeinsamem Verständnis und einem einfachen Design.

Übersicht über XP
07:41
Vergleich: SCRUM und XP
04:42

Es gibt auch Schwierigkeiten beim Extreme Programming. Erstmal ist da die Befremdlichkeit, die das agile Arbeiten bei Menschen auslöst, die bisher klassisch gearbeitet haben. XP klingt so einfach. Ist es auch. Die Einfachheit ist auch eine Schwierigkeit. Denn, gerade bei uns in Deutschland, wird Einfachheit oft nicht ernst genommen. Dabei ist Einfach nicht gleich leicht.

Komplizierte Dinge sind leichter anzugehen. Dieser Paradigmawechsel ist schwierig.

Auch fordert XP dazu auf, Dinge zu lernen. Ständig zu lernen. Es sagt auch ganz klar, dass man viele Dinge nicht weiß. Dies einzusehen ist nicht einfach.

Kommunikation ist beim XP ein zentrales Element. Hier geht es auch um Gefühle und Intuition. Das ist - gerade auch für Entwickler - nicht einfach.

Entscheider denken schnell: Wenn es so einfach ist, kann es nicht gut sein. Es muss einen Haken geben.

Der Haken ist: Man muss sich darauf einlassen.

Schwierigkeiten von XP
06:18
Wert, Prinzip und Technik
02:35
+ XP-Werte
4 lectures 08:34

Fast alle Probleme lassen sich auf schlechte oder ausbleibende Kommunikation zurückführen.

Viele Umstände tragen zum Scheitern von Kommunikation bei:

  1. Überbringer schlechter Nachrichten werden bestraft

  2. Programmierer ignorieren wichtige Informationen vom Kunden

  3. Programmierer und Kunde nutzen die Selben Wörter - sprechen jedoch über andere Konzepte

  4. Zwei Programmierer entwickeln das selbe Feature, reden jedoch nicht miteinander

  5. Der Code besitzt keine einheitliche Form und ist daher schwer zu lesen

Preview 02:44

Man soll sich immer Fragen "Wie sieht die einfachste Lösung aus?".

Einfachheit ist schwierig. Es ist immer leichter, Dinge "einfach so" umzusetzen. Dann kommen aber fast immer komplizierte Lösungen dabei raus. Auch wird häufig zu weit in die Zukunft gedacht und dies direkt mit umgesetzt. So werden oft viele Dinge umgesetzt, die wahrscheinlich niemals so gebraucht werden.

XP  ist hier eine Wette. Man wettet darauf, heute etwas Einfaches zu tun und morgen etwas mehr zu zahlen, wenn man es ändern muss, statt heute etwas Kompliziertes zu tun, das vielleicht niemals eingesetzt wird.

Einfachheit
02:31

Feedback ist zentral. Vom System, vom Kunden, von anderen Entwicklern oder vom Nutzer.

Feedback vom System ist unendlich wertvoll für einen Programmierer. Das System sollte so entwickelt werden, dass es innerhalb von Sekunden Feedback über seinen Status gibt.

Kunden sollten so eingebunden sein, dass sie immer Feedback zum aktuellen Stand und den Fragen der Programmierer geben können.

Die Entwickler sollten sich gegenseitig häufig, wertvolles Feedback zu ihrer Arbeit geben.

Der Nutzer sollte so schnell wie möglich das Produkt nutzen können um Feedback geben zu können.

Feedback
02:23

Viele Dinge, die gute Programmierer tun müssen, erfordert Mut. Ein Projekt, dass sich verrannt hat, muss zum Teil erneut angegangen werden. Code der nicht mehr gebraucht wird, muss weggeschmissen werden. Ein Problem muss dem Kunden so schnell wie möglich mitgeteilt werden. All diese Dinge brauchen Mut. Sie müssen aber gemacht werden. Werden sie herausgezögert, werden sie immer schwerwiegender und gefährden die gesamte Arbeit.

Mut
00:56
+ XP-Grundprinzipien
5 lectures 13:55

Alles beim XP sollte so angelegt sein, dass jeder so unmittelbares Feedback wie möglich, für seine Arbeit bekommt.

Hier können es für die Entwickler durch automatisierte Tests Sekunden oder Minuten sein. Für Rückmeldung vom Nutzer sollten nicht mehr als ein paar Tage oder Wochen vergehen. Der Kunde sollte tägliche Rückmeldung geben können.

Umso schneller und gleichmäßiger - umso besser.

Umittelbares Feedback
02:23

Jedes Problem soll so behandelt werden, als wäre es lächerlich einfach zu lösen.

Die Zeit, die bei den 98% der Problemen gespart wird, bei denen dies zutrifft, kann dann für die 2% wirklicher Probleme verwendet werden.

Programmierer akzeptieren dies fast nie. Sie planen für die Zukunft und bauen Alles so abstrakt und "wiederverwendbar", dass eine Änderung dieser Angewohnheit enorm schwierig sein kann.

Statt zu Planen, ist die Fähigkeit, Komplexität bei Bedarf hinzuzufügen zu können, viel wichtiger. Sie sollte besonders trainiert werden.

Einfachheit anstreben
04:14

Große Brocken sind schlechter umzusetzen, als kleine Stückchen. Daher sollte Software immer inkrementell umgesetzt werden. Kleine, funktionierende Einheiten, die separat getestet werden können.

Jedes Problem wird durch eine Reihe kleiner, aber wirkungsvoller Änderungen gelöst.

Inkrementelle Veränderung
02:19

Die beste Strategie ist diejenige, die das dringendste Problem löst und gleichzeitig die meisten Optionen offen hält.

Veränderungen haben einen Grund. Fast immer ist dies ein guter Grund. Daher sollten Veränderungen begrüßt werden. Sie gehören zur Arbeit eines Entwicklers einfach dazu.

Veränderungen wollen
02:00

Arbeit die schlampig durchgeführt wird, macht keinen Spaß. Dem Programmierer nicht, dem Kunden nicht, dem Nutzer nicht. Niemanden.

Daher sollten die Ansprüche an die Qualität der Arbeit niemals verringert werden.

Qualitätsarbeit
02:59
+ Programmieren, Testen, Zuhören und Designentwurf
5 lectures 15:19

Das kennt fast jeder erfahrene Entwickler. Da hat man eine Programmiersprache gelernt und macht sich auf, das erste größere Programm zu schreiben. Doch es klappt nicht wirklich.

Man kann zwar Programmieren - aber zur Softwareentwicklung gehört so viel mehr. Programmieren macht nur einen kleinen Teil davon aus.

Entweder man verzweifelt, kommt in ein Team, dass einen sagt, was man programmieren soll, oder man versteht, dass da mehr ist - und bringt sich dieses bei.

Preview 04:47

Grundlage jeder Softwareentwicklung ist das Programmieren. Wir als Entwickler müssen verstehen, wofür Programmieren da ist. Es setzt Gedanken um in ausführbare Programme.

Es dient als wunderbares Kommunikationsmittel.

Programmieren
02:47

Wenn wir etwas programmiert haben, müssen wir testen, ob es auch das ist, was wir uns gedacht haben. Hierzu nutzen wir natürlich automatische Tests. XP sagt: Was nicht automatisch getestet ist, gibt es nicht.

Als Entwickler müssen wir uns daher mit automatisierten Tests auseinandersetzen. Und zwar genauso intensiv, wie wir uns mit dem Programmieren auseinandersetzen.

Testen
01:31

Wenn Ideen ohne Programme in die Welt kommen könnten - würden wir Entwickler ganz schnell arbeitslos sein. Wir setzen Ideen anderer Leute um - und zwar für andere Leute.

Wir haben Ahnung vom Programmieren - aber erstmal keine Ahnung von der Domäne unserer Kunden und Nutzern.

Daher müssen wir zuhören können. Den Kunden, den Managern, den Nutzern und den Kritikern.

Zuhören ist so wichtig, dass wir hier unbedingt enorme Kompetenz aufbauen sollten.

Zuhören
04:24

Einfach nur zuhören, Test schreiben und Programmieren klappt so nicht. Irgendwann kommt so ein Vorgehen an seine Grenzen.

Ohne sich Gedanken über die interne Struktur eines Codes zu machen, stößt diese schnell an Grenzen. Neue Features sind nur noch enorm aufwändig zu verwirklichen. Bugs werden nicht mehr gefunden. Der Code wird unverständlich und irre kompliziert.

Daher müssen wir Entwickler lernen, wie man gutes Design - eine saubere und gute Struktur des Codes - entwerfen kann.

Dies müssen wir von Zeit zu Zeit auch anwenden.

Design entwerfen
01:50
+ Weitere XP-Prinzipien
10 lectures 24:06

Statt den Programmierern zu sagen, wie sie Etwas zu erledigen haben, sollte man sich darauf konzentrieren, Strategien zu lehren, wie man lernt und wie man entscheiden kann, was wie zu erledigen ist.

Lernen lehren
01:52

Man soll mit knappem Budget rechnen. Dieses zwingt Programmierer und Kunden dazu, Anforderungen und Ansätze zu beschneiden. Sie werden ermutigt, möglichst gute und einfache Arbeit zu liefern.

Wenn die Ressourcen zu knapp sind - es sich nicht mal ein wichtiges Problem damit lösen lässt - ist das Projekt nicht interessant.

Man merkt dadurch oft, dass man mit viel weniger Ressourcen auskommt, als erwartet.

Kleine Anfangsinvestition
02:24

Viele Entwickler wollen, dass ein Projekt nicht scheitert. Sie tun Alles, damit das Projekt nicht scheitert. Wenn es scheitert, dann soll es wenigstens nicht die eigene Schuld sein - schließlich hat man sich an alle Regeln gehalten.

Dieses Prinzip sagt: Tu alles, damit das Projekt ein Erfolg wird. Dies ist die richtige Sichtweise.

Spielen, um zu gewinnen
02:11

Entscheidungen, die ohne Überprüfung gefällt werden, haben eine Wahrscheinlichkeit, dass sie falsch sind.

Daher sollten wichtige Entscheidungen durch gezielte Experimente überprüft werden.

Wenn z.B. über das Design der Software gesprochen wird, sollte das Ergebnis eine Reihe von Experimenten sein, deren Ergebnisse, dann zum Design führen - statt eines fertigen Designs, dass nur "besprochen" wurde.

Gezielte Experimente
01:59

Man sollte auf Augenhöhe und mit Professionalität kommunizieren. Hier sollte man auch in der Lage sein, sein Fachgebiet zu erklären. Vor allem die Konsequenzen, die aus bestimmten Handeln entstehen, sollen kommuniziert werden.

Offene, ehrliche Kommunikation
02:44

Extreme Programming geht davon aus, dass ein Team aus erfahrenen Entwicklern, von sich aus instinktiv gute Software entwickeln kann. Diese Instinkte, diese Intuition sollte man unbedingt nutzen.

XP - und auch andere Methoden - sollten nur dazu dienen, dem Team die richtige Richtung zu zeigen und ihnen Werkzeuge zu geben, damit sie diese immer wieder anpeilen können.

Die Instinkte des Teams für sich nutzen, nicht dagegen arbeiten
01:51

Als Team soll man Verantwortung übernehmen, statt nur darauf zu warten, dass einem gesagt wird, was zutun ist. Hierbei geht es nicht um das Picken von Rosinen.

Verantwortung übernehmen motiviert auch ungemein.

Verantwortung übernehmen
02:30

XP sagt ganz klar, dass man die vorgestellten Verfahren, an die eigenen Gegebenheiten anpassen soll. Jedes Team, jede Firma ist anders und sollte anders arbeiten.

Keiner soll nach dem Schauen eines solchen Kurses sagen: Ah, so geht das.

ABER: Wer keine Erfahrung besitzt, kann häufig nicht gut entscheiden, was wirklich wichtig ist und wie so eine angepasste Methode aussehen könnte. Daher sollte man erst mit größer werdender Erfahrung Methoden anpassen.

An örtliche Gegebenheiten anpassen
03:26

Softwareentwickler haben immer viel Kram, den sie mit sich rumschleppen. Programmiersprachen, Frameworks, Methoden, Entwicklungsumgebungen und so weiter. Was soll hier bevorzugt werden?

Wir sollten Dinge bevorzugen, die

  • wenig

  • einfach

  • wertvoll

sind.

Mit diesen Dingen im Gepäck, kann man schnell die Richtung ändern. Wir sollen nicht an schweren Dingen hängen. Dicken Frameworks oder Umgebungen.

Mit leichtem Gepäck reisen
02:45

Seine Arbeit zu messen ist wichtig und wird häufig gemacht.

Wir sollten bei unseren Messungen jedoch ehrlich zu uns sein. Aufwände lassen sich nicht in Minuten rechnen. Niemanden ist etwas damit geholfen, statt "grob 2 Wochen" von 9,76 Tagen zu sprechen.

Also, messen ja - aber sich klar darüber sein, was genau diese Messung aussagt.

Ehrliches Messen
02:24
+ Die XP-Rollen
8 lectures 22:11

Es braucht bestimmte Rollen, um mit XP arbeiten zu können.

Auch wenn die Verantwortung für ein gutes Gelingen der Entwicklung bei allen Beteiligten liegt, gibt es bestimmte Personen, die für einen bestimmten Bereich mehr Verantwortung tragen.

Die Leute müssen für die Rollen passen. Es gibt jedoch einige Grundideen:

Programmierer sind nicht gleichzeitig Kunden.

Technische Entscheidungen sollen von geschäftlichen Entscheidungen getrennt sein.

Ausnahmen bestätigen hier natürlich wieder die Regel. Aber auch hier muss man genau wissen, was man tut.

Eine Person kann auch mehrere Rollen einnehmen. Hierbei muss man jedoch sorgfältig sein.

Rollenverteilung
02:43

Programmierer stehen beim XP im Mittelpunkt. Könnten sie von sich aus, alle kurzfristigen und langfristigen Interessen sorgfältig gegeneinander abwägen, bräuchte es nur Programmierer.

Ihre Schwerpunkte sind andere, als in klassischen Projekten. Neben dem Programmieren müssen sie auch viel kommunizieren und vereinfachen.

Sie müssen z.B. mit dem Kunden diskutieren, ob bestimmte Dinge wirklich erforderlich sind. Aber auch der Code soll einfach sein.

Ein Programmierer soll eine Hand voll Tools verfügen, die er wirklich beherrscht und die gut eingesetzt werden können - statt zu viele Konzepte und Ansätze zu kennen, und damit eine aufwändige Lösung zu riskieren.

An Fähigkeiten muss er einigermaßen gut programmieren können Refactoring betreiben können und man muss den Code automatisiert testen können.

Ohne Mut geht es nicht. XP-Programmierer müssen auch mit Ängsten klarkommen.

  • für dumm gehalten zu werden

  • für nutzlos gehalten zu werden

  • überflüssig zu werden

  • nicht gut genug zu sein

Wer den Weg geht, wird auch Spaß an der Softwareentwicklung haben.

Programmierer
04:06

Der Programmierer weiß, wie man programmiert. Der Kunde weiß, was programmiert werden soll. Zumindest will er dies herausfinden und lernt daher immer dazu.

Ein XP-Kunde muss einige Methoden kennen - z.B. das Planungsspiel. Auch muss er eine Haltung haben und sich daran gewöhnen, dass Projekt zwar beeinflussen, aber nicht kontrollieren zu können.

Kunden fällen Geschäftsentscheidungen - das ist eine der schwierigsten Fähigkeiten überhaupt.

Klassische Kunden, sind es gewohnt, dass die IT nicht die Hälfte von dem fertig bekommt, was sie verspricht und/oder die Hälfte von dem, was sie fertigstellt einen Fehler hat. Daher geht er auch nicht mehr auf die Wünsche der IT ein.

XP braucht einen anderen Kunden. Die Programmierer müssen ihrem Kunden aber auch klar machen können, wieso Etwas so und nicht so gemacht werden soll.

Auch müssen Kunden Funktionstests schreiben. Sie müssen die Testfälle erstellen, mit denen die Funktionalität des Systems getestet wird. Akzeptanztests.

Kunde
02:29

Das Testen der Units liegt beim XP in der Verantwortung der Programmierer. Tester sind dennoch als Rolle wichtig, denn sie helfen dem Kunden dabei Funktionstests zu schreiben und durchzuführen.

Es geht beim Tester also darum, dass er die Anforderungen an das System, aus Sicht des Kunden, testet.

Hierfür arbeitet er eng mit dem Kunden zusammen.

Tester
02:08

Der Terminmanager wird im XP als "das Gewissen" des Teams bezeichnet.

Er ist für die Schätzungen und den Liefertermin zuständig. Er schätzt nicht selbst - dies wird von demjenigen gemacht, der eine Funktionalität auch umsetzt - aber, er fordert die Schätzung ein.

Der Terminmanager hält auch das gesamte Projekt im Blick. Er macht das Team darauf aufmerksam, wenn die Zeit knapp wird oder man im Verzug ist.

Er ist kein Chef und ist nicht dafür da Überstunden anzuordnen.

Terminmanager
02:50

Der Coach ist für den Gesamtprozess verantwortlich. Er soll das Team dabei unterstützen, in die richtige Richtung zu laufen.

Wenn sich das Team verzettelt, soll der Coach es darauf aufmerksam machen. Dabei soll er so wenig wie möglich eingreifen, dann jeder Eingriff nimmt dem Team Selbstbewusstsein. Es kann jedoch auch notwendig sein, ein wenig konkreter einzugreifen. Dies sollte jedoch nur so lange gemacht werden, bis das Team wieder in die richtige Richtung läuft.

Ein Coach sollte - und das ist der Unterschied zu SCRUM - auch technisch in der Lage sein, gutes Design und die Fähigkeiten für XP zu lehren. Er muss nicht der beste Programmierer sein - aber er muss erkennen, wo noch Defizite im Team herrschen. Dieser Teil kann in einigen Situationen auch von einem anderen erfahrenen Teammitglied übernommen werden.

Umso erfahrener das Team wird, umso weniger wichtig wird der Coach.

Coach
04:34

XP-Programmierer sind selten Spezialisten. Daher kann es immer mal wieder einzelne Situationen geben, bei denen das Team einen Spezialisten braucht. Diese nehmen im XP die Rolle des Beraters ein. Sie sind temporär Teil des Teams, um eine klare Aufgabe zu lösen oder dem Team das Wissen zum Lösen der Aufgabe zu lehren.

Das Team sollte einem Berater nicht einfach so vertrauen. Es sollte nachfragen, diskutieren und verstehen, was der Berater vor hat.

Berater
00:56

Der Boss ist dafür da, dem Team Mut zu machen. Er steht außerhalb des Prozesses und muss sich nicht mit XP auskennen. Er muss nur akzeptieren, dass die Entwickler anders arbeiten, als er es gewohnt ist.

Auch muss ihm klar sein, dass Kommunikation von Seiten des Teams ehrliche und offene Kommunikation ist. Kein Gejammer oder überzogene Angstmache.

Big Boss
02:25
+ Das Planungsspiel
6 lectures 22:31

Es wird ein grober Plan entworfen. Dieser wird ständig weiter verbessert. Hierbei gelten immer kürzere Zeiträume.

Der Plan wird schnell und kostengünstig erstellt.

Er dient unter anderem den Zwecken

  • ein Team zusammenzuführen

  • über Umfang und Prioritäten zu entscheiden

  • das Vertrauen aller Beteiligten zu stärken, dass das System tatsächlich implementiert werden kann

  • einen Fixpunkt für regelmäßiges Feedback zur Verfügung zu stellen

Folgende Prinzipien finden Anwendung:

  • Detailliert wird immer nur die nächste Iteration geplant. Alles danach wird nur anhand von Stichpunkten geplant.

  • Verantwortung kann nur übernommen werden. Ein Manager kann das Team nur bitten, die Verantwortung zu übernehmen - und sich dann dessen Reaktion anhören

  • Die Person, die für die Implementierung verantwortlich ist, schätzt den Aufwand

  • Abhängigkeiten ignorieren. Jedes Teil soll so implementiert werden, dass die Teile beliebig vertauscht werden könnten.

  • Die Prioritäten ergeben sich nach dem Geschäftswert.

Planung in XP
03:35

Das Piel hat 3 Phasen

  • Erforschen - Herausfinden, was das alte System geleistet hat

  • Verpflichtung - Entscheiden, welche Anforderungen als nächstes in Angriff genommen werden

  • Steuerung - Die Entwicklung wird gesteuert, wobei die Realität den Plan formt

Phasen des Spiels
02:20

Bewusstsein für das gesamte System bekommen.

1. Stoycard schreiben - Die Geschäftsseite schreibt auf eine Storycard, was das System leisten soll. Leistungsmerkmale werden beschrieben und es wird auch das WIESO geklärt.

2. Storycard einschätzen - Die Entwickler schätzen die optimale Entwicklungszeit.

3. Storycard aufteilen - Wenn sie das nicht können oder die Geschäftsseite erkennt, dass ein Teil der Story wichtiger ist als ein anderer, wird die Storycard mit den Kunden weiter erläutert und/oder aufgeteilt.

Erforschungsphase
04:22

Datum und Umfang der nächsten Version werden festgelegt und die Entwickler commiten sich darauf.

1. Nach Wert sortieren - Die Geschäftsseite teilt die Storycards in drei Stapel.

  • Das System funktioniert nicht ohne diese Storys

  • Leistungsmerkmale der Story sind weniger wichtig, liefern jedoch enormen Geschäftsgewinn

  • Leistungsmerkmale sind wünschenswert, aber nicht unbedingt erforderlich

2. Nach Risiko sortieren - Die einzelnen Stapel werden jeweils in drei Stapel geteilt

  • Die Leistungsmerkmale können genau eingeschätzt werden (da schon bekannt oder sehr einfach)

  • Die Leistungsmerkmale können halbwegs eingeschätzt werden

  • Die Leistungsmerkmale können nicht eingeschätzt werden

3. Geschwindigkeit festlegen - Die Entwicklerseite teilt mit, mit welcher idealen Geschwindigkeit sie pro Kalendermonat entwickeln kann.

4. Die Geschäftsseite wählt die Storycards für eine Version aus, indem sie entweder

  • ein Datum festlegt, und dann Storycards je nach Schätzung und Geschwindigkeit auswählt, oder

  • Storycards auswählt, und das Datum für die nächste Version berechnet

Verpflichtungsphase
05:08

Zweck ist, den Plan ständig an die Gegebenheiten und Geschwindigkeiten anzupassen. Hierzu gibt es die Iteration von einer bis drei Wochen länge.

1. Iteration - Am Beginn jeder Iteration wählt die Geschäftsseite die Elemente aus, die während dieser einen Iteration entwickelt werden können. Die erste Iteration soll zu einem funktionsfähigem System führen.

2. Plankorrektur - Wenn erkannt wird, dass das Tempo langsamer ist, schätzen die Entwickler neu, und der Umfang der Version wird angepasst.

3. Neues Leistungsmerkmal - Wenn die Geschäftsseite ein neues Leistungsmerkmal braucht, kann sie das als Storycard schreiben. Die Entwicklung schätzt die Storycard ein und die Geschäftsseite entfernt andere Storycards mit gleichem oder höherem Aufwand aus der aktuellen Version.

4. Neueinschätzung - Wenn der Plan den Entwicklungsverlauf nicht mehr genau genug beschreibt, kann eine Neueinschätzung gemacht werden.

Steuerungsphase
03:51

Jede Iteration (1-3 Wochen) hat ihre eigene Planung. Diese wird jedoch nur von den Entwicklern ausgeführt. Hier werden die Storycards in sogenannte Taskcard aufgeteilt. Diese werden übernommen und geschätzt.

Iterationsplanung
03:15
+ XP-Techniken
12 lectures 26:51

Grundidee ist, dass gleiches Verständnis zwischen Kunde und Entwickler zentral für eine gute Softwareentwicklung ist. Daher muss ein Kunde direkt vor Ort mit bei der Entwicklung dabei sein.

Hier wird als Kunde derjenige angesehen, der das Programm auch benutzt - bzw. die Vision des Programmes entwickelt hat.

Der Kunde vor Ort
02:10

XP setzt auf Metapher, wenn es um das Reden über ein Produkt oder Programm geht.

Eine Metapher ist ein sehr gutes Mittel, um ein gemeinsames Verständnis von einer Vision zu bekommen.

Eine klare Metapher hilft Allen, das Produkt zu begreifen.

Metapher
01:49

Jeder im Team ist für den gesamten Code verantwortlich. Nur so entsteht funktionierende Software.

Wissensinseln sollen abgebaut werden. Es gibt kein "mein Code" und "dein Code".

Durch Versionskontrolle, gute Kommunikation und automatisierte Tests gibt es genug Sicherheit, dass gemeinsame Verantwortung ein großer Vorteil ist und nur wenige Risiko birgt.

Gemeinsame Verantwortung
01:39

XP geht in Iterationen vor. Ständig werden lauffähige Versionen der Software bereitgestellt. Daher ist eine fortlaufende Integration sehr wichtig.

Neue Features sollten klein sein. Sie sollten automatisiert getestet sein und dann in den bestehenden Code integriert werden.

Am besten sollte dies automatisch geschehen.

Fortlaufende Integration
01:24

Innerhalb eines Codes, sollen einheitliche Progammierstandards  verwendet werden. Hierbei sollte sich das Team freiwillig auf einen Standard verständigen.

Ein Standard soll das Arbeiten erleichtern. Am besten gehst du da nicht zu dogmatisch vor. Er sollte leichtgewichtig und einfach sein und jederzeit den Bedürfnissen angepasst werden können.

Programmierstandards
02:02

Zentrale Technik im XP. Programmiert wird immer im Paar. Zu zweit sitzt man vor der selben Aufgabe und vor dem selbe Code. Ja, am selben Rechner.

Es gibt verschiedene Ausführungen vom Pair Programming. Typisch ist, dass einer den Code schreibt und der andere seine Kommentare dazu abgibt. Pair Programming ist auch immer Kommunikation.

Die Rollen "Pilot" und "Navigator" werden häufig gewechselt. Auch die Paare werden innerhalb des Teams durchmischt.

Pair Programming
04:49

Einfaches Design und dummes Design liegen leider direkt nebeneinander. Daher muss man aufpassen, dass man wirklich einfach bleibt.

Hierfür sollte man Refactoring zur täglichen Praxis erheben und nicht davor zurückscheuen, den Code jederzeit zu ändern, wenn man merkt, dass das Design nicht passt.

Auch sollte man eine klare, prägnante Metapher haben, damit man sicher sein kann, dass auch zukünftiger Code dieser Metapher folgt. So kann man das Design so wählen, dass es die Metapher unterstützt und sie nicht behindert.

Wenn man als Paar programmiert, ist es einfacher, einfaches Design zu entwickeln.

Hierzu ist Clean Code und objektorientiertes Design enorm wichtig. So helfen z.B. die SOLID-Prinzipien enorm dabei, die Software flexibel und stabil zu machen.

Einfaches Design
02:58

Tests schreiben macht Spaß wenn es ein einfaches Design gibt. Ist das Design zu ausladend oder zu komplex, werden dies die Tests auch. Dann beschäftigt man sich als Entwickler 80% seiner Zeit mit Testen. Das sollte nicht sein.

Automatische Tests sind über­le­bens­wich­tig. Sie machen stolz und erzeugen einen doppelte Boden. Es gibt weniger Bugs und man erstellt signifikant häufiger die Software, die der Kunde auch haben will.

Testen
01:25

Jeder sollte für den gesamten Code verantwortlich sein und ihn ändern dürfen. Hier kommt Refactoring ins Spiel. Dies bedeutet die Technik, Code so anzupassen, dass das Design sich ändert, das Verhalten jedoch gleich bleibt.

Diese Technik ist enorm wichtig für uns Entwickler. So verbessern wir jeden Tag unseren Code und unser Design.

Pfadfinderregel anwenden: Verlasse ein Stück Code immer ein bisschen besser, als du es vorgefunden hast.

Refactoring
02:13

20% des Aufwands ist für 80% der Features zuständig.

20% der Funktionen werden 80% der Zeit genutzt.

20% Können in einer Technik, ermöglicht 80% der Anwendungen.

Die 20:80 Regel
02:33

Hier ist der Schreibtisch, das Teambüro und auch der Rechner gemeint. Spielt damit rum. Whiteboardwände, Sitzecken oder sonstige Ideen. Heutzutage immer häufiger anzutreffen - damals noch recht neu.

Jeder Entwickler soll sich auch seine eigene Hardware und Software aussuchen können. So ist er motivierter und produktiver

Experiemente mit der Arbeitsumgebung
02:07

Dies soll ganz klar anmerken, dass Überstunden nicht gut sind. Softwareentwicklung ist eine anstrengende, hoch konzentrierte Tätigkeit. Niemand kann längere Zeit hinweg 60 Stunden pro Woche gute Arbeit abliefern.

Wenn Überstunden anstehen, gibt es ein Problem, dass sich nicht durch Überstunden lösen lässt.

40-Stunden Woche
01:42
+ XP in der Praxis
3 lectures 08:55

Das ist ganz einfach. Man setzt sich mit allen Verantwortlichen und Mitwirkenden zusammen und entscheidet, dass man jetzt nach XP entwickeln möchte.

Zusammen einigt man sich auf ein paar Grundlagen und organisiert z.B. das Planungsspiel und die Releases.

Rollen werden verteilt.

Dann geht es los.

Wenn Probleme auftauchen, werden die Werte, Prinzipien und Techniken des XP zur Rate gezogen.

XP einführen
01:47

Wichtigster Hinderungsgrund ist die Unternehmenskultur. Wenn ein Unternehmen einem Team immer direkt vorgibt, wie und was es zutun hat, wird es XP sehr schwer haben.

Auch sollte man XP nicht ausprobieren, wenn der Kunde vor der Implementierung ein komplettes Design oder eine komplette Spezifikation des Programms haben möchte.

Auch eine Kultur, die Überstunden unterstützt, ist mit XP nicht vereinbar. So lässt sich keine gute Leistung abliefern.

Wirklich intelligente Entwickler tun sich auch manchmal schwer mit XP. Sie fühlen sich durch das ständige Kommunizieren und die fortwährende Evolution oft eingeschränkt.

Werden die Teams zu groß, klappt XP auch nicht. Möglichst kleine Teams sind hier wichtig.

Auch kann die Umgebung ein No-Go für XP sein. Kleine, strickt getrennte Einzelbüros eignen sich nicht für XP. Auch das Verteilen der Programmierer über mehrere Stockwerke funktioniert nicht.

Wann man XP nicht ausprobieren sollte
03:26

Ein Festpreis ist immer kritisch. Liefere die 20 Funktionen in 12 Monaten für Preis X.

Er funktioniert bei der Softwareentwicklung einfach nicht. Der Kunde will so viel wie möglich für sein Geld, die Entwickler wollen so wenig wie möglich liefern. Daher gibt es immer Konflikte. "Das stand so nicht in den Anforderungen!" "Das ist doch komplett anders gemeint gewesen!"

Besser sind hier agile Abmachungen. Die Entwickler arbeiten X Monate für den Preis von Y um das Produkt fertig zu stellen. Sie tun dies mit vollem Einsatz. Nach jeder Iteration hat der Kunde die Möglichkeit das Projekt zu beenden. (Dies unterstützt das "mit vollem Einsatz").

Festpreis
03:42
+ BONUS: Hier gibt es tolle Angebote von mir
3 lectures 04:01
Weitere Kurse zum Bestpreis
00:28
Bonus: TeamUp! für dein agiles Team
02:18
Bonus: Coding.Cards
01:14