Moin.

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)

Im modernen .NET konnten zur Laufzeit erzeugte Assemblies bisher nur im RAM gehalten werden. Mit .NET 9.0 ist es nun auch wieder wie im klassischen .NET Framework möglich, zur Laufzeit erzeugte Assemblies im Dateisystem zu persistieren.

In .NET 9.0 Preview 1 hatte Microsoft die aus dem klassischen .NET Framework bekannte Möglichkeit wieder eingeführt, dynamisch zur Laufzeit erstellte Assemblies im Dateisystem oder einem beliebigen Stream zu persistieren.

In Preview 3 änderte Microsoft die API aber erneut: Anstelle der zuvor verwendeten Klasse AssemblyBuilder

AssemblyBuilder ab = AssemblyBuilder.DefinePersistedAssembly(new AssemblyName("Math"), typeof(object).Assembly);

nutzt man nun die neue Klasse PersistedAssemblyBuilder:

PersistedAssemblyBuilder ab = new PersistedAssemblyBuilder(new AssemblyName("Math"), typeof(object).Assembly);

Folgender Code zeigt den Einsatz der neuen Klasse. Weitere Beispiele zur Anpassung der Metadaten wie dem Einstiegspunkt finden sich in den Release Notes.

using System.Reflection;
using System.Reflection.Emit;
using System.Reflection.Metadata;
using System.Reflection.Metadata.Ecma335;
using System.Reflection.PortableExecutable;
using ITVisions;
using Microsoft.NET.HostModel.AppHost;
 
namespace NET9_Console.FCL90;
internal class FCL9_Reflection
{
 
 /// 

 /// Im modernen .NET konnten zur Laufzeit erzeugte Assemblies
 /// bisher nur im RAM gehalten werden. Mit .NET 9.0 ist es mit
 /// PersistedAssemblyBuilder nun auch wieder möglich, zur Laufzeit
 /// erzeugte Assemblies im Dateisystem zu persistieren.
 /// siehe auch 
 /// 
 public void CreateAndSaveAssembly()
 {
  // TODO: Bei RTM-Version anpassen!
  var currentVersion = "9.0.0";
 
  CUI.Demo(nameof(CreateAndSaveAssembly));
  string AssemblyName = "App42";
  string AssemblyNameWithExtension = AssemblyName + ".exe";
 
  CUI.H2($"\nErzeuge {AssemblyNameWithExtension}");
  string referencePath = @$"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\{currentVersion}\ref\net9.0";
  PathAssemblyResolver resolver = new(Directory.GetFiles(referencePath, "*.dll"));
  using MetadataLoadContext context = new(resolver);
  Assembly coreAssembly = context.CoreAssembly!;
  Type voidType = coreAssembly.GetType(typeof(void).FullName!)!;
  Type objectType = coreAssembly.GetType(typeof(object).FullName!)!;
  Type stringType = coreAssembly.GetType(typeof(string).FullName!)!;
  Type int32Type = coreAssembly.GetType(typeof(Int32).FullName!)!;
  Type stringArrayType = coreAssembly.GetType(typeof(string[]).FullName!)!;
  Type consoleType = coreAssembly.GetType(typeof(Console).FullName!)!;
 
  // --> NEU in .NET 9.0: PersistedAssemblyBuilder
  // 
  PersistedAssemblyBuilder assemblyBuilder = new(new AssemblyName(AssemblyName), coreAssembly);
 
  TypeBuilder typeBuilder = assemblyBuilder.DefineDynamicModule(AssemblyName).DefineType(AssemblyName, TypeAttributes.Public | TypeAttributes.Class, objectType);
 
  #region Methode Sum() erzeugen
  var mb = typeBuilder.DefineMethod("Sum", MethodAttributes.Public | MethodAttributes.Static,
      int32Type, new Type[] { int32Type, int32Type });
  var ilSum = mb.GetILGenerator();
  ilSum.Emit(OpCodes.Ldarg_0);
  ilSum.Emit(OpCodes.Ldarg_1);
  ilSum.Emit(OpCodes.Add);
  ilSum.Emit(OpCodes.Ret);
  CUI.Cyan($"Sum() wurde erzeugt");
  #endregion
 
  #region Methode Main() erzeugen
  MethodBuilder methodBuilder = typeBuilder.DefineMethod("Main", MethodAttributes.Public | MethodAttributes.Static, voidType, [stringArrayType]);
  ILGenerator ilMain = methodBuilder.GetILGenerator();
  // Aufruf von Console.WriteLine("Die Antwort auf Ihre Frage ist:")
  ilMain.Emit(OpCodes.Ldstr, "Die Antwort auf Ihre Frage ist:");
  ilMain.Emit(OpCodes.Call, consoleType.GetMethod("WriteLine", [stringType])!);
  // Aufruf von Console.WriteLine(Sum(40,2))
  ilMain.Emit(OpCodes.Ldc_I4, 40); // Load the constant 40
  ilMain.Emit(OpCodes.Ldc_I4, 2);  // Load the constant 2
  ilMain.Emit(OpCodes.Call, mb);
  var writeLineMethod = consoleType.GetMethod("WriteLine", [int32Type]);
  ilMain.Emit(OpCodes.Call, writeLineMethod);
  ilMain.Emit(OpCodes.Ret);
  CUI.Cyan($"Main() wurde erzeugt");
  #endregion
 
  #region Metadaten und PE-Header erzeugen
  typeBuilder.CreateType();
 
  MetadataBuilder metadataBuilder = assemblyBuilder.GenerateMetadata(out BlobBuilder ilStream, out BlobBuilder fieldData);
  PEHeaderBuilder peHeaderBuilder = new(imageCharacteristics: Characteristics.ExecutableImage);
 
  ManagedPEBuilder peBuilder = new(
      header: peHeaderBuilder,
      metadataRootBuilder: new MetadataRootBuilder(metadataBuilder),
      ilStream: ilStream,
      mappedFieldData: fieldData,
      entryPoint: MetadataTokens.MethodDefinitionHandle(methodBuilder.MetadataToken));
  CUI.Cyan($"Metadaten und PE-Header wurden erzeugt");
  #endregion
 
  #region Speichern der DLL
  BlobBuilder peBlob = new();
  peBuilder.Serialize(peBlob);
  using (FileStream fileStream = new($"{AssemblyName}.dll", FileMode.Create, FileAccess.Write))
  {
   peBlob.WriteContentTo(fileStream);
  }
  CUI.Cyan($"{AssemblyName}.dll wurde gespeichert");
  #endregion
 
  #region AppHost und runtimeconfig erzeugen
  HostWriter.CreateAppHost(
      @$"C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\{currentVersion}\runtimes\win-x64\native\apphost.exe",
      $"{AssemblyName}.exe",
      $"{AssemblyName}.dll");
 
  CUI.Cyan($"{AssemblyName}.exe wurde gespeichert");
 
  File.WriteAllText($"{AssemblyName}.runtimeconfig.json",
  $$"""
   {"runtimeOptions": {
      "tfm": "net9.0",
      "framework": {
        "name": "Microsoft.NETCore.App",
        "version": "{{currentVersion}}"
      }
    }
   }
  """);
 
  CUI.Cyan($"{AssemblyName}.runtimeconfig.json wurde gespeichert");
  #endregion
 
  CUI.Success("OK");
 
  #region Testen
  CUI.H2($"\nStarte {AssemblyName}.exe");
  System.Diagnostics.Process.Start($"{AssemblyName}.exe");
  #endregion
 }
}

