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)

In dieser Episode seines englischsprachigen Podcasts „Testing Unleashed“ spricht Richard Seidl mit Szilárd Széll über die Herausforderungen und Chancen, die mit der Integration von KI-Agenten in Unternehmensprozesse verbunden sind. Szilárd Széll, ein Experte in der Test- und DevOps-Transformation, beleuchtet die Notwendigkeit eines Vertrauensaufbaus in KI-Systeme, insbesondere wenn diese zunehmend zentrale Geschäftsentscheidungen treffen.

Die Diskussion behandelt Fragen, wie die Qualitätssicherung in einer Welt erfolgt, in der KI ständig lernt und sich anpassen kann.

Dieser Podcast betrachtet alles, was auf Softwarequalität einzahlt: von Agilität, KI, Testautomatisierung bis hin zu Architektur- oder Code-Reviews und Prozessoptimierungen. Alles mit dem Ziel, bessere Software zu entwickeln und die Teams zu stärken. Frei nach dem Podcast-Motto: Better Teams. Better Software. Better World.

Richard Seidl spricht dabei mit internationalen Gästen über modernes Software-Engineering und wie Testing und Qualität im Alltag gelebt werden können.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „KI-Agenten und die Zukunft des Testens – Szilárd Széll“ und steht auf YouTube bereit.

(mdo)