Technische Praktiken [Technik]

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

☝️ SingleEin Team arbeitet mit langlebigen Feature-Zweigen, die nach zwei bis drei Wochen zusammengeführt werden. Welche Folge ist am gravierendsten für die Scrum-Arbeitsweise?
❌Die Versionshistorie wird unübersichtlich
✅Integrationsprobleme werden erst am Sprintende sichtbar, sodass ein fertiges Increment strukturell gefährdet ist
❌Die Zahl der Zusammenführungskonflikte steigt für die Developers
❌Die Codeüberprüfung wird aufwendiger
Alle vier Punkte treffen zu, aber nur der erste betrifft die Lieferfähigkeit. Lange Zweige verlagern Risiko ans Sprintende, genau dorthin, wo keine Zeit mehr zur Behebung bleibt. Das ist der Grund, warum kontinuierliche Integration technische Voraussetzung für Scrum ist.
☝️ SingleWelche Aussage über Test-Driven Development im Scrum-Kontext trifft zu?
❌Es ersetzt die Notwendigkeit von Integrationstests
✅Es ist eine optionale Praktik; der Scrum Guide schreibt keine Entwicklungstechnik vor, TDD unterstützt aber die Erfüllung einer strengen Definition of Done
❌Es ist für die Erfüllung der Definition of Done zwingend erforderlich
❌Es ist mit kurzen Sprints unvereinbar, da es den Aufwand erhöht
Scrum ist bewusst unvollständig und schreibt keine technischen Praktiken vor. Der Zusammenhang ist dennoch real: Ohne belastbare automatisierte Prüfungen ist eine strenge Definition of Done in kurzen Zyklen kaum einzuhalten.
✍️ OffenEin Team kann am Sprintende kein auslieferbares Increment erzeugen, weil die Auslieferung einen manuellen Prozess mit Freigaben durch drei Abteilungen erfordert. Beschreiben Sie Ihr Vorgehen.
Musterantwort: Zuerst würde ich den Prozess sichtbar machen, statt über ihn zu reden. Eine einfache Aufnahme der Wertstromschritte mit der jeweils tatsächlichen Bearbeitungs- und Wartezeit zeigt fast immer, dass der überwiegende Teil der Dauer Wartezeit ist. Diese Zahl ist das wirksamste Argument gegenüber allen Beteiligten, weil sie niemanden beschuldigt. Dann würde ich unterscheiden, was technisch und was organisatorisch bedingt ist. Technisch fehlen meist automatisierte Bereitstellung, automatisierte Prüfungen und versionierte Datenbankänderungen; das kann das Team selbst angehen und schrittweise in die Definition of Done aufnehmen. Organisatorisch sind die Freigaben das eigentliche Hindernis, und die kann das Team nicht allein auflösen; hier ist der Scrum Master auf Organisationsebene gefragt. Bei den Freigaben würde ich nach dem Zweck fragen statt nach der Abschaffung. Jede Freigabe soll ein Risiko abdecken. Für viele dieser Risiken gibt es automatisierte Nachweise, die schneller und verlässlicher sind als eine Unterschrift, etwa Sicherheitsprüfungen im Bau oder automatisierte Konformitätstests. Der Vorschlag lautet dann nicht "weniger Kontrolle", sondern "dieselbe Kontrolle, kontinuierlich statt am Ende". Parallel würde ich die Definition of Done ehrlich halten. Solange die Auslieferung nicht möglich ist, ist das Increment nicht auslieferbar, und genau diese Unbequemlichkeit hält den Druck aufrecht. Eine abgesenkte Definition würde das Problem unsichtbar machen. Schließlich würde ich klein anfangen: eine Freigabestufe automatisieren, die Wirkung messen und das Ergebnis als Beleg für die nächste nutzen. Ein Gesamtumbau als Programm scheitert an denselben Freigabewegen, die er beseitigen soll.
Bewertet werden: Wertstromaufnahme mit Warte- gegen Bearbeitungszeit + Trennung technischer und organisationaler Ursachen + Scrum Master für die Organisationsebene + Freigaben über ihren Zweck und automatisierte Nachweise adressieren + Definition of Done ehrlich halten + schrittweises Vorgehen statt Programm.
← Alle ThemenIm Quiz üben