Entwicklung & Code
Projektmanagement: Darf das Product Backlog sichtbar sein?
Moin.
(Bild: Stefan Mintert )
Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.
Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.
Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.
Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.
Neulich haben wir in unserem eigenen Team darüber gesprochen, ob das Product Backlog innerhalb einer Firma öffentlich sichtbar sein darf. Da wir als externe Berater, POs und Coaches mit verschiedenen Kundenteams zu tun haben, hat jeder von uns andere Erfahrungen gemacht. Deshalb war es gar nicht so einfach, eine gemeinsame Antwort zu finden.
Nach dem Gespräch habe ich folgende Sichtweise: Es sollte das Ziel sein, dass das Product Backlog und damit die Arbeitspakete des/der Entwicklerteams für jede Person im Unternehmen einsehbar sein sollen. Vorbehalte gegen diese Transparenz können sein:
- ein unbestimmtes Gefühl des Teams, sich nicht in die Karten schauen zu lassen,
- die Sorge, sich angreifbar zu machen,
- die Angst vor häufigen Eingriffen in den Arbeitsablauf.
Alle drei Punkte rechtfertigen aus meiner Sicht, das Backlog vertraulich zu behandeln. Allerdings ist mit jedem einzelnen Punkt auch eine Erkenntnis verbunden: Hier muss sich etwas ändern.
Wenn sich Teams dadurch angreifbar machen, dass jemand sehen kann, woran sie arbeiten, stimmt etwas nicht. Vielleicht hat die Person die Priorisierung oder die Roadmap nicht verstanden. Das kann man hinterfragen und klären.
Vielleicht wird aber auch die Rolle des Product Owners, der das Backlog maßgeblich verantwortet, nicht ausreichend respektiert.
Egal, was zu den Vorbehalten gegen die Transparenz anzuführen ist: Die Ursachen müssen erkannt und ausgeräumt werden.
Hat man das geschafft, dann darf das Product Backlog sichtbar sein. Ob es überhaupt sinnvoll ist, den Stakeholdern jedes kleine Bugticket und jede technische Aufgabe zu zeigen, ist eine andere Frage. Eine Darstellung des Entwicklungsfortschritts über Meilensteine, Epics oder (echte) User Stories dürfte in der Regel besser und ausreichend sein.
Erst lesen, dann hören
Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.
(rme)
Entwicklung & Code
.NET: Jetzt 24 Monate Support für Standard-Term Releases ab .NET 9.0
Der Release-Zeitraum für .NET-STS-Versionen (Standard-Term Support) wird auf 24 Monate verlängert. Bisher gewährte Microsoft 18 Monate Support für STS-Releases, während LTS-Releases (Long-Term Support) drei Jahre lang Updates erhalten.
Die neuen Support-Laufzeiten
Die Neuerung gilt bereits für das aktuelle STS-Release .NET 9.0, das somit erst am 10. November 2026 seinen End of Support erreichen wird, statt wie ursprünglich geplant am 12. Mai 2026. Das Datum lag bisher bei sechs Monaten nach Erscheinen der .NET-Folgeversion, nun sind es zwölf Monate. Der Support-Zeitraum für LTS-Releases ändert sich nicht. So soll etwa das für November 2025 geplante .NET 10.0 wie geplant drei Jahre im Support verbleiben.
Der neue Zeitplan für den .NET-Support sieht zwei Jahre Support für .NET 9.0 vor.
(Bild: Microsoft)
(Bild: coffeemill/123rf.com)
Verbesserte Klassen in .NET 10.0, Native AOT mit Entity Framework Core 10.0 und mehr: Darüber informieren .NET-Profis auf der Online-Konferenz betterCode() .NET 10.0 am 18. November 2025. Nachgelagert gibt es sechs ganztägige Workshops zu Themen wie C# 14.0, künstliche Intelligenz und Web-APIs.
Support-Phasen von .NET-Releases
Unter Support für .NET und .NET Core versteht Microsoft sowohl den Active Support, der Funktionen verbessert und Sicherheitsrisiken vermindert, als auch den Maintenance Support, der während der letzten sechs Monate des Support-Zeitraums für STS- und LTS-Releases gilt und sich lediglich auf das Verringern von Sicherheitsrisiken bezieht. Ist das End of Life (EOL) beziehungsweise der End of Support (EOS) für ein .NET-Release eingetreten, erhält dieses keinerlei Fixes, Updates oder technischen Online-Support mehr.
Das steckt dahinter
Als Begründung nennt Microsoft, dass .NET sich schnell weiterentwickelt und immer häufiger neue Features in Out-of-Band-Releases (OOB) statt in den jährlichen Releases landen, was zum Beispiel .NET Aspire, Microsoft.Extensions.AI und das C# Dev Kit betrifft.
.NET-Anwenderinnen und -Anwender verbleiben mitunter aufgrund ihres längeren Supports bei einer .NET-LTS-Version, statt zu einem neueren STS-Release zu wechseln. Im Umgang mit OOB-Releases kann das zu Schwierigkeiten führen: So konnte es bisher sein, dass ein verwendetes OOB-Release eine Abhängigkeit zu einem neueren STS-Release hatte und somit einen Teil der Runtime von LTS zu STS verschob. Für dieses Paket galt dann eine kürzere Support-Laufzeit, da das jüngere STS-Release bereits sechs Monate vor dem älteren LTS-Release aus dem Support fiel.
Nun haben jedoch zum Beispiel das LTS-Release .NET 8.0 und das STS-Release .NET 9.0 das gleiche End-of-Support-Datum, den 10. November 2026. Aber auch abseits von OOB-Releases soll der längere Support-Zeitraum Anwenderinnen und Anwender dazu ermutigen, künftig STS-Releases in Erwägung zu ziehen.
(mai)
Entwicklung & Code
Cisco und Splunk gehen agen tische KI und Maschinendaten-Verarbeitung an
Die Cisco-Tochter Splunk veröffentlichte auf der Hauskonferenz .conf25 in Boston eine neue dezentrale Datenarchitektur: die Cisco Data Fabric. Sie soll helfen, den Umgang mit wachsenden Mengen an Maschinendaten zu erleichtern. Die Architektur ist offen angelegt und kann Daten aus Edge-, Cloud- und hybriden Umgebungen zusammenführen. Damit lassen sich Datenströme in Echtzeit analysieren und in verwertbare Informationen überführen, ohne dass sie vorher zentralisiert werden müssen. Das soll zu geringeren Kosten, niedrigeren Latenzen und weniger Komplexität führen. Auch sollen so dezentrale Daten für weitere KI-Verarbeitung zur Verfügung stehen.
Foundation Model für Zeitreihen
Hierfür kündigte der Hersteller eine Reihe integrierter KI-Modelle an. Dazu gehört auch ein speziell auf Zeitreihen ausgelegtes Time Series Foundation Model (TSFM), das mit Maschinendaten sprechen können soll, erklärte Jeetu Patel, Präsident und Chief Product Officer bei Cisco. Es wurde mit einer Mischung aus internen Cisco-Servicedaten, spezifischen Protokollen und branchenspezifischen sowie öffentlich zugänglichen Daten trainiert. Das TSFM soll Muster, Zusammenhänge und Ursachenketten in verschiedenen Logs und Telemetriedaten erkennen und Anwendungsfälle wie Anomalieerkennung, Vorhersagen und automatisierte Root-Cause-Analysen unterstützen. Während die Data Fabric ab sofort in Splunk verfügbar ist, soll das TSFM erst im November 2025 auf Hugging Face veröffentlicht werden. Dank seiner Datenbasis und Architektur lässt es auf hohe Präzision und Anpassbarkeit hoffen.
Erweiterte Föderation
Parallel baut Splunk die Federated Search aus, mit der sich Betriebs- und Geschäftsdaten über verschiedene Umgebungen hinweg verbinden, abfragen und kombinieren lassen. Neben bereits verfügbaren Datenquellen wie Amazon S3 sollen im Laufe des Jahres 2026 auch Apache Iceberg, Delta Lake, Snowflake und Microsoft Azure hinzukommen. Ergänzend wurde bereits die Federated Search um Cisco-Firewall-Daten erweitert, wodurch Sicherheitsanalysen direkt von der Splunk Cloud Platform aus durchführbar sind. Passend dazu kündigte Cisco an, dass ab sofort das Einspeisen von Firewall-Logs aus Cisco-Firewalls in Splunk kostenfrei sei.
Agentische Automatisierung
Auch im Bereich Security und Observability baut Cisco sein Angebot rund um KI-Agenten aus. Im Mittelpunkt stehen zwei neue Editonen für Splunk Enterprise Security. Die Splunk Enterprise Security Essentials Edition kombiniert fortan Splunk Enterprise Security 8.2 sowie den Splunk AI Assistant und ist weltweit verfügbar. Die Splunk Enterprise Security Premier Edition umfasst zusätzlich Splunk SOAR sowie Splunk UEBA und befindet sich aktuell im Early-Access-Programm. Zuletzt stellte Splunk auch eine Reihe spezialisierter KI-Agenten vor, die Triage, Malware-Analyse, Playbook-Erstellung und personalisierte Detektionsregeln automatisieren sollen. Diese sollen ab Anfang nächsten Jahres verfügbar sein.
(kki)
Entwicklung & Code
software-architektur.tv: Residuality Theory mit Barry O’Reilly
Die Residualitätstheorie (engl.: Residuality Theory) ist eine revolutionäre neue Theorie des Softwaredesigns, die darauf abzielt, die Entwicklung von Softwaresystemen für komplexe Geschäftsumfelder zu erleichtern. Sie modelliert Softwaresysteme als miteinander verbundene Residuen – eine Alternative zur Komponenten- und Prozessmodellierung. Dabei wird angewandte Komplexitätswissenschaft genutzt, um den Umgang mit Unsicherheit zu einem grundlegenden Bestandteil des Designprozesses zu machen.
In dieser englischsprachigen Episode des Videocasts software-architektur.tv bespricht Eberhard Wolff mit Barry O’Reilly, einem erfahrenen Architekten, diesen neuartigen Ansatz. Barry O’Reilly wird außerdem einen Workshop und einen Vortrag zu diesem Thema beim Software Architecture Gathering halten, das vom 24. bis 27. November 2025 in Berlin stattfindet.
Livestream am Freitag, 19. September
Die Ausstrahlung findet am Freitag, 19. September 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.
Weitere Informationen zur Folge finden sich auf der Videocast-Seite.
(mdo)
-
UX/UI & Webdesignvor 1 Monat
Der ultimative Guide für eine unvergessliche Customer Experience
-
UX/UI & Webdesignvor 3 Wochen
Adobe Firefly Boards › PAGE online
-
Social Mediavor 1 Monat
Relatable, relevant, viral? Wer heute auf Social Media zum Vorbild wird – und warum das für Marken (k)eine gute Nachricht ist
-
Entwicklung & Codevor 4 Wochen
Posit stellt Positron vor: Neue IDE für Data Science mit Python und R
-
Entwicklung & Codevor 2 Wochen
EventSourcingDB 1.1 bietet flexiblere Konsistenzsteuerung und signierte Events
-
UX/UI & Webdesignvor 3 Tagen
Fake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
Digital Business & Startupsvor 3 Monaten
10.000 Euro Tickets? Kann man machen – aber nur mit diesem Trick
-
Digital Business & Startupsvor 3 Monaten
80 % günstiger dank KI – Startup vereinfacht Klinikstudien: Pitchdeck hier