Wer profitiert von solchen abstrakten Konzepten?
Vorrangig der, der dir das Zeug verkauft und dich "berät", wie man das am besten in deinem Betrieb einsetzen kann. Denn offensichtlich muss man Allgemeinwissen ab&zu in neue Schläuche abfüllen, um wieder Abnehmer zu finden.
Lothar M. schrieb: > Vorrangig der, der dir das Zeug verkauft und dich "berät", wie man > das > am besten in deinem Betrieb einsetzen kann. > > Denn offensichtlich muss man Allgemeinwissen ab&zu in neue Schläuche > abfüllen, um wieder Abnehmer zu finden. Welches Allgemeinwissen wird denn hier beschrieben?
Bert W. schrieb: > Welches Allgemeinwissen wird denn hier beschrieben? Der gesunde Menschenverstand.
Lothar M. schrieb: > Denn offensichtlich muss man Allgemeinwissen ab&zu in neue Schläuche > abfüllen, um wieder Abnehmer zu finden. Es scheint so zu sein, dass alles, was auf Englisch ist automatisch als GUT erachtet wird. Wir haben wir auch jetzt solche design Sprints. Alle machen eifrig mit, finden es offiziell gut, tuscheln hinter vorgehaltener Hand aber genau so, als alter Wein. Ist wie in der DDR früher: Was die Oberen entscheiden, ist automatisch gut. Darf auch nicht infragegestellt werden. Tust du das, bist du raus.
Lothar M. schrieb: > Vorrangig der, der dir das Zeug verkauft und dich "berät", wie man > das am besten in deinem Betrieb einsetzen kann. > > Denn offensichtlich muss man Allgemeinwissen ab&zu in neue Schläuche > abfüllen, um wieder Abnehmer zu finden. Ach halt dich da raus du hast keine Ahnung vom leben. Am leben vorbei.
Bert W. schrieb: > Ingenieur schrieb: > Der gesunde Menschenverstand. > > Blödsinn. Was willst du denn eigentlich?
Bastian schrieb: > Es scheint so zu sein, dass alles, was auf Englisch ist automatisch als > GUT erachtet wird. Mein Problem damit ist, daß alles verenglischt wird und so das Verständnis nicht hinterherkommt. Definition LS von https://www.liberatingstructures.de
1 | Über Liberating Structures |
2 | Machst Du einen besseren Job, wenn du dich einbezogen und beteiligt fühlst? Glaubst du, dass viel bessere Ergebnisse erzielt werden, wenn Menschen in Teams gut zusammen arbeiten? Hast du bemerkt, dass die besten Ideen oft aus unerwarteten Quellen kommen? Möchtest du deine Intelligenz komplett ausschöpfen und auch anderen diese Gelegenheit geben? |
3 | |
4 | Wenn Du diese Fragen mit JA beantwortest: auch wir haben herausgefunden, dass die Menschen sich so organisieren und zusammen arbeiten wollen. UND: Wir glauben dass Liberating Structures dabei helfen, das zu ermöglichen. |
5 | |
6 | Liberating Structures sind (aktuell) 33 Mikrostrukturen, die von Keith McCandless und Henri Lipmanowicz zusammengetragen wurden. Diese Strukturen wurden sowohl auf der Liberating-Structures-Website und im Liberating-Structures-Buch veröffentlicht. |
Ich kriege bei solchen Texten Kopfschmerzen.
Ingenieur schrieb: > Bert W. schrieb: >> Ingenieur schrieb: >> Der gesunde Menschenverstand. >> >> Blödsinn. > > Was willst du denn eigentlich? Eine fundierte Antwort auf die Frage "Wer profitiert von solchen abstrakten Konzepten?". Gäbe es niemanden, der davon profitiert, gäbe es diese Konzepte nicht. Irgendwer setzt sich hin und erfindet sie. Und sie finden Abnehmer. Wer profitiert nun von solchen abstrakten Konzepten? Ja, natürlich derjenige, der sie lehrt. Doch wer ist die Zielgruppe, der das wirklich hilft?
Bert W. schrieb: > Doch wer ist die Zielgruppe, der das wirklich > hilft? Den Schätzern in den Firmen, die nichts mehr auf die Reihe kriegen und irgendetwas brauchen, wo sich wichtig sind. Hatte letzterdings mit einem Herrn von Zülke zu tun. Der hat uns 1.5h zugequatscht mit Big Data und Industrie 4.0, team founding und SRUM. Am Ende waren wir so schlau wie vorher. Einem General Manager hat es aber so toll gefallen, dass er es gleich eingekauft hat. Danach kamen Schulungen und viel Trallala mit dem Ergebnis, dass wir nun noch weiter den Plänen hinter her hinken.
> Re: Design Sprint, Liberating Structures etc.
Was ist das den für ein Quatsch ?
Kritiker schrieb: > Bert W. schrieb: > Doch wer ist die Zielgruppe, der das wirklich > hilft? > > Den Schätzern in den Firmen, die nichts mehr auf die Reihe kriegen und > irgendetwas brauchen, wo sich wichtig sind. Hatte letzterdings mit einem > Herrn von Zülke zu tun. Der hat uns 1.5h zugequatscht mit Big Data und > Industrie 4.0, team founding und SRUM. Am Ende waren wir so schlau wie > vorher. Einem General Manager hat es aber so toll gefallen, dass er es > gleich eingekauft hat. Danach kamen Schulungen und viel Trallala mit dem > Ergebnis, dass wir nun noch weiter den Plänen hinter her hinken. Die üblichen Bullshit-Unternehmensberatungen (Deloitte, KPMG, etc) profitieren davon. Das Zeug ist deren „Produkt“. Man nimmt meist 10 Jahre alte Trends aus Amerika, die längst schon wieder aus der Mode sind und in der Praxis (u.a. wegen meist völlig falscher Annahmen) schlichtweg nicht umsetzbar sind und verkauft sie als „Konzept“ für Unsummen an Manager, die sich damit profilieren wollen. Vergleichbar mit den Reformen in der öffentlichen Verwaltung (Beispiel „New Public Management”). Da kommt auch nichts bei rum.
Bert W. schrieb: > UND: Wir glauben dass Liberating Structures dabei helfen, das zu > ermöglichen. “Wir werden die Liberalisierung notfalls auch mit illiberalen Methoden durchsetzen.” Im Grunde genommen ist es eine Ideologie, die da geschickt verpackt wird. Und zwar ein amerikanisch geprägter Neoliberalismus. Neu ist daran gar nichts. Betriebliche Mitbestimmung und die dringend notwendige Demokratisierung der Arbeitswelt kommen in den Konzepten zum Beispiel gar nicht vor.
Abgebrühter Vollprofi schrieb: > die dringend notwendige Demokratisierung > der Arbeitswelt Damit bist du auf dem gleichen Level wie die von dir gescholtenen Unternehmensberatungen. Ich persönlich bevorzuge es, die Politik aus der Arbeit herauszuhalten.
War auch schon mal bei so einem "Event" einer Unternehmensberatung. Was da an Bullshit verzapft wurde, unglaublich!!! Ich habe glaube ich, einer Minute im Schnitt 5-6 Hype Bullshitwörter gezählt. Es ging um "Digitalisierung" (man höre und staune) von Geschäftsprozessen. Man arbeitet also jetzt "digital". Soso. Hab schon vor 20 Jahren am Rechner gearbeitet, einer der ersten in meiner Klasse mit 56k Modem damals - ja ich hatte nicht so ein hippes Wort dafür, stimmt. Da fielen Wörter wie "agil" (ca. 367x), Kickstarter, Ventures, innovieren, Startup Garage, "Blockchain for Education" oder ein anderer Müll, IoT, Software Factory, Scrum+Kanban= Scrumban (!), Freetime Programming, DevOps, Function as a service (FaaS), soll ich aufhören oder weitermachen ;-) Könnte nun ein Wörterbuch schreiben :-). klausi
Hier zB "Networking", "Get out of your comfort zone" etc. von so nem Oracle Typ, wo wir mal waren ;-) https://youtu.be/iSqkUPrDbcY
Bevor wir jetzt wieder in die Lager "Alles blöd" <-> "Alles super" abdriften, will ich den Fokus wieder auf den Zweck im Eingangsbeitrag richten. Fakt ist: 1. Es gibt diese Methoden. Also muß sie jemand entwickeln. 2. Es kommen immer wieder neue Methoden dieser Art. Also muß sie jemand wollen. Und bezahlen. Es ist zu simpel zu sagen, daß alles nur Schall und Rauch sei. Wenn es so wäre, warum gibt es die Leute dann noch? Wenn sich kein Geld damit verdienen ließe, auf Kunden UND Dozentenseite, warum stirbt das nicht aus? Warum gibt die Bundesregierung Milliarden an Berater aus? Bitte sagt mir nicht, daß "die halt blöd" seien. Wer sagt, alle seien inkompetent, verpaßt gute Geschäftsmodelle. Ich warte noch auf jemanden, der erklären kann, wofür diese Konzepte gut sind. Für WEN diese Konzepte gut sind. Denn der hat es verstanden. Es interessiert mich nicht, von noch einem weiteren Idioten zu lesen, daß er den Sinn dahinter nicht sieht.
Hatten wir vor über zwanzig Jahren auch. Mit dem Resultat, daß nach ein paar Jahren fast 8000 an Belegschaft "Involuntary liberalisation methodology" praktizieren mußten. Vor dieser "Liberalisierung" waren wir mit der Technik ganz vorne, heute wird nur noch zugekauft. Früher führten Ingenieure den Betrieb, heute sind es nur noch fachfremde Generalmanager ohne fundiertes Technik Wissen die sechstellige gehälter und Tantiemen beziehen und dicke Autos fahren. Aber die Aktien gehen gut. Die müssen ja etwas richtig gemacht haben. Mit den Flausen dieser GL wird auch viel Geld rausgeschmissen und und an unnötigen Sachen verschwendet. Alle diese Firmenverbesserer sind ausnahmslos gewissenslose Scharlatane, Guns for Hire, um die Wünsche der GL zu realisieren. Diese angeheuerten Aasgeier gehen über Leichen. Da geht es in der Regel auch hauptsächlich um eine Veränderung der Firmenkultur. In den USA ist diese Geschäftssparte extrem hochgezüchtet und wird in gewissen Universitäten als Wissenschaft gelehrt.
Beitrag #5905935 wurde von einem Moderator gelöscht.
Bert W. schrieb: > Es interessiert mich nicht, von noch einem weiteren Idioten zu lesen, > daß er den Sinn dahinter nicht sieht. Modern Times schrieb: > Alle diese Firmenverbesserer sind ausnahmslos gewissenslose Scharlatane, Halt einfach dein Maul
Bert W. schrieb: > Bevor wir jetzt wieder in die Lager "Alles blöd" <-> "Alles super" > abdriften, will ich den Fokus wieder auf den Zweck im Eingangsbeitrag > richten. > > Fakt ist: > 1. Es gibt diese Methoden. Also muß sie jemand entwickeln. > 2. Es kommen immer wieder neue Methoden dieser Art. Also muß sie jemand > wollen. Und bezahlen. > > Es ist zu simpel zu sagen, daß alles nur Schall und Rauch sei. > > Wenn es so wäre, warum gibt es die Leute dann noch? Wenn sich kein Geld > damit verdienen ließe, auf Kunden UND Dozentenseite, warum stirbt das > nicht aus? Naja, eigentlich ist das Problem recht einfach zu sehen. Problemzutaten sind: a) Ein mehr oder weniger großer Haufen Leute soll so koordiniert werden, daß diese ein ganzes Projekt entwickeln, wobei das Projekt viel zu groß ist als daß zwei oder drei Leute den Überblick behalten können. b) Die Leute, die du hast, sind gut. Manche sind besser, manche sind es etwas weniger, aber im Großen und Ganzen leisten sie gute Arbeit. Jetzt willst du aber das Wissen aller deiner Leute möglichst weitgehend abschöpfen. Wenn ein oder zwei Leute die Softwarearchitektur entwickeln, brauchst du noch 25 Leute, die das umsetzen. Und die langweilen sich dabei zu Tode, suchen sich möglicherweise interessantere Jobs...und wenn du da fähige Leute zu sitzen hast, können die ihre Fähigkeiten nicht ausspielen. Außerdem: wenn Konzepte entwickelt werden ist es immer gut, wenn dies mit einem möglichst breiten Wissens- und Erfahrungshorizont geschieht. Wenn sich 10 Leute hinsetzen und gemeinsam ein Konzept erarbeiten ist die Wahrscheinlichkeit, daß jemand eine gute Idee hat, groß. Das ist sie aber auch bei weniger Beteiligten. Aber: Je mehr Beteiligte am Konzept, desto größer ist auch die Wahrscheinlichkeit, daß jemand bereits früher versucht hat, die gut klingende Idee umzusetzen und dabei schlechte Erfahrungen gemacht hat, an die vorher schlicht niemand dachte. Oder jemand kann die Idee als gut bestätigen-auch das ist was wert. c) Du hast Kunden, die selber nicht genau wissen was sie brauchen. Andererseits wissen sie auch nicht, was alles eigentlich machbar ist. Und daraus resultieren dann ständig wechselnde Anforderungen. Diesen wechselnden Anforderungen willst du derart gerecht werden, daß eben nicht 25.000 Mannstunden Arbeitszeit über den Jordan geschossen werden, sondern daß vielleicht das Ergebnis aus 20.000. Mannstunden Arbeitszeit weiter genutzt werden kann. Oder: Du Kunde kennt seine Anforderungen nur ganz grob, aber längst nicht detailliert genug um zu einer vernünftigen Lösung zu kommen. Also arbeitet man erstmal an den groben bekannten Anforderungen entlang, hält sich möglichst alle Türen offen und versucht Irrwege so früh wie möglich zu erkennen. Im Probebetrieb merkt man dann, wie gut die Lösung ist, wo sie nicht gut ist, warum sie nicht gut ist, hat in der Regel aber ein paar Erfahrungen gewonnen die einem am Anfang gefehlt haben. Dann geht es zur nächsten Iteration. Wie auch immer, irgendwann haben sich Leute hingesetzt und Konzepte erstellt, mit den oben genannten Problemen umzugehen. Das Problem an solchen Konzepten ist immer: man muß diese auch leben.
Hallo Wühlhase. Wühlhase schrieb: > Ich persönlich bevorzuge es, die Politik aus der Arbeit herauszuhalten. Möglicherweise mag Dir dass in einem wissenschaftlichen Elfenbeinturm gelingen. Aber in der restlichen Arbeitswelt sind Politik und Arbeit sehr eng miteinander verflochten. Immerhin hängt daran, inwieweit Du mit Deinem Gehalt an der Wirtschaft partizipierst, ob Das Unternehmen, für das Du Arbeitest, einen Markt für seine Produkte bekommt, und somit Überlebensfähig ist, und ob das ganze überhaupt in die Richtung geht, die Du für Dein Leben benötigst. Jeder hat das im Kopf, auch wenn er aus Gründen des Batriebsfriedens darüber schweigt. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Hallo wülhase. Wühlhase schrieb: > Wie auch immer, irgendwann haben sich Leute hingesetzt und Konzepte > erstellt, mit den oben genannten Problemen umzugehen. > Das Problem an solchen Konzepten ist immer: man muß diese auch leben. Selbst wenn alles toll ist und funktioniert, ergeben sich durch die daraus entstandenen Strukturen kleine Fehler, wo sich dann irgendetwas einschleift, was aber nicht erkannt wird oder zu aufwendig zum beheben ist. Dieses kleine Einschleifen, oder alternativ, etwas im Umfeld ändert sich gewaltig, führt dann dazu, das die alten Konzepte nicht mehr so recht funktionieren, und man benötigt neue. Da es aber nicht unendlich viele Konzepte gibt, sind diese "neuen" Konzepte oft wesentlich älter als die alten Konzepte. Darum müssen sie an aktuelle Gegebenheiten angepasst werden. Und dass sind dan die neuen schläuche, in die der alte Wein gefüllt wird. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Bernd W. schrieb: > Möglicherweise mag Dir dass in einem wissenschaftlichen Elfenbeinturm > gelingen. Aber in der restlichen Arbeitswelt sind Politik und Arbeit > sehr eng miteinander verflochten. Ich arbeite in der Industrie, nicht in der Wissenschaft. Ansonsten stimme ich dir bei letzterem mit Bedauern zu und finde, daß das nicht sein muß. Bernd W. schrieb: > Selbst wenn alles toll ist und funktioniert, ergeben sich durch die > daraus entstandenen Strukturen kleine Fehler, wo sich dann irgendetwas > einschleift, was aber nicht erkannt wird oder zu aufwendig zum beheben > ist. Und die alten Konzepte waren ohne Fehler? Selbst wenn sie das sind, arbeiten sie immer noch maximal mit den Werkzeugen ihrer Zeit. Heute hat man andere Möglichkeiten. Bernd W. schrieb: > Da es aber nicht unendlich viele Konzepte gibt, sind diese "neuen" > Konzepte oft wesentlich älter als die alten Konzepte. Darum müssen sie > an aktuelle Gegebenheiten angepasst werden. Und dass sind dan die neuen > schläuche, in die der alte Wein gefüllt wird. Wie gesagt-heute hast du andere Möglichkeiten als z.B. in den 60er Jahren, wo Boeing mit hunderten von Ingenieuren die 747 entwickelt hat. Ich muß dazu sagen, daß ich bisher noch nie in der Verlegenheit war, mich mit Scrum et All zu beschäftigen oder danach zu arbeiten, stehe dem aber durchaus aufgeschlossen gegenüber. Ansonsten zum Thema Werkzeuge und Konzepte: Schau dir alleine das Thema Versionskontrolle an. Heute gibt es GIT oder (was ich nutze) SVN und noch zig andere Sachen. Was wird-gerade in kleinen Firmen am häufigsten genutzt? Eine schnöde Kopie des Projektordners, ohne jeden Kommentar, ohne Schutz daß die Daten eines "Versionsstandes" geändert werden, usw. Oder: Ich habe in einer Firma mal die Erfahrung gemacht, wie nützlich ein Wiki in einer Firma sein kann. Eine super Sache, alle möglichen Informationen da reinkippen zu können-und trotzdem findet man sie schnell wieder. Inklusive Versionskontrolle, bei Bedarf können MA mit entsprechenden Rechten diese editieren, alles recht angenehm. Die Praxis sieht in den meisten Firmen, die ich bisher gesehen habe, folgendermaßen aus: Irgendeine wilde Ordnerstruktur, wo kein Mitarbeiter jemals reinschaut (weil er sich da auch nie und nimmer zurechtifinden würde), wo irgendwo versteckt irgendwelche PDFs mit irgendwelchen Arbeitsanweisungen rumgammeln. Das wird dann stolz QM-Handbuch genannt.
Interessant, Wühlhase, das ist die Art von Information, die weiterhilft. Welche der Methoden, die du kennst, ist für ein Ein-Mann-Unternehmen anwendbar?
https://www.youtube.com/watch?v=3-w0-lZldWA Entwicklungs-Rollenspiele: Die "Flachen Hierarchien" sind geplante Firmenstrukturen bei denen die Hierarchie in der kreditgebenden Bank liegt. Darum dreht sich auch die ganze Konkurrenz der Firmen. Mc Kinsey hat die Tafeln entwickelt, damit gute Lebensmittel teuer sein können und Arme auch noch bezahlen dürfen. Man nennt es Preisdiskriminierung. 2010 fiel es kaum auf aber jetzt steigen die Preise. Ökonomen hätten es vorher wissen können. Während jeder Beamte deeskalieren soll "eskalieren" Konzernmitarbeiter einen bestimmten Supportfall. Alle netten friedlichen Leute schaffen die Personal-Runde nicht. Drinnen im Team sind die Testosteronsilos und Kampfhennen. Dieser Gemengelage (dank Basisdemokratie von Anweisungen unabhängig) bringe man Ordnung bei. In den engen Bürokäfigen und bei 25°C steigt dann der Aggressionslevel wie in den Legebatterien der Hühnerbarone. In der Autoindustrie entwickeln feste Mitarbeiter, die im Auto zur Arbeit kommen, ein neues Auto. Da wissen sie worum es geht und der Manager (kommt im Auto) hat neue Ideen was sein Auto bringen soll (oder das seiner Gattin). Ideen wie das fünfte Rad kommen nicht auf weil die Ings. täglich am eigenen Auto üben. Leiharbeiter bei VDO brauchen kein Auto, höchstens als Gruppenleiter. VDO Schwalbach z.B. verkaufte um 2008 erst den halben Mitarbeiterparkplatz an eine Schule (dort alle Leute reich) um einige Monate später schlagartig Leiharbeiter abzubauen. Leute wie ich sind jetzt überall unbeliebt weil wir danach riechen diese Methoden zu kennen. Wie sagte Prof. Hirschmann von der HTW Dresden 2001: Diese ganzen Fertigteile halten nicht ewig, man muss es immer wieder neu machen. Zwar meinte er damit Softwarebibliotheken und keine Rollenspiele. Denn in Softwareengineering war er davon überzeugt (z.B. moderne strukturierte Analyse). Ja, wenn man einen Hammer hat, sieht alles auf der Welt wie ein Nagel aus. Was hilft bei Rollenspielen: Man sollte bei der Wahrheit bleiben. Mit den Leihfirmen haben viele Konzerne diesen Pfad bereits verlassen. Ein Leihfirma aus Thüringen inserierte für den Arbeitsort Taunusstein die Stelle eines Elektrohelfers für EG4. Im Volltext erfahre ich, es soll Schaltschrankbau in Holland sein. Na und Erfahrung: langjährig. Was macht der Akademiker wenn er was will was er nicht bekommen kann: Mundwerk anschalten, "machst du blablabla". Für die Barbie-Puppe gibt es z.B. ein Pferd, das nur aus den äußeren Muskeln besteht. Der Bauch ist hohl und von unten offen. Man könnte ein Papierknäuel drinnen verstecken. Weil: Kunststoff zieht sich in der Spritzmaschine zusammen. Deshalb muss er dünnwandig verarbeitet werden. Das Kind wird später mal ein Manager und versteht dann, warum sein Pferd innen keine Organe hat. Von den Hausbanken deutscher Betriebe ging das Land in den 80-ger, 90-ger Jahren zum Investmentbanking über. Es arbeitet nicht langfristig planend sondern sucht nach kleinen Differenzen zwischen den Geldbergen, die es mit Gewinn abträgt. Es hält die erste Ableitung klein. Sobald was auftaucht kommen mehrere Spezialisten auf ein Problem. Betriebe ohne Cashflow werden sofort geschlossen. Dafür baut uns die Nato Google hin um Email und Suchbegriffe abzuhören. Ist ja auch kostenlos. So gibt es die Auffassung von Unternehmenssanierer Thomas Sattelberger in KenFm, nicht zu früh in Hardware zu machen (hat er vom MIT). Hingegen scheint das falsch zu sein, Extreme Programming halte ich für viel besser, und natürlich mit zwei Leuten und nicht, wie beim LKW, den zweiten Mann einsparen.
Bert W. schrieb: > Welche der Methoden, die du kennst, ist für ein Ein-Mann-Unternehmen > anwendbar? Naja, Scrum et All wurden in der Regel ja für Teams entwickelt. Daß das nicht 1:1 anwendbar ist, sollte klar sein. Wer diese Diskussion hier für Ein-Mann-Unternehmen führt, der disqualifiziert sich meiner Meinung nach für alles weitere. Allerdings lassen sich bestimmt die ein oder anderen Dinge adaptieren und umstricken. Aus der Erfahrung heraus, wie nützlich ein Wiki ist, hab ich mir später z.B. ein eigenes Wiki angelegt. Da landen z.B. Checklisten drin, auf welche Fehler ich z.B. nochmal extra kontrolliere. Ich habe mir auch mal einen kompletten Altium-Standard geschrieben, wie auf welche Weise vorzugehen ist, wie Bauteile angelegt werden, usw. Dafür, daß ich das alles alleine nutze, schaue ich da erstaunlich oft rein. Schlicht, weil ich sowas nicht im Kopf behalten will und manche Dinge schnell wieder vergesse. Oder daß ich, beim Software schreiben, stets das Paradigma "Erst den Unittest, dann erst den Code implementieern" befolge, das stammt auch aus so einem "Beraterkonzept". Es macht das Arbeitsergebnis meiner Erfahrung nach tatsächlich besser, und unterstützt die Selbstdisziplin.
Wühlhase schrieb: > Erst den > Unittest, dann erst den Code implementieern Was bedeutet das? > Wer diese Diskussion hier für Ein-Mann-Unternehmen führt, der disqualifiziert > sich meiner Meinung nach für alles weitere. Kannst du das erklären?
:
Bearbeitet durch User
Bert W. schrieb: > Was bedeutet das? https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung Bert W. schrieb: >> Wer diese Diskussion hier für Ein-Mann-Unternehmen führt, der disqualifiziert >> sich meiner Meinung nach für alles weitere. > > Kannst du das erklären? Wählst du für deine Arbeit geeignetes Werkzeug aus, oder greifst du wahllos in die Kiste und benutzt das, was du als erstes zu fassen kriegst?
Wühlhase schrieb: > Wählst du für deine Arbeit geeignetes Werkzeug aus, oder greifst du > wahllos in die Kiste und benutzt das, was du als erstes zu fassen > kriegst? Ich habe zum ersten Mal von Liberating Structures durch Meetup erfahren. Dort spricht niemand von einer Zielgruppe. Ich habe mal einer ähnlichen Veranstaltung, die kostenlos war, beigewohnt. Immer, wenn ich die Veranstalter nach der Zielgruppe der Methode fragte, sind sie ausgewichen oder erklärten sie für "alle" gültig. Nachdem viele dieser Methoden durch Worthülsen und Anglizismen unnötig verkompliziert werden, muß man die Methoden erst anhören um zu erkennen, daß sie eben nicht für ein Ein-Mann-Unternehmen geeignet sind. Daher meine Frage "Welche der Methoden, die du kennst, ist für ein Ein-Mann-Unternehmen anwendbar?". Ich habe sie auch in abgewandelter Form Erstellern solcher Seiten wie liberatingstructures.de gestellt. Erstaunlich selten habe ich Antwort erhalten. Das gleiche Problem habe ich mit Networking-Events jeder Art. Mir ist weder die Zielgruppe klar, noch der Zweck. Und keiner - selbst die Veranstalter - kann mir den Zweck und die Zielgruppe scheinbar beantworten. Oft wird schwammig argumentiert. Ich habe den Eindruck, daß alle anderen etwas wissen, das mir verborgen bleibt. Und es mir keiner sagen will. Inzwischen handhabe ich es so: wenn jemand mir nicht antwortet oder der Frage ausweicht, weiß er es selbst nicht, will mir schaden oder ich bin ihm nicht wichtig genug. Wie dem auch sei, ich gehe dann zu einer solchen Veranstaltung nicht.
Hallo, Wühlhase schrieb: > Bert W. schrieb: >> Was bedeutet das? > > https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung Mal eine Zwischenfrage: Wenn ich Testsoftware erstelle um andere Software auf Funktion und Richtigkeit zu zu prüfen, müsste ich doch eigentlich für diese Testsoftware wiederum Testsoftware entwickeln u.s.w. Wie funktioniert so was in der Praxis? rhf
Bert W. schrieb: > Immer, wenn ich die Veranstalter nach der Zielgruppe der > Methode fragte, sind sie ausgewichen oder erklärten sie für "alle" > gültig. Nun, wie ich bereits oben sagte: Ich habe mit Scrum usw. bisher praktisch noch nie gearbeitet, auch mit Liberating Structures nicht und ich kann mir darunter ehrlich gesagt auch nichts vorstellen. Ich komme vornehmlich aus dem Hardwarebau (etwas Software mache ich vornehmlich zum Privatvergnügen), da sind die Arbeitsmethoden weitgehend noch genauso wie vor 30 Jahren, eigentlich haben sich nur die CADs weiterentwickelt, bzw. wurden überhaupt CADs eingeführt, obwohl die Probleme in beiden Entwicklungszweigen sehr ähnlich sind. Soll heißen: Deine Frage kann ich dir auch nicht beantworten, ich kenne aber zumindest einige der Probleme (habe selber mal vor einer Weile, sagen wir mal "projektmanagementnah" gearbeitet). Wenn dir aber Leute, die das eigentlich wissen müssten und die dafür Geld bekommen, auch nicht sagen können, kann ich deine Frustration verstehen. Diese Leuten würde ich auch nicht mehr allzu ernst nehmen. Ansonsten bin ich an einer Antwort auf deine Frage auch interessiert-nur deshalb lese ich hier mit.
Roland F. schrieb: > Mal eine Zwischenfrage: Wenn ich Testsoftware erstelle um andere > Software auf Funktion und Richtigkeit zu zu prüfen, müsste ich doch > eigentlich für diese Testsoftware wiederum Testsoftware entwickeln > u.s.w. > Wie funktioniert so was in der Praxis? Naja, im Hardwarebau testet man sein Werk ja auch. Ich hab aber noch nie gesehen, daß man die Testumgebung testet.
Roland F. schrieb: > Wie funktioniert so was in der Praxis? Muss man das hier echt noch erklären? Lebt ihr hinterm Mond?
Testen ist immer gut, aber TDD ist auch so ein Hype. 1. Ist es nicht ratsam seine eigene Software zu testen. Viele Fehler wird man so nicht erkennen können, da man dafür selbst blind ist. Man wird sie auch beim Testen nicht finden, da einem schlicht die Testfälle dafür nicht bewußt sind. Beispielsweise Sonderfälle die ein Algorithmus haben kann. Die wird man beim eigenen Testen nicht finden, denn dazu müßte man sich ja des Sonderfalls bewußt sein. Es fehlt das 4 Augen-Prinzip: Das Phänomen kennt vermutlich jeder Entwickler, der nach 1-2 Jahren wieder auf ein Stück Code sieht und ihm darin sofort ein Fehler ins Auge springt. Im Moment des Schreibens vor 1-2 Jahren sah die Funktion aber absolut fehlerfrei aus und man hätte sie damals noch 3 Tage betrachten können und hätte das Problem nicht erkannt. 2. Testen heißt Vergleich des Tatsächlichen mit dem Erwarteten. Wo aber bitte ist das Erwartete wenn sich der TDD Guru gegen Spezifikationen, Konzepte und Dokumentation wehrt, weil das nicht agil genug ist? Wenn man sagt, das sei alles jetzt der Test, geht man implizit davon aus, dass die Tests fehlerfrei und vollständig sind. Beides sind völlig falsche Grundannahmen. Woran sollte ein Dritter entscheiden, ob in den Tests etwas fehlt oder falsch ist oder in dem Produkt? Außerdem dürfte jeder Entwickler unfassbar dankbar sein, wenn man statt Dokumentation wie ein Software-Modul funktioniert, ein völlig undokumentiertes Modul mit einem Haufen völlig undokumentierter Testfälle serviert bekommt, da das ja nun die Dokumentation ist. 3. Das Modul ist das primäre Artefakt. Ändert sich dieses, muss man alle abgeleiteten Artfakte (z.B. Unittests) anpassen. Es unökonomisch das umzudrehen. 4. Alles grün = alles gut. Man kann also beruhigt weiterarbeiten. Das führt zu einer falschen psychologischen Sicherheit. Man kann selbst für simple Funktionen zeigen, dass nur Grenzwerte praktisch testbar sind und selbst die bei komplexen Funktionen nicht mehr vollständig abtestbar sind. Da das vollständige Testen enorme Arbeit bedeutet, werden meistens nur ein paar offensichtliche Tests gemacht. Das bringt aber fast nichts.
Wühlhase schrieb: > Bert W. schrieb: >> Welche der Methoden, die du kennst, ist für ein Ein-Mann-Unternehmen >> anwendbar? > > Naja, Scrum et All wurden in der Regel ja für Teams entwickelt. Daß das > nicht 1:1 anwendbar ist, sollte klar sein. Wer diese Diskussion hier für > Ein-Mann-Unternehmen führt, der disqualifiziert sich meiner Meinung nach > für alles weitere. > > Allerdings lassen sich bestimmt die ein oder anderen Dinge adaptieren > und umstricken. > > Aus der Erfahrung heraus, wie nützlich ein Wiki ist, hab ich mir später > z.B. ein eigenes Wiki angelegt. Da landen z.B. Checklisten drin, auf > welche Fehler ich z.B. nochmal extra kontrolliere. > Ich habe mir auch mal einen kompletten Altium-Standard geschrieben, wie > auf welche Weise vorzugehen ist, wie Bauteile angelegt werden, usw. > Dafür, daß ich das alles alleine nutze, schaue ich da erstaunlich oft > rein. Schlicht, weil ich sowas nicht im Kopf behalten will und manche > Dinge schnell wieder vergesse. > > Oder daß ich, beim Software schreiben, stets das Paradigma "Erst den > Unittest, dann erst den Code implementieern" befolge, das stammt auch > aus so einem "Beraterkonzept". Es macht das Arbeitsergebnis meiner > Erfahrung nach tatsächlich besser, und unterstützt die Selbstdisziplin. Wir machen das mit Wiki genauso und ist eine Goldgrube wert. Alles Team-Wichtige um konsistente Zusammenarbeit zu ermöglichen ist darin enthalten. Könnte mir Arbeit ohne Wiki eigentlich nicht mehr vorstellen. Das betrifft SW Entwicklung bis zu MCAD/ECAD. Die andere Thematik hier im Thread ist höchstwahrscheinlich nur Schall und Rauch und Spiegelgefechte. Damit verzettelt man sich nur. Am besten arbeitet sich wenn das Entwicklungsteam nicht mit unnötigen GL Bulls..t abgelenkt wird. Mit SCRUM besteht auch die Gefahr, daß man wichtige Design Aspekte nicht gut genug in Ruhe durchdenkt und wichtige Einzelheiten übersieht. Ein Team muß für beste Resultate natürlich, bedächtig und eingespielt vorgehen können. In vielen existierenden maturen Projekten ist SCRUM sogar hinderlich. Auch für Spezialisten die sehr fokussiert entwickeln müssen, ist es eher hinderlich. Blonde SCRUM Umsetzung ohne Berücksichtigung der Umstände wirkt am Ende eher destruktiv. SCRUM IST ein gefährliches Werkzeug das sich nur in der Hand von kompetenten und eingespielten Mitarbeitern bewährt. Es ist KEINE Allgemeinlösung oder ein Panacea. Man muß wissen was man tut. Die Projektleitung muß sogar das Team von der GL BS so weit wie möglich abschirmen. Wie schon gesagt Managenent Consultants sind nur zu oft hörige Scharlatane um vorher entschiedene Outcomes zu realisieren, auch wenn es Euch zum Teil nicht gefällt. Ich bin schon zu lange im Geschäft um diese Art "Verbesserer" nicht gleich erkennen zu können. Das Endresultat solcher externen geballten Macht ist immer "Involuntary Methodology" für viele. Man wir das ja auch bald bei Kathrein praktizieren. Und jetzt halte ich, wie schon von anderer Seite gefordert, mein Maul...
Modern Times schrieb: > Und jetzt halte ich, wie schon von anderer Seite gefordert, mein Maul... Das ist nur der ungehobelten Ausdrucksweise des miesepetrigen Threaderstellers ohne jegliche Manieren geschuldet, mach dir nichts draus.
Ingenieur schrieb: > Modern Times schrieb: >> Und jetzt halte ich, wie schon von anderer Seite gefordert, mein Maul... > > Das ist nur der ungehobelten Ausdrucksweise des miesepetrigen > Threaderstellers ohne jegliche Manieren geschuldet, mach dir nichts > draus. Wenn ich ungehobelt bin und ohne jegliche Manieren, dann muß ungehobelt und ohne jegliche Manieren die beste Eigenschaft sein, die ein Mensch haben kann.
:
Bearbeitet durch User
Roland F. schrieb: > Mal eine Zwischenfrage: Wenn ich Testsoftware erstelle > um andere Software auf Funktion und Richtigkeit zu zu > prüfen, müsste ich doch eigentlich für diese Testsoftware > wiederum Testsoftware entwickeln u.s.w. > Wie funktioniert so was in der Praxis? Die Gesamtzahl der Fehler nimmt natürlich zu, weil die Testsoftware ihrerseits fehlerhaft ist. Das kann man aber in Kauf nehmen, denn: 1. Es ist sehr unwahrscheinlich, dass ein Fehler in der Test- software einen Fehler im Prüfling genau kompensiert. 2. Wenn das Gesamtsystem aus Testsoftware und Prüfling einen Fehler zeigt, der von einem Fehler in der Testsoftware hervorgerufen wurde, dann ist das zwar ärgerlich, aber es fällt bei der Suche nach der Fehlerursache relativ schnell auf. Die Suche nach der Fehlerursache macht ja immer noch der Mensch. Anders formuliert: Wenn die Testsoftware genausoviele Fehler hat wie der Prüfling, die Testüberdeckung aber verzehnfacht, dann hat man bei doppeltem Arbeitsaufwand die Fehler im Prüfling auf 10% reduziert. Das ist doch ganz ordentlich.
Wühlhase schrieb: > Roland F. schrieb: >> Mal eine Zwischenfrage: Wenn ich Testsoftware erstelle >> um andere Software auf Funktion und Richtigkeit zu zu >> prüfen, müsste ich doch eigentlich für diese Testsoftware >> wiederum Testsoftware entwickeln >> u.s.w. >> Wie funktioniert so was in der Praxis? > > Naja, im Hardwarebau testet man sein Werk ja auch. Ich hab > aber noch nie gesehen, daß man die Testumgebung testet. Tatsächlich? Du arbeitest prinzipiell mit unkalibrierten und ungeprüften Multimetern? Du hast noch nie die Frequenzkompensation am Tastkopf geprüft und eingestellt? Du warst noch nie dabei, wenn die QS Prüfmuster in Form von Gut- oder Schlechtteilen durch eine Prüfeinrichtung geschickt hat? Sehr merkwürdig.
Bert W. schrieb: > Fakt ist: > 1. Es gibt diese Methoden. Also muß sie jemand entwickeln. Ja. Korrekt. > 2. Es kommen immer wieder neue Methoden dieser Art. Also > muß sie jemand wollen. Und bezahlen. Nein. Zu kurz gedacht. Du gehst naiverweise davon aus, dass die Methode entwickelt und (gegen viel Bares) gelehrt wurde, damit sie a) praktisch angewendet wird und b) denjenigen, die sie anwenden, Nutzen bringt. Das KANN im Einzelfall so sein -- muss aber nicht. > Es ist zu simpel zu sagen, daß alles nur Schall und > Rauch sei. > > Wenn es so wäre, warum gibt es die Leute dann noch? Wenn > sich kein Geld damit verdienen ließe, auf Kunden UND > Dozentenseite, warum stirbt das nicht aus? Weil es im Einzelfall sehr praktisch sein kann, einen bezahlten "Schuldigen" zu haben. Vieles wird nicht deshalb gemacht, weil man an den konkreten Sinn und Erfolg dieser Maßnahme glaubt, sondern weil man im Falle des Scheiterns jegliche Schuld von sich weisen können möchte. > Ich warte noch auf jemanden, der erklären kann, wofür diese > Konzepte gut sind. Für WEN diese Konzepte gut sind. Naja. Ebenso könntest Du fragen, für wen "diese" Bauelemente nützlich sind. Das ist aber nicht sinnvoll zu beantworten, solange Du Dich nicht festlegst, ob "dieses" Bauelement ein Langstabisolator oder ein SMD-Widerstand ist...
Egon D. schrieb: > Du arbeitest prinzipiell mit unkalibrierten und ungeprüften > Multimetern? Du hast noch nie die Frequenzkompensation am > Tastkopf geprüft und eingestellt? Du glaubst nicht, in wie vielen Firmen es höchstens ein kalibriertes Gerät gibt. Aber selbst dann: Wer prüft vor jeder Messung, ob sein Gerät mit der erforderlichen Genauigkeit mißt? Viel mehr ist es doch so, daß die Messung als ok angenommen wird, wenn das Ergebnis dem entspricht was man erwartet hat. Erst wenn das nicht der Fall ist, schaut mancher mal nach ob das Meßmittel in Ordnung ist-aber selbst dann verlassen sich die meisten noch ohne weitere Prüfung auf das Meßgerät. Wie schon jemand geschrieben hat: es ist sehr unwahrscheinlich, daß ein Fehler in der Testsoftware UND im Prüfling fälschlich ein "Test OK" ergeben.
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.