Wenn wir uns mit agiler Softwareentwicklung beschäftigen, sprechen wir grundsätzlich auch über Application Lifecycle Management (ALM). Ebenso treibt das Business, das hinter allen Anforderungen für die Entwicklung von Software steht, immer die Frage nach Wertschöpfung um. Damit wir euch Antworten auf eure Fragen geben können, müssen wir die Werte von ALM mit den Methodiken von Business Intelligence (BI) in Einklang bringen. Und genau aus diesem Aspekt möchte ich mich in diesem Post theoretisch mit der Wortschöpfung „Application Lifecycle Intelligence“ auseinandersetzen.
Was verbirgt sich hinter dem Begriff Business Intelligence?
Laut dem Gabler Wirtschaftslexikon ist BI ein „Sammelbegriff für den IT-gestützten Zugriff auf Informationen, sowie die IT-gestützte Analyse und Aufbereitung dieser Informationen. Ziel dieses Prozesses ist es, aus dem im Unternehmen vorhandenen Wissen neues Wissen zu generieren. Bei diesem neu gewonnenen Wissen soll es sich um relevantes, handlungsorientiertes Wissen handeln, das Managemententscheidungen zur Steuerung des Unternehmens unterstützt.“
Um nun Methodiken von BI anwenden zu können, benötigen wir noch Metriken. Eine Metrik ist, laut IEEE Standard 612.10, ein quantitatives Maß für den Grad, zu dem ein System, eine Komponente oder ein Prozess ein bestimmtes Attribut besitzt.
Aus den Metriken werden dann mit der Zeit und im Lauf eines Prozesses die Key Performance Indicators (KPIs). Diese geben an, was wichtig für das Team und den Business Case ist. Ebenso dienen sie auch als Grundlage für Trendberechnungen.
Ist Agilität messbar?
Wir bewegen uns ja in einem agilen Umfeld. Genau dieser Umstand stellt aber auch die größte Hürde bei der Messbarkeit dar. Nach den agilen Prinzipien ist die funktionierende Software die primäre Messgröße. Es ergeben sich aber auch sprachliche Schwierigkeiten, bezogen auf das Verständnis von Messbarkeit im Team. In der Regel treffen wir dort auf drei Typen: die Entwickler, den Product Owner (PO) und meist auch noch zusätzlich auf einen Projektmanager (PM). Alle drei haben ein grundlegend anderes Verständnis bezogen auf den Satz „Das Projekt läuft gut“. Die Entwickler verstehen darunter, dass die Softwarelösung gut durchdacht und entwickelt wurde. Für den PO wurden alle Features eines Sprints ausgeliefert. Und der PM ist der Ansicht, dass das Projekt gut in der Zeit und im Budget liegt.
Eine weitere Herausforderung der Agilität bezogen auf die Messbarkeit ist die Fokussierung auf ein Produkt und nicht auf Projekt. Die Idee von Agilität besteht ja darin ein funktionierendes Produkt auszuliefern und nicht ein Projekt abzuschließen. In der Regel vermischen sich im Projektalltag genau diese Sichtweisen, da das Projektmanagement grundsätzlich zahlengetrieben funktioniert.
Daten des Software Development Life Cycle
Wenn wir nun den Software Development Life Cycle (SDLC) betrachten, sind die Daten über einzelne Tools verteilt. Eine einheitliche Sicht wird dadurch erschwert. Bei den Tools der Firma Atlasssian gibt es durch die vorhandene Integrationsmöglichkeit der einzelnen ein erster Ansatz, der aber mit Sicht auf die Daten und deren Lage eher rudimentär ist. Wir wollen uns nun mit den folgenden genannten Systemen, aber ohne die Nennung eines konkreten Produkts, beschäftigen:
Diese einzelnen Systeme beantworten unterschiedliche Fragestellungen.
Die Fragen, die sich aus den jeweiligen Datenlagen ergeben, sind somit sehr kleinteilig. Wenn wir nun Datenlagen zusammenfassen, bekommen wir ein größeres Bild und können auch detailliertere Fragen stellen.
Für weitere und zugleich noch gezieltere Fragestellungen müssen wir die jeweiligen Datenlagen noch mehr miteinander in Verbindung bringen. Hierzu kann eine Mindmap zur Visualisierung der Zusammenhänge eine konkrete Hilfe sein.
Nachdem wir uns Gedanken zu möglichen Fragestellungen gemacht haben, ist es nun an der Zeit, dass wir versuchen an die konkreten Daten aus den beteiligten Systemen zu gelangen. In der heutigen Zeit haben Systeme, die sich mit Themen des SDLC bzw. ALM beschäftigen eine gut dokumentierte Rest-API. Genau über diese APIs bekommen wir nun die Informationen, die wir für das weitere Vorgehen benötigen.
Aber welche Daten bekommen wir von den Systemen geliefert?
| System | Datenlagen |
|---|---|
| PVS |
|
| VKS |
|
| CI/CD |
|
| AM |
|
Aus Daten werden Metriken
Nachdem wir die Datenlagen der einzelnen Systeme betrachtet haben, können wir nun erste einfache Metriken zusammenfügen.
Sobald wir die Bedeutung der einzelnen Werte verstanden haben, werden wir in die Lage versetzt komplexere Metriken durch Kombination dieser Werte und auch durch Hinzunahme weiterer Datenlagen zu entwerfen. Doch dazu müssen die neu geschaffenen Daten erst in eine normalisierte Form gebracht werden. Auch hier können Mindmaps den Herleitungsprozess unterstützen.
Es ist aber zu beachten, dass jegliche Änderung von Prozessen auch eine Anpassung der Metriken erfordert. Somit gelangen wir auch auf der Ebene der Daten und Metriken in einen kontinuierlichen Prozess.
Nun wollen wir uns einmal eine komplexe Metrik überlegen. Aufgrund der Tatsache, dass wir uns in einem kontinuierlichem Entwicklungsprozess befinden, möchten wir nun wissen, wie sich die Qualität der Releases in der fortlaufenden Entwicklung verändert. Zu aller erst bekommt unsere neue Metrik einen aussagekräftigen Namen, „Kontinuierliche Releasequalitätsbewertung“ (KRQB). Nun schauen wir unsere bekannten Metriken an und entscheiden uns für die Rückfälligskeitsquote (RFQ). Des Weiteren interessieren wir uns für die Anzahl der veränderten Zeilen Sourcecode (VZS). Die dritte Größe, die wir benötigen, ist der sogenannte Gesundheitsfaktor der Schätzungen (GFS). Dieser stellt in normalisierter Form die Genauigkeit aller Schätzungen dar. Der letzte Wert, der unser Interesse für die Erstellung weckt sind die entgangenen Fehler (EF). Bei den entgangenen Fehlern handelt es sich um die Fehler, die nicht während des Testens, sondern erst in der Produktion, aufgefallen sind.
Nachdem wir Metriken, einfach oder komplex, erstellt haben, stehen wir vor der Herausforderung diese innerhalb einer Organisation zu veröffentlichen. Hierbei müssen wir als erstes klären, für wen wir die Informationen zur Verfügung stellen wollen. Denn diese Personen müssen auf Grundlage der Metriken handeln können, somit erzeugen wir auch die entsprechenden KPIs.
Wenn wir nun die Personen in drei verschiedene Publikumsebenen zusammenfassen, ergibt sich die folgende Übersicht.
| Ebene | Metriken |
|---|---|
| Team |
|
| Manager |
|
| Executive |
|
In der Übersicht taucht mit „kundenorientierte Qualitätsbewertung“ eine Metrik auf, die wir bisher nicht betrachtet haben. Die Daten hierfür bekommen wir über Kundenbefragungen bzw. -bewertungen und diese müssen wir dann nur normalisieren. Um die jeweiligen Interessengruppen nicht mit Zahlenkolonnen zu erschlagen, sollten wir uns über die Art die Visualisierung Gedanken machen. Wenn wir uns dem Begriff „Business Intelligence“ wieder zuwenden, stossen wir auf sogenannte Dashboards. Diese sorgen dafür, dass die entstandenen KPIs eine ansprechende Darstellung zur schnellen Verwendbarkeit erhalten.
Ich hoffe, dass euch dieser Blogpost einen ersten Einblick in die Analyse von Wertströmen innerhalb von Entwicklungsprozessen gegeben hat. In einem nachfolgendem Blogpost werde ich mit Unterstützung der Statistikumgebung R und einiger Bibliotheken eine Umsetzung eines Application Lifecycle Intelligence Dashboard darstellen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Daniel Kocot
13.11.2024 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.