Kontinuierliches Testen und Integrieren

Herr Vitalji, der eine Diplomarbeit über das agile Entwicklungsvorgehen schreibt, hat sich mit 4 Fragen an mich gewandt. Die 3. davon ist:

Das kontinuierliche Integrieren und Testen der Produktinkremente hat in der agilen Entwicklung eine große Bedeutung. Wie sieht das Integrieren und Testen der Produktinkremente in der agilen Hardwareentwicklung aus?

Das Integrieren und Testen der Baugruppen, in den ersten Inkrementen, erfolgt in der virtuellen Welt. Sehr viele Punkte können wir mittels Berechnungen oder durch Reviews mit Experten testen. Auch das Integrieren mehreren Maschinekomponenten zueinander erfolgt virtuell. Zuerst wird Baugruppe A, dann Baugruppe B geplant. Das Integrieren von A zu B wird dann oft als eigene Story aufgesetzt. 
Während der Konzepterstellung kommt es auch vor das gewisse Sachen nicht berechenbar sind oder die Berechnungen zeigen das es knapp ist. Dann wird vom Team oder vom PO vorgeschlagen ein Funktionsmuster der betreffenden Einheit zu bauen.
Später wenn reale Hardware vorhanden ist wird weiterhin "inspect and adapt" betrieben. Das heisst erkennen wir ein Teil der Maschine das nicht wie gewünscht funktioniert, oder besser wäre wenn es anders funktioniert, wird es ausgetauscht. 
Ja das kann sehr viel Geld kosten aber es wird weiterhin nach Kosten - Nutzen entschieden ob etwas angepasst wird oder nicht. (nach ROI priorisierter Backlog)
Der Vorteil der agilen Methode liegt darin das wir einen höheren Reifegrad im Prototypen erreichen und dadurch weniger oft teure "real" Hardware austauschen müssen. Für die Projektkalkulation haben wir bis dato mit ca. 100% des Preises einer ganzen Maschine gerechnet was an Versuchsteilen und Ausschussbaugruppen anfällt. Bei der aktuellen Entwicklung  werden wir nicht mal die 50% Marke erreichen.

Agile Bodensee early bird

agile bodensee early bird Ticket

Anforderungen beim Start eines Hardware Projektes

Herr Vitalji, der eine Diplomarbeit über das agile Entwicklungsvorgehen schreibt, hat sich mit 4 Fragen an mich gewandt. Die 2. davon ist:

Die Änderung von Anforderungen ist in der Hardwareentwicklung nicht so problemlos wie im Softwarebereich. Wie detailliert müssen die Anforderungen zu Beginn eines Hardwareentwicklungsprojektes vorliegen und die Umsetzung geplant werden? 

Wenn wir für ein neues Projekt viele detaillierte Anforderungen hätten, wäre eine agile Vorgehensweise nicht sinnvoll. 

Wir haben uns für scrum entschieden da anfangs sehr wenig Anforderungen vorhanden sind. Meistens gibt es eine Idee oder eine spezielle Anfrage des Kunden die zu einer neuen Maschine führt. Wie die Idee umgesetzt werden könnte ist höchstens in groben Ansätzen vorhanden. Aus den Ideen und Vorstellungen wird gemeinsam ein Vision erstellt. Sachen wie Lastenheft, Pflichtenheft,... fallen komplett weg. Und bei einer Ausgangslage wie dieser macht es Sinn agil zu entwickeln.

Wir machen ein Inkrement und stellen es dann vor. Sobald die Stakeholder den 1. Entwurf sehen findet sofort die gewünschte Feedback Diskussion statt. " ... das ist so wie wir uns das vorstellen... , ...aber das wäre besser wenn es so funktioniert... , ...könnte man nicht...". Mit diesen Inputs erstellen wir neue user storys die dann wieder priorisiert und in den folgenden Sprints abgearbeitet werden.

Mit diesem Vorgehen beim aktuellen Projekt haben wir erreicht das jetzt die Maschine in "real hardware" in der Montagehalle steht und jeder Stakeholder findet das sie so ist wie er sich das vorgestellt hat. Wir haben, im Vergleich zu früheren Projekten, keine Diskussionen, ob das so wie es da steht so ist wie man es wollte.

Will man scrum Projekte im Hardware Bereich durchführen, muss aus meiner Sicht ab dir 1. Projektidee agil gearbeitet werden.

Änderungen an den Anforderungen sind in der Planugsphase sehr leicht umzusetzen. Durch das agile Vorgehen sind weniger Änderungen an der "real Hardware" notwendig da die Qualität der 1. Maschine in vielerlei Hinsicht besser ist als bei nicht agilem Vorgehen.

Shipable in der Hardware Entwicklung

Herr Vitalji, der eine Diplomarbeit über das agile Entwicklungsvorgehen schreibt, hat sich mit 4 Fragen an mich gewandt. Die 1. davon ist:

In der agilen Entwicklung wird ein potentiell auslieferbares Produktinkrement nach jeder Iteration verlangt. In der Hardwareentwicklung ist das Fertigstellen von auslieferbaren Produktinkrementen in kurzen Iterationen problematisch und gegebenenfalls mit hohen Kosten verbunden. Wie sieht ein Produktinkrement in ihrer agilen Hardwareentwicklung aus und was ist in dem Fall der auslieferfähige Zustand des Produktinkrements? 

Das ist eine Frage die wir lange und oft diskutiert haben bevor wir mit scrum gestartet haben. Wir sahen das auch lange als schwierig an.

Wir haben das "shipable" gegen "reviewable" getauscht. Das heisst nach einem Sprint ist die Konstruktion der betreffenden Einheit auf einem Stand das Stakeholder sich eine Meinung bilden können. Somit ist sichergestellt das in die nächste Interration alle erforderlichen Punkte einfliessen können. Die Stakeholder mit denen wir diese Reviews abhalten können aus den unterschiedlichsten Bereichen kommen. Je nach Projektstatus kann das der zukünftige Betreiber einer Maschine oder auch unser Monteur sein der die Anlage später zusammenbauen muss. Bei allen Reviews ist der Product Owner eingeladen. Mit unseren 3D Zeichensystemen sind wir in der Lage etwas so darzustellen das es für jeden verständlich ist. Komplexere Abläufe können wir animieren. Die Animationen gehen ohne grossen Aufwand soweit das wir die Bewegunskurven aus dem Programm Antrieb ins CAD einlesen und dort die Abläufe in "Echtzeit" darstellen.

Also der auslieferfähige Zustand ist für uns der Zustand in dem wir Bilder, 3D Daten, Animationen, Analysen etc so darstellen können das wir Feedback bekommen. Ich denke das ist auch der Grundgedanke von shipable.