V‑Modell, DevOps und KVP: Philosophien des IT‑Projektmanagements

OK, worum geht es eigentlich? Nerden wir uns rein:

Software: Alle digital speicherbaren Inhalte. Damit umfasst der Qualitätsbegriff bei Software alle bei der Bearbeitung und Entwicklung anfallenden Artefakte - mit dieser Sprachregelung wird der Blickwinkel aller Beteiligten auf das „große Ganze“ erweitert.

Engineering: Fachkompetentes, bewusst‑gezieltes Gestalten von Technik.

Na ja, tatsächlich sind Ingenieure (prinzipiell) dazu da, den Stand der Wissenschaft in einen neuen Stand der Technik umzuwandeln. Techniker wenden den Stand der Technik dann für neue Aufgabenstellungen an, Meister bedienen sich der auf diese Weise entstandenen Ergebnisse. In der Praxis darf sich natürlich jeder an alles heranwagen 😉.

Philosophien und Paradigmen
Es existiert leider kein belastbarer Stand der Technik oder Wissenschaft, nach dem wir aus Eingangsgrößen wie Unternehmenskultur, Art des Projekts, Persönlichkeitseigenschaften der beteiligten Personen und Beziehungshistorien direkt und zwingend logisch auf die am besten passende Art des Projektmanagements schließen können. Ein hochwertig moderierter Aushandlungsprozess samt Erarbeitung eines tauglichen Verhaltenskodexes (code of conduct) zu Beginn wird sich im Laufe des SDLC amortisieren. Und damit komme ich zu zwei ausgewählten Beiträgen zum Thema, das V‑Modell und DevOps:

Das V‑Modell
Zur Visualisierung des gesamten Projektes zeigen wir als Software Engineers immer mal wieder auch unauffällig am Rande das jeweils zugrunde liegende Entwicklungsparadigma, hier das V‑Modell: Dieses basale Element des Software Engineerings dient dazu, allen Personen im Team eine umfassende Perspektive auf das Projekt zur zweiten Natur werden zu lassen. Aber jetzt erst einmal zum Inhalt des klassischen V‑Modells. Grundsätzlich stellt der linke Ast die Planungsschritte dar, unten findet die Umsetzung ihren Platz, rechts aufsteigend sind iterative Schritte von Test und Integration notiert. Das Modell findet in der Industrie Anwendung für Projekte aus Hardware, Software, Maschinellem Lernen, Künstliche Intelligenz und ihre Kombinationen wie z.B. bei embedded Systemen. Natürlich geht es im Kern um Softwareentwicklung und das Projektmanagement.
Der Entwicklungsprozess geht links oben mit dem maximal erfolgskritischen Requirements Engineering und damit den Spezifikationen los. Ist es wirklich eine gute Idee, einen introvertierten Entwickler mit dieser Aufgabe beim Kunden zu betrauen? Na ja, kann man machen. Es folgen immer noch links die SOLL‑Architektur‑ und Entwurfsfmuster, darzustellen überwiegend in der Modellierungssprache UML. Alle Ergebnisse bis hierher sind bereits Bestandteil der Software. Unten findet sich zentral die Realisierung von Hardware HW und aktiver Software SW mit semantisch bedeutsamen Kommentarzeilen, so dass Betrieb, Wartung, Ergänzung und die Wiederverwendbarkeit der Module gute Chancen auf elegante Bearbeitung haben. Jetzt geht es auf dem rechten Ast mit schrittweiser Integration HW/SW oder SW/SW und parallelen Tests weiter. Schrittweise entsteht so auch parallel die IST‑Architektur in UML. Wer die Testentwicklung von den Entwicklern der aktiven SW‑Komponenten durchführen lässt, ist selbst schuld: geplantes Misslingen ist die typische Folge. Natürlich soll ein freundschaftlicher(!) Wettbewerb zwischen Testern und Entwicklern stattfinden. Dies stellt für die Führungskräfte eine gewisse Herausforderung dar - aber diese werden ja auch für ihre Qualitäten als Soziale Architekten bezahlt 😉. Oben rechts sind noch Freigabe und Auslieferung notiert. Damit findet das klassiche V‑Modell seinen unvollständigen Abschluss: als wäre der Betrieb ohne Belang. Daher ist es eine gute Idee, auch die Betriebsphase immer mitzuführen. Immerhin entstehen dort regelmäßig 75% der Kosten. Dies macht die finanzielle Bedeutung des Requirements Engineering RE deutlich: Nachlässigkeiten beim RE fallen typischerweise erst während des Betriebs auf, die Behebung der Fehler ist maximal kostenträchtig und weist erhebliches Konfliktpotenzial in alle Richtungen auf. Das V‑Modell ist gut geeignet für Projekte im Bereich Embedded (z.B. Integration mit ASICs und Controllern), bei regulatorischen Vorgaben und vertraglich festgelegten Pflichten‑ und Lastenheften. Agilität kann dann immer noch in Form eines in Teilbereichen „agilen Wasserfalls“ einfließen.

