Entwicklungspraktiken [Technik]

6 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWas ist Pair Programming?
Ein Senior überwacht die Arbeit eines Juniors
Zwei Developers bearbeiten dieselbe Aufgabe unabhängig und vergleichen danach
Zwei Teams arbeiten an derselben Komponente
Zwei Developers arbeiten gemeinsam an einer Aufgabe an einem Rechner und wechseln sich zwischen Schreiben und Mitdenken ab
Der Einwand "doppelter Aufwand" greift zu kurz: Pair Programming ersetzt das nachgelagerte Review, verteilt Wissen sofort und senkt die Fehlerrate – der Vergleich muss also die gesamte Kette umfassen.
☝️ SingleWas ist Mob Programming (Ensemble Programming)?
Ein Team bearbeitet möglichst viele Aufgaben gleichzeitig
Eine Form der Code-Review nach Fertigstellung
Das gesamte Team arbeitet gleichzeitig an derselben Aufgabe an einem Arbeitsplatz
Mehrere Teams arbeiten parallel an derselben Komponente
Besonders wirksam bei sehr komplexen oder risikoreichen Aufgaben und beim Aufbau gemeinsamen Wissens in neu zusammengesetzten Teams. Für Routinearbeit ist es dagegen unwirtschaftlich.
☝️ SingleWas ist der Zweck von Refactoring?
Die Software auf eine neue Technologie umzustellen
Die innere Struktur des Codes zu verbessern, ohne sein äußeres Verhalten zu verändern
Neue Funktionen hinzuzufügen, ohne bestehende zu beeinträchtigen
Fehler zu beheben, die der Test gefunden hat
Genau deshalb ist eine Testabdeckung die Voraussetzung: Ohne sie lässt sich nicht belegen, dass das Verhalten unverändert geblieben ist.
☝️ SingleEin Product Owner lehnt Refactoring ab, weil es "keinen Geschäftswert liefert". Wie ist das zu bewerten?
Der Einwand ist berechtigt, Refactoring sollte nur bei Kapazitätsüberschuss stattfinden
Der Product Owner entscheidet über die technische Vorgehensweise der Developers
Der Einwand verkennt die Wirkung: Wachsende technische Schulden verteuern jede künftige Änderung, wodurch der künftige Wertfluss sinkt
Refactoring sollte als eigener Backlog-Eintrag mit Geschäftswert verhandelt werden
Das Wie liegt bei den Developers. Sinnvoll ist, technische Qualität in die Definition of Done aufzunehmen, statt sie sprintweise neu zu verhandeln – dann ist die Diskussion ein für alle Mal geführt.
✌️ MultiWelche Aussagen zu technischen Schulden treffen zu? (Mehrere richtig)
Sie verursachen Zinsen: Jede Änderung im belasteten Bereich wird teurer.
Sie entstehen ausschließlich durch mangelnde Sorgfalt der Developers.
Sie können bewusst und zeitlich begrenzt eingegangen werden, um schneller Feedback zu erhalten.
Sie sollten sichtbar gemacht werden, damit ihre Abarbeitung entscheidbar ist.
Der Ursprung des Bildes von Ward Cunningham meint gerade die bewusste Entscheidung: Schulden aufzunehmen kann klug sein – sie nicht zurückzuzahlen ist es nie.
✍️ OffenEin Team liefert am Sprint-Ende Code, der erst in einer nachgelagerten Testphase geprüft wird. Analysieren Sie die Folgen und beschreiben Sie einen Weg heraus.
Musterantwort: Der Zustand bedeutet, dass am Sprint-Ende kein Increment im Sinne des Scrum Guide vorliegt, weil die Definition of Done innerhalb des Sprints nicht erfüllt wird. Damit verliert das Sprint Review seinen Gegenstand: Gezeigt wird ein Stand, dessen Qualität unbekannt ist, und das Feedback der Stakeholder bezieht sich auf etwas, das noch scheitern kann. Die Prognosefähigkeit sinkt, weil unklar bleibt, wie viel Nacharbeit die nachgelagerte Phase erzeugen wird. Zugleich wächst der Abstand zwischen Bauen und Prüfen, wodurch die Fehlersuche teurer wird und sich Ursachen überlagern. Typischerweise entstehen daraus Stabilisierungssprints, Terminverschiebungen und eine Kultur, in der Testen als fremde Zuständigkeit gilt. Der Weg heraus führt über mehrere Schritte. Zunächst macht das Team den Ist-Zustand sichtbar, etwa indem es die tatsächlich offene Arbeit am Sprint-Ende beziffert, statt sie als Randnotiz zu behandeln. Anschließend wird die Definition of Done schrittweise verschärft, beginnend mit dem, was ohne externe Abhängigkeiten machbar ist, und die Testarbeit wandert in den Sprint hinein, indem Testfälle gemeinsam mit dem Eintrag entstehen. Parallel wird automatisiert, beginnend bei den Bereichen mit den häufigsten Regressionen, und es wird kleiner geschnitten, damit weniger gleichzeitig offen ist. Wo die Ursache außerhalb des Teams liegt, etwa bei einer separaten Testabteilung, ist das ein organisatorisches Impediment und gehört entsprechend eskaliert.
← Alle ThemenIm Quiz üben