Value Driven Metriken – Erkenntnis und Softwareentwicklung (II)

the-kano-model-700x557
Source, microtool.de, 2016

Im Teil 1 zu „Metriken in IT-Projekten habe ich beispielhaft zur Metrikorientierung in Projekten das magische Dreieck als „Kaffeesudleserei“ bezeichnet. Meiner Meinung nach ist das Project Controlling den Geschäftsnutzen-Metriken anzupassen, will man heutzutage IT-Projekte oder Anforderungen schätzen, messen und erfolgreich umstzen. Für mich steht aufgrund meiner Praxiserfahrung außer Frage, dass Projekte nur dann erfolgreich sind, wenn projektinterne Metriken (Time, Costs, Resource, Quality) den geschäftsnutzenbringenden Metriken angepasst werden. Ich denke in meinen Modellen immer in mehreren Kategorien. Anders ausgedrückt möchte ich in verschiedenen horizontal,- u. vertikal Perspektiven messen, damit ich sicherstellen kann, dass der Valuestream sichergestellt wird. Die Betrachtung des Kausalzusammenhangs wie im magischen Projektmanagementdreieck und im Teufelsquadrat, ist mir zu eindimensional. Ich möchte keine Prognosen erstellen, sondern den Valuestream in Echtzeit berechnen. Ändert sich ein Parameter im Dreieck oder Quadrat wehrt sich jeder traditionell denkende Projektmanager diese Änderung einzuplanen, weil sich etwa durch zeitliche Verzögerung auch Kostenveränderungen ergeben. Das bedeutet natürlich Konfliktstoff erster Güte und ist meiner Erfahrung nach eine der Hauptquellen für Projektkrisen. Dieser Ansatz ist einfach zu kurz gegriffen – ich kann das gar nicht oft genug wiederholen – ,  weil dieses Modell vom wesentlichen in einem IT-Projekt ablenkt, nämlich der Entwicklung von adäquaten Cost Center als Modelle, die einer Falsifikation (Überprüfung) standhalten oder nicht. Ich bin davon überzeugt, dass der Betrachtungsraum des „Magischen Dreiecks“ eine Value-Driven-Steuerung verunmöglicht. Aus meiner Sicht kann man als Freelancer heutzutage die Kundenaufträge nur mit Modellflexibilität und Echtzeitanpassung für den jeweiligen Auftrag auf den Boden bringen. Irgendwelche Modell,- und oder Approach-Religionen sind eventuell im akademischen Bereich angebracht, mit Sicherheit jedoch nicht im Daily Business. Jeder Value Driven Ansatz ermöglicht die Entwicklung von passenden Cost Center, die metrisch messbar gemacht werden. Aber dazu sollte man eine wesentliche Fähigkeit mitbringen und zwar optionsoffenes Denken. Mittlerweile gehen mir die Apologeten einzelner „Schulen“ oder selbsternannte „Methoden-Gurus“ deswegen ziemlich auf die Nerven, weil einseitige Orientierungen die Lösungs-Perspektive deutlich verkürzen. Wenn ich mir im Jahr 2016 in einer Lehrveranstaltung noch anhören muss, dass

Kaffeesudlesen.png
Kaffeesudlesen: Kobald Agile Expert & IT-Projects, 2016

das magische Projektmanagementdreieck ein wichtiges Steuerungsinstrument sei, wird mir wieder bewusst, weswegen 70% der gescheiterten Projekt wegen „unterschiedlicher Planungssichten“ scheitern (vgl. IDG Business Research Service, 2013). Es wird immer schwieriger junge Kollegen die notwendigen Schritten setzen zu lassen, weil sie innere Blockaden aufbauen, die ihren „Werteeinstellungen zu Modellen“ widersprechen, weil sie davon überzeugt sind, dass der vorgeschlagene Ansatz falsch ist. Wo ist hier die notwendige Optionsoffenheit? Anders ausgedrückt, wo bleibt der Blick über den Tellerrand?  Als Freelancer gibt es aber immer nur ein Ziel, nämlich den Auftrag des Kunden laut Vertrag zu erfüllen, denn der ist unsere einzige Grundnorm. Wie aber können wir das leisten, ohne passende Metriken? Auch Frage ich mich, wie das in dynamischen Marktumfeldern, dynamischen Entwicklungen und dynamischen Projekten mit einseitigem „Gurudenken“ oder einseitigem „Standard-Modell-Denken“ funktionieren soll? Bitte erinnern wir uns gemeinsam an das KANO-Modell. Uns als Freelancer muss es immer um Value des Kunden gehen und das mit Excitment Attributes!

