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.
Sehr schöner Artikel und überhaupt ein interessanter Blog. Um aufzudrücken, dass ein product increment “reviewable” sein soll, nutzen wir in der Scrum Community den Begriff “potentially shippable”. Euer 3D Model ist in etwa das, was z.B. bei den Softwerkern ein Testsystem ist. Ihr könnt wie die Softwareleute das Produkt bauen lassen und zum Kunden ausliefern. Wie die Softwerker werdet ihr aber auch hier so manche Überraschung erleben. Übriges in vielen IT-Umgebungen ist auch dieser Schritt nicht gerade günstig. Auch da unterscheiden sich Softwareteams nicht so sehr von Hardwareteams. Wie die Hardwareteams versuchen die Softwerker diesen letzen Schritt durch ein möglichst realistisches “potentially shippable product increment” günstig und risikoarm zu gestallten. Den Sourcecode könnte man am Besten mit dem Eurem Konstruktionsmodel bzw. den Konstruktionszeichnungen vergleichen. Ich finde aber Euer Argument, dass die Stakeholder die Lieferung sich anschauen bzw. reviewen können - wie soll ich sagen - sehr anschaulich :-)
AntwortenLöschenMehr hier