Richard Seidl hat sich für diese Folge seines Podcasts erneut Sebastian Dietrich eingeladen, um mit ihm über rechtliche Stolpersteine in Softwareprojekten zu sprechen: Es geht um Werkvertrag versus Dienstvertrag, Gewährleistung, Haftung und Warnpflicht.

Als Gerichtssachverständiger erklärt Sebastian Dietrich, warum Freelancer oft Erfolg schulden und agile Verträge schnell zum Werkvertrag werden, in dem plötzlich das ganze Backlog gilt. Das Duo zeigt, wie Leistungen klar beschrieben, Qualitätskriterien messbar festgelegt und der Stand der Technik als gemeinsamer Prozess dokumentiert werden.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Rechtliche Stolperfallen in Softwareverträgen – Sebastian Dietrich“ und steht auf YouTube bereit.

Ältere Folgen mit Sebastian Dietrich:

(mdo)

Wie viel Zeit sollten Product Owner eigentlich in das Schreiben von User Stories investieren? Darüber sprechen Dominique Winter und Tim Klein in dieser Podcastfolge. Wenn der Kalender voll ist und die To-do-Liste überquillt, wirkt das Story-Schreiben schnell wie eine lästige Pflicht. Viele betrachten es als reine Schreibarbeit. In Wahrheit ist es jedoch vor allem Denk- und Teamarbeit.

Eine gute User Story entsteht nicht allein am Schreibtisch, sondern im Gespräch. Sie ist das sichtbare Ergebnis gemeinsamer Klärung und ein Zeichen dafür, dass ein Team ein gemeinsames Verständnis erreicht hat. Das Schreiben von User Stories dient daher weniger der Dokumentation als der Verständigung. Eine Story ist kein statisches Artefakt, sondern ein Kommunikationswerkzeug, das an ein Gespräch erinnert, in dem klar wird, welches Nutzerproblem gelöst werden soll.

Das Ziel im Blick behalten

Manche Teams versuchen, Sicherheit durch besonders ausführliche Formulierungen zu schaffen und verlieren dabei leicht das eigentliche Ziel aus den Augen. Gute User Stories entstehen, wenn Teams gemeinsam begreifen, worum es geht – nicht, wenn jedes Detail schriftlich fixiert wird. Sie sind eine Einladung zum Dialog, sollen Empathie für Nutzerinnen und Nutzer wecken sowie den Blick auf deren Bedürfnisse richten. In dieser Haltung wird das Schreiben von Stories zu einem Werkzeug, das Orientierung schafft. Wenn Teams verstehen, warum etwas wichtig ist, finden sie auch den passenden Weg dorthin. Manchmal genügt ein einziger Satz, um eine Idee zu verankern und das Gespräch darüber am Laufen zu halten.

Organisationen gehen sehr unterschiedlich mit User Stories um. In großen Unternehmen wird häufig zu viel dokumentiert – oft, weil es der gewohnte Weg ist. Start-ups hingegen schreiben meist zu wenig auf. Beides zeigt ein Ungleichgewicht zwischen Vertrauen und Kontrolle. Teams, die ihre Prozesse kennen und einander vertrauen, benötigen keine langen Texte. Sie verlassen sich auf Dialog und gemeinsame Verantwortung. Wie viel Zeit in die Story-Erstellung fließt, hängt daher stark von der Reife eines Teams ab. Eingespielte Teams mit tiefem Produktverständnis kommen mit wenigen Worten aus, während neue Teams mehr Austausch benötigen, um ein gemeinsames Verständnis aufzubauen. In jedem Fall sollte die Energie eher in Nachdenken und Reflexion fließen als in das Polieren von Formulierungen.

Zehn-Prozent-Regel und KI-Einsatz

Hilfreich ist die bekannte Zehn-Prozent-Regel: Rund zehn Prozent der Sprintzeit sollten in die Erstellung und das gemeinsame Refinement des Backlogs investiert werden. Diese Zeit schafft Klarheit über Ziele, Annahmen und Prioritäten. Wer hier spart, zahlt später mit Missverständnissen und Nacharbeit.

