Bewerten und überwachen Sie die Leistung Ihrer Software-Fabrik

Kontext

Der Anwendungsfall gilt für alle Arten von Softwaresystemen jeglicher Programmiersprachen.

Ein „Software-Teil" kann sein:

• Ein Softwareprodukt oder eine IT-Anwendung, d. h. eine Software, die von den Endbenutzern als eine Einheit wahrgenommen wird. Beispiele: ein Desktop-E-Mail-Programm, eine mobile App für Podcasts oder ein SAP-System.
• Eine Software, die mit Hardware verbunden ist (Embedded System). Beispiele: Software für ein Abstandsradar im Auto oder Software für einen Drucker.
• Eine Softwarekomponente, d. h. ein (mehr oder weniger) eigenständiger Baustein, der Teil der vorgenannten Softwaretypen ist.

Die Arbeit Ihrer Teams umfasst:

• Das Aufgreifen von fachlichen Anforderungen (Features, Change Requests, ...) als Input
• Schreiben von neuem Code und Wartung des bestehenden Software-Codes
• Auslieferung der Software als Folge von getesteten und fehlerfreien Releases

Pains

Zu oft bleibt die Leistung Ihrer Teams hinter dem versprochenen Zeitplan - und auch Ihre Experten können nicht sagen, wie man dies in Zukunft verhindern kann. Zu oft enthalten die ausgelieferten Releases Fehler - und selbst Ihre Experten können nicht sagen, wie man dies in Zukunft verhindern kann.

Sie sind unter Druck durch das Management, mit dem gleichen Budget mehr Wert zu schaffen. Aber Sie haben keine Möglichkeit, die Effizienz Ihrer Teams zu bewerten und zu benchmarken, noch können Sie Ineffizienzen identifizieren, lokalisieren und bekämpfen.

Sie erhalten unregelmäßige oder widersprüchliche Ratschläge von Ihren Experten, die jeweils aufgrund ihres besonderen Verantwortungsschwerpunkts und aufgrund der aktuellen Feuerwehraktion voreingenommen sind: An einem Tag wird Ihnen vielleicht gesagt, dass die Lösung darin besteht, stark in die Beseitigung technischer Schulden zu investieren. Am nächsten Tag wird Ihnen vielleicht geraten, in Testautomatisierung zu investieren. Später sagt man Ihnen vielleicht, dass Sie mehr Entwickler einstellen müssten.

Die Ratschläge Ihrer Experten folgen normalerweise einem ähnlichen Muster: "Wenn wir jetzt einen erheblichen Teil der Zeit für die geschäftliche Wertschöpfung wegnehmen und sie stattdessen in Codebereinigung und Testautomatisierung investieren, werden wir morgen viel produktiver sein." Aber niemand kann etwas Konkreteres versprechen. Wenn Sie also zustimmen und einem dieser Vorschläge folgen, haben Sie keine Möglichkeit, den Effekt dieser Investition auf die Leistung Ihrer Softwarefabrik zu quantifizieren.

Gains

Es wäre in Ihrer Situation äußerst wertvoll, ...

• von der reaktiven Brandbekämpfung zu einer weitsichtigeren, proaktiven Steuerung Ihrer Software-Fabrik zu wechseln.
• eine datengetriebene 360°-Sicht auf die tatsächlichen Auswirkungen Ihrer Änderungen auf Prozesse, Methoden, Werkzeuge oder Teamstrukturen in Ihrer Software-Fabrik zu etablieren. Dies würde greifbare Antworten auf Fragen liefern wie: War es eine gute Idee, das Team aus Indien zu in-sourcen? War es eine gute Idee, den Sprint-Zyklus von 3 Wochen auf 2 Wochen zu verkürzen?
• die verschiedenen Teams oder Aktivitätsströme zu vergleichen, für die Sie verantwortlich sind. Identifizieren Sie, wer der Klassenbeste ist, und übertragen Sie deren Best Practices und Wissen auf Ihre gesamte Organisation.