eXtreme Programmierung Sebastian Galenski BA Lörrach – WWI 00 B

Gliederung

eXtreme Programmierung - Sebastian Galenski Gliederung 1 Was ist extremes Programmieren ? 1.1 Definition 1.2 Ursprung 2 Praktiken der extremen Programmierung 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmierrichtlinien 3 Voraussetzungen für XP 4 Vergleich 4.1 Traditionelle Modelle 4.2 XP 4.3 Folgen und Konsequenzen 5 Anwendungsbereich 6 Bewertung und Ausblicke von XP 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

1 Was ist XP ?

eXtreme Programmierung - Sebastian Galenski 1 Was ist XP ? Herkömmliche Prozessmodelle sind schwergewichtig: Träge Reaktion auf Kundenwünsche Anwachsender Projektfortschritt wird teuer Fehlende Flexibilität: Kundenberührung mit dem System zu spät „Nein, bitte doch anders !“ „Das habe ich mir aber leichter vorgestellt“ Erster Ansatz nach dem Wasserfall war der Unified Process: Noch nicht die maximale Freiheit für Kunden und Entwickler eXtreme Programmierung: Leichtgewichtig und flexibel, da es die Kundenwünsche und Entwicklermöglichkeiten berücksichtigt Hoher Stellenwert der Änderungswünsche 1 Was ist XP ? 1.1 Definition 1.2 Ursprung 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 1.1 Definition Code-zentriertes Prozessmodell Bestimmte Techniken werden in extremem Maße ausgeübt Als hochgradig iterativer Entwicklungsprozess ist XP prädestiniert für Projekte mit unklaren oder sich ändernden Anforderungen 1 Was ist XP ? 1.1 Definition 1.2 Ursprung 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 1.2 Ursprung Wer hat´s erfunden ? Kent Beck, Ward Cunningham, Ron Jeffries Durch Erprobung in Projekten weiterentwickelt Der Ansatz ? kleine Projekte mit unklaren und sich immer wieder ändernden Anforderungen Kunde hat hohe Ansprüche an die Qualität Die Motivation ? Develop for today – nur auf die heutigen Probleme konzentrieren Do the simplest thing that could possibly work – einfachstes Design zur Problemlösung 1 Was ist XP ? 1.1 Definition 1.2 Ursprung 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

2 Praktiken

