Guten Morgen liebe Forengemeinde,
ich habe Fragen zur agilen Geräteentwicklung (soll Firmware, Mechanik
und Elektronik umfassen).
Ich habe zwar Erfahrungsberichte im Netz dazu gefunden, jedoch waren
diese meist von Managern/Abteilungsleitern verfasst.Ich würde gerne von
Entwicklern Feedback dazu hören, da wir bei uns in der Firma mit dem
Gedanken spielen auf diese Weise Geräte zu entwickeln. Ich bin selber
Hardware-Entwickler, habe aber noch nie agil entwickelt.
Bedeutet... das Ziel wird dynamisch, das Ziel bewegt sicht. Die
Spezifikationen, die Anforderungen, kommen erst waehrend des
Entwicklungsprozesses raus. Bedeutet N moegliche Schema Varianten
einplanen, die man nach Wunsch dann bestuecken und testen kann.
Funktionelle Gruppen koennen einzeln zugeschaltet und ueberbrueckt
werden. Per Draht/Bruecke, per Software. Also nicht mit einem Tiny AVR
beginnen, denn es kommen ploetzlich zusaetzlich benoetigte Signale
hinzu.
Zusaetzlich zur seriellen Schnittstelle lieber noch eine USB to serial
hinzu, weil Serial alleine nicht mehr sexy erscheint. Am Controller per
Jumper selektierbar.
Du wirst schnell bei der 3.Version der Leiterplatte sein. Weil sich
immer mehr rauskristallisiert.
Eigentlich sollte man so arbeiten wenn man das Problem noch nicht mal
genau kennt und trotzdem eine Loesung bringen muss.
Das Ziel von agiler Entwicklung ist, daß Manager öfter darüber
informiert werden, was Entwickler so treiben. Somit lernen die Manager
endlich, was los war.
Sowas kostet den Leistungsträger aber viel Zeit.
Kann denn heute niemand mehr ein Lasten- bzw. Pflichtenheft schreiben?
Offenbar nein. Das letzte Lastenheft, das auf meinem Tisch lag,
beschrieb alle verwendeten Stecker detailgenau mit 3D-Darstellung bis
auf die letzte Rastnase. Im Gegenzug fehlte die gewünschte
Gerätefunktion völlig.
Mit Agilität wird das dann zur grundsätzlichen Methode.
Na dann Prost, Genossen!
Bürovorsteher schrieb:> Kann denn heute niemand mehr ein Lasten- bzw. Pflichtenheft schreiben?
Wie sieht das in der Realität denn aus.
Ich kenne zwei z.T. extreme Ausprägungen.
1. Du bekommst WischiWaschi Anforderungen und musst in vielen
Gesprächen, Meetings, Mails etc. die eigentlichen Anforderungen
herausfinden, definieren und vom Kunden absegnen lassen
2. Der Kunde hat sich die Pest und Cholera in Form eines
Beratungsunternehmens ins Haus geholt und die liefern jetzt ein 150
Seitiges Dokument mit utopischen und völlig überzogenen Anforderungen
für ein Gerät/Software das eigentlich nur den Entwicklungsumfang von
30PT haben soll. gewünschte Fertigstellung war vor einem Monat weil die
Berater so lange gebraucht haben, Budget ist schon überzogen.
In beiden Fällen ergeben sich immer wieder Änderungen.
Agil hat jetzt die Idee diese eh unvermeidlichen Änderungen mit in die
Vorgehensweise aufzunehmen.
Was in der Realität aus diesem Modell wird, siehe dazu die vielen
Aussagen aus in dem anderen Thread auf den ich oben verwiesen habe.
Mein persönliches Fazit: Ich bleibe schön in meiner Ecke, und möglichst
weit weg von unseren agilen Teams :-)
Bürovorsteher schrieb:> Kann denn heute niemand mehr ein Lasten- bzw. Pflichtenheft> schreiben?> Offenbar nein.
Deine wunderbaren Heftchen nützen dir nichts wenn sich die Welt draußen
weiter dreht.
Entweder
du folgst deinen ursprünglichen Heftchen sklavisch,
du hoffst dass die hellseherischen Fähigkeiten der Autoren
ausreichend
waren um ein paar Jahre in die Zukunft zu sehen,
benutzt die Heftchen als Waffe "Aber das steht genau so da!"
um jede Diskussion abzubügeln (da kommt der ganze Bürovorsteher
raus),
bist nach ein paar Jahren mit der Entwicklung fertig und
der Kunde oder der Markt schauen blöd
weil dann etwas anderes benötigt wird,
obwohl deine Heftchen doch klasse sind
Dein Chef schaut auch blöd weil der Kunde längst was anderes hat,
was zwar nur 50% von deinem Produkt kann,
dafür aber Jahre früher auf dem Markt war und gut genug ist.
oder
du etablierst ein Änderungsmanagement,
einmal im Monat wird an den Heftchen herum geschrieben,
du läufst den Änderungen hinterher,
baust sie bei Gelegenheit ein und
ärgerst dich dass du jedesmal wieder ein paar Monate Arbeit
in den Müll werfen kannst
zumindest ist das Produkt halbwegs brauchbar,
ist doppelt so teuer wie geplant,
kommt spät und
deine Heftchen sehen toll aus (wofür dir niemand Geld gibt)
oder
du etablierst ein Änderungsmanagement,
einmal in der Woche wird durch die Anforderungen und
(neue) Wünsche des Kunden oder veränderte Marktsituation
gegangen (inhaltlich, zeitlich, finanziell),
du entscheidest was du in der nächsten Woche angehst,
musst gelegentlich eine Woche Arbeit wegwerfen,
der Kunde bekommt eine Reihe von halbfertigen Zwischen-Produkten
mit denen er heute teilweise leben kann,
das endgültige Produkt wird etwas teurer als geplant,
ist brauchbar und auf deine Heftchen schei*t du
weil es zu teuer ist die ständig umzuschreiben
und dir niemand Geld für perfekte Heftchen gibt.
Letzteres nennt sich agil. Der Kern von "agil" ist es ein schnelles
Änderungsmanagement zu haben. Die ersten beiden Alternativen sind die
klassischen Ansätze. Der zweite dabei mit dem Versuch ein paar Probleme
des ersten zu umgehen.
In Zeiten in denen Kunden und Märkte durch schnelle Änderungen verwöhnt
sind und die benötigten hellseherischen Fähigkeiten für langfristige
Planungen in der Industrie immer noch nicht vorhanden sind siehst du mit
den klassischen Ansätzen immer wieder schei*e aus.
koocky schrieb:> da wir bei uns in der Firma mit dem Gedanken spielen auf diese Weise> Geräte zu entwickeln
Na wunderbar, entsprechend der Softwarebranche, die seit 10 Jahren nur
noch kaputte Produkte unzureichender Leistungsfähigkeit abliefert, soll
dann also auch eure Hardwareentwicklung kaputt gemacht werden.
Bei Software kostet es 'nur' Zeit, ein Programm ständig umzuschreiben
(daher dauert Entwicklung seit Scrum auch 10 x so lange wie vofher). Bei
Hardwareentwicklung kostet es richtig Material das weggeschmissen wird.
Na denn Prost. Hauptsache die Velocity im Schaumschlagen steigt von
Sprint zu Sprint, dann kann sich der BWL Hecht auf die Schulter klopfen.
Ich arbeite schon seit Jahren agil. Weil niemand ein Pflichtenheft
schreiben kann. Weil niemand die kleinen Details ueberblickt. Es gibt
immer ein "UUps", etwas wurde vergessen. Sei dass der Prozess anders
laeuft wie geplant, sei dass die Leute vom Prozess an den Leuten der
Elektronik vorbei reden, weil sie eben einen anderen Hintergrund haben.
Sei, dass die Komponenten nicht das machen was man glaubte sie machen
wuerden.
Deswegen, bei einer Wischi-Waschi Anfrage mit ungenauen/fehlerhaften
Details immer kommunizieren - ja wir koennen das, aber Termine und
Kosten werden ueberzogen. Wenn sie einen Schnelleren und Guenstigeren
haben - machen lassen. Die geschaetzten Kosten mal 3 ist ein Ansatz.
Eher mehr.
Ja, es ist gut, wenn die nicht-Fachleute bei der Entwicklung mitreden.
Sonst ist die Entwicklung eine Blackbox, welche sowieso zu lange dauert
und viel zu teuer ist.
Schliesslich muessen oft Nicht-Fachleute mit der Loesung leben. Wenn man
denen die Arbeit erleichtert hat man viel gewonnen.
Solange die fertige Hardware einfach nach 15min aus dem Compiler fällt
und man dem Kunden damit alle vier Wochen ein Exemplar mit dem
bescheidenen Fortschritt präsentieren kann, relativ geringe
Änderungswünsche (wir wollen doch in den USA verkaufen) das Design nicht
komplett obsolet machen und so etwas wie EMV vollständig isoliert von
der Umgebung mit sich selber ausgemacht werden kann, ...
...warum nicht?
Nein, der Kunde, resp Auftraggeber, kann ja auch inhouse sein, ist
eingebunden. Die wollen erst mal etwas, was laeuft. Um zu sehen, dass
das Problem richtig verstanden wurde. Dann kommen "unbedingt"
Anforderungen in einer naechsten Stufe.
EMV, Debug- und Fabrizierbarkeit muessen natuerlich von Anfang an
eingeplant, aber nicht unbedingt ausgefuehrt werden. Bedeutet das EMV
Filter ist im Schema, im Layout, wird aber nicht bestueckt. Debug pins,
Kontroll Leds sind im Schema und im Layout und koennen in einer
spaeteren Version unbestueckt bleiben.
Das macht dann eben den erfahrenen Entwickler aus, an moeglichst alles
zu denken was die anderen (noch) nicht bedenken.
EMV ist auch keine Hexerei mehr, das ist planbar. Ausser mam beschreitet
voellig neue Konzepte, wie das erste Mal Plastikgehaeuse, das erste Mal
Medizin.
Ich hatte auch schon einen DCDC drin, mit der Ahnung den in einer
naechtsen Stufe durch einen Linearen zu ersetzen. Bedeutet schon beim
einplanen des DCDC dran zu denken, wie man beim Linearen die Waerme
wegbringt. Dass das dann eben ein TO220 sein wird und angeschraubt
werden muss. Mit der ersten Version war das Rauschen zu hoch, sie
konnten aber trotzdem die Funktionalitaet testen. Und ja es ist gut,
wenn die Leute total versiffte Signale sehen und in einem naechten
Schritt sind die sauber. Sie sollen richtig zittern. Dann bist du es,
welcher das Projekt gerettet hat.
Das Material, welches auf der Leiterplatte ist ist eh vernachlaessigbar.
Doof ist, wenn man schon Material fuer 100 Stueck bestellt hat.
Von einem meiner Kunden kenne ich die folgende Vorgehensweise:
Der Produktmanager hat durchaus Ahnung von Elektronik und macht als
Erstes einen Schaltungsvorschlag. Dabei sucht er schon Bauteile zusammen
und schreibt deren Absolute Maximum Ratings als Anforderungen in ein
Dokument, das sich weder als Lastenheft noch als Pflichtenheft ansehen
lässt. Funktionale Anforderungen sind hingegen entweder sehr vage
formuliert, was mehr offene Fragen generiert als beantwortet. Oder sie
sind sehr streng formuliert, aber leider nicht vollständig durchdacht.
Und dann werden mit Visio auf der "Leiterplatte" schon einmal die
ausgesuchten Kernkomponenten zusammengewürfelt, natürlich ohne den
Platzbedarf für das Vogelfutter, andere wichtige Schaltungsteile,
Montagebohrungen, Kühlkörper usw. realistisch zu berücksichtigen. Und
wenn sich dabei herausstellt, dass noch ein Quadratzentimeter frei sein
sollte, wird einfach noch eine weitere, von den Endanwenders niemals
benötigte Funktionalität hinzuerfunden.
Dir fehlt die Autoritaet, resp der Kunde hat noch zuwenig Projekte an
die Wand gefahren. Das kommt dann spaeter.
Spaetesten wenn man von EMV, Produkesicherheit und Normen redet ist
Ruhe. Dann muss man noch ein paar Duzend : "was waere wenn" Faelle
durchspielen .. Falschbedien-Ruecklaeufe, Falschbedien-Supportfaelle, ..
.. der Kunde in China bezahlt 50k fuer diese Loesung und wenn's dann
aussteigt ? Zuruecksenden, 3 Wochen warten, oder wer geht hin ? Ich bin
dann in den Ferien.
Udo S. schrieb:> Bürovorsteher schrieb:>> Kann denn heute niemand mehr ein Lasten- bzw. Pflichtenheft schreiben?>> Wie sieht das in der Realität denn aus.> Ich kenne zwei z.T. extreme Ausprägungen.> 1. Du bekommst WischiWaschi Anforderungen
Ja, aber warum ist das so?
Weil die Anforderungen oftmals von Leuten erstellt werden, die keine
Ahnung davon haben wie man das richtig macht. Es ist also ein
selbstgemachtes Problem. Wenn eine Firma nur einen Vertriebler mit dem
Kunden sprechen lässt, der grundsätzlich erstmal alles verspricht nur um
den Auftrag zu bekommen, dann darf man sich nicht wundern wenn es die
Entwicklungsabteilung nachher entsprechend schwer hat.
koocky schrieb:> Guten Morgen liebe Forengemeinde,>> ich habe Fragen zur agilen Geräteentwicklung (soll Firmware, Mechanik> und Elektronik umfassen).>> Ich habe zwar Erfahrungsberichte im Netz dazu gefunden, jedoch waren> diese meist von Managern/Abteilungsleitern verfasst.Ich würde gerne von> Entwicklern Feedback dazu hören, da wir bei uns in der Firma mit dem> Gedanken spielen auf diese Weise Geräte zu entwickeln.
Und wie soll das funktionieren? ?
Hardware kann man nicht mal eben einfach so ändern wie Software, bzw.
die Kosten für eine Änderung sind wesentlich größer.
> Weil die Anforderungen oftmals von Leuten erstellt werden, die keine
Ahnung davon haben wie man das richtig macht.
.. Du kannst auch selbst zum Kunden hingehen und an dem Vorbeireden. Der
erzaehlt dir die fuer ihn selbstverstaendlichen Details nicht.
Doof wenn das erst erkannt wird nachdem alle glauben ein wasserdichtes
Pflichenheft existiere
Joggel E. schrieb:>> Weil die Anforderungen oftmals von Leuten erstellt werden, die keine> Ahnung davon haben wie man das richtig macht.>>> .. Du kannst auch selbst zum Kunden hingehen und an dem Vorbeireden. Der> erzaehlt dir die fuer ihn selbstverstaendlichen Details nicht.>> Doof wenn das erst erkannt wird nachdem alle glauben ein wasserdichtes> Pflichenheft existiere
Pacta sunt servanda. Wenn der Kunde den Lieferumfang X bestellt und
unterschrieben hat, kann er nicht einen beliebig(!) anderen Lieferumfang
Y erwarten. Jedenfalls nicht ohne Aufpreis.
Mark B. schrieb:> Ja, aber warum ist das so?>> Weil die Anforderungen oftmals von Leuten erstellt werden, die keine> Ahnung davon haben wie man das richtig macht.
Na ja, wenn der Kunde die Expertiese selbst hat, dann kann er das
Projekt auch selbst machen.
Es ist doch der Normalfall, dass sich immer jemand mit technischer
Ahnung mit dem eigentlichen Anwender zusammensetzt und Stück für Stück
die Anforderungen zusammenstellt.
Dass man ein "gutes" Lasten oder Pflichtenheft bekommt ist doch
höchstens bei BtoB der Fall, also wenn z.B. Bosch die Entwicklung einer
Elektronikkomponente auslagert. Und selbst dann ist man nie vor späten
Anforderungsänderungen gefeit.
Ich sage nicht das das schön ist, aber es ist halt der Normalfall.
ohne aufpreis..Das war gestern.
Eben das waere der agile Teil davon. Das Ziel ist variabel, der Preis
auch. Wichtig ist, dass nachher eine akzeptable Loesung existiert.
Udo S. schrieb:> Na ja, wenn der Kunde die Expertiese selbst hat, dann kann er das> Projekt auch selbst machen.
Nicht unbedingt. Vielleicht hat er die Expertise, aber selbst nicht
genügend freie Kapazität.
> Es ist doch der Normalfall, dass sich immer jemand mit technischer> Ahnung mit dem eigentlichen Anwender zusammensetzt und Stück für Stück> die Anforderungen zusammenstellt.> Dass man ein "gutes" Lasten oder Pflichtenheft bekommt ist doch> höchstens bei BtoB der Fall, also wenn z.B. Bosch die Entwicklung einer> Elektronikkomponente auslagert. Und selbst dann ist man nie vor späten> Anforderungsänderungen gefeit.>> Ich sage nicht das das schön ist, aber es ist halt der Normalfall.
Ich hab auch schon gute Spezifikationen/Lastenhefte/Pflichtenhefte
gesehen. Ist zugegeben eher selten, aber es kommt vor.
Mark B. schrieb:> Pacta sunt servanda.
Ja klar, wenn der CEO des Kunden mit deinem CEO regelmäßig Golf spielt
oder der Kunde mit einem Auftrag über 50 Mio in 5 Jahren wedelt und
deine Abteilung gerade mal 15 Mio Jahresumsatz macht, dann lacht dir der
Kunde ins Gesicht und du machst das.
Und zwar PRONTO!
So oft kannst du dir gar nicht einen neuen Job suchen wenn du das
verweigerst.
Udo S. schrieb:> Mark B. schrieb:>> Pacta sunt servanda.>> Ja klar, wenn der CEO des Kunden mit deinem CEO regelmäßig Golf spielt> oder der Kunde mit einem Auftrag über 50 Mio in 5 Jahren wedelt und> deine Abteilung gerade mal 15 Mio Jahresumsatz macht, dann lacht dir der> Kunde ins Gesicht und du machst das.> Und zwar PRONTO!>> So oft kannst du dir gar nicht einen neuen Job suchen wenn du das> verweigerst.
Wenn es um Produkte geht, die eine Zulassung durch Behörden erforden
(Automotive, Medizintechnik, Luft- und Raumfahrt, Eisenbahn, ...) wird
man selbstverständlich nicht jeden Quatsch akzeptieren, den der Kunde
will. Man ist ja durch entsprechende Normen gebunden, die man einhalten
muss.
Joggel E. schrieb:> Dir fehlt die Autoritaet, resp der Kunde hat noch zuwenig Projekte an> die Wand gefahren. Das kommt dann spaeter.
Wieso fehlt mir die Autorität? Ich beobachte doch nur, welche Leute bei
welchen Kunden arbeiten.
Und der betreffende Produktmanager war bzw. ist ja nicht mein
Auftraggeber, sondern die Entwicklungsleitung. Und die stört sich an
solchen tollen Konzepten genau so sehr wie ich. Wenn auf Grund solcher
Vorgaben "Extrarunden" gefahren werden müssen, stört mich das nicht im
geringsten, denn das bedeutet ggf. Folgeaufträge. Wichtig ist nur, diese
Themen dem eigentlichen Auftraggeber gegenüber richtig zu kommunizieren.
Anders sieht das natürlich bei Projekten aus, bei denen der Kunde ein
fertiges Produkt und nicht nur die Entwicklungsleistung einkaufen will.
Im Nachhinein wäre es vermutlich oft besser gewesen, die (zukünftigen)
Entwickler einer Lösung vorher ausgiebig das Problem selber erkunden zu
lassen.
Also wenn Firma X z.B. irgendein altes Gerät durch ein Neues ersetzen
will, läßt man die Entwickler vorher einen Vormittag lang ein Praktikum
in der Abteilung machen, damit sie den aktuellen Stand selber
kennenlernen und erfahren.
Am Nachmittag setzt man sich mit den Entscheidern zusammen und der Kunde
erklärt, wie er sich die Zukunft vorstellt.
Ich weiß, wird so nie gemacht, aber man wird ja mal träumen dürfen...und
wer weiß, wieviele Krisenbesprechungen und Telefonate eine solche
Vorbereitung ersetzen würde.
Danke schon mal für den Input. Ich habe mir auch schon gedacht, dass es
wahrscheinlich keine gute Idee ist und mehr Schlechtes als Gutes mit
sich bringt.
koocky schrieb:> Danke schon mal für den Input. Ich habe mir auch schon gedacht, dass es> wahrscheinlich keine gute Idee ist und mehr Schlechtes als Gutes mit> sich bringt.
Nein, agile Methoden, und dazu gehört nicht nur Scrum, sind sehr einfach
zu sabotieren. Wenn man nicht mit dem Willen und der Einstellung heran
geht die Methoden für sein Projekt positiv zu nutzen und die Methoden
nur rituell dem Wortlaut nach, nicht nach den Ideen dahinter,
anzuwenden, dann scheitert man wahrscheinlich.
Agile Entwicklung hat erst mal gar nichts mit Scrum zu tun. Ich betreibe
schon schon seit fast 40 Jahren agile Entwicklung in Hardware und
Software. Im Sinne von moeglichst schnell etwas zum Zeigen,
Loesungsorientiert. Schnelle Abfolge von Aenderungen, das Ziel bewegt
sich.
Auch aus der Notwendigkeit heraus eine Antwort zu haben auf die Frage :
Wie weit sind Sie naechsten Freitag ? Haben wir dann etwas zum Anschauen
?
Denn wenn du im Kaemmerchen vor Dich hin arbeitest, hast du von den
Auftraggebern her, auch inhouse, gefuehlt zu lange, und die Arbeit ist
zu teuer.
Dann ist es besser immer auf sichtbare Ziele hin zu arbeiten, und das
weniger Noetige auf spaeter zu verschieben. Dabei kommt trotzdem
Debugging und EMV, CE, Normen zuerst. Dann kommt das Gehauese, das Look
and Feel, und dann erst die Funktionalitaet. Anders herum ist nicht gut.
Da ich fast immer alleine an einem Projekt arbeite, habe ich Scrum nie
vermisst.
Es immer um die Praesentation von sich selbst. Die Arbeit wird um so
mehr geschaezt je besser die Show dazu ist. Am besten jeden einzelnen
verbauten Transistor als den grossen Durchbruch feiern. Und wenn du eine
Platine mit drei Transistoren bringst, welche einen Ballon aufblasen ist
das sowas von wahnsinnig gut, das reicht fuer ewigen Star Status.
Denn deine Auftraggeber haben keine Ahnung was du effektiv tust.
Andreas S. schrieb:> Von einem meiner Kunden kenne ich die folgende Vorgehensweise:>> Der Produktmanager hat durchaus Ahnung von Elektronik und macht als> Erstes einen Schaltungsvorschlag. Dabei sucht er schon Bauteile zusammen> und schreibt deren Absolute Maximum Ratings als Anforderungen in ein> Dokument, das sich weder als Lastenheft noch als Pflichtenheft ansehen> lässt. Funktionale Anforderungen sind hingegen entweder sehr vage> formuliert, was mehr offene Fragen generiert als beantwortet. Oder sie> sind sehr streng formuliert, aber leider nicht vollständig durchdacht.>
Really?
Die Absolute Maximum Ratings als Anforderung?
Ich würde weglaufen, schnell es geht.
Wühlhase schrieb:> Zumindest die Beschreibung in deren Blog klingt durchaus interessant.
Ich hab mir einen Kunden von denen angesehen: relayr.io.
Ich persönlich ordne den Kunden unter "Schaumschläger" ein. Rein von
deren Homepage.
Ich war da mal zum VG. Die betreiben Scrum der übelsten Sorte. Ansonsten
wirkten die ganz in Ordnung. Der Chef war in kurzer Hose zum VG, genauso
wie ich ;).
Thread beobachten
Seitenaufteilung abschalten