Hallo, wer von euch hat eigentlich schon einmal richtig entwickelt, also so, wie man es in der Theorie lernt? - D. h. SCRUM, Wasserfallmodell, V-Modell, W-Modell, Spezifikation, Lastenheft, Pflichtenheft, CMMI, SPICE, Versionvserwaltung, CD, CI, Bestimmung der zyklomatischen Komplexität, Testspezifikation, Testplanerstellung, Test-Driven-Design, Design-for-Testability, formale Spezifikation, formale Verifikation, Projektmanagement, Life Cycle Management, Dokumentation, ASIL, ISO26262 Oder ist es eher normal, dass die "Hauptsache-es-geht"-Mentalität vorherrscht?
Es hängt nun mal auch vom Entwickler ab. Diese Procedere die du genannt hast, sind ja schön und gut, aber müssen auch mit Entwicklern gefüllt werden, sonst sind sie nichts wert. Aber andererseits wird auch so ein stromlinienförmiger Entwickler gebraucht, der diese Prozesse treiben kann und genauso auch ein glattes Produkt, dass durch diese Prozesse passt. Wie du hier siehst, sind diese Prozesse eher für Massenware von der Stange geeignet, die in Millionen-Stückzahlen verkauft werden sollen und daher man sich weniger Fehler erlauben kann. Für Basisinnovationen und Grundlagenforschung kannst du solche Prozesse knicken. Aber nur mit den Letzten lässt sich das gute Geld verdienen, für die glatten Produkte brauchst du Masse und kriegst nur Krümmel pro Einheit. Also so oder so, ich entwickle lieber Einzelprodukte.
Stefan H. schrieb: > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? - D. h. SCRUM, Wasserfallmodell, > V-Modell, W-Modell, Spezifikation, Lastenheft, Pflichtenheft, CMMI, > SPICE, Versionvserwaltung, CD, CI, Bestimmung der zyklomatischen > Komplexität, Testspezifikation, Testplanerstellung, Test-Driven-Design, > Design-for-Testability, formale Spezifikation, formale Verifikation, > Projektmanagement, Life Cycle Management, Dokumentation, ASIL, ISO26262 Bei uns im Konzern wird nur so entwickelt. Stefan H. schrieb: > Oder ist es eher normal, dass die "Hauptsache-es-geht"-Mentalität > vorherrscht? Das klingt für mich, mit Verlaub, eher nach kleiner "Bastlerbude", vielleicht noch ein Start-Up oder gar Hobbyprogrammierer. Wenn man ein Auto entwickelt, arbeitet man auch nach gewissen Prinzipien und sagt nicht "Hauptsache es geht".
Stefan H. schrieb: > wer von euch hat eigentlich schon einmal richtig entwickelt Offenkundig Software. Damals, vor Scrum, da wurde noch richtig entwickelt, und es kam was bei raus, es war für den Kunden kostengünstig und für die Firma lukrativ genug. Bei Flugzeugsoftware darf man auch keine Bananensoftware abliefern, sonst Boeing 737Max. Aber schöner waren Aufträge die kurz liefen. Ganze Programme, 1 Tag mit dem Auftraggeber klären was er braucht, 1 Tag programmieren, 1 Tag testen, 1 Tag dokumentieren, Freitag ist frei. Da kamen richtig nützliche Programme bei raus die jahrelang im Einsatz waren. Auch noch ok wenn es je 1 Woche dauert. Aber ein sauberer Wasserfall, wo nicht zwischendrin 99% nachgeschoben werden. Stressfrei, planbar, effektiv. Heute, na, alles Pfusch. Seit Scrum und Kanban. Teuer, dauert ewig, kommt nix bei raus, aber es sind dutzende Leute gut beschäftigt und keiner hat einen PLAN.
Stefan H. schrieb: > Hallo, > > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? Umso grösser, komplexer (Abhängigkeiten / Schnittstellen etc.), umfangreicher etc. ein Softwareprodukt in der Entwicklung ist, umso mehr rentiert sich der Aufwand (in eingesparten Budget- bzw. "Manntagen" hinsichtlich bspw. Testing, Qualität) eines professionellen Entwicklungsvorgehens, Testingmethodiken und QM-Prozesses. Jedoch rentiert dies nicht unendlich (Entwicklungskosten gehen nicht gg. 0) sondern, prof. Vorgehen sparen im Projekt u.a. (meistens) höchstens einen Teil an Aufwand und Kosten ein wenn sie soweit optimiert sind, aber das heisst nicht dass sie komplett gegen 0 gehen (Law of Diminishing returns). Hingegen geht der Nutzen des Aufwands solcher Verfahren gegen 0, umso kleiner der Entwicklungsaufwand bzw. Komplexität dieses Produkts ist. D.h. aber als Fazit bzw. Umkehrschluss: So richtig habe ich aber in kleineren Projekten entwickelt, wo eben nicht dieser ganze Ballast, der auch einiges an Administration erfordert, anfällt. Da war ich die meiste Zeit mit "Entwicklung" an allen möglichen Modulen also direkt im Code, beschäftigt. Da aber auch gibt es Methodiken wie TDD, wo man ja bekanntlich die Testklasse vor der eigentlichen schreibt. Das was du als "richtig" entwickeln bezeichnest, fällt in die Kategorie, Grossprojekte meistens in Konzernen, wo man eher als kleines Zahnrad vom ganzen etwas entwickelt, aber meistens eher Meetings, Standups, Dokumentation schreibt und so fast gar nicht mehr entwickelt.
Konzernangestellter schrieb: > Das klingt für mich, mit Verlaub, eher nach kleiner "Bastlerbude", > vielleicht noch ein Start-Up oder gar Hobbyprogrammierer. Die arbeiten heute alle nach Scrum, Kanban,... alles schon gesehen sind oft moderner unterwegs als jeder Konzern wo ich bis jetzt gesehen habe. Ob das immer besser oder sinnvoll ist sei mal dahingestellt aber das Klischee kleiner Laden -> Gefrickel stimmt schon lange nicht mehr. > Wenn man ein > Auto entwickelt, arbeitet man auch nach gewissen Prinzipien und sagt > nicht "Hauptsache es geht". Das Ergebniss ist aber oft so wo man denkt genau so wurde dort der Schrott entwickelt, siehe VW mit seinen neuens Modellen, Golf und der andere Softwaremüll.
bashooka schrieb: > Klischee kleiner Laden -> Gefrickel stimmt schon lange nicht mehr. Um so besser. bashooka schrieb: > Das Ergebniss ist aber oft so wo man denkt genau so wurde dort der > Schrott entwickelt, siehe VW mit seinen neuens Modellen, Golf und der > andere Softwaremüll. Wenn die Prozesse zu bürokratisch werden, kann das Innovation abwürgen. Aber wenn in einem großen Konzern jeder oder jedes Projekt einfach nach dem Prinzp" Hauptsache unser Part geht" arbeitet und nicht nach Prozessen und Standards entwickelt wird, endet das erst recht im Chaos.
klausi schrieb: > Das was du als "richtig" entwickeln bezeichnest, fällt in die Kategorie, > Grossprojekte meistens in Konzernen, wo man eher als kleines Zahnrad vom > ganzen etwas entwickelt, aber meistens eher Meetings, Standups, > Dokumentation schreibt und so fast gar nicht mehr entwickelt. Das kann ich so bestätigen. Macht aber trotzdem Spaß und ist auch nicht so anstrengend.
> SCRUM
Damit fuettert man nur kleine Kodierschweinchen die niemals
das Grosse & Ganze im Blick haben.
Der Erkenntnishorizont liegt bei 24 Stunden.
Und genau solch zusammengestueckelter Dreck kommt da auch
zum Schluss raus. Und mit "richtig" entwickeln hat das
natuerlich ueberhaupt nichts zu tun.
Würde ich so nicht sagen. Ich habe in vielen schlechten Scrum Projekten gearbeitet - aber auch in guten. Jedenfalls aus Entwicklersicht. Am allerwichtigsten finde ich, dass alle ihre Rolle kennen und verstehen. Und natürlich sollten die Rollen auch entsprechend den Kompetenzen vergeben werden. Es nützt nichts, einen PO zu definieren, der keine Anforderungen festlegen kann. Oder einen Scrum Master, der es als seine einzige Aufgabe versteht, Sprints zu starten und zu stoppen. Auch wenn das Entwicklerteam kein durchgängiges Verständnis von Scrum hat, führt das sehr schnell zu ungleicher Arbeitsverteilung und viel gefühltem Overhead. Meine Erfahrung ist hier auch, dass sich viele Entwickler krass überschätzen. Die haben dann mal ein Buch angelesen oder ein youtube Video über Scrum geguckt und meinen dann, sie wären fit. Und wenn das Projekt scheisse läuft, ist halt das blöde Scrum schuld. Aber so ist es eben nicht. Auch Scrum erfordert eine gewisse Denkweise und ein Teamverständnis. Man muss sich selbst gut kennen, kommunizieren können, einen guten Überblick über die Teamaktivität haben, Augen und Ohren offen halten. Man kann sehr viel falsch machen, in einem Scrum Projekt. Das Problem ist, dass ein schwaches Team-Mitglied relativ schnell das ganze Projekt runterzieht, wenn man nicht rechtzeitig und richtig darauf reagiert. Aber wenn es rund läuft, finde ich das eigentlich ganz angenehm.
Richtig ? Und dann einen Konzern Ablauf zeigen... Ich entwickle auch "richtig", in endlicher Zeit, welches auch bei fast fehlenden Spezifikationen im Rahmen von Monaten ist. Fast fehlende Spezifikationen bedeutet nicht dass alles sowieso gut ist, sondern, dass diese oft erst am Projekt erarbeitet werden muessen. Bei mehreren Hardware Prototpen zieht sich's dann etwas laenger hin. Bei mir ist meist mit der Kleinserie Schluss. Dabei werden mehrere der genannten Schritte auf eine oder zwei Person zusammengefasst und optimiert. Und ja, es hat auch schon in ein Space Projekt gereicht, das Zeug war im Weltraum. Das geht offensichtlich mit einem Zweipersonen Projekt.
:
Bearbeitet durch User
Stefan H. schrieb: > Hallo, > > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? Die Frage ist doch schon, was man in der Theorie gelernt hat. Auf der Liste tauchen da bei mir einige der Begriffe auf (einiges gab es damals auch noch nicht ;-) Hier wird Folgendem größere Beachtung geschenkt: > Spezifikation, Lastenheft, Pflichtenheft, Versionverwaltung, > Komplexität, formale Verifikation, Projektmanagement, > Dokumentation Da wir allerdings nur zu zweit arbeiten ("Garagenunternehmen" passt ganz gut :-), fällt natürlich vieles weg, das in größeren Teams benötigt wird. Dazu kommt noch, dass wir nur noch für eigene Hardware/Maschinen/Forschung entwickeln, praktisch nicht mehr unter Auftrag. Feste Deadlines gibt's nicht (mehr) > Oder ist es eher normal, dass die "Hauptsache-es-geht"-Mentalität > vorherrscht? Am ehesten "zwingen" muss ich mich zur projektbegleitenden Dokumentation. Lässt man das einmal schleifen, dann kann man das am Ende fast nicht mehr nachhalten. Und: Ja, man weiß sonst nach einem Jahr nicht mehr, warum man dies so und so gemacht hat und warum dieser Sensor genau so hergestellt wurde. Trotz allem sind das hier aber doch schlanke Prozesse, einfach weil vieles ("Wer macht was?", "Wie lange benötigen wir dafür?") aufgrund der Kenntnis des anderen und der Erfahrung sehr gut eingeschätzt werden kann. Das ist dann wieder ein Vorteil eines Kleinstunternehmens :-)
:
Bearbeitet durch Moderator
Purzel H. schrieb: > Richtig ? Und dann einen Konzern Ablauf zeigen... Der TO hat ja nur eine bunt gemischte Sammlung irgendwelcher Schlagworte gelistet. Ein paar Methoden, ein paar Technologien, ein paar Produkte... Manches passt zu einander oder gehört ohnehin zusammen, manches schließt sich gegenseitig aus. Alles zusammen in einem Topf wäre ja das reinste Chaos. Mit der Unternehmensgröße hat das kaum was zu tun. Eher mit der Projektgröße... im Sinne von "steht der Aufwand im Verhältnis zum Projekt?". Um Versionsverwaltung, Spezifikationen und Testmethoden darf sich ruhig auch auch ein Einzelkämpfer Gedanken machen ;)
formale Verifikation das 1x1 der Softwareentwicklung. Wer das nicht macht der bastelt nur Was ein Troll-Thread
MaWin schrieb: > Heute, na, alles Pfusch. Seit Scrum und Kanban. Teuer, dauert ewig, > kommt nix bei raus, aber es sind dutzende Leute gut beschäftigt und > keiner hat einen PLAN. Das kann ich so nur bestätigen.
MaWin schrieb: > Heute, na, alles Pfusch. Seit Scrum und Kanban. Teuer, dauert ewig, > kommt nix bei raus, aber es sind dutzende Leute gut beschäftigt und > keiner hat einen PLAN. Du sprichst mir aus der Seele..
>formale Verifikation [ist] das 1x1 der Softwareentwicklung. Wer das nicht macht
der bastelt nur. Was [fuer] ein Troll-Thread
Aha, der Troll persoenlich. Bei Echtzeitanwendungen sagt sich "formale
Verifikation" mal so schnell, speziell was das Timing betrifft.
Stefan H. schrieb: > Hallo, > > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? Hä?! Es gibt keine Theorie zu "richtig entwickeln"! Sowie es keine allgemeinverbindliche Theorie zur richtigen Lebensführung gibt. Richtig ist, was in der Praxis gut funktioniert, für Dich und fürs Team.
Fpgakuechle K. schrieb: > Sowie es keine allgemeinverbindliche Theorie zur richtigen Lebensführung > gibt. > Richtig ist, was in der Praxis gut funktioniert, für Dich und fürs Team. Na ja, es gibt viele Leute, die dir vorschreiben wollen, wie man richtig zu leben hat. Also gibt es auch richtiges Entwickeln. Das müssen gar keine Taliban sein, Religiöse reichen schon, wahlweise umweltreligiös oder fortschrittsreligiös. Da besucht man Kurse zu SixSigma und wird zertifiziert, Schulungen zu Scrum und Kanban und bekommt Rollen zugesprochen, dann wieder ASIL und ISO14001, IEC61508, IEC61800. Jeder weiss, wie man's angeblich richtig macht, keiner von denen hat je ein erfolgreiches Produkt entwickelt. Am brauchbarsten war (damals, inzwischen auch Scrum) noch die Softwareentwicklung für die Flugzeugindustrie, die wussten wenigstens was sie taten, hatten Audits und klare Prozesse. Am witzigsten ist, dass man dir an der Uni beibringt was ein gutes Programm ist, schnell und klein, der passende Algorithmus, beweisbar. Aber die Hansel, die später erklären wollen wie man gute Programme schreibt das alles vergessen haben, für unwichtig halten, als störenden Zopf betrachten. Das werden die sein, die an der Uni nicht aufgepasst haben.
> Jeder weiss, wie man's angeblich richtig macht, keiner von denen hat je > ein erfolgreiches Produkt entwickelt. +1, obwohl von MaWin
Ich glaube ich habe mit 90% der am Anfang aufgezählten Dingen schon mal was zu tun gehabt. Eigentlich kann man das alles in folgende Gruppen aufteilen: * Dinge die schon auf dem Papier nicht funktionieren können. * Dinge die in der Praxis funktionieren könnten, wenn nicht <1001 reale oder erfundene Gründe> * Dinge die in der Praxis funktionieren, weil ... Zwischen den letzten zwei Gruppen verschieben sich die Dinge je nach Kontext. Zum Beispiel ist SCRUM sehr einfach durch Entwickler zu sabotieren und funktioniert dann nicht. Wasserfall kann mal funktionieren (1 Tage Projekt) und kann genau so fast garantiert eine Katastrophe werden (mehrjähriges Großprojekt). Usw. Genauso funktionieren Dinge manchmal und manchmal nicht wenn der Kontext ein anderer ist. Wenn zum Beispiel dein Konzern-Einkauf typischerweise 6 Monate braucht um einen weiteren Server für die Entwicklung ran zu schaffen, dann kannst du dir viele agile Methoden in die Haare schmieren. Allgemein wenn du eine Art Impedanzfehlanpassung zum Rest der Firma hast. Sei es der genannte Einkauf, der Vertrieb, der nicht zulässt das du mit dem Kunden redest, das Management das gewisse Powerpoints und objektiv sinnlose Kennzahlen sehen will ... Ein früherer Chef von mir sagte mal "irgendwo ist immer Minenfeld". Die Hälfte der Firma ist damit beschäftigt Minenfelder für die andere Hälfte auszulegen. Zum Schluss läuft es immer auf drei Dinge hinaus: 1. Kommunikation 2. Kommunikation 3. Kommunikation Ob das über ein Pflichten- und Lastenheft, "miteinander Reden" oder stillschweigend passiert, ob über Funktionen des Produkts oder Projektfortschritt kommuniziert wird, wenn es nicht passiert wird's Scheiße. Dem entgegen steht der typische, klischeehafte Entwickler. Egal ob man ihn als mundfaul, sozial ungeschickt oder Autist bezeichnet, in F&E sammelt sich ein spezieller Typ Mensch an. Manche kannst du noch mit Vorgaben wie einer formalen Spezifikation oder Daily Scrum einfangen, andere sind einfach hoffnungslose Nichtkommunizierer. Es gibt einen Anhaltspunkt auf den man achten kann: Wenn Teammitglieder aktiv oder passiv mehr Aufwand betreiben etwas zu vermeiden oder nicht richtig zu machen (Sabotage) als es Aufwand kosten würde es einfach zu machen und richtig zu machen. Um dein Projekt zu retten musst du notfalls auf so einen Helden verzichten.
:
Bearbeitet durch User
ich habe "früher" entwickelt, ein chilliger Job für Absolventen oder gar Ungelernte ... aber man entwickelt sich auch weiter und bleibt nicht lange auf solchen "niederen" Postitionen lange kleben
Die Standards, Theorien, Methoden oder Modelle, die du nennst, sind teils schwer vereinbar, teils ergänzend, orientieren sich an verschiedenen Werten und Prinzipien, finden auf unterschiedlichen Abstraktionsebenen der sozialen und technischen Arbeitsorganisation statt. Daraus lässt sich also schwer ein einheitliches Modell ableiten, mit dem man "richtiges Entwickeln" beschreiben könnte. Es handelt sich doch bei all den Buzzwords um Namen für Modelle, die in irgendeiner Art und Weise versuchen, die Komplexität beherrschbar zu machen, die bei ernstzunehmenden Projekten, die eine Vielzahl von Akteuren benötigen, immer vorliegt. Es sind Modelle, d.h. Abstraktionen, die in ihrer konkreten Implementierung nie den Lehrbüchern entsprechen, außer vielleicht bei stumpfer bürokratischer Anwendung. Die geht i.d.R. in die Hose. Erfahrung mit den verschiedenen Methoden und mehr noch: Erfahrung mit den Problemen, die sie zu lösen versuchen und gesunder Menschenverstand sind bei "richtigen Entwicklern" meist die beste Mischung.
Stefan H. schrieb: > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? Betonung auf 'richtig' oder auf 'Theorie'? Für mich ist das eine Aufzählung von Begriffen aus dem Lehrbuch. Manche der Begriffe kenne ich überhaupt nicht. Macht für einen Unwissenden vielleicht viel her, ist aber graue Theorie. Ich kenne nur die Entwicklung in kleinen 'Klitschen' mit etwa 25 Mitarbeitern. Und da wäre so ein theoretischer Überhang hinderlich bis sogar unmöglich. Und immerhin haben wir spezielle Elektroniken für Siemens entwickelt (Siemens kauft vieles zu und schreibt dann seinen Namen drauf). Also 'richtig' entwickeln in einem Autokonzern oder in einer mehr oder weniger Garagenfirma macht schon einen gewaltigen Unterschied. Stefan H. schrieb: > Oder ist es eher normal, dass die "Hauptsache-es-geht"-Mentalität > vorherrscht? Nein, das nicht. Pflichtenheft, gute Dokumentation, ISO etc. sind selbstverständlich.
tork schrieb: > Es handelt sich doch bei all den Buzzwords um Namen für Modelle, die in > irgendeiner Art und Weise versuchen, ... irgendein Produkt, d.h. Software, Bücher oder Schulungen, zu dieser Thematik zu verkaufen. Interessanterweise sind nämlich all die hochgelobten Methodenpäpste zufällig auch in erheblichem Umfang an den Unternehmen beteiligt, die die zugehörigen Produkte verkaufen. Und in den Schulungen lernt man auch, dass es eigentlich nur ein einziges Produkt gibt, mit dem man alle Aspekte der neuen Methoden umsetzen kann. Wie fragte schon Cicero: Cui bono? Aber nicht nur die Anbieter selbst preisen die strikte Einhaltung der Methoden an, sondern in vielen Unternehmen gibt es auch die entsprechenden Leute: keine Projektverantwortung mehr, aber hemmungsloses Durchsetzen der Methode, auch in sinnlosen bzw. ausweglosen Situationen. Den Höhepunkt erlebte ich vor etlichen Jahren, als der damalige Methodenpapst ernsthaft durchsetzen wollte, dass ein komplettes eingekauftes (in C geschriebenes) RTOS so umgeschrieben werden müsse, dass es seinem C++-Styleguide entspreche. Wohlgemerkt C++ und nicht etwa C. Dass so etwas doch ziemlich fehlerträchtig wäre und man sich damit natürlich auch von weiteren Releases des RTOS komplett abhängt, war dabei egal. Und dass damit auch die laufenden Projekte, in denen das RTOS schon eingesetzt wurde, um etliche Monate bis Jahre zurückgeworfen würden: ebenfalls egal.
:
Bearbeitet durch User
hast du sicher nicht ganz unrecht. Ich hab mir so Mühe gegeben, den Zynismus draußen zu lassen :/
> Pflichtenheft... etc. sind selbstverständlich.
Na sowas. Kommt irgendwie bekannt vor. Standardmaessig wissen die
Auftraggeber, auch Vorgesetzte, zwischen wenig bis gar nichts.
Das Pflichtenheft ist eher etwas was dem Auftraggeber das Gefuehl gibt
auch beteiligt zu sein. Entwickeln bedeutet man muss erst mal
herausfinden was gebraucht wird und wie die Details skalieren. Also ich
sehe eher ein Entwicklungslog und eine Buglist als zentrales Tool.
Das Pflichtenheft sagt zB wir wollen ein Radar vorne am Auto haben,
Frequenz, Reichweite.
Und du darfst dann die Antennenmontageorte herausfinden. Und wie man den
Strahl buendeln muss. Die Auftragsgeber duerfen dann die vorgeschlagenen
Details abnicken.
Purzel H. schrieb: > Das Pflichtenheft sagt zB wir wollen ein Radar vorne am Auto haben, > Frequenz, Reichweite. Nein, diese Information findet sich im Lastenheft. Im Pflichtenheft steht dann für jeden Punkt des Lastenheftes, wie das ganze umgesetzt wird. Das Pflichtenheft wird dabei vom Auftragnehmer erstellt. So zumindest die reine Lehre. Statt der Bezeichnung Lastenheft sind auch andere Begriffe üblich, z.B. Anforderungsspezifikation.
Am witzigsten finde ich ja, dass irgendwann die BWLer, ohne jegliche technische Ahnung, meinten den tatsächlichen Programmierern erklären zu müssen, wie man denn richtig zu entwickeln habe. Und dann die Programmierer alle schön brav und devot diesen Propheten in die Schleimspur gerutscht sind. Klar, eine erfolgreiche Software-Entwicklung braucht einen organisatorischen Rahmen. Aber die erfolgreichen Softwareteams, zumindest die, die ich kenne und sich viele Jahre erfolgreich auf dem Markt halten können, nutzen allesamt kein einziges Entwicklungsmuster in seiner Reinform. Diejenigen, die wieder schnell verschwinden oder nach langen erfolgreichen Jahren plötzlich schlechte Software anbieten und dann verschwinden, sind fast alle den Kurs der vorbildlichen, richtigen Entwicklung gegangen oder waren sowieso ein planloser Chaotenhaufen.
someone else schrieb: > Am witzigsten finde ich ja, dass irgendwann die BWLer, ohne jegliche > technische Ahnung, meinten den tatsächlichen Programmierern erklären zu > müssen, wie man denn richtig zu entwickeln habe. > > Und dann die Programmierer alle schön brav und devot diesen Propheten in > die Schleimspur gerutscht sind. Wer zahlt bestimmt die Musik. Das sind die BWLer. Du darfst bei deinem Arbeitgeber natürlich gerne einen kleinen Aufstand gegen die BWLer anzetteln. Ich werde den Zeitungsbericht darüber aufmerksam lesen (natürlich online).
Ich bin Hardwareentwickler hauptsächlich für Leistungselektronik. Ich war schon als Kind Bastler und hab meine eigenen Platinen entworfen. Studium hab ich mit Bestnote abgeschlossen. Hab einige Patente in meiner bisherigen Laufbahn anmelden können. Vor längerer Zeit wurde mein AG dann durch einen Konzern übernommen und uns dessen Prozesse übergestülpt, wie man „richtig“ zu entwickeln hat. Seit dieser Zeit geht es uns stetig schlechter. Jetzt treibt man eine neue Sau durchs Dorf und wir müssen Hardware nun (Schein-)“agil“ entwickeln. Rausgekommen ist dabei micromanagement per excellence. Tägliche Statusmeetings mit Team- und teilweise Entwicklungsleitung. Dazu alle zwei Tage Stand-Ups. Vor dem Sprintende dann der Aufruf, Stunden einfach zu buchen, dass das Burn-Down Chart passt. Ich hab keinen Bock mehr auf Entwicklung. Erste Bewerbungen sind raus. Ich versuche es in der Energieverteilung neu, aber den Sch*** können die selber machen!
Frustrierter_Entwickler schrieb: > Jetzt treibt man eine neue Sau durchs Dorf und wir müssen Hardware nun > (Schein-)“agil“ entwickeln. Bedeutet das wenn ich als normaler Elektriker und Hobby Enthusiast ein kleines 350€ Gerät aufmache bei dem ich gespannt Wunder erwarte wie das wohl gelöst wurde und mir denke das ist aber komisch umgesetzt, das sind ja nur 20€ Bauteile und ein Designtes 5v Netzteil.
Hannes J. schrieb: > Wer zahlt bestimmt die Musik. Das sind die BWLer. > > Du darfst bei deinem Arbeitgeber natürlich gerne einen kleinen Aufstand > gegen die BWLer anzetteln. Ich werde den Zeitungsbericht darüber > aufmerksam lesen (natürlich online). Ist mir doch wurscht, wenn die "BWLer" Geld verbrennen. Ich arbeite halt nicht mehr für solche Firmen. Wie Frustrierter_Entwickler schon schrieb, ich hab keine Lust mehr auf endlose Meetings und Vorgesetzte mit Mikromanagement-Fetisch, die dann anschließend den Entwicklern die Schuld zuschieben, dass es schief geht. Und übrigens, zahlen tut der Kunde, nicht der BWLer. ;-)
Stefan altes Haus! Wie gehts wie stehts? Noch arbeitslos oder wieder bei der Uni tätig?
Stefan H. schrieb: > wer von euch hat eigentlich schon > einmal richtig entwickelt Ich. Stefan H. schrieb: > also so, > wie man es in der Theorie lernt? Nein nicht so. Da kannst du lange suchen, in der Regel wird "getailord bis der Arzt kommt". Du verwechselst Entwicklung mit Einhalten von Prozessen. Die sind dazu da, eine Qualität zu erreichen und garantieren. Du verwechselst Entwicklung mit Einhalten von Normen. Die sind dazu da, dass du nicht etwas am Stand der Technik vorbei oder schlechter als Stand der Technik entwickelst. Und noch einen habe ich, das hier ... Stefan H. schrieb: > ASIL, ISO26262 ... passt eigentlich überhaupt nicht zu ... > "Hauptsache-es-geht"-Mentalität ... habe ich aber bei einem Zulieferer schon so gesehen. Der wird für solche Themen eben nicht mehr angefragt. mfg mf
:
Bearbeitet durch User
Meiner Erfahrung nach kochen die anderen auch nur mit Wasser. Will sagen: Kein Projekt läuft aus Sicht aller Teilnehmer perfekt ab. In der Regel ist das primäre Ziel der Unternehmen, möglichst viel Geld zu verdienen. Dem muss sich alles andere unterordnen. Ein perfektes Projekt mit einem perfekten Produkt kann vollkommen wertlos sein, wenn die Firma daran zugrunde geht. Wenn die Leute bereitwillig zusammen arbeiten und sich gegenseitig wert schätzen, hat man mehr Aussicht auf Erfolg, als wenn man sich streng an formelle Prozesse hält. Betrachte diese Regelwerke eher als Anregungen für mögliche Verbesserungen. Ein guter Koch würde über Sätze wie "Man nehme 5 Kartoffeln mit jeweils 95 Gramm" nur lächeln. So sollten es auch die Software-Entwickler halten.
Andreas S. schrieb: > Nein, diese Information findet sich im Lastenheft. Im Pflichtenheft > steht ... Vermutlich hast du Recht. Doch in erfolgreichen Projekten spielt es keine Rolle, wie das "Heft" heißt. Sprich: Wenn der Kommandant sagt "nimm Lösung B", dann nehme ich Lösung B. Ganz egal in welchem Dokument das steht und ob es überhaupt so schriftlich angefordert war. Ich denke, jede Firma hat für gewisse Teilbereiche solche "Kommandanten" hat. Bei uns gibt es niemanden, der ein ganzes Projekt alleine kommandiert. Wichtig ist, dass die Projektmitglieder ihre Meinungen und Ideen ehrlich kommunizieren, aber am Ende die Entscheidung des jeweiligen Kommandanten unterstützen.
Stefan H. schrieb: > D. h. SCRUM, Wasserfallmodell, > V-Modell, W-Modell, Spezifikation, Lastenheft, Pflichtenheft, CMMI, > SPICE, Versionvserwaltung, CD, CI, Bestimmung der zyklomatischen > Komplexität, Testspezifikation, Testplanerstellung, Test-Driven-Design, > Design-for-Testability, formale Spezifikation, formale Verifikation, > Projektmanagement, Life Cycle Management, Dokumentation, ASIL, ISO26262 diese Aufzählung ist vollkommener Quark, die einzelnen Vorgehesenweisen die du da aufsagst widersprechen sich grundlegend. Entweder Agil (zB. SCRUM, Kanban etc. pp.), oder eben nach Wasserfall (Lastenheft, Pflichtenheft, formale Spezifikation, Testplanerstellung, Dokumentation etc., also wenn nix dabei raus kommen muss aber alle beschäftigt wirken sollen). In der SW Entwicklung arbeitet man heute eigentlich nur noch agil, ausser wenn die Firma keine Technologiefirma ist, dann nicht.
Der unproduktive bürokratische Wasserkopf (im Zeichen fortschrittlicher Methoden) wächst überall. Warum sollte das in der SW Entwicklung von Firmen anders sein? 'Richtig' wird heute höchstens noch im Hobbybereich entwickelt. Dort besteht noch die Chance auf den Punkt zu kommen und sich auf das wirklich nötige zu beschränken!
scrummel schrieb: > Man kann sehr viel falsch machen, in einem Scrum Projekt. Wenn das Werkzeug extrem viele Moeglichkeiten bietet, es falsch zu benutzen, sind dann natuerlich die Benutzer Schuld, klar. Nach dem uns fuer die taegliche Arbeit unfertige Bastelsoftware uebergestuelpt wurde, ist meine Lust am Arbeiten schwer geschrumpft. Bastel-SW-Genervter
Bastel-SW-Genervter schrieb: > Wenn das Werkzeug extrem viele Moeglichkeiten bietet, es falsch zu > benutzen, sind dann natuerlich die Benutzer Schuld Scrum ist kein Werkzeug, sondern eine Methode. Im Gegensatz zu anderen agilen Methoden gibt es bei Scrum gar nicht viele Möglichkeiten. Die Lehrbücher und "Trainer" haben stets propagiert, dass man es ganz genau nach dem Buch umsetzen soll, sonst sei man zum Scheitern verurteilt.
Stefan ⛄ F. schrieb: > Die > Lehrbücher und "Trainer" haben stets propagiert, dass man es ganz genau > nach dem Buch umsetzen soll, sonst sei man zum Scheitern verurteilt. Ja, ja Meister, machen wir.
Stefan H. schrieb: > wer von euch hat eigentlich schon einmal richtig entwickelt ich glaube richtig wurde noch nicht definiert? was ist richtig, wenns funktioniert, wenn es bei -100°C funktioniert, wenn es funktioniert solange der Nachbar den Staubsauger nicht einschaltet. bis jetzt kenne ich Entwicklung nur so, man überlegt sich was für die Anwendung, entwickelt top down und in der Praxis zeigt es sich dann was man alles nicht bedacht hatte.
eine "ordentliche" Entwicklung nach Wasserfall-Modell und SCRUM widersprechen sich schon im Ansatz. Das SCRUM ist der hilflose Versuch, einen chaotischen Saustall zu ordnen, der entsteht, wenn Abteilungen ständig neue Entwicklungsmodelle übergestülpt bekommen, sie niemals "einschwingen" können und die, die ihnen die neuen Modelle auferlegen, selber dagegen verstoßen.
Stefan H. schrieb: > Oder ist es eher normal, dass die "Hauptsache-es-geht"-Mentalität > vorherrscht? Wenn dein Chef dir mehr Zeit gibt und der Projektleiter nicht ständig pusht sowie 1 Monat zum richtigen Meilenstein Puffer einbaut, dann stehen du und deine Kollegen doch ständig in der Kaffeeküche. Das ist wie mit deutschen Handwerkern. Da muss man dabei sein. Da muss man antreiben, sonst arbeiten 90% vom Team nicht. Nur diejenigen mit Aufstiegskarotte vor der Nase oder Briefmarkensammler ohne Leben hängen sich rein ohne das jemand Druck ausübt. Die meisten anderen brauchen das. Weil sonst das Unternehmen 5 Jahre später Insolvenz anmelden kann, wenn alle 40 Jahre Entwicklungszeit flüchten.
Ich entwickel richtig. Weil ich Elektronik liebe und weil es für mich keine Last ist, Elektronik zu entwickeln. Ich tu es nicht für die Firma, sondern für mich. Wenn ich morgens aufstehe und meinen Kaffee schlürfe, mache ich geistig schon einen Plan, was ich heute mache oder ich löse schon Probleme. Bei mir gibt es keine Entwicklung ohne morphologischen Kasten/Mindmap, es gibt immer ein Sourcing der in Frage kommenden Komponenten und ich dokumentiere alles. Wenn ich ein blödes Gefühl habe, simuliere ich den Schaltungsteil. Wenn ich was messe, dokumentiere ich den Messaufbau, die Messmittel und die Messung. In Zeiten wie gerade, wo sich die Bauteilverfügbarkeit innerhalb von wenigen Wochen komplett ändert, ist richtig entwickeln wohl auch effizient gegenüber "straight forward" und am Ende gibt es die Bauteile zum Implenentieren nicht.
Frustrierter_Entwickler schrieb: > Vor längerer Zeit wurde mein AG dann durch einen Konzern übernommen und > uns dessen Prozesse übergestülpt, wie man „richtig“ zu entwickeln hat. > Seit dieser Zeit geht es uns stetig schlechter. Jetzt treibt man eine > neue Sau durchs Dorf und wir müssen Hardware nun (Schein-)“agil“ > entwickeln. Rausgekommen ist dabei micromanagement per excellence. > Tägliche Statusmeetings mit Team- und teilweise Entwicklungsleitung. Ganz genau, ist bei uns im Konzern auch so! Scheinagil inkl. elendslangen ITIL Prozessen. Gutes Beispiel: Da wurden zB neue Server über ITIL Prozesse aufgesetzt, das dauerte ungefähr 3-4 Wochen. Dann ist man draufgekommen, dass noch Portfreigaben fehlen, da selbst in der Entwicklungsumgebung alle Ports aus Securitygründen im Konzern standardmäßig zu sind und die neuen Server sonst nicht kommunizieren können. Wieder einen ITIL Prozess gestartet. Das ist nun bereits nun 5-6 Tage in Bearbeitung bei der Netzwerk Engineering Abteilung... in welcher Welt leben die alle? Die werden sich bis zum Konkurs bis zum Tode selbst verwalten. Mladen G. schrieb: > In der SW Entwicklung arbeitet man heute eigentlich nur noch agil, > ausser wenn die Firma keine Technologiefirma ist, dann nicht. Ganz richtig.. hab in allen anderen nicht technischen Firmen noch nie gesehen, dass dort Agil funktioniert. Versteht das Mgmt und Mitarbeiter wohl nicht. Hobbyist schrieb: > Der unproduktive bürokratische Wasserkopf (im Zeichen fortschrittlicher > Methoden) wächst überall. Warum sollte das in der SW Entwicklung von > Firmen anders sein? 'Richtig' wird heute höchstens noch im Hobbybereich > entwickelt. Ja heutzutage völlig richtig, vernünftig entwickeln, wo es noch Spass macht = Hobbybereich oder im akademischen Bereich. zB in meiner Diplomarbeit für eine Firma (OEM Automobilzulieferer) hatte ich selbst eine kleine Software entwickelt, das war anspruchsvoll und hat sogar Spass gemacht und sehr gut funktioniert. Joachim B. schrieb: > bis jetzt kenne ich Entwicklung nur so, man überlegt sich was für die > Anwendung, entwickelt top down und in der Praxis zeigt es sich dann was > man alles nicht bedacht hatte. Ja genau kann ich unterschreiben, für jede Firma für die ich bis jetzt gearbeitet habe, wars so. Keiner macht sich analytische Gedanken, man entwickelt top down und nachher in der Praxis zeigen sich die Überraschungen. Wahrscheinlich aus Geld Kalkül. Funktionierende Software muss ja nicht entwickelt werden, sondern etwas was Geld bringt.. Man kann sagen, dass die meiste Software, die heutzutage in der Praxis entwickelt wird, amateurhafte Bananensoftware 🍌 ist, die dann beim Kunden reift und dort gefixt wird. 99% aller Firmen verwenden dieses Modell / Entwurfsmuster. Welche Nichtraucher? evtl. hoch anspruchsvolle Software medizinische oder wissenschaftliche Bereiche?
Stefan ⛄ F. schrieb: > Andreas S. schrieb: >> Nein, diese Information findet sich im Lastenheft. Im Pflichtenheft >> steht ... > > Vermutlich hast du Recht. Doch in erfolgreichen Projekten spielt es > keine Rolle, wie das "Heft" heißt. > > Sprich: Wenn der Kommandant sagt "nimm Lösung B", dann nehme ich Lösung > B. Ganz egal in welchem Dokument das steht und ob es überhaupt so > schriftlich angefordert war. Die Unterscheidung ist extrem wichtig, weil das Lastenheft den Auftragsumfang des Kunden definiert. Und dementsprechend müssen natürlich bei (Teil-)Lieferungen an den Kunden die gelieferten mit den beauftragten Leistungen abgeglichen werden. Ansonsten nimmt der Kunde das Produkt einfach nicht ab oder kürzt die Zahlung. Und es interessiert ihn auch völlig zu recht nicht die Bohne, welche Anweisungen wer innerhalb der Organisation des Leistungserbringers erteilt hat.
Andreas S. schrieb: > Die Unterscheidung ist extrem wichtig, weil Klar, diese beiden Dokumente sind nötig. Nur wie man sie nennt ist mir ziemlich egal. Das hält jede Firma anders, wo ich bisher war. Dennoch gibt es immer Leute, die die Macht haben, sich über Dokumente hinweg setzen zu dürfen. Man sollte wissen, ob man noch mächtiger ist, dagegen zu arbeiten, oder ob man das Spiel mit spielt. Das sind die Fälle, bei denen ich recht ausführlich dokumentiere, wer was wann gefordert hat und wie begründet hat.
Stefan H. schrieb: > Hallo, > > wer von euch hat eigentlich schon einmal richtig entwickelt, also so, > wie man es in der Theorie lernt? Woher kommt die Annahme, dass es nur eine richtige Art gäbe zu entwickeln? Das iPhone wäre wohl kaum jemals entstanden, wenn man von Anfang an alles strikt formal entwickelt hätte. Bei sicherheitskritischen Dingen wie Autos, Flugzeugen, Chemieanlagen etc. ist ein strikter und sehr formalisierter Entwicklungsprozess natürlich gerechtfertigt. Aber es besteht nun mal nicht die ganze Welt aus sicherheitskritischen Geräten und Systemen.
Entwürger schrieb: > Für Basisinnovationen und Grundlagenforschung kannst du solche Prozesse > knicken. So sieht's aus.
klausi schrieb: > Ganz genau, ist bei uns im Konzern auch so! > Scheinagil inkl. elendslangen ITIL Prozessen. > Gutes Beispiel: > Da wurden zB neue Server über ITIL Prozesse aufgesetzt, das dauerte > ungefähr 3-4 Wochen. Dann ist man draufgekommen, dass noch > Portfreigaben fehlen, da selbst in der Entwicklungsumgebung alle Ports > aus Securitygründen im Konzern standardmäßig zu sind und die neuen > Server sonst nicht kommunizieren können. Wieder einen ITIL Prozess > gestartet. Das ist nun bereits nun 5-6 Tage in Bearbeitung bei der > Netzwerk Engineering Abteilung... in welcher Welt leben die alle? Die > werden sich bis zum Konkurs bis zum Tode selbst verwalten. Werden halt alle Mitarbeiter auf Anschlag gefahren, könnte ja sonst sein, dass jemand mal Zeit zum Nachdenken hat. Also Server anfordern aber auf die Ports vergessen denn man ist ja im Stress. Gut, kann passieren, und alles im Voraus durchzudenken ist auch nicht immer effizient. Dann schießt man halt eine Anforderung nach, so wie viele andere Leute auch, der überarbeitete ITler verwaltet das nur noch bzw. schießt was geht möglichst ohne Zusatzaufwand auf seiner Seite (d.h. fehlender Kontext) dem überarbeiteten Security-Menschen rüber usw.
Mark B. schrieb: > Bei sicherheitskritischen Dingen wie Autos, Flugzeugen, Chemieanlagen > etc. ist ein strikter und sehr formalisierter Entwicklungsprozess > natürlich > gerechtfertigt. und trotzdem gibt es Fehlentwicklungen, Prozess hin oder her. Es bleibt dabei, frei nach Murphy: was schief gehen kann geht schief. Auch wenn ich jahrelang immer neue PKW mit Reservereifen kaufte ist das zukünftig keine Sicherheit, auch wenn jahrelang alle VCR HF auf UHF Kanal 30-40 ausgaben ist das keine Selbstverständlichkeit. Wann immer ich dachte alles bedacht zu haben wurde ich überrascht. Da rüstet man einen XP PC auf 3GB auf und erfährt Jahre später das ohne boot.ini Switch nur 2GB genutzt werden und Siedler 4 mit abgeschalteten virt MEM nicht läuft obwohl genug MEM vorhanden ist, Abhilfe Ramdisk installieren.
:
Bearbeitet durch User
Joachim B. schrieb: > und trotzdem gibt es Fehlentwicklungen, Prozess hin oder her. A400M, A380, A350, Talarion, wie war das nochmal mit dem fälschen von Abgaswerten bei VW? Formale Prozesse verhindern sowas nicht. Formale Prozesse haben den Zweck, Ordnung und Stabilität zu schaffen. Innovation dagegen braucht Chaos, Mut dazu Fehler zu machen, diese einzusehen und daraus zu lernen. Beispiel Eurocopter NH90 das ich selber miterlebt habe vor ca. 20 Jahren: Mein Chef bekam einen Anruf am Sontag vormittag, er sollte helfen Fotos vom Innenleben vom NH90 zu machen (Teilenummern) vor der Auslieferung.. die Entwicklungsingeneure haben den zum fliegen gebracht, mit Bauteilen von denen es manchmal nichtmal eine Zeichnung gab, ganz zu schweigen von anderen Papierkram. In echter Serienproduktion müssen Dinge anders laufen, aber in der Luft- & Raumfahrt hat man keine echte Serienproduktion, jeder Flieger ist einzigartig, selbst die Prototypen werden mitverkauft. Grosse Konzerne haben eigentlich immer Sonderregelungen für echte Entwicklungsabteilungen, oft in eigene Firmen ausgelagert, damit die Bürokratie Innovationen nicht verhindert bzw. erstickt.
:
Bearbeitet durch User
klausi schrieb: > Ganz richtig.. hab in allen anderen nicht technischen Firmen noch nie > gesehen, dass dort Agil funktioniert. Versteht das Mgmt und > Mitarbeiter wohl nicht. Mitarbeiter würden es lernen können, das Management aber hat Angst vor selbstbestimmenden Teams.. "people over processes" und so In Technologiefirmen dagegen läuft das ganz anders IME. Die arbeiten ergebnisorientiert, müssen sie ja, da gibt es keine Nische in der man sich bis zur Rente ausruhen darf.. da kommt der Druck von den Kollegen, wie in einem funktionierenden Sportteam eben auch.
Mladen G. schrieb: > Grosse Konzerne haben eigentlich immer Sonderregelungen für echte > Entwicklungsabteilungen, oft in eigene Firmen ausgelagert, Solche Paralleluniversen sind aber auch nicht gut bzw. können sich sicher nur große Firmen leisten. Die Kunst ist eher die verschiedenen Gewerke über die Prozesse zu integrieren. Eine mechanische Konstruktion hat das know how um etwas zu konstruieren, eine Entwicklungsabteilung muss keine eigenen Konstrukteure haben. Die Konstruktion muss dann aber auch Zeit für Entwicklungen haben wenn die auch Aufträge abarbeiten. Aber in der Praxis ist sowas auch nicht einfach.
Johannes S. schrieb: > Solche Paralleluniversen sind aber auch nicht gut bzw. können sich > sicher nur große Firmen leisten. Diese "Paralleluniversen" sind ein Versuch, von Konzernen zumindest im kleinen Masstab "auszubrechen" aus ihrem Trott. das passt IMO: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ Ich hatte selber das Glück beim letzten AG in einem reinem SW "Konzern" zu arbeiten der sehr modern geführt wurde, der Grossteil der Belegschaft waren SW Entwickler, flache Hierarchiestufen, auch ein Senior Entwickler mit 20 Jahren auf dem Buckel musste einer Junior Entwicklerin zuhören und Punkte argumentieren, "wir machen das immer so" war verboten :) Da gibt es immer noch komplette Re- bzw. Umstrukturierungen, mindestens einmal im Jahr, das "middle management" wird regelmässig "ausgetauscht", also grosse Veränderungen im grossen Massstab, und die laufen natürlich nie reibungslos, aber es ist alles gut organisiert. Prozesse dienen dort dazu Dinge zu erleichtern, wenn sie das nicht mehr tun, werden diese geändert, man überlegt sich neue, und da ist "weniger ist mehr" immer richtig IMO. Als SW Entwickler musste man da zB. nicht vor dem Abteilungsleiter kuschen wenn der "Grenzen überschritten" hatte, zB. einfach so ins Standup kommen um uns neue, dringende Aufgaben zu geben, dann kam erstmal ein "so funktioniert das hier nicht" zurück von einem Entwickler, daraufhin sagte der Abteilungsleiter "du kannst das ja den CEOs erklären das das nicht fertig wird wenn du möchtest", woraufhin der Entwickler nur sagte "ne das ist dein Job", daraufhin gab es grosses Gelächter :) Am nächsten Tag kam der CEO zum Standup, entschuldigte sich für dich Störung und erklärte uns dass die Aufgabe wirklich wichtig ist und zu einem Termin fertig sein muss, rechtlich gäbe es sonst grosse Probleme (GDPR und so halt). Klar haben wir das dann gemacht, aber wie man miteinander umgeht war sehr wichtig, Teil der Firmenkultur, und da stand das Team im Mittelpunkt. Leute meinen immer dass es modernen Tech Firmen nur um high tech geht, IME erstaunlich wenig, da geht eher darum wie man "Fehlschläge" interpretiert, dass alle ein gemeinsames Ziel haben, da kann die ganze Firma mal plötzlich einen 180 Grad Kurswechsel machen, alle gehen in eine Richtung, keine einzelnen Fraktionen die sich gegenseitig bekämpfen, und wenn es die Situation erfordert, macht man das eben wieder :) Man wird da sehr gefordert, zB. jeden Sprint/Monat/Quartal alle Ziele zu 100% zu erreichen heisst das man es sich zu einfach gemacht hat beim Ziele setzten (macht ja auch das Team für sich), "push the envelope", "go for moonshots" usw. usf. Sowas geht nicht wenn die Strukturen verkrustet sind wie bei meinem jetztigen AG, viel zu viele Prozesse, alle sind sehr langsam, kaum einer "funktioniert", zu arbeiten gibt es nicht viel, man verbringt viel Zeit in Meetings und muss den "politischen Tretminen" aus dem Weg gehen, das Management ist erstaunlich defensiv wenn man ihnen zeigt wo Dinge nicht funktionieren und was man probieren könnte um es besser zu machen.. ist auch keine Technologiefirma, da hört man halt "wir machen das immer so", "klar sind wir agil aber ich leite alle Meetings, rede zu 80% der Zeit, treffe alle relevante Entscheidungen..."
DoS schrieb: > Wenn ich morgens aufstehe und meinen Kaffee schlürfe, > mache ich geistig schon einen Plan, was ich heute mache oder ich löse > schon Probleme. Bei mir gibt es keine Entwicklung ohne morphologischen > Kasten/Mindmap, es gibt immer ein Sourcing der in Frage kommenden > Komponenten und ich dokumentiere alles. Das ultimative Bullshit Wort > morphologischen Kasten/Mindmap Ha Ha hahahahahaha! Was der wohl im Kaffee hatte? Bullenpisse?
> Wer hat schon einmal richtig entwickelt?
Ich. - Vor gaaanz langer Zeit ... Und zwar:
4q-Leistungssteller für Antriebe mit Kleinspannung DC 24 V,
mit bis zu 1 kA:
Das war richtig "schwere" Hardware.
Da diese von mir verantwortete
Entwicklung aus Sicht der Projektleitung viel zu lange dauerte,
bekam ich alle aus Terminverschiebungen resultierenden Prügel
ganz alleine ab.
Erst als dann mein Kram endlich fertig war,
- nur die zum Betrieb dessen zwingend erforderliche Software
immer noch nicht - ,
kam ich in eine andere Abteilung ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.