A SPICE löst Probleme in der Entwicklung

Teil 1 unserer Artikel-Serie über A SPICE.
Lesen Sie auch unseren Einführungsartikel Drei Mythen rund um A SPICE.

Bevor wir im ersten Teil der Serie in die Tiefe gehen, gibt es eine wichtige Denkweise bzw. Betrachtungsweise, die wir im Vorfeld näher betrachten möchten:

Dr. Gerhard Wohland [1], grandioser Systemtheoretiker, Autor des Buchs “Denkwerkzeuge der Höchstleister” und Leiter des Instituts für dynamikrobuste Organisation (IdO) unterscheidet zwischen der blauen Welt stabiler, vorhersehbarer Umgebungen mit festen Prozessen und der roten Welt unsicherer, dynamischer Umgebungen, die Flexibilität erfordern.
In der blauen Welt steht Effizienz durch standardisierte Regeln im Vordergrund.
Die rote Welt erfordert Anpassungsfähigkeit und den Umgang mit Ungewissheit und Überraschungen. In beiden Welten tauchen Probleme auf… Aber was genau sind Probleme?

Probleme werden, von Dr. Gerhard Wohland, als Signale beschrieben, die man nicht ignorieren kann. Wenn man sie trotzdem ignoriert, kann das später zu Schwierigkeiten führen. Das bedeutet, wir müssen uns mit solchen Problemen auseinandersetzen.

Wie werden Probleme in der blauen und/oder roten Welt gesehen?

  • Die blaue Welt und Probleme:

In der blauen Welt werden Probleme oft als Störungen des normalen Betriebs betrachtet. Die idealisierte Annahme ist, dass, wenn alles nach Plan läuft, es keine roten Probleme geben sollte. Es gibt häufig vorgefertigte Lösungswege oder Richtlinien, wie mit bestimmten Problemen umzugehen ist. Die Lösung der blauen Probleme erfolgt mithilfe von Wissen, das z.B. in Prozessen, Methoden oder Arbeitsanweisungen konserviert ist.

  • Die rote Welt und Probleme:

In der roten Welt werden Probleme oft als Gelegenheiten für Lernen und Weiterentwicklung gesehen. Das Auftreten eines Problems signalisiert, dass es etwas Neues zu entdecken oder zu verstehen gibt. Anstatt auf vorgefertigte Lösungen zurückzugreifen, werden in dieser Welt kreative und innovative Ansätze zur Problemlösung benötigt und gefördert. Die Person, die eine Lösung für das Problem, zu dem es noch kein Wissen geben kann, erarbeiten soll, ist entscheidend. Rote Probleme lassen sich nur durch Können und nicht durch Wissen lösen.

Weiterlesen

Drei Mythen rund um A SPICE

In unserer neuen Serie möchten wir Ihnen über A SPICE erzählen.
Den Anfang machen wir mit einer kurzen Einführung und Allgemeinen Informationen . Das A steht übrigens für Automotive :-)
Den Rest erfahren Sie natürlich auch.

Also klären wir doch erstmal die Frage: “Was ist Automotive SPICE?“.

Automotive Software Process Improvement and Capability Determination, kurz Automotive SPICE, ist zweifellos ein wichtiges Werkzeug zur Verbesserung der Systementwicklungsprozesse in der Automobilindustrie. Es bietet eine strukturierte und standardisierte Herangehensweise, um die Qualität und Effizienz in der Entwicklung zu steigern.

Die Kernbedeutung von Automotive SPICE lautet zusammengefasst:

Weiterlesen

“Alles unter vier Releases im Jahr ist Wasserfall“ – Releaseplanung im agilen Systems Engineering

„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” ist eines der zwölf Prinzipien des agilen Manifests für Softwareentwicklung. Man könnte also je nach Auslegung dessen, was „couple of months“ bedeutet, ableiten, dass alles unter einer gewissen Anzahl von Releases pro Jahr keine agile Entwicklung mehr ist. Das mag vielleicht ein Indikator sein, Sie sollten sich jedoch auch bewusst machen, ob in Ihrem konkreten Kontext überhaupt die Notwendigkeit, Möglichkeit und Sinnhaftigkeit für eine solche Releasefrequenz besteht. Die Frage nach der Zweckmäßigkeit haben wir bereits im ersten Beitrag unserer Serie adressiert und im letzten Beitrag sowie in einem Fachartikel sind wir auf eine in vielen Bereichen essenzielle Voraussetzung für Releases eingegangen, die Dokumentation – oder genauer gesagt einen Ansatz („Continuous Documentation“), um diese aktuell und in einem releasefähigen Zustand zu halten. In diesem Beitrag möchten wir nun auf die aus unserer Erfahrung heraus wichtigsten Punkte eingehen, die bei der Releaseplanung im Rahmen einer Produktentwicklung zu berücksichtigen sind.

Weiterlesen

Keine Continuous Delivery ohne Continuous Documentation! – agiles Systems Engineering im regulierten Umfeld

Kurze Releasezyklen oder Releases-on-Demand? Der Usus in der technischen Entwicklung (Systems Engineering) geht eher in Richtung ein oder maximal zwei Releases pro Jahr. Ein häufiger Grund dafür, den wir in unseren Kundenprojekten beobachten, ist, dass die Dokumentation nicht auf dem aktuellen Stand ist und damit – zumindest in Bereichen, in denen die Dokumentation regulatorisch für ein Release erforderlich ist – kein Release stattfinden kann. Den ersten wichtigen Schritt, um dem entgegenzuwirken haben wir bereits im letzten Blogbeitrag unserer Serie zum agilen Systems Engineering beschrieben. Nämlich die systemische, gesamtheitliche Betrachtung dessen, was dazu erforderlich ist, um das Produkt auf den Markt zu bringen, z.B. eben die Dokumentation. Ein konkreter Ansatz, dem das Verständnis der Dokumentation als Teil des Produktes zu Grunde liegt, ist Continuous Documentation. Das Ziel: Die Dokumentation zu jedem Zeitpunkt der Entwicklung in einem potenziell releasebaren Stand zu halten, um dadurch den Gedanken des auslieferbaren Inkrements der agilen Softwareentwicklung auch im technischen Umfeld zu erfüllen.

Weiterlesen

Den Blick für das Wesentliche wahren – wertschöpfende Tätigkeiten im agilen Systems Engineering

“Was ist der Betrachtungsgegenstand in der Entwicklung?“ – eine Frage, die wir unseren Kunden immer wieder stellen und die überraschend häufig zu längeren Diskussionen zwischen den an der Entwicklung beteiligten Personen führt. Warum ist diese Frage im Kontext der Entwicklung von Systemen so wichtig? Ganz einfach! Wenn Sie nicht wissen, was das Ergebnis Ihrer Systementwicklung sein soll, fällt es Ihnen schwer, die für dessen Erzeugung notwendigen Tätigkeiten festzulegen und mit dem erforderlichen Aufwand durchzuführen.

Weiterlesen