eXtreme Programmierung - Sebastian Galenski 2 Praktiken XP zeichnet sich durch 12 Praktiken aus 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2 Praktiken 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2 Praktiken XP zeichnet sich durch 12 Praktiken aus Stützen sich gegenseitig => nur in ihrer Gesamtheit sinnvoll Sonst kann der XP Ansatz scheitern Praktiken selbst sind nicht neu, jedoch die Kombination und der „extreme Grad“ 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.1 Kleine Releases Oder auch kleine Projektteile oder Version Ein Release-Zyklus dauert i.d.R. zwischen ein und drei Monaten Besteht aus mehreren Iterationen (Dauer etwa ein bis vier Wochen) Eine Iteration zerfällt in mehrere Tasks/Arbeitspakete (Dauer etwa ein bis drei Tage) Nach jeder Iteration kann der Kunde Abweichungen feststellen und korrigieren Das erste Release sollte bereits ein funktionierendes Kernsystem bilden Es wird dann inkrementell in weiteren Releases ausgebaut Vorteile: Kunde bekommt frühzeitig wichtige Funktionalitäten Entwickler bekommen schnelles Feedback 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.2 Planungsspiel Iterationen planen Entwicklerressourcen und Kundenwünsche in Einklang bringen Aufgabe des Kunden Anforderungen als User Stories (ähnlich der Use Cases) Prioritäten vergeben Worst Case: Falls der Aufwand die verfügbaren Ressourcen übersteigt, muss der Kunde User Stories verschieben. Aufgabe der Entwickler Aufwandsabschätzung Load-factor als Puffer einbauen Worst-Case: Falls der Entwickler mit seiner Abschätzung daneben lag, kann nachverhandelt werden. 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.3 Tests Zentrale Rolle, ohne sie geht´s nicht Wissen über gewünschte Funktion steckt in den Testfällen und den User Stories Testarten: Entwicklertests für Klassen (unit tests) – technische Sicht, Dokumentationscharackter, Sicherheit bei Änderungen Kundentests für User Stories (functional tests) – funktionale Fehler abdecken, Nachweis über bereitstellung der Funktion Müssen automatisch ausgeführt werden Müssen schnell ausführbar sein !! Erst die Tests, dann die Implementierung !! Zwingt Entwickler zu Fallbeispielen 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.4 Systemmetapher Steht für die grundsätzliche Idee hinter der Architektur des Systems Sie soll für den Entwickler und den Kunden verständlich sein Sie soll den Architekturentwurf ersetzen in puncto neue Programmteile soll sie folgendes vermitteln: Welche Form angenommen werden soll An welche Stelle ins System integriert werden soll 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.5 Einfacher Entwurf Es soll immer nach einer einfachen Lösung gesucht werden Do the simplest thing that could possibly work Nur die momentan anstehenden Anforderungen sollen abgedeckt werden develop for today Sollten später Änderungen notwendig sein, so wird der Entwurf refaktorisiert Aspekte des einfachen Entwurfs: Erfüllung der Anforderungen – der Entwurf muss der Aufgabe gerecht werden Redundanzfreiheit – jede Information darf nur einmal gehalten werden Refaktorisierung – geringst mögliche Anzahl von Klassen, Attributen und Methoden 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.6 Refaktorisierung Dient der Vereinfachung des Entwurfs unter Beibehaltung der Semantik/Funktionalität Verbesserung der Verständlichkeit und Änderbarkeit des Codes Selbsterklärungsfähigkeit da sich die Dokumentation wegen der häufigen Anpassungen auf den Code beschränkt, sollten beim Refaktorisieren Struktur und Namensgebungen selbsterklärend sein Wenn also Code existiert, welcher eines Kommentares bedarf, so sollte der Code angepasst/vereinfacht werden Nach der Refaktorisierung sollten immer die Tests durchlaufen werden sollten der Code wieder die geringst mögliche Anzahl Klassen, Attribute und Methoden aufweisen Ständiger Fluss im Design => kontinuierliche Refaktorisierung 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.7 Pair Programming Entwurf, Codierung und Tests von zwei Entwicklern gemeinsam Eine Tastatur, eine Maus, ein Rechner Rollenverteilung: Implementierer-Rolle, Reviewer-Rolle Bei Bedarf kann getauscht werden Paarbildung ist nicht fest, sondern geeigneten Partner suchen Positiver Nebeneffekt: Wissen über alle Aspekte des System breitet sich über alle Entwickler aus (Ausfallsicherheit) Einer programmiert, der andere prüft Der Reviewer hat andere Ziele im Auge: Fehler (logische und syntaktische) Passt der Code zum Entwurf Kann der Entwurf verbessert werden Fehlen noch Tests zum Code => Kontinuierliche Begutachtung Williams und Cookburn: Entwicklungsaufwand im Vergleich zu allein arbeitenden Entwicklern nimmt ca. 15% zu Code ist hingegen leichter verständlich und hat weniger Fehler (ca. 60%) 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

2.8 Gemeinsames Code-Eigentum Der Code gehört nicht einem sondern allen Entwicklern Jedes Entwicklerpaar darf zu jeder Zeit am gesamten Code Änderungen vornehmen. Um z.B. die Verständlichkeit zu verbessern. Änderungen können aber fehlerhaft sein Deshalb müssen nach jeder Änderung alle Tests durchlaufen werden 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

2.9 Fortlaufende Code-Integration Neuer oder geänderter Code wird alle paar Stunden integriert Auf einen dedizierten Integrationsrechner Alle Tests nach Integration durchlaufen Bei Fehlern muss der Code vom Paar zurückgenommen werden Fehler müssen von dem Paar beseitigt werden So besteht immer ein lauffähiges System 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 2.10 40-Stunden-Woche Pair Programming stellt hohe Ansprüche an die Entwickler Im Paar müssen beide hoch konzentriert sein Das können sie aber nicht, wenn sie erschöpft sind Deshalb: geregelte Arbeitszeiten 40 ist nur ein Richtwert Überstunden nur als Ausnahmefall => unfreiwillige Mehrarbeit 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier- richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

2.11 Kundenvertreter im Team Da keine echte Spezifikation (User Stories sind nicht detailliert genug) => viele Rückfragen an den Kunden Deshalb sollte ein Kundenvertreter für die Entwickler ständig im Zugriff sein (on-site customer) Zukünftiger Anwender Entwickelt die Testfälle (funktionale Tests) 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier- richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

2.12 Programmierrichtlinien Um das Arbeiten in Paaren und das gemeinsame Code-Eigentum zu erleichtern Werden von den Entwicklern untereinander vereinbart und eingehalten Hat zur Folge, dass: der Code einheitlich ist ihn alle verstehen ihn alle ändern können 1 Was ist XP ? 2 Praktiken 2.1 Kleine Releases 2.2 Planungsspiel 2.3 Tests 2.4 Systemmetapher 2.5 Einfacher Entwurf 2.6 Refaktorisierung 2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum 2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche 2.11 Kundenvertreter im Team 2.12 Programmier-richtlinien 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