Von welchen Metriken rede ich? 

agile-iron-triangle
Source, Learntesting Ltd, 2016

Prinzipiell ist meine momentane Sichtweise zum Thema agile Methoden durch die Erfahrung gekennzeichnet, dass es derzeit eine Menge an Missverständnissen dazu gibt. Hier kann diese Problematik nicht eingehend diskutiert werden. Nur so viel – wenn man in seinem Skillprofil „agile Methodenkenntnisse“ angibt, dann sollte man diese in der Tat auch jahrelang angewandt haben. Weiter sollte man dann auch verstanden haben, dass es bei agilen Ansätzen nicht um Projektmanagement geht, sondern um Controlling und Metrics sowie um Value Driven Scopeerfüllung. Anders gesagt, wenn ich eine Fehlerkurve habe, dann kann ich auch eine Fehlerkostenkurve entwickeln und frühzeitig steuern, um entlang der Requirements den Fachbereich ehestmöglich entscheiden zu lassen, ob ein oder mehrere Featrues unter der Prämisse der Projekt-Zeiteinhaltung zu einem bestimmten Zeitpunkt x Must-Have-Criterias sind, um einen Gesamt-Roll-Out einer Applikation oder einer Systemkomponente zum definierten Zeitpunkt x1 zu gewährleisten.

Erkenntnistheorie in der Softwareentwicklung, oder das Divide et impera Prinzip 

Harry Mash Sneed’s „Teufelsquadrat“ (Evils Square) eigent sich eindeutig besser als das magische Projektdreieck passende Metrik-Deduktionen vorzunehmen. Mich stört jedenfalls die Starrheit des Modells enorm. Um Cost Center bilden zu können, die der Eichtzeit-Realität entsprechen, fehlt im Teufelsquadrat ganz explizit die wichtige Metrik der Prioritätensetzung. Sowohl das magische Projektdreieck als auch das Teufelsquadrat sind Modelle mit metaphysischen Grundgedanken, da sie zu einseitig sind. Mit beiden Modellen soll eine Prognose möglich sein. So wie diese allerdings gestaltet sind, führen sie eher zur Mantik – der Kunst der Zukunftsdeutung. Das Wort „Mager“ aus dem Altiranischen bezeichnet die metaphysische Zuordnung von bestimmten Kräften an Ereignisse oder Zustände. Diese Modellvoraussetzungen sind für mich daher wenig dafür geeignet Software-Metriken abzuleiten.

Computersysteme und Software sind formale Realitäten deren Komplexitätsgesammtheit nur in reduzierter From entlang formaler Aspekte in formalen Modellen abgebildet werden. Klarerweise deswegen, weil Systeme nur formale Programmiersprachen verstehen. Softwareprodukte sind reale, formale Gegenstände mit logischen Abläufen, denen gleichzeitig das Prinzip der Komplexitätsreduktion inhärent ist. Divide et impera ist ein alter Spruch der Softwareentwicklung. Das heutigen Divide and conquer Algorithm Paradigma entspricht genau den Gedanken des bisher gesagten. Ein Divde and conquer Algorithmus arbeitet rekursiv indem ein Problem in mindestens zwei und mehr Sub-Probleme des selben Problemtyps heruntergebrochen wird. Die Lösungen werden dann logisch kombiniert,  um das eigentliche Problem lösen zu können. Anders ausgedrückt werden Eigenschaften der Software abstrahiert, um ein Lösungsmodell zu finden. Beispielsweise werden in der Entwicklung von Navigationssoftware formale Kriterien (Eigenschaften) wie Erdkrümmung, Oberflächnereliefs, Straßen,- und Ortskarten etc. pp zu einem Softwaremodell abstrahiert.