Das DevOps‑Paradigma
Der Grundgedanke von DevOps wird durch die liegende Acht als Symbol für Unendlichkeit visualisiert: Viele schnelle Durchläufe sind gegenüber einer „Big‑Bang‑Integration“ zu bevorzugen. So wird beispielsweise angestrebt, dass nach jeder Freigabe eines beliebig kleinen Codebestandteils automatisch ein neuer Build als ad‑hoc‑Test gestartet wird. Auf diese Weise bleiben die gegenseitigen Abhängigkeiten (Interdependenzen) von Änderungen überschaubar und können im Abbruch‑ bzw. Fehlerfall leicht korrigiert werden. In diesem Zuge sprechen wir auch von Continuous Build, Integration und Deployment, der CB/CI/CD‑Pipeline: Automatisierung wird für alle Tests angestrebt. Entropie erzeugende, lokale Workarounds können so vermieden werden. Insgesamt ist DevOps damit enger an Agilität gekoppelt als das V‑Modell. Achtung: DevOPs ist kein Tool, nicht jira oder was auch immer. DevOps ist eine handlungsleitende innere Haltung, eine besondere Art des Denkens und ja, auch des Fühlens. Planen Sie einige Jahre kompetenten Führungshandelns für die Transformation ein, um die äußerst positiven Wirkungen von DevOps zur Entfaltung zu bringen.

Der Kontinuierliche Verbesserungsprozess KVP aus dem Lean‑Management
Halt! Stopp! Bitte nicht einfach abwinken, weil Lean‑Management LM bei Ihnen bisher noch nicht funktioniert hat. Das ist normal, denn LM ist in der asiatischen, kollektivistischen Kultur entwickelt worden. Für eine Anwendung in unserer individualistischen Kultur braucht es erhebliche Übersetzungsleistung, wie sie ein Wirtschaftspsychologe gut leisten kann. Mal anders überlegt: so falsch kann nicht sein, was Toyota zum weltgrößten Automobilhersteller mit 1a‑Werten für KPIs wie z.B. die FTT (First Time Through) gemacht hat. Auch kann es nicht falsch sein, Verschwendung zu minimieren, einer der Grundgedanke des Lean‑Managements LM. Falsch ist es nur, die Werkzeuge allzu naiv einsetzen zu wollen, dann ist LM bei uns in der Produktion als Begriff schnell verbrannt. Andererseits: es gibt auch bei uns Unternehmen mit Kulturen, in denen LM wunderbar funktioniert. Die Idee der kontinuierlichen Verbesserung KVP ist in jedem Fall erkennbarer Bestandteil von DevOps. Die optimale Gestaltung des Ganzen erfordert allerdings auch in dieser Anwendung wirtschaftspsychologische Kompetenz.

Eine Info am Rande zum Geschäftsmodell Software: per Download erhältliche Software ist nahezu überall in der Welt zollfrei (man recherchiere zur aktuellen Lage unter gtai.de).

Tja, und dann gibt es noch in jeder Phase jeder Entwicklung Gefahrlosigkeit bei Fehlfunktion (Safety), Schutz (Security by Design z.B. durch Realisierung der großen Drei) und die Gefahrlosigkeit der beabsichtigten Funktion (SotiF) mitzudenken. Das alles gelingt nur dann gut, wenn wir Software Engineers als Projektleiter fachlich hochwertig in Moderation, Mediation und Gesprächsführung ausgebildet sind. Allzu oft findet eine Root Cause Analysis (RCA) verborgene Mängel als Ursache an genau dieser Stelle mangelhafter Praxistauglichkeit der Kommunikation, ohne dass irgend jemand vor der RCA auf diese Idee kommen konnte. Insgesamt finden die Modelle für sehr unterschiedliche Projektarten hilfreiche Anwendung: Ob nur Hardware, nur Software, Maschinelles Lernen und Künstliche Intelligenz, embedded oder was‑auch‑immer, der dahinter stehende Prozessgedanke taugt (fast) immer.

Also dann: schauen Sie sich die einzelnen Schritte auf meinen Webseiten näher an oder wir überlegen gemeinsam.

Reden wir jetzt darüber!