3 Voraussetzungen

eXtreme Programmierung - Sebastian Galenski 3 Voraussetzungen Alle müssen sich auf die XP Praktiken einlassen Kunde muss qualifizierten Mitarbeiter abstellen Keine großen Entwicklerteams: max. 10-15 Entwickler Entwickler an einem Ort konzentriert zwecks Kommunikation und Paarbildung Tests müssen automatisch und in kurzer Zeit ausführbar sein Beck´s Empfehlung: Schrittweise Einführung von XP 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

4 Vergleich

4.1 Traditionelle Modelle Wasserfall oder Unified Process sind schwergewichtig Keine bis wenig Flexibilittät und Freiheit Änderungswünsche sind teure und schwer realisierbar Kosten beim Wasserfall (exponentiell) oder UP (linear) Ausgangspunkt für diese Annahmen Was kostet eine Änderung in der: Analysephase Designphase Implementierungsphase Im Gegensatz zu XP: größerer Planungsaufwand (Analysephase) Späte Implementierung/Codierung (Implementierungsphase) 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 4.1 Traditionelle Modelle 4.2 XP 4.3 Folgen und Konsequenzen 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

eXtreme Programmierung - Sebastian Galenski 4.2 XP Leichtgewichtig Geringer Planungsaufwand Frühe Codierung Änderungswünsche der Kunden werden berücksichtig Möglichkeiten der Entwickler werden berücksichtigt Nur ein einfaches Design erlaubt: Späteres Auftreten von Anforderungen Kosten steigen nicht linear oder exponentiell Die geringen Kosten sind zu erklären durch den Einsatz von objektorientierten Sprachen einfaches Design automatisierte Tests Erfahrungen im Ändern 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 4.1 Traditionelle Modelle 4.2 XP 4.3 Folgen und Konsequenzen 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

4.3 Folgen und Konsequenzen 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 4.1 Traditionelle Modelle 4.2 XP 4.3 Folgen und Konsequenzen 5 Anwendungsbereich 6 Bewertung und Ausblicke Traditionelle Modelle (z.B. Unified Process) XP Modell Änderungen Antizipieren Erst bedenken wenn gefordert Änderungsmöglichkeiten Einbauen Nicht einbauen, nur das notwendigste implementieren Umfang der Software Komplex Einfach Anfangskosten Hoch Gering Gesamtkosten Projektfortschritt Anfangs langsamer Schneller Gesamtzeit gering 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

5 Anwendungsbereich

eXtreme Programmierung - Sebastian Galenski 5 Anwendungsbereich Einsatz von XP ist nur möglich, wenn die Voraussetzungen erfüllt sind Es empfiehlt sich, XP nur bei kleineren Projekten mit unklaren oder sich ständig ändernden Anforderungen einzusetzen Meist bei individueller Software der Fall Aus Mangel an Erfahrungen wird noch kontrovers über die Skalierbarkeit die möglichen Projektgrößen diskutiert 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

6 Bewertung und Ausblicke

6 Bewertung und Ausblicke Contra – XP Explizite Spezifikation und Entwurfsdokumentation fehlen Zwar ist Doku im Test und im Sourcecode, jedoch kennen diese nur die Teammitglieder Gemeinsames Code-Eigentum wird zum Problem, da kein Übersichtsdokument vorhanden ist Änderungen am Entwurf ziehen Änderungen an den Tests nachsich Sorgfältige Arbeit ist nötig Reicht die Begutachtung des Pair Programmings aus ? QS wird in Frage gestellt XP selbst ist nur unzureichend dokumentiert Die Systemmetapher wird z.B. nur kurz und knapp erwähnt Keine Nachweise über die Überlegenheit von der Vorgehensweise von XP 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

6 Bewertung und Ausblicke Pro – XP C3 Projekt bei DaimlerChrysler Berichte über andere Projekte bei Beck Alle beteiligten Gruppen waren mit XP zufrieden Hohe Motivation und Freude am Programmieren bei den Entwicklern Gute Termineinhaltung im Management Frühe Verfügbarkeit und hohe Qualität eines laufenden Systems beim Kunden 1 Was ist XP ? 2 Praktiken 3 Voraussetzungen 4 Vergleich 5 Anwendungsbereich 6 Bewertung und Ausblicke 14. Juli 2002 eXtreme Programmierung - Sebastian Galenski

für Ihre Aufmerksamkeit ! Vielen Dank für Ihre Aufmerksamkeit !