Auch Künstliche Intelligenz (KI) kann unterstützen – etwa durch Strukturvorschläge oder Formulierungsideen. Doch sie ersetzt kein gemeinsames Denken. Eine automatisch erzeugte Story ist noch keine Story, solange nicht darüber gesprochen wird. KI kann inspirieren, aber kein echtes Verständnis schaffen. Am Ende braucht es immer Menschen, die beurteilen können, ob das Ergebnis wirklich gut ist. Gute User Stories entstehen in Gesprächen, nicht in Tools. Sie schaffen ein gemeinsames Bild des Nutzerproblems und machen die Produktentwicklung wirkungsvoller. Teams, die sich Zeit für den Austausch nehmen, gewinnen Klarheit – und diese Klarheit ist die beste Grundlage für jedes gute Produkt.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Wie viel Zeit darf User-Story-Erstellung kosten – hilft uns KI dabei?„

(mai)

Der Debian-Entwickler Julian Andres Klode hat angekündigt, ab Mai 2026 harte Rust-Abhängigkeiten in den Paketmanager APT einzuführen. Künftig werden zentrale Teile von APT in der Programmiersprache Rust implementiert. Betroffen sind unter anderem der Code zum Parsen von .deb-, .ar- und .tar-Archiven sowie die HTTP-Signaturverifizierung.

APT (Advanced Package Tool) ist das zentrale Werkzeug zur Paketverwaltung in Debian und darauf basierenden Distributionen wie Ubuntu. Die geplante Umstellung auf Rust betrifft damit eine der grundlegendsten Systemkomponenten der Distribution. Klode begründet den Schritt mit den Vorteilen speichersicherer Programmiersprachen und besseren Möglichkeiten für Unit-Tests.

Die Rust-Integration umfasst zunächst den Rust-Compiler, die Standardbibliothek und das Sequoia-Ökosystem. Sequoia ist eine OpenPGP-Implementierung in Rust, die bereits in verschiedenen Projekten zum Einsatz kommt. Durch den Einsatz von Rust sollen typische Speicherfehler wie Buffer Overflows oder Use-after-Free vermieden werden, die in C und C++ häufige Sicherheitslücken eröffnen.

Die Ankündigung richtet sich explizit auch an Maintainer weniger verbreiteter Debian-Ports. Architekturen wie m68k, hppa (HP PA-RISC), sh4 (SuperH) und Alpha adressiert Klode in der Nachricht direkt. Diese Ports haben nun sechs Monate Zeit, eine funktionierende Rust-Toolchain bereitzustellen – andernfalls droht die Einstellung des Supports.

Modernisierung versus Retro-Hardware

Klode betont in seiner Nachricht, dass es für das Projekt wichtig sei, sich weiterzuentwickeln und auf moderne Technologien zu setzen. Man könne nicht zulassen, dass die Distribution durch den Versuch ausgebremst werde, moderne Software auf Retro-Computing-Geräte zu portieren. Diese Haltung dürfte in der Community durchaus kontrovers diskutiert werden, da Debian traditionell eine sehr breite Hardwareunterstützung anstrebt.

Die Entscheidung reiht sich in einen größeren Trend ein: Auch der Linux-Kernel hat mit der Integration von Rust begonnen, um sicherheitskritische Komponenten schrittweise in der speichersicheren Sprache zu implementieren. Rust hat sich in den vergangenen Jahren als bevorzugte Alternative zu C und C++ für systemnahe Programmierung etabliert, wenn es um Sicherheit und Zuverlässigkeit geht.

Für Nutzer von Debian auf gängigen Architekturen wie x86-64, ARM oder RISC-V dürfte die Umstellung transparent verlaufen, da Rust für diese Plattformen bereits vollständig unterstützt wird. Die Frist bis Mai 2026 gibt den Maintainern kleinerer Ports zumindest etwas Zeit, entweder eine Rust-Toolchain zu implementieren oder ihre Ports offiziell einzustellen.

Die vollständige Ankündigung findet sich in einer Nachricht an die Debian-Entwicklerlisten.

(fo)