Leserfrage: Modulare Maschine sinnvoll?

Frage:

5. Ein Grund, warum späte Veränderungen an Software nicht so kostspielig sind wie an Hardware, ist die geringere Abhängigkeit der Systemkomponenten.

- Sollte man da bei der Entwicklung von Hardware auch ansetzen und versuchen, Produkte so zu konzipieren, dass Bauteile möglichst unabhängig voneinander austauschbar sind?

- Ist das überhaupt möglich?

 

Eine fein granular modulare Maschine zu bauen ist immer wieder ein Thema. 

Die gesamt Anlage ist modular (vom Granulat – Palette mit Flaschen). Die eigentliche Maschine nicht. Es gibt aus meiner Sicht mehrere Gründe dafür.

1.         Eine Modulare Maschine ist ca. 20-30% teurer da viele Schnittstellen und zum Teil auch zusätzliche Antriebe notwendig sind.

2.         … ist es schwieriger hochdynamische Prozesse zu fahren.

3.         … ist mehr Installationsaufwand erforderlich – bis die Maschine produziert – da mehrere Einheiten aufeinander abgestimmt/ eingestellt werden müssen.

4.         … erfordert mehr Entwicklungszeit da die Schnittstellen zwischen den Modulen auch entwickelt werden müssen.

5.         … die Maschine wird grösser – und Platz ist sehr teuer.

6.         …

Ich denke hochspezialisierte Systeme sind modular nicht sinnvoll.

...schwierige Frage…, denn modular ist so ein Schlagwort unter dem man viel verstehen kann. Denn anders betrachtet ist auch unsere Maschine modular. Denn wann immer spezial Lösungen in der Maschine erforderlich sind, finden wir ein Modul das wir „reinschrauben“ können und es funktioniert. Also ich würde sagen, wir haben einen Baukasten und keine Module.

Die Frage stammt von Steffen Berreth, er schreibt seine Bachelorarbeit über das Thema "Agiles Projektmanagement in der physischen Produktentwicklung"

Leserfrage: Hardware nach ROI priorisieren?

Frage:

Inwieweit reicht es bei der Entwicklung von Hardware aus, Anforderungen nach ROI zu priorisieren, ohne deren Abhängigkeiten durch klassische Sequenzierungsmodelle wie z.B. Gantt- Charts abzubilden und zu planen?

ROI ist die Priorisierungsmethode für uns. Allerdings muss ROI richtig verstanden werden – vor allem das Return – für uns gehört da mehr dazu als nur Euro zB Kundenzufriedenheit welche sich zusammensetzt aus Personalbindung, Energieverbrauch, Umrüstzeit, und einigen anderen Punkten.

Du siehst für uns ist ROI nicht so „flach“ bewertet wie für manch andere.

Auch eine Form der Gantt Charts verwenden wir – es gibt Meilensteine zB wenn eine Produktion mit der neuen Maschine starten muss. Der Umfang bis zu diesen Meilensteinen ist veränderbar. Unter Umständen lassen wir gewisse Features weg, die für einen Produktionsstart nicht zwingend erforderlich sind – und haben dadurch mehr Zeit für die wirklich wichtigen Features.

Zwingend erforderlich dafür ist, dass der PO versteht, was der Kunde braucht – noch besser das Projektteam versteht es.

Gibt es keine Features die verschoben werden können müssen wir die Meilensteine verschieben. Eigentlich sind unsere Meilensteine im Release Burndown implementiert. Storys werden immer dem spätest möglichen Meilenstein zugeordnet. Somit haben wir ein dynamisches Gantt Chart im Release burn down. Um genau zu sein machen wir das nicht mehr sehr ausführlich da unser Kunde nicht mehr den Bedarf an Meilensteinen hat. Das kommt daher das wir permanent mit ihm abgestimmt sind und er jederzeit weiss wie der Projektstand ist und auch immer wieder nachsteuern und eingreifen kann.

Die Frage stammt von Steffen Berreth, er schreibt seine Bachelorarbeit über das Thema "Agiles Projektmanagement in der physischen Produktentwicklung"

3 Tage scrum master Training...

... leider ist es vorbei. Vorab - es war ein tolles und sehr gewinnbringendes Training.

Sehr spannend ist, dass es keine grossen Unterschiede zwischen Software und Hardware gibt, zumindest was Entwicklung mit agilen Methoden anbelangt. Wären da nicht ein paar spezielle Domänenbegriffe könnte man nicht sagen ob es sich um Hard oder Software Entwickler handelt.

Also zumindest bei den Trainings von «Das Scrum Team» muss man als Hardware Entwickler keine Angst haben das Falsche zu lernen. Im Gegenteil, ich fand es spannend das an sich gleiche Problem aus verschiedenen Richtungen betrachtet zu sehen.
Auch die Abhandlung des Trainings mittels einem von den Teilnehmern mitgestalteten Backlogs ist super, da es Raum für konkrete Probleme aus dem Alltag lässt.

Das Training vermittelt neben dem Scrum Rahmenwerk auf viel Verständnis dafür wieso selbiges gut und wichtig ist. Und erst dieses Verstehen kann zu einem motivierten agilen Mindset führen.
Ich kann jedem, der in Zukunft agil oder mit scrum arbeite soll - muss - darf, ein CSM Training zu besuchen. Egal ob man danach SM oder PO oder was auch immer für eine Rolle einnimmt, ein Kurs dieser Art vermittelt viel Verständnis für die agile Welt. Man merkt sehr schnell das Scrum kein Hexenwerk, sondern eine ganz natürliche Geschichte ist.

Ich freue mich schon heute von den Erfolgsgeschichten der anderen Teilnehmer zu hören.

Scrum beyond Software

Toll das es jetzt auch schon CSM Trainings gibt die nicht nur auf Software Entwicklung eingehen.

Peter Beck wird nächste Woche ein spezielles Scrum Master Training für agile Entwicklung ausserhalb der Software abhalten. Ich werde auch anwesend sein um unsere Erfahrungen im Maschinenbau weiterzugeben. Die Veranstaltung ist in Sankt Gallen – für mich also um die Ecke.

Ich hatte mein CSM Training bei Peter und kann es daher sehr empfehlen.
 

LINK