Entzwei und gebiete! Tüchtig Wort; Verein und leite! Bessrer Hort. (Johann Wolfgang von Goethe)

 

 

In der Messung und Schätzung von Softwareentwicklungs-Projekten geht es, genauso wie in der Erkenntnistheorie, darum, Strukturen zu analysieren, um eine  Aussage „wahr“ oder „nicht wahr“ zu erhalten. Das heißt, kann ich aus bestimmten Parametern Erkenntnis darüber erlangen, ob diese als Metriken geeignet sind oder nicht.

Was hat die „Reine Rechtslehre“ Hans Kelsens mit Metriken zu tun?

In Summe plädiere, und wende ich meine Modellidee selbst seit vielen Jahren an, für eine „reine“ Schätz,- u. Metrikenlehre. Ganz im Sinne von Hans Kelsens „reiner Rechtslehre“einem zentralen Vertreter der rechtlichen Erkenntnisgewinnung. In der Vergangenheit und während meines Studiums beschäftigte ich mich intensiv mit der Erkenntnistheorie. Deren Vertreter geht es um das Wesen und den Grenzen der „wahren“ Erkenntnis. Ein wichitges Themengebiet bilden die Fragen nach der Struktur von Erkenntnis. So gelten im Recht Normen als struktureller Bezugspunte (Kategorien). Den verschiedenen Denkansätzen der Erkenntnistheorie sind zwei grundlegende Fragestellungen gemein: Wie und auf welche Weise sind Begründungsketten innerhalb einer „Konstruktion“ (z. B. Meinungssystem) strukturiert?Der Vater der österreichischen Verfassung kritisiert die Sein-Sollen-Dichotomie. Die Aussage, dass „etwas ist“, ist von der Aussage, dass „etwas sein soll“, grundlegend zu unterscheiden. Wenn etwas sein soll, ist das Wunschdenken ohne wissenschaftliche Verifikationsmöglichkeit. Es geht ihm um die Festlegung von „reinen“ Rechtsnormen, in einem Normensystem mit bestimmten Grundnormen, um  relative Werturteile in der Rechtssprechung vermeiden zu können. Es geht Kelsen um die streng wissenschaftliche Begründung von Normen. So sehe ich eine reine Schätz,- u. Metrikenlehre: In etwas umgekehrter Form zeigt mir meine Erfahrung, dass das Berufen auf wenige, statische Grundparametern wie Time, Budget und Resource kein erfolgsversprechendes Steuerungssystem bieten (können). Es müssen aus vielen dynamischen Metriken, die sich auf jeweilige Cost Center als jeweils ein Metrikensystem beziehen, jene gefunden werden, die die Grundparameter (ähnlich der Kelse’schen Grundnormen) des Cost Centers bilden.

Formale Modelle – insbesondere in der Informatik (zum Beispiel von betrieblichen Aufgabenbereichen) – sind spezielle Formen von Erkenntnis. Sie sind das Ergebnis kognitiver, empirischer Verfahren (Beobachtung, Beschreibung, Typisierung, Abstraktion, Formalisierung). Damit sind sie und ihre Erstellung Gegenstand erkenntnistheoretischer Überlegungen. (Rupp/Holl, 2006)

Die Parallele zur Erkenntnistheorie ist jedenfalls laut Chris Rupp und Alfred Holl (beide aus dem RE-Bereich) eine eindeutige und ist keineswegs von der Hand zu weisende, und wenn Experten im Range einer Chris Rupp  von „Erkennntnistheorie, (Wirtschafts-) Informatik und Requirements-Engineering“ schreiben, ist wohl eine Menge daran, bestimmte Erkenntnistheorien zu überdenken und auf deren Umsetzungsmöglichkeit auf Projektmetriken hin zu überprüfen.