(rme)

Ob der Einsatz von LLMs in der Softwarearchitektur einen echten Mehrwert schaffen kann, wollen Eberhard Wolff und Ralf D. Müller in einem Live-Experiment herausfinden. Zum Auftakt in der letzten Folge hat Anthropics LLM Claude unter der Leitung von Ralf in Echtzeit die Architektur für einen Wardley-Map-Editor mit draw.io-Exportfunktion entwickelt. In nur einer Stunde ist dabei eine Express-Architektur entstanden – schnell, spontan, ungeprüft.

Aber was passiert, wenn diese Express-Architektur auf die Realität des Codes trifft? In der neuen Folge testen Ralf D. Müller und Ingo Eichhorst das mit dem ultimativen “Garbage-In/Garbage-Out”-Experiment: Kann Claude aus der spontanen Architektur funktionierenden Code entwickeln? Oder wird die fehlende Verifikation und Tiefe der Architektur zum Stolperstein?

Live-Coding meets Architektur-Realitätscheck – mit ungewissem Ausgang.

Gemeinsam ergründen Ralf und Ingo:

• Wie robust sind LLM-generierte Architekturen in der Praxis?
• Wo sind die Grenzen zwischen Architektur-Theorie und Code-Realität?
• Kann Claude Code die Lücken einer “schnellen” Architektur selbst schließen?
• Welche architektonischen Entscheidungen erweisen sich als tragfähig, welche als Luftschlösser?

Ein authentisches Experiment ohne Drehbuch: Werden Ralf und Ingo am Ende einen funktionsfähigen Wardley-Map Editor haben – oder lernen sie schmerzhaft, warum gründliche Architektur-Arbeit durch nichts zu ersetzen ist?

Eberhard Wolff ist dieses Mal nicht mit von der Partie und Lisa Marie Schäfer erstellt keine Sketchnotes.

Livestream am 20. Juni

Die Ausstrahlung findet live am Freitag, 20. Juni 2025, zwischen 13 und 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.

(map)