Bei uns findet gerade eine Agile Transformation statt. Wir werden jetzt dann User-Stories schreiben, um unserer Projekte besser zu organisieren. Bei einer User Story beschreibt man das Problem aus der Sicht eines Anwenders. Damit kann man das Problem dann besser verstehen. Die User Stories werden dann innerhalb eines Sprints abgearbeitet und sind erledigt, wenn sie die aufgeschriebenen Akzetpanzkriterien erfüllen. Ich dachte ursprünglich, das Prinzip wäre nur für die Softwareenttwicklung, aber man kann es scheinbar auch für die Elektronikentwicklung und die Konstruktion verwenden. Verwendet ihr auch schon Agile Methoden und wie sind eure Erfahrungen mit den User Stories?
:
Trollpost. Agile Entwicklung funktioniert sehr gut, man muss es zunächst mal verstehen, dann anwenden und dann auch in der täglichen Arbeit leben. Zusätzlich zur agilen Entwicklung benötigt man aber auch die entsprechende Infrastruktur und auch entsprechend ausgebildete Entwickler. Leider scheitert es in Deutschland sowohl bei den Managern als auch bei den Entwickler sowohl bei Punkt 1, bei Punkt 2 und bei Punkt 3.
Herbert schrieb: > Verwendet ihr auch schon Agile Methoden Nicht mehr. Kam nie was sinnvolles bei raus wenn man ständig die velocity im Schaumschlagen erhöht weil BWL Hansel nichts verstehen aber ständig steigende Zahlen sehen wollen. Agile Methoden wie Scrum, Kanban, Kaizen, Lean können prinzipbedingt keine qualitätsgesicherten Produkte liefern. Six Sigma DMAIC (define, measure, analyze, control, improve) liegt näher an ISO9001, im seriösen Umfeld gilt DO-178, V-Modell XT und IEEE 12207 falls es um den ganzen SW Lifecykle geht. Die DIN EN 61508 ("SIL-Norm") verlangt daher für sicherheitsgerichtete Funktionen die Wasserfall oder V-Modell Methode bei der Entwicklung.
>Agile Entwicklung funktioniert sehr gut ...
Das hört sich so an, als wenn du schon Erfahrungen damit hast.
Welche Funktion übernimmt bei euch der Produkt-Owner?
MaWin (Gast) 04.03.2021 20:56 >Herbert schrieb: >> Verwendet ihr auch schon Agile Methoden >Nicht mehr. >Kam nie was sinnvolles bei raus wenn man ständig die velocity im >Schaumschlagen erhöht weil BWL Hansel nichts verstehen aber ständig >steigende Zahlen sehen wollen. Seit ihr ein reines Softwareteam oder sind auch andere Disziplinen wie Hardware beteiligt? Bei der Software gibt es ja oft das Problem der Arbeitsüberlastung und durch die User-Stories erhoffe ich mir ein besseres Fernhalten von Leuten, die immer neue Features einkippen wollen.
MaWin schrieb: > Agile Methoden wie Scrum, Kanban, Kaizen, Lean können prinzipbedingt > keine qualitätsgesicherten Produkte liefern. Du solltest dich erst mal informieren. Gerade bei agilen Methoden steht Qualität sogar im Mittelpunkt. V-Modell und agil stehen übrigens auch überhaupt nicht im Widerspruch. Die Qualität bei agilen Methoden steht und fällt aber mit dem Qualität der Entwickler. Garbage In. Gargabe Out. Wenn Nichtskönner grottigen Code produzieren und Nichtskönner diesen grottigen Code grottig reviewen und Nichtskönner grottige Definitions of Done schreiben, na dann gibt es natürlich keine Qualität. Herbert schrieb: > Das hört sich so an, als wenn du schon Erfahrungen damit hast. > Welche Funktion übernimmt bei euch der Produkt-Owner? Ich habe Erfahrung. Und sogar eine kleine Geschichte. Habe eine zeitlang in einem sehr großen Konzern gearbeitet. Zwei Standorte A und B haben gleichzeitig begonnen an einem Projekt zu arbeiten. Das Proejkt an beiden Standorten war in Details verschieden, jedoch grundsätzlich sehr sehr ähnlich. Grund für die Parallelentwicklung war zu 80% Firmenpolitik und zu 20% irgendwelche rechtlichen Gründe (für Kunde xyz muss eigener Code produziert werden kA). Standort A nutzte stures Projektmanagement nach Wasserfall. Am Anfang des Projekte wurde auf 2 Wochen genau geplant, wer was wann macht und wann was fertig zu sein hat. Die beteiligten Manager haben dann noch 10% Sicherheitspuffer draufgeschlagen, weil man das halt so macht. Fertig war der Plan. Standort B entschied sich von Anfang für ein agiles Vorgehen. Und zwar wirklich agil. Sowohl Manager als auch Entwickler wurden darauf geschult und es gab eine externe Begleitung. Es wurden am Anfang des Projekt alle User Storys, die aus den Kundenrequirements abgeleitet werden konnten, aufgeschrieben. Und dann begann man zu arbeiten. Ende der Geschichte: Standort B lieferte mit minimalen Verzug (bedingt durch diverse Change Requests) in hoher Qualität. Standort A lieferte mit monatelangem Verzug in nichtmal annährender Qualität ab. Gleichzeitig gab es beim Standort A massive Überstunden und damit Budgetüberschreitungen.
Herbert schrieb: > Welche Funktion übernimmt bei euch der Produkt-Owner? Die selbe wie schon zu Zeiten als man solche Leute noch "(Interne)Kunden" genannt hat:-) Will alles sofort, will jeden Tag was anderes, will dafür keine budget bereitstellen usw. Alles genauso wie seit Jahrzehneten, eine neuere Name für irgendwas ändert da garnichts dran. Herbert schrieb: > Seit ihr ein reines Softwareteam oder sind auch andere Disziplinen wie > Hardware beteiligt? Bei der Software gibt es ja oft das Problem der > Arbeitsüberlastung und durch die User-Stories erhoffe ich mir ein > besseres Fernhalten von Leuten, die immer neue Features einkippen > wollen. Die Agile-Sau wird derzeit durch alles getrieben was man irgendwie entwickeln kann. Das kann auch ein Handtuchhalter sein ganz ohne Elektronik oder Software. Zu glauben das User-Storys irgendwas "Fernhalten" grenzt daran zu glauben das an Ostern der Weihnachtsmann vorbeikommt. Mit den Dingern wird das Ganze noch viel schlimmer als vorher weil jeder glaubt man muss nur genug von denen Schreiben und wie durch eine Wunder erledigt - ist ja jetzt alles Agile und alles wird sofort erledigt und nicht mehr wie früher von langer Hand geplant. Seit Einführung von dem Agilen scheißdreck muss man bei uns schon froh sein, wenn man wenigstens noch einen Tag die Woche zum Arbeiten kommt. Der Rest geht für Unmengen bla bla Runden drauf wo eine Userstory mit eigentliche 2-3 Stunden Arbeit erstmal mit 20 Leuten 2 Stunden lang diskutiert wird ob die überhaupt so gemacht werden kann und wenn das rum ist geht es dann noch in zig Priorisierungsrunden über die Reihenfolge der Userstorys. Und das alle paar Tage wieder von vorne weil sich garantiert irgendein Auftraggeber bei der Priorisierung benachteiligt fühlt und sein Projekt ja so wichtig ist das alles nochmal neu von vorne ausgehandelt werden muss. Mit dem ganzen Agile Zeug ist es endlich gelungen die perfekte Selbstverwaltung zu erschaffen und die ganze Arbeitszeit mit dem Prozess zu verbringen ohne auch nur irgendeinen output zu generieren. Und falls mal "Auftragsmangel" in Sicht kommen sollte schreibt man sich halt selbst eine paar User-Stories und kippt die ins System:-)
shkval schrieb: > Du solltest dich erst mal informieren. > Gerade bei agilen Methoden steht Qualität sogar im Mittelpunkt. V-Modell > und agil stehen übrigens auch überhaupt nicht im Widerspruch. Man soll unterscheiden, welche Qualität. Denn es kann unterschiedliche sein. > Die Qualität bei agilen Methoden steht und fällt aber mit dem Qualität > der Entwickler. > Garbage In. Gargabe Out. Wenn Nichtskönner grottigen Code produzieren > und Nichtskönner diesen grottigen Code grottig reviewen und Nichtskönner > grottige Definitions of Done schreiben, na dann gibt es natürlich keine > Qualität. Ja, das Problem dabei ist, wenn einer nur sagt, dass er agil arbeitet, dann sind die anderen Fähigkeiten wieso auch immer weniger relevant. Das Wort wird zu einer Frei-Karte. Und wird sehr oft missbraucht. > Ich habe Erfahrung. Und sogar eine kleine Geschichte. Es erinnerte mich an die andere Geschichte. Einer fand wo ein Geldstück. Der andere, der davon erfuhr ging auf diese Stelle immer wieder - jedoch fand nie was. Damit wollte ich zum Ausdruck bringen, dass individuelle Beispiele nicht immer repräsentativ für etwas sein können. Das Problem ist dabei, dass vergessen wird, dass auch "gestern" Autos, Flugzeuge, Computer, Macs, Formel-1, Raketen fürs All usw. auch erfunden und gemacht wurden. Das beweist, dass auch die anderen Methoden gut funktionieren können. Ich vermisse in agil so was wie Wissenschaftlichen Bezug mit Formeln und Regeln. Ja, wenn ich eine Brücke über Rhein machen möchte, wird in diesem Projekt sehr viel, was man agil erledigen kann. Aber eine Konstruktion zu entwerfen, erst danach für sie die Statik zu berechnen usw. - einige grundlegende Aufgaben sind nicht agil, sondern brauchen eine grundlegende Überlegung und Erfahrung und Zeit. Auch die Software braucht eine vernünftige Architektur, Technologie und Datenmodell, die über mehrere Jahre stabil sein sollen. Eine stabile Architektur kann man nicht in 2-wochigen Zyklen erstellen. Meine Meinung, mit der nicht jeder einverstanden sein soll.
Wenn eine Firma unter Wasserfall oder sonst einem Modell nix gebacken & fertig bekommt, dann ist es ein Trugschluss sowas nur durch agile, übergestülpte Methoden verbessern zu können. Ich würde mittlerweile eher sagen es ist oft ein Führungs, Firmenkultur & Mitarbeiterproblem(je nachdem in unterschiedlicher Gewichtung) Würden die Grundsätzlichen Probleme angegegangen (Kommunikation, Aufgabenverteilung, Verantwortlichkeit, Entscheidungsfindung bei unterschiedlichen Meinungen usw) dann ist das vorgehen in der Entwicklung eher zweitrangig.
Irgend W. schrieb: > Die Agile-Sau wird derzeit durch alles getrieben was man irgendwie > entwickeln kann. > .... sind wir Kollegen? <ironie>
Agil & Scrum gibt dem ganzen Gequatsche, Planlosigkeit, Abstimmung & letztendlicher Planung ja nur ein Gesicht bzw eine Struktur. Vorher wurde halt nebenbei über den Kram diskutiert zwischen Tür & Angel, jetzt gibst dafür wöchentliche Meetings. Der Abstimmungsbedarf & die Unklarheiten waren ja auch schon vorher da. Jetzt wird es nur ein wenig offensichtlicher
A. B. schrieb: > Wenn eine Firma unter Wasserfall oder sonst einem Modell nix gebacken & > fertig bekommt, dann ist es ein Trugschluss sowas nur durch agile, > übergestülpte Methoden verbessern zu können. Bin mir dir voll einverstanden. Leider wird die Methode nicht als Zusatz, sondern als Ersatz positioniert. > > Ich würde mittlerweile eher sagen es ist oft ein Führungs, Firmenkultur > & Mitarbeiterproblem(je nachdem in unterschiedlicher Gewichtung) > > Würden die Grundsätzlichen Probleme angegegangen (Kommunikation, > Aufgabenverteilung, Verantwortlichkeit, Entscheidungsfindung bei > unterschiedlichen Meinungen usw) dann ist das vorgehen in der > Entwicklung eher zweitrangig. Dein Fazit hast du gut zusammen gefasst.
Irgend W. schrieb: > Die Agile-Sau wird derzeit durch alles getrieben was man irgendwie > entwickeln kann. Allein das du schreibst "derzeit" lässt mich deine Äußerungen schon etwas skeptisch betrachten. Die agile Sau wird schon so dermaßen lange getrieben, dass sie fast schon tot ist. Unter welchem Stein lebst du?
A. B. schrieb: > Irgend W. schrieb: >> Die Agile-Sau wird derzeit durch alles getrieben was man irgendwie >> entwickeln kann. > > Allein das du schreibst "derzeit" lässt mich deine Äußerungen schon > etwas skeptisch betrachten. > Die agile Sau wird schon so dermaßen lange getrieben, dass sie fast > schon tot ist. Unter welchem Stein lebst du? So einen Höhepunkt wie derzeit hat agile noch nie gehabt. Daher - er traf den richtigen Ton.
shkval schrieb: > Du solltest dich erst mal informieren Danke. 20 Jahre agiler Quatsch mit dutzenden Lehrgängen, Mentoren und wer noch so alles Geld verdienen wollte reichen als Information. Und nicht jeder der dutzend Verantwortlichen hat agil nicht verstanden oder absichtlich umgangen. Die Methoden haben nachweislich bewiesen, dass sie nicht geeignet sind, gute Produkte in kurzer Zeit mit optimaler Resourcennutzung zu erzeugen. Die "Performance" der Entwicklung vor 20 Jahren mit ordentlichem Pflichtenheft war weit effektiver, die Produktqualität deutlich höher. Es hat seinen Grund, warum aktuelle Software, auch und vor allem Webangebote die fast alle agil entwickelt werden, hanebüchener Quatsch sind. Wollte gerade meinen Warenkorb bei Pollin ausdrucken 4 Artikel pro DIN A4 Seite werden gedruckt. Typisches Ergebnis agilen Unsinns. Die Theorie: "wenn es nicht funktioniert, hast du nur nicht fest genug dran geglaubt", ist religiöses Geschwurbel.
MaWin schrieb: > Six Sigma DMAIC (define, measure, analyze, control, improve) liegt näher > an ISO9001, im seriösen Umfeld gilt DO-178, V-Modell XT und IEEE 12207 > falls es um den ganzen SW Lifecykle geht. Die DIN EN 61508 ("SIL-Norm") > verlangt daher für sicherheitsgerichtete Funktionen die Wasserfall oder > V-Modell Methode bei der Entwicklung. Als ich das las, habe ich mir gedacht, dass kein Scrum-Master, kein PO, kein PM usw. diese Begriffe kennt, jemals wo hörte, darüber las usw. Außer den Jenigen, die rechtzeitig auf diesen agilen-Zug umgesprungen sind, weil dort viel mehr zu holen war...
Herbert schrieb: > Bei der Software gibt es ja oft das Problem der > Arbeitsüberlastung und durch die User-Stories > erhoffe ich mir ein besseres Fernhalten von Leuten, > die immer neue Features einkippen wollen. Sofern es sich bei den "Leuten, die immer neue Features einkippen wollen" um Chefs handelt: Vergiss Deine Idee. Du als Indianer kannst mit keiner Methode der Welt Deinen Häuptling erziehen. Frei nach Tom DeMarco: "Gegen pathologische Projektpolitik gibt es kein wirksames Mittel." "Mitarbeiter verursachen Probleme. Chefs verursachen Katastrophen."
A. B. schrieb: > Würden die Grundsätzlichen Probleme angegegangen > (Kommunikation, Aufgabenverteilung, Verantwortlichkeit, > Entscheidungsfindung bei unterschiedlichen Meinungen > usw) dann ist das vorgehen in der Entwicklung eher > zweitrangig. Übersetzung: "Würde man all die Probleme, die die agilen Methoden zu lösen versuchen, irgendwie anders lösen, wäre es egal, ob man agile Methoden anwendet." Ähh... ja. Korrekt. Aber völlig nutzlos.
Valeri D. schrieb: > Auch die > Software braucht eine vernünftige Architektur, Technologie und > Datenmodell, die über mehrere Jahre stabil sein sollen. Eine stabile > Architektur kann man nicht in 2-wochigen Zyklen erstellen "Vernünftig" klingt für mich so danach, dass du alle Anforderungen kennst. Die kennt man aber zumeist nicht. Zumindest nicht in wahrscheinlich 95% der Entwicklungsteams(da könnte man jetzt erörtern warum das so ist) in der heutigen Zeit. Wenn du versuchst eine Brücke zu bauen so wie heute Software geplant wird, dann bekommst du die Kinderzeichnung einer Duplo Brücke, mit Fragezeichen & Platzhaltern bei 90% der relavanten Informationen welche sich während des Prozesses noch ändern können oder auch nicht. Zwischendurch bekommst du noch Zeichnungen von Holz, Beton und Glasbrücken die Fussgänger tragen können sollen aber evtl. auch einen Panzer. Ich habe an einem Projekt mitgearbeitet, welches eine Version 2.0 werden sollte(das sind eh die schlimmsten Projekte) Man fängt nicht auf der grünen Wiese an, sondern hat x Anforderungen die jeder reinkippt um sich wichtig zu machen. Alte Zöpfe werden quasi nie abgeschnitten. Jeder Mist der über Jahre nur genervt hat ist plötzlich doch wichtig, damit sich auch ja jeder verewigen kann. Laufen sollte alles auch noch auf veralteter Hardware da man die erst später neu entwickeln wollte. Für moderne GUI-Frameworks war die zu lahm. Also mit GUI Eigenentwicklung(kann ich niemandem empfehlen). Über die Architektur wurde sich massivst Gedanken gemacht. Auch ein Problem. Wenn man die Anforderungen nicht genau kennt, kann man alles zu knapp & zu ungenau planen oder auch verleitet werden, jedes potentielle Feature overengineeren. Man meint, man weiß ja was v1.0 Scheiße gemacht hat, dann macht man es in v2.0 richtig. Es gibt aber neue, andere & unkonkrete Anforderungen und man macht wieder neue & andere Fehler wie auch bei v1.0 schon. Zeit kostet das auch alles. Irgendwann sitzt einem der Chef im Nacken der sich im Idealfall nicht mal mehr an seine unkonkreten Wünsche von vor 2 Jahren erinnert. Plötzlich ist alles lahm, unschick und letztendlich zieht irgendjemand den Stecker. Auf eine Person kann man da auch nicht zeigen die alles falsch gemacht hat. Da kommt so viel Kleinscheiß zusammen, das übersteigt manchmal die Vorstellungskraft des uC.net Hobbyentwicklers Zusätzlich sollte man nicht unterschätzen, dass die Ansprüche heutezutage gestiegen sind. Wenn mir jemand erzählt, wie super das damals vor 25 Jahren alles war und wie effektiv da doch entwickelt wurde, dann kann ich nur schmunzeln. Da hatte auch nicht jeder Hanz&Franz ein Smartphone in der Tasche, an dessen Features dann halt auch mal 500 Mann Teams sitzen. Viel Spaß dagegen mit dem 5 Mann Entwicklerteam zu konkurrieren, in deren Firma IT Nebensache ist. Aber die Experten hier können darüber natürlich nur müde Lächeln :)
Egon D. schrieb: > Ähh... ja. Korrekt. Aber völlig nutzlos. Ja eben...wenn man sich der ursächlichen Probleme nicht bewusst wird, ist es eben auch das: völlig nutzlos! Oder meinst du, in einer Firma aus Einzelkämpfern und schlechter Kultur bringt die 2wöchentliche Retro plötzlich automatisch den Umschwung nur weil man jetzt agil ist?
A. B. schrieb: > Oder meinst du, in einer Firma aus Einzelkämpfern > und schlechter Kultur bringt die 2wöchentliche Retro > plötzlich automatisch den Umschwung nur weil man > jetzt agil ist? Nein, das meine ich nicht. Ich meine folgendes: Du zählst (zu Recht) einige Problem- felder auf und sagst: "Wenn man diese Probleme lösen könnte, wäre egal, ob man agil arbeitet oder nicht." Du zäumst damit aber das Pferd vom Schwanz her auf, denn (einige) agile Methoden versuchen ja gerade, genau für diese Problemfelder konkrete Lösungen anzubieten! Und -- ja, selbstverständlich: Wenn man für diese Probleme ANDERE Lösungen hätte, bräuchte man die agilen Methoden nicht! Richtig erkannt -- aber nutzlos.
Valeri D. schrieb: > Das Problem ist dabei, dass vergessen wird, dass auch "gestern" Autos, > Flugzeuge, Computer, Macs, Formel-1, Raketen fürs All usw. auch erfunden > und gemacht wurden. Das beweist, dass auch die anderen Methoden gut > funktionieren können. Ich vermisse in agil so was wie Wissenschaftlichen > Bezug mit Formeln und Regeln. Ja, wenn ich eine Brücke über Rhein machen > möchte, wird in diesem Projekt sehr viel, was man agil erledigen kann. > Aber eine Konstruktion zu entwerfen, erst danach für sie die Statik zu > berechnen usw. - einige grundlegende Aufgaben sind nicht agil, sondern > brauchen eine grundlegende Überlegung und Erfahrung und Zeit. Auch die > Software braucht eine vernünftige Architektur, Technologie und > Datenmodell, die über mehrere Jahre stabil sein sollen. Eine stabile > Architektur kann man nicht in 2-wochigen Zyklen erstellen. Meine > Meinung, mit der nicht jeder einverstanden sein soll. Es wird leider sehr viel vermischt und agile Entwicklung wird auch missbraucht. Daher auch der schlechte Ruf agiler Methoden. Vielleicht ein wenig länger aber... Agile Entwicklung heißt nicht, das sich plötzlich im 2 Wochen Rythmus ALLES ändere. Agile Entwicklung heißt nicht, dass ich plötzlich alle 2 Wochen neue Requirements mache. Agile Entwicklung heißt nicht, dass ich alle 2 Wochen meine Technologie oder Architektur ändere. Der agile Entwicklungsprozess ist so gesehen ein kleiner Bereich im Gesamtentwicklungsprozess. Der agile Prozess kann in ein klassisches V-Modell eingebettet werden. Der agile Prozess kann auch in einen klassischen Projektplan eingebettet werden. Die besten Erfahrungen, die ICH gemacht habe, waren agile Kernentwicklungsteams die in größere Prozesse zur Qualitätssicherung und Produktabnahme eingebettet waren. Ich arbeite in einem Bereich der nicht weit weg von Flugzeugen und Raketen fürs All ist und wir haben z.B. einen größeren Prozess mit mehreren Teilprozessen, von denen die Implementierung einer ist. Bevor das Kernentwicklerteam beginnt, müssen verschiedene Teilprozesse abgeschlossen werden z.B. das Requirements Engineering oder das Systems Engineering. Auch Architekturfragen können so zeitnah vor der Implementierung geklärt werden. Die Alternative ist, dass man zunächst Zeit einplant für eine agile Architekturentwicklung, da man z.B. im Vorraus manchmal nicht sagen kann, ob gewisse Architekturen auch die gewünschte Performance usw. bringen (im Beispiel oben, könnte man z.B. zunächst Zeit einplanen um herauszufinden, inwieweit die Pläne des Architekten statisch überhaupt möglich sind und wo der Architekt ändern muss... bevor man z.B. erstmal eine komplette statische Berechnung durchführt und dann drauf kommt, ok, geht nicht, Architekt muss neu planen). Insofern wiedersprechen sich agile Entwicklung und auch wissenschaftlicher Bezug gar nicht. In Wahrheit ist z.B. agile Entwicklung sehr nahe auch an wissenschaftlicher Arbeit... Agile Entwicklung funktioniert nicht 1) Wenn Requirements unklar sind und einfach gesagt wird, fangt mal an 2) Wenn agil nur ein Buzzword ist und der Cheffe trotzdem micro-managed und jeden Tag munter irgendwelche Aufgaben direkt vergibt 3) Wenn dem Entwicklerteam seine Selbstorganisation genommen wird (siehe 2) 4) Wenn "agil" bedeutet, dass man nur mehr "Systemerhalter" für endlose und sinnlose Meetings ist und alle Entwickler zu allen Meetings eingeladen werden 5) Wenn "agil" bedeutet, dass der Product Owner eigentlich Projektleiter ist und dann trotzdem ein paar schöne Gantt Charts und Co zeichnet, um das Management zufrieden zu stellen ....
A. B. schrieb: > Valeri D. schrieb: >> Auch die Software braucht eine vernünftige >> Architektur, Technologie und Datenmodell, die >> über mehrere Jahre stabil sein sollen. Eine >> stabile Architektur kann man nicht in 2-wochigen >> Zyklen erstellen > > "Vernünftig" klingt für mich so danach, dass du alle > Anforderungen kennst. Nicht unbedingt. "Vernünftig" heisst nicht zwingend "ein für alle Mal feststehend". Es ist aber deutlich verschieden von "hat sich halt so ergeben". Ein gewisser... "Gestaltungswille" sollte schon erkennbar sein... :) > Die kennt man aber zumeist nicht. Zumindest nicht in > wahrscheinlich 95% der Entwicklungsteams(da könnte > man jetzt erörtern warum das so ist) in der heutigen > Zeit. Damit weisst Du schonmal mehr als gefühlt 90% aller Mitglieder eines beliebigen Projektteams.
A. B. schrieb: > ...overengineeren. Man meint, man weiß ja was v1.0 Scheiße gemacht hat, > dann macht man es in v2.0 richtig. Es gibt aber neue, andere & > unkonkrete Anforderungen und man macht wieder neue & andere Fehler wie > auch bei v1.0 schon. Du hast alles gut erfasst. Leider oder zum Glück habe ich nichts gehört, wo du mir widersprechen wolltest. Denn dennoch werden auch heute Brücken gebaut und Autos hergestellt und Motoren für sie fertigentwickelt und nicht erst danach iterativ stätig verbessert, nachdem das Auto bereits verkauft wurde. Ja, Fehler passieren. Und ja, auch manchmal werden auch Autos zurück gerufen. Diese Aktion ist jedoch mehr Ausnahme als Regel. Es gibt in jedem Projekt, besonders in einem Ingenieur- oder Softwareprojekt so was wie Hauptgrundlage. Diese braucht nicht zu wissen, ob ein Button runde oder eckige Ecken später haben wird. Diese Hauptgrundlage ist eine Konstruktion. Wie in einem Hochhaus. Ja, die Räume werden später zusammengelegt, anders gestrichen, neue Dosen werden installiert, neu Fahrstühle werden verbaut usw. Jedoch in einem Wolkenkratzer aus den 30-Jahren steht die Hauptkonstruktion nach wie vor stabil, weil sie für diese Stabilität entwickelt wurde. Meiner Meinung nach sollen auch die anderen Projekte so design werden. Denn man kann eine Konstruktion eines Wolkenkratzer nicht iterativ realtime-artig entwickeln. Mir ist die Methode dafür nicht bekannt. Das heißt für mich - zuerst Konstruktion entwerfen, danach Statik, danach agil und parallel - bauen lassen und Raume gestalten. Wenn man ständig neue Anforderungen in den Bauplänen berücksichtigen möchte, dann erlebt man ähnliches wie Berliner-Flughafen - endloses Projekt.
shkval schrieb: >... > Agile Entwicklung funktioniert nicht > 1) Wenn Requirements unklar sind und einfach gesagt wird, fangt mal an > 2) Wenn agil nur ein Buzzword ist und der Cheffe trotzdem micro-managed > und jeden Tag munter irgendwelche Aufgaben direkt vergibt > 3) Wenn dem Entwicklerteam seine Selbstorganisation genommen wird (siehe 2) > 4) Wenn "agil" bedeutet, dass man nur mehr "Systemerhalter" für endlose > und sinnlose Meetings ist und alle Entwickler zu allen Meetings > eingeladen werden > 5) Wenn "agil" bedeutet, dass der Product Owner eigentlich Projektleiter > ist und dann trotzdem ein paar schöne Gantt Charts und Co zeichnet, um > das Management zufrieden zu stellen > .... Du hast sehr gut alles erfasst. Ich habe mir dein Kommentar notiert. Ich muss ihn noch einige Male lesen, um ihn genauso auch wiedergeben zu können. Danke. Eine kleine Ergänzung. Du hast Recht. Und ich verstehe, was agil ist und was nicht ist. Es wird aber massiv von denen verbogen, die agil überall mit allen Mitteln durchsetzen wollen - passt oder nicht, weil ... (hier kann jeder die Liste der Gründe selber gestallten).
Ich will dir gar nicht unbedingt widersprechen. Ich sinniere nur über das Leben als Softwareentwickler. uC.net Therapiestunde ;-)
A. B. schrieb: > Ich will dir gar nicht unbedingt widersprechen. Ich sinniere nur über > das Leben als Softwareentwickler. > uC.net Therapiestunde ;-) Volltreffer :)
Valeri D. schrieb: > Denn dennoch werden auch heute Brücken gebaut und > Autos hergestellt und Motoren für sie fertigentwickelt > und nicht erst danach iterativ stätig verbessert, > nachdem das Auto bereits verkauft wurde. Das stimmt. Du vergisst dabei, dass Brücken seit tausenden von Jahren und Autos immerhin seit 130 Jahren gebaut werden. Sicher, die Details entwickeln sich allmählich weiter, die Technik ändert sich -- aber viele Grundfunktionen bleiben erhalten. Smartphones haben (lt. Wikipädie) seit 13 Jahren (!!) eine nennenswerte Verbreitung. Das Auto ist zehnmal so alt! Wenn sich die Geschwindigkeit der Autos genauso entwickelt hätte wie die Rechenleistung der Smartphones, wären wir wohl alle mit Mach 10 unterwegs. > Ja, Fehler passieren. Es geht nicht (primär) um Fehler. Es geht darum, dass die Computer Dinge automatisieren, die noch nie zuvor eine Maschine vollbracht hat. Dabei tritt regelmäßig der Fall ein, dass der zukünftige Anwender noch KEINE klare Vorstellung davon hat, was das Computerprogramm leisten kann und muss. Das ist auch völlig logisch -- es ist ja NEU! > Es gibt in jedem Projekt, besonders in einem Ingenieur- > oder Softwareprojekt so was wie Hauptgrundlage. Diese > braucht nicht zu wissen, ob ein Button runde oder eckige > Ecken später haben wird. Diese Hauptgrundlage ist eine > Konstruktion. Wie in einem Hochhaus. Nein. Das ist Dein Irrtum. Eine echte Innovation ist in mindestens einem Punkt NEU -- sonst wäre es keine Innovation. Dafür gibt es aber noch keine erprobte Methode.
Beitrag #6609378 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Nein. Das ist Dein Irrtum. > Eine echte Innovation ist in mindestens einem Punkt NEU -- > sonst wäre es keine Innovation. Dafür gibt es aber noch > keine erprobte Methode. mit allem von dir einverstanden, jedoch, was du hier beschreist - ist eine akribische Suche nach den neuen Wegen - das hat mit sehr vielen Projekten nicht zu tun. Eine echte Innovation zu wollen - bedeutet, wirklich was Neues machen. Viele Projekt haben diesen Anspruch nicht. Und die erprobten Methoden existieren auch für Sachen, die es noch nicht gibt. Das Stichwort dafür ist z.B. TRIZ https://de.wikipedia.org/wiki/TRIZ Keiner von mir bekannten Scrum-Master hat diesen Begriff jemals gehört. Wir reden nicht darüber - das sie es anwenden würden.
shkval schrieb: > Agile Entwicklung heißt nicht, das sich plötzlich im 2 Wochen Rythmus > ALLES ändere. Agile Entwicklung heißt nicht, dass ich plötzlich alle 2 > Wochen neue Requirements mache. Agile Entwicklung heißt nicht, dass ich > alle 2 Wochen meine Technologie oder Architektur ändere. Ja, das heiß nicht, aber wenn man sich keine Gedanken über Architektur macht, was grundsätzlich beim puren agilen Vorgang (eigentlich) nicht möglich ist. Dann wird sich das schnell ändern. Und dann hat man keine richtige Architektur, auf der man stätig (agile) aufbauen kann, sondern einen Flickenteppich. Mit dem Wasserfall kann das auch passierten, aber dort liegt solches Risiko bei den "dummen" Architekten und nicht bei der Methode.
Beitrag #6609401 wurde von einem Moderator gelöscht.
Bei uns hat das Flightlevel 3 Managment vor kurzem den Transformationsprozess vorgestellt. Der große Vorteil ist, dass durch die agile Transformation die Projektschwierigkeiten transparenter werden und sie uns Entwicklern im Flightlevel 1 besser helfen können.
Ich habe gute Erfahrungen damit, die Nachteile von Wasserfall durch Rapid Prototyping zu eliminieren, was agile Ideen mit Wasserfall ganz gut kombiniert. Man merkt viel schneller und damit günstiger, wenn man auf dem Holzweg ist.
Ich frage mich, ob wirkliche Fachexperten gerne in agilen Teams arbeiten. Mir scheint, dass besondere Leistungen eines einzelnen im agilen Team in der "Teamleistung" verschwindet.
Gustav schrieb: > Mir scheint, dass besondere Leistungen eines einzelnen im agilen Team in > der "Teamleistung" verschwindet. Ich fühle mich als Fachexperte in meinem agilen Team sehr wohl. Meine Kollegen bekommen von mir jeden Morgen detaillierte Anweisungen, die sie dann agil und selbstverantwortlich in hochwertige Arbeitsprodukte überführen. Bin deren Chef.
Gustav schrieb: > Ich frage mich, ob wirkliche Fachexperten gerne in agilen Teams > arbeiten. Mir scheint, dass besondere Leistungen eines einzelnen im > agilen Team in der "Teamleistung" verschwindet. Das ist doch die Definition von Team: Toll, ein anderer macht's. So kann sich ein Einzelner mit seiner Nicht-Leistung im agilen Team hinter der "Teamleistung" verstecken. Kann man also auch positiv sehen, je nach Standpunkt.
Bei uns wurde auch "agiles arbeiten" eingeführt, offiziell Scrum. Trotzdem werden ständig Prio 1 Themen eingekippt, auch im Sprint. Gerne übergeht das Management dabei auch mal den Product Owner und verteilt die Aufträge direkt an einzelne Mitarbeiter. Der Product Owner darf nebenher noch allen lästigen Papierkram erledigen (PPTs, Entwicklungsverträge, Patentanmeldungen) und hat keinerlei Entscheidungsfreiheit weil das Management alle Themen für die nächsten Monate schon fest vorgegeben hat. Dazu gibt es für manche Themen Zeitpläne im Excel-Format bei denen jede Terminderung eine kleine Krise verursacht. Zusätzlich haben wir ein Zentralkomittee in dem u.a. der CEO sitzt (bei über 10.000 MA!), dort wird immer genehmigt an was die einzelnen agilen Teams die nächsten 3 Monate arbeiten dürfen. Inklusive fester Vorgaben was im nächsten Release zu liefern ist. Releases sind auch fest vorgegeben alle 3 Monate zu liefern. Releases werden auch immer aufwendiger, weil alles immer formaler wird und immer mehr kram dazu kommt. Das Dokument mit den Vorgaben für ein Release hat über 20 Seiten. Das Review ist ein reiner reporting Termin fürs Management. Fail fast, aber wehe ein Projekt failt, das ist schonmal prinzipiell ausgeschlossen. Wir dürfen ein bisschen tests schreiben, aber wenn es eng wird werden die Tests wieder als Zeitverschwendung gesehen und die Entwickler sollen gefälligst Features machen. Hunterher wundert und beschwert man sich dann über Stabilitätsthemen und Bugs. Aber ja, wir sind jetzt total agil. Kannst du dir nicht ausdenken. Ist es besser als vorher? Nein, im Gegenteil. Die Dailies finde ich gut, da ist man immer auf dem Stand was die Kollegen so tun. Der Rest ist Cargo Kult und organisatorisch ist es jetzt eine Vollkatastrophe. Eine Mischung aus Bürokratie, Micromanagement und Willkür. Das Management erwartet mehr Output als vorher und mischt sich viel mehr ein als vorher. Etwas ausprobieren oder Zeit um technische Schulden zu begleichen, Refactoring, das ist alles nicht mehr drin. Ich glaube man kann sehr gut agil arbeiten und Software entwickeln. Aber nicht bei uns.
Abc schrieb: > Ich glaube man kann sehr gut agil arbeiten und Software entwickeln. Aber > nicht bei uns Ihr kombiniert einfach alle Nachteile aus verschiedenen Prozessen. Genial.
Beitrag #6609497 wurde von einem Moderator gelöscht.
Agil transformiertes Neuronennetzwerk schrieb im Beitrag #6609497:
> Warum kann man nicht einfach am Bewährten festhalten?
Weil das eben gerade die Sau ist die von den Beraterbuden für viel Geld
durchs Dorf getrieben wird... Wir haben dafür 6-stellige Beträge an ne
große IT Beratung gezahl, bekommen haben wir ein paar Coaches, fast alle
Berufsanfänger, bis auf einen auch noch völlig fachfremd. Die wollten
auch nicht wissen wie wir arbeiten oder was unsere Branche oder Produkte
für Besonderheiten haben. Die haben schlicht ihr Schema F runtergebetet,
genauso wie sie es auch bei nem Webentwickler tun würden.
Es ist ja nicht so dass agil per se schlechter sein muss, aber man muss
es dann auch richtig machen. Bei uns dient es nur der Außendarstellung
und den Micromanagern.
Fun Fact: Die meisten hochbezahlten und ach so klugen Manager lesen agil
und verstehen schnell. Dabei bedeutet agil wendig oder beweglich, aber
nicht per se schnell...
Abc schrieb: > Ist es besser als vorher? Nein, im Gegenteil. Aber das Management kann gegenüber dem Kunden belegen, wie kräftig und mit steigender Effizienz ihr am Projekt der explodierenden Kosten arbeitet und hat eine einfache Möglichkeit die Effizienzsteigerung der Teams zu messen: immer mehr Stories pro Sprint. Und wenn auch die Story im ersten Sprint lautete "erstelle Prototypen" und heute "lege einen Spike darüber an ob an das Ende eines Satzes ein Punkt gehört". Senf D. schrieb: > Ihr kombiniert einfach alle Nachteile aus verschiedenen Prozessen. > Genial. Nicht wirklich. Scrum und Kanban funktionieren nicht. Es ist eben nicht jeder Mitarbeiter gegen jeden anderen bei gleicher Arbeitseffizienz austauschbar. Es wird nicht jede Story-Liste im 3-Wochen-Raster fertig. Schon absolute Grundannahmen von Scrum treffen so wenig zu wie die Bibel im echten Leben. Abc schrieb: > Es ist ja nicht so dass agil per se schlechter sein muss, aber man muss > es dann auch richtig machen. Der übliche Blödsinn der Gläubigen: "du musst nur stark genug dran Glauben". Egon D. schrieb: > Wenn sich die Geschwindigkeit der Autos genauso entwickelt > hätte wie die Rechenleistung der Smartphones, wären wir > wohl alle mit Mach 10 unterwegs. Na ja, wenn der Autobau in Scrum-Teams gelaufen wäre, hätten wir heute Ochsenkarren mit Flügeln aus Blei. Egon D. schrieb: > Dabei tritt regelmäßig der Fall > ein, dass der zukünftige Anwender noch KEINE klare > Vorstellung davon hat, was das Computerprogramm leisten > kann und muss Nur bei sehr sehr Dummen. Seit Scrum machen die aber mit bei der Produktentwicklung. Daher kommt nur noch Schrott bei raus. Erinnert sich noch einer an den XML Hype ? Das Ende der Dateiformate, jedes Programm kann alles lesen. Man musste sehr sehr dumm sein, trotzdem hielt sich der Hype mindestens 10 Jahre. Valeri D. schrieb: > shkval schrieb: > >> Agile Entwicklung funktioniert nicht > > Du hast sehr gut alles erfasst Eigentlich reicht der erste Satz. Valeri D. schrieb: > Denn man kann eine Konstruktion eines Wolkenkratzer nicht iterativ > realtime-artig entwickeln. Mir ist die Methode dafür nicht bekannt. Das > heißt für mich - zuerst Konstruktion entwerfen, danach Statik, danach > agil und parallel - bauen lassen Jein. Auch die Statikberechnung kann ergeben, dass die Konstruktion Mist ist, und iteriert werden muss oder ganz verworfen. Und beim Bau wollen wir auch nicht agil jeden Tag Material neu einkaufen, sondern im voraus bestellen, mit Liefertermin. Das ist alles andere als agil. Sondern basiert auf ERFAHRUNG. Die fehlt halt den Kindern in der Softwareentwicklung total. shkval schrieb: > Daher auch der schlechte Ruf agiler Methoden. Im Gegenteil, es gibt ja nichts anderes mehr, jeder der nicht agil in den Himmel hochlügt, wird als Ketzer versucht zu brandmarken. Vor 30 Jahren gab es lean production bis die Produktion stillstand, danach kaizen was in Europa ganz anders verstanden wird als in Japan aber natürlich trotzdem hervorragend funktioniert. In einer komplexen Welt suchen Menschen einfach klingende Lösungen, auch wenn die Falsch sind. Um so ahnungsloser die Menschen sind, um so mehr erheben sie die Antwort zum Dogma, welches sie mit religiöser Inbrunst verteidigen.
Valeri D. schrieb: > Egon D. schrieb: > >> Nein. Das ist Dein Irrtum. >> Eine echte Innovation ist in mindestens einem Punkt >> NEU -- sonst wäre es keine Innovation. Dafür gibt es >> aber noch keine erprobte Methode. > > mit allem von dir einverstanden, jedoch, was du hier > beschreist - ist eine akribische Suche nach den neuen > Wegen - das hat mit sehr vielen Projekten nicht zu tun. Hmm. Erstmal: Projekt ist nicht gleich Projekt. In einem Konsortium von einem Dutzend Firmen mit insgesamt 500 Entwicklern einen neuen Schnellzug zu entwickeln ist eine andere Sache als mit 5 Entwicklern ein Gerät der Konkurrenz nachzubauen und zu verbessern. Meiner Meinung nach sind die Herausforderungen für den einzelnen Entwickler in kleinen Teams höher (!) als in großen. In kleinen Teams muss jeder Entwickler eine höhere Komplexität bewältigen als in großen. > Eine echte Innovation zu wollen - bedeutet, wirklich > was Neues machen. Viele Projekt haben diesen Anspruch > nicht. Das ist der Knackpunkt: Der zweite Satz stimmt -- der erste nicht. "Viele Projekte haben diesen Anspruch nicht." -- Das ist sicherlich richtig. Aber: "Eine echte Innovation zu wollen - bedeutet, wirklich etwas Neues machen" -- nee, genau das stimmt eben im Allgemeinen nicht. Es ist doch geradezu DER Klassiker in Entwicklungs- projekten, dass das Projektziel erstmal recht harmlos aussieht, und eine Weile kommt man auch gut voran. Irgendwann taucht dann ein Problem auf, das niemand vorhergesehen hat -- das sich aber zum Showstopper entwickeln könnte. Genau JETZT ist der Zwang zur Innovation da: Niemand WOLLTE dieses Problem lösen -- aber jetzt MUSS man es lösen! Es nützt Dir auch nichts, dass Jahre später irgendwer feststellt, dass eine kleine japanische Firma schon vorher auf dieselbe Lösung gekommen ist wie Du -- das hilft Dir exakt GAR NICHT weiter, wenn Du vor dem Problem stehst. Es ist schlicht EGAL, ob Du TATSÄCHLICH etwas weltweit Neues erfunden hast oder nicht -- wenn der Aufwand, das notwendige Wissen zu beschaffen, HÖHER ist als der Aufwand, die Lösung selbst zu finden. Die geschilderte Sache nennt man schlicht "Entwicklungs- risiko". Die Ursache für das Risiko ist ein WISSENSDEFIZIT. Deswegen hat auch das Wasserfallmodell seine Gefahren, denn es wird immer so GETAN, ALS SEI schon alles klar. Unwissenheit ist dann persönliches Versagen des Mit- arbeiters. Wenn dann irgendwann auch bei der Projektleitung angekommen ist, dass das Ziel leicht erreicht werden kann, sofern sich der Energieerhaltungssatz außer Kraft setzen lässt -- dann ist das Kind schon in den Brunnen gefallen. > Und die erprobten Methoden existieren auch für Sachen, > die es noch nicht gibt. Das ist richtig. Trotzdem lassen sich solche Projekte nicht einfach so planen und durchführen wie das Errichten einer weiteren Eigenheimsiedlung. Man kann eben NICHT sicher vorhersagen, WANN man eine Lösungidee haben wird, und welche Richtung das Projekt DANACH nehmen wird. Es ist zu Projektbeginn schlicht UNBEKANNT. > Das Stichwort dafür ist z.B. TRIZ Sehr interessant. Vielen Dank.
MaWin schrieb: > Egon D. schrieb: >> Wenn sich die Geschwindigkeit der Autos genauso >> entwickelt hätte wie die Rechenleistung der >> Smartphones, wären wir wohl alle mit Mach 10 >> unterwegs. > > Na ja, wenn der Autobau in Scrum-Teams gelaufen > wäre, hätten wir heute Ochsenkarren mit Flügeln > aus Blei. Naja, der innovative Teil der Auto- Entwicklung ist mit Sicherheit nach agilen Prinzipien abgelaufen. Das nannte nur noch niemand so. Methodiken und Vorgehensmodelle sind der Versuch, das in lehrbare und lernbare Regeln zu fassen, was sehr gute Leute intuitiv können. Ja -- dieser Versuch kann schiefgehen. Trotzdem ist das Ansinnen ehrenwert (-- außer natürlich für die "Elite", deren Pfründe jetzt bedroht sind). Du hast Dich dafür entschieden, agile Methoden auf ihre Formalien zu reduzieren, und leugnest schlicht und einfach, dass es da überhaupt ein reales Problem gibt, was sie zu lösen versuchen. Okay. Deine Entscheidung. Warum sollte ich mit Dir streiten? > Egon D. schrieb: >> Dabei tritt regelmäßig der Fall ein, dass der >> zukünftige Anwender noch KEINE klare Vorstellung >> davon hat, was das Computerprogramm leisten kann >> und muss > > Nur bei sehr sehr Dummen. Nicht jeder hat das (zweifelhafte) Privileg, sich seine Kunden nach IQ aussuchen zu können.
Beitrag #6609627 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Du hast Dich dafür entschieden, agile Methoden auf > ihre Formalien zu reduzieren, und leugnest schlicht und > einfach, dass es da überhaupt ein reales Problem gibt, > was sie zu lösen versuchen Ich habe mich für gar nichts entschieden. Es war die Firma, die entscheidet, jedem Hype hinterherrennen zu müssen, genauer so 5 Firmen. Als Opfer kann man erst mal nur sagen: es kann ja nur besser werden. Die Erfahrung über 20 Jahre sagt aber: es wurde schlimmer, schlimmer als man es sich je vorstellen konnte. Und das lag nicht an den handelnden Personen, die wurden in den 20 Jahren reichlich ausgetauscht. Und es lag nicht am eigenen Widerwillen, man war teilweise erstmal begeistert dabeu und teilweise nur Beobachter. Aber was man beobachten musste, war krass: dasselbe Produkt, welches in der Entwicklung 2 Jahre gekostet hatte, sollte moderner schicker schneller nachprogrammiert werden, also das Konzept lag inklusive marktfähigem example schon vor, es musste nichts mehr hinzuerfunden werden, die Doku war vollständig. Das Ergebnis nach 10 Jahren ist etwa genau so schnell bei 100-fachem Resourcenverbauch, setzt auf Eclipse auf weil das ja Arbeit spart, und kann noch immer nicht das, was das Original mal konnte. Die Kunden bleiben lieber beim Alten Produkt. Und auch andere Projekte aus den 20 Jahren kann man nur als gescheitert ansehen, wurden entwickelt und sind wegen Untauglichkeit schon wieder eingestampft Aber es wurden Millionen umgesetzt. Ich WEISS inzwischen, dass agiles Scrum die Ursache vielen Übels ist und Ursache, warum es dermassen viele Produkte gibt, die nichts mehr taugen. Ich weiss auch, dass BWL Controller es lieben, weil es eine perfekte Knute ist mit der man das gemeine Fussvolk noch mehr Output antreiben kann, dabei aber nicht merken, dass ihre Zahlen mit denen die die Performance messen und ihren Chefs präsentieren nur fake Zahlen sind. Denn das Fussvolk ist auch nicht blöd.
Beitrag #6609757 wurde von einem Moderator gelöscht.
MaWin schrieb: > Egon D. schrieb: >> Du hast Dich dafür entschieden, agile Methoden >> auf ihre Formalien zu reduzieren, und leugnest >> schlicht und einfach, dass es da überhaupt ein >> reales Problem gibt, was sie zu lösen versuchen > > Ich habe mich für gar nichts entschieden. Das nehme ich deutlich anders wahr: Du hast Dich dafür entschieden, die Schuld in der METHODE zu suchen und nicht in ihrer falschen ANWENDUNG. (Einen halben Schritt kann ich Dir aber entgegen- kommen: Es kann wohl sein, dass die Methode unausgereift ist und bestimmte Anwendungsfehler geradezu provoziert.) [...] > Und das lag nicht an den handelnden Personen, die > wurden in den 20 Jahren reichlich ausgetauscht. Es liegt fast nie an den handelnden Personen. Es ist wurscht, ob der Diktator Pinochet, Hitler oder Stalin heisst, und es ist auch wurscht, ob der Oberscherge auf den Namen Berija, Müller oder Gonzales hört. Systeme -- leider auch pathologische -- entwickeln eine Eigendynamik, nicht nur in der großen Politik. > Ich WEISS inzwischen, dass agiles Scrum die Ursache > vielen Übels ist und Ursache, warum es dermassen viele > Produkte gibt, die nichts mehr taugen. Naja, genau DAS ist die Entscheidung, von der ich rede: Deine Schlussfolgerung in Form dieser Schuldzuweisung. Die schlechten Erfahrungen wurden Dir aufgezwungen -- aber die SCHLUSSFOLGERUNG aus ihnen ist immer noch Deine Sache. > Ich weiss auch, dass BWL Controller es lieben, weil es > eine perfekte Knute ist mit der man das gemeine Fussvolk > noch mehr Output antreiben kann, Und was daran ist spezifisch für Scrum? Wo taucht in der Beschreibung von Scrum ein BWLer auf? Richtig -- nirgends. Die Aussage "Scrum ist schuld!" hat nur dann irgendeinen Wert, wenn Scrum INHALTLICH UND FORMAL KORREKT praktiziert wird UND DANN reproduzierbar Scheisse herauskommt. Davon lese ich bei Dir aber nichts. Du beschreibst nie, dass das Team während der Sprints ungestört arbeiten konnte. Du sprichst nie davon, dass natürlich die Anforderungen, die den laufenden Sprint betreffen, nicht mehr geändert werden. Es ist nie die Rede davon, dass Refactoring-Sprints durchgeführt wurden, und auch von Sprint-Reviews ist keine Rede. Und schließlich -- das Wichtigste am Schluss: Ich habe bei Dir nie etwas von einem "Product Owner" gelesen, der die Rolle so ausfüllt, wie die Methode das erfordert. Auch für das Scrum-Team gilt: garbage in -- garbage out. Wenn der Product Owner nur eine Marionette ist, die die fixen Ideen aller interessierten Manager ins Team drücken muss, dann ist es inhaltlich sinnlos, das Ganze "Scrum" zu nennen.
Egon D. schrieb: > Auch für das Scrum-Team gilt: garbage in -- garbage out. In der Praxis wird "agil" so gut wie nirgends umgesetzt, weil das vor allem mal erfordern würde, daß die Kunden agil sind. Sind sie aber nicht. Die Kunden erwarten nach wie vor einen fest definierten Umfang zu fest definierten Preisen, wollen jetzt aber zwischendrin noch mit drin rumfummeln, und das leistet agil nicht, und auch nichts anderes. Das Versagen des Managements ist es, die Kundenerwartungen nicht im Griff zu haben. Die grundsätzliche Idee bei agiler Entwicklung ist ja, daß die Kunden am Ende eines festen Zeitraumes vielleicht nur 70% bekommen - aber 70% von dem, was sie wirklich haben wollen. Das ist besser als 100% von dem, womit sie am Ende doch nichts anfangen können.
Nop schrieb: > In der Praxis wird "agil" so gut wie nirgends umgesetzt, Ach was, die sind alle so agil, die wissen gar nicht mehr, wie zielorientiertes Arbeiten geht. Egon D. schrieb: > Die Aussage "Scrum ist schuld!" hat nur dann irgendeinen > Wert, wenn Scrum INHALTLICH UND FORMAL KORREKT praktiziert > wird UND DANN reproduzierbar Scheisse herauskommt Und genau so ist es. Das ist, als wenn du den 100m Lauf in Stöckelschuhen absolvierst. Danach hast du die ERFAHRUNG, dass das Scheisse ist. Und wenn du zuvor in Turnschuhen schon mal gewonnen hast, weisst du, dass es am Verfahre liegt, nicht am Läufer. Blöd halt, wenn du darüber mit allen Tussen der Welt erst diskutieren musst, weil sie dir die Stöckelschuhe aufzwingen wollen.
Ich habe ein Video gefunden, in dem die agile Transformation recht gut erklärt wird: https://www.youtube.com/watch?v=502ILHjX9EE Da kann man auch verstehen, wie die einzelnen Rollen der Team-Mitglieder definiert sind.
Beitrag #6610263 wurde von einem Moderator gelöscht.
Herbert schrieb: > Ich habe ein Video gefunden, in dem die agile Transformation recht gut > erklärt wird: > https://www.youtube.com/watch?v=502ILHjX9EE > Da kann man auch verstehen, wie die einzelnen Rollen der Team-Mitglieder > definiert sind. An Erklärungen, wie und wieso das funktioniert - daran mangelt es nicht. Die Realität ist aber immer was anderes als pure Theorie. Vergleiche das mit dem Quellcode und dem Anspruch, es perfekt zu schreiben. Dieser Anspruch existiert seit mehreren Jahrzähnten, jedoch auch mit vielen Tools, die das sehr unterstützen erleben wir überall alles - aber nicht den perfekten Code. Wieso? Weil das von Menschen geschrieben wird. Und Menschen haben Laune, Emotionen, Höhen und Tiefen, Stress und Glücksgefühl. Und das begleitet uns ständig. Und so bleibt die Theorie nie so richtig erfüllt. Kleines Beispiel mit Agil. Wie soll deiner Meinung nach in einem agilen Verfahren ein Entwickler nach einer bestimmten Zeit sich Geld-mäßig verbessern? In einer "normalen" Welt, die zwar nicht perfekt ist - man wird von Junior nach einer Zeit zum Senior, danach steht einem zu, weitere Karieren-Stufen anzugehen. Welche Kariere-Stufen gibt es im SAFE, Scrum? Auf dieser Seite wird der normale menschlichen Anspruch als Irrtum ausgewiesen. https://hr-pioneers.com/2013/07/scrum-karriere-widerspruch/ <auszug> Irrtum Nummer 1: Karriere bedeutet ausschließlich Aufstieg in der Hierarchie In klassischen Unternehmen steht der Aufstieg in der Hierarchie im Vordergrund. Je höher ich komme, desto mehr Verantwortung und, ab einer bestimmten Position, desto mehr disziplinarische Führung, übernehme ich. Im agilen Kontext bedeuten Entwicklungsperspektiven jedoch nicht, die Karriereleiter innerhalb einer Pyramide Schritt für Schritt zu erklimmen. Im Vordergrund steht hierbei vielmehr die fachliche Weiterentwicklung. Fachliche Weiterentwicklung bedeutet, dass die eigenen Kompetenzen bzw. die sogenannten Kompetenzradien stetig erweitert werden, um so den eigenen Verantwortungsbereich auszuweiten – ohne Übernahme disziplinarischer Führungsverantwortung. </auszug> fachliche Weiterentwicklung - das ist ein Witz. Ist das alles? Von mehr Kompetenz und gleichem Geld kann man kein Haus planen, keine außergewöhnliche Ausgaben in der Zukunft sich vorstellen. Ich halte diese Aussagen für Schwachsinn, und bestimmt, dass der Jenige, der das geschrieben hat, hat nach diesem Artikel sofort bei seinem Chef nach mehr Gehalt gefragt. (ironie) Die agile Methode will alle einigermaßen gleich machen. Das sind die Menschen aber niemals. Sie wollen anderes als die Kollegen sein. Und die Menschen wollen von der Erfahrung, von dem wissen, was sie bereit sind aufzunehmen und auszubauen - davon wollen sie auch profitieren. Agil gibt dazu keine Antwort. Daher bin ich überzeugt, dass es etwas davon bleibt - genau das, was es schon immer da war - der Rest wird verschwinden. Den die Menschen werden versuchen, auf die Dauer diese Dogmas abzustoßen. Meine pers. Meinung, die nicht unbedingt geteilt werden soll.
>Die agile Methode will alle einigermaßen gleich machen. Das sind die >Menschen aber niemals. Das ist vielleicht des Pudels Kern. Einerseits arbeitet ein Team besonders effektiv Zusammen, wenn keine Revierkämpfe mehr statt finden. Andererseits ist das wohl in menschlichen Gruppen unvermeidlich, Hirachien auszubilden. Vor kurzem habe ich mal gehört, dass wenn einer bei seiner User Story schon fertig ist dann einfach die User Story eines anderen übernehmen soll. Dass das funktioniert, da habe ich größte Zweifel.
Valeri D. schrieb: > Die agile Methode will alle einigermaßen gleich > machen. Agile Methoden wollen Projekte zum Erfolg führen -- nicht die Welt retten.
Herbert schrieb: > Vor kurzem habe ich mal gehört, dass wenn einer bei > seiner User Story schon fertig ist dann einfach die > User Story eines anderen übernehmen soll. Dass das > funktioniert, da habe ich größte Zweifel. Vielleicht mal weniger Theoretisieren und mehr Machen? Nur so ein Gedanke...
Egon D. schrieb: > Valeri D. schrieb: > >> Die agile Methode will alle einigermaßen gleich >> machen. > > Agile Methoden wollen Projekte zum Erfolg führen -- > nicht die Welt retten. Logisch, und dieser Hund will nur spielen... https://img.fotocommunity.com/er-will-nur-spielen-f006ba9c-2ab5-4379-8bb4-856ea59fca19.jpg?width=1000
Wie machte man das in Instituten wie JPL, oder Firmen wie Boeing, Keysight u.a.? Wie geht es dort zu? Experimentieren die auch mit Agil und Scrum? Die scheinen ja in der Regel mit ihren Arbeitsmethoden ziemlich produktiv zu sein. Wie koordinierte man denn die geballte Kraft und Expertwissen von 1960s Ingenieure während der Apollo Raumfahrt Ära? Wie geht es bei ESA oder MBB zu? Man müsste eigentlich daraus lernen können welche der Methoden sich bei wichtigen Projekten tatsächlich bewährt haben. So würde für mich der Maßstab aussehen mit dem man neuzeitliche Methoden vergleichen könnte. Damals beschränkte man sich wahrscheinlich eher nur auf das Wesentliche und man verschwendete wahrscheinlich keine Zeit und Energie mit langbärtigen Firlefanz.
>Wie machte man das in Instituten wie JPL, oder Firmen wie Boeing, >Keysight u.a.? Wie geht es dort zu? Experimentieren die auch mit Agil >und Scrum? Es gibt eine extrem sehenswerte Doku über die Entwicklung der Boing 747. https://www.youtube.com/watch?v=nz2v2D55epc An irgend einer Stelle wird der damalige Chefentwickler Jahrzehnte später interviewt. Er meint, es sei kaum zu verstehen, wie lange die jetzigen Entwicklungen im Vergleich zu seinem Projekt damals bräuchten, obwohl sie Computer für die Konstruktion hätten und sie damals nur Zeichenbretter. ( Kleines Bonmot: Beim finalen Test des Flugzeugs wird im Film gezeigt, wie er seine Frau ans Ende der Startbahn stellt, um zu zeigen, dass er an das Flugzeug glaubt und es vorher abhebt ... was für ein Frauenbild damals ). Weiter oben in diesem Thread wurde schon einmal angemerkt, dass durch Scrum und Agil weithin unbrauchbare und nicht funktionierende Software in die Welt verteilt wird. Ich glaube aber, das liegt eher am zunehmenden Einsatz informationstechnischer Produkte und Mikrocontroller. Wenn schon die einfachsten embedded ARM Prozessoren mehrere Megabyte Speicher haben, steigt die Komplexität ins Unermessliche und eine klare Zielvorstellung des zu lösenden Problems verschwimmt. Man verliert sich in der Vielfalt der Möglichkeiten, das eigentliche Ziel gerät aus den Augen und die Software wird überkomplex. Agil und Scrum ist der Versuch, dieses wieder in den Griff zu bekommen. Boing ist bezüglich der Entwicklungsprozesse heutzutage nicht unbedingt das beste Vorbild, denkt man an das Desaster der Boing 737 MAX, das ohne staatliche Hilfen zweifelsohne zum Konkurs der Firma geführt hätte. Wobei ich hier immer noch der Meinung bin, dass dieses Versagen dem Management zuzuschreiben ist und nicht den Entwicklern. Die scheinbar unveränderte Firmenphilosophie wird auch schon in der Boing 747 Doku sichtbar.
Herbert schrieb: > Boing ist bezüglich der Entwicklungsprozesse heutzutage nicht unbedingt > das beste Vorbild, denkt man an das Desaster der Boing 737 MAX, das ohne > staatliche Hilfen zweifelsohne zum Konkurs der Firma geführt hätte. > Wobei ich hier immer noch der Meinung bin, dass dieses Versagen dem > Management zuzuschreiben ist und nicht den Entwicklern. Die scheinbar > unveränderte Firmenphilosophie wird auch schon in der Boing 747 Doku > sichtbar. Keiner hier im Forum hat behauptet, dass agile wegen Entwickler nicht funktioniert. Es ist das Ganze zusammen. Und wegen Boeing - genau das Gegenteil. Die Firmenphilosophie hat sich geändert. Nicht die eigene Entwicklung war bevorzugt, sonder würde vollständig ausgelagert ins Ausland. Und führte zu sehr vielen Problemen in der Umsetzung. Die reporteten Zahlen aus den Sprints waren wahrscheinlich super. Jedoch damit zu fliegen - war plötzlich zum Problem. Es ist immer ein Management Problem. Die Menschen (Designer, Entwickler, Elektroniker usw.), die von solchen Entscheidungen betroffen sind, können die Auswirkungen von solchen Fehlentscheidungen verlangsamen oder beschleunigen. Aber nicht wieder gut machen.
Maximilian Schellenberg schrieb: > Wie machte man das in (...) Firmen wie Boeing? Wie geht es dort zu? > Die scheinen ja in der Regel mit ihren Arbeitsmethoden > ziemlich produktiv zu sein. Boeing würd ich in letzter Zeit eher verneinen in Sachen Produktivität... > Damals beschränkte man sich > wahrscheinlich eher nur auf das Wesentliche und man verschwendete > wahrscheinlich keine Zeit und Energie mit langbärtigen Firlefanz. Raumfahrt ist eh nochmal ein anderes Thema.
:
Bearbeitet durch User
Reinhard S. schrieb: > Maximilian Schellenberg schrieb: > >> Wie machte man das in (...) Firmen wie Boeing? Wie geht es dort zu? >> Die scheinen ja in der Regel mit ihren Arbeitsmethoden >> ziemlich produktiv zu sein. > > Boeing würd ich in letzter Zeit eher verneinen in Sachen > Produktivität... Richtig. Ein schlechteres Beispiel hätte sich Maximilian Schellenberg kaum heraussuchen können. Er scheint hinterm Mond zu leben.
Senf D. schrieb: > Reinhard S. schrieb: > >> Maximilian Schellenberg schrieb: >>> Wie machte man das in (...) Firmen wie Boeing? Wie geht es dort zu? >>> Die scheinen ja in der Regel mit ihren Arbeitsmethoden >>> ziemlich produktiv zu sein. >> >> Boeing würd ich in letzter Zeit eher verneinen in Sachen >> Produktivität... > > Richtig. Ein schlechteres Beispiel hätte sich Maximilian Schellenberg > kaum heraussuchen können. Er scheint hinterm Mond zu leben. Na ja, Boeing ist Vorreiter bei agilen Methoden in der Flugzeugentwicklung. Schon 1995 bei der 777 wurden erste Ansätze gemacht als das agile Manifest noch nicht mal existierte, 2008 zur 737Max war Boeing voll agil, und Nein: an mangelnder Erfahrung bei der Umsetzung kann es nicht liegen, auch wenn Religiöse meinen, man müsse nur noch mehr beten wenn das Gewünschte nicht eintritt. https://www.infosysconsultinginsights.com/2019/06/12/the-risks-of-moving-to-mature-agile-too-fast-a-cautionary-tale/ Die Ursachenanalyse des 737Max Problems führte zu: Developers with insufficient aviation domain experience; Poor oversight compared to that for hardware and overall aerodynamics;
MaWin schrieb: > Die Ursachenanalyse des 737Max Problems führte zu: > > Developers with insufficient aviation domain experience; > Poor oversight compared to that for hardware and overall aerodynamics; Sehr richtig. Jedoch, wer hat sie beauftragt bzw. Ihnen den Auftrag erteilt? Der schlechte Handwerker hat nicht die Schuld daran, dass er schlecht arbeitet. Es immer der Jeniger, der trotz seiner Inkompetenz dafür beauftragt. Und um agilen Verfahren ist es schlecht damit, solche schlechte oder inkompetent Arbeit das Zeug zu nehmen. Weil das angeblich nicht die Arbeit und Entscheiden von einem, sondern kollektive...
Senf D. schrieb: > Richtig. Ein schlechteres Beispiel hätte sich Maximilian Schellenberg > kaum heraussuchen können. Er scheint hinterm Mond zu leben. Richtig.. Aber wie vorher erwähnt wurde.. wohl hauptsächlich auf Managementfehler zurückzuführen. Normalerweise outsourct man generell "manuelle" repetitive, handwerkliche Tätigkeiten (nach F. Taylor bezeichnet); nicht höchst anspruchsvolle Tätigkeiten, wie Engineering wo man vor allem "explicit knowledge" (Nonaka, 2007; "Knowledge-Management" Anm.) auslagert, das leicht artikuliert, rekapituliert und dokumentiert werden kann. D.h. auf keinen Fall "tacit knowledge" und das auch noch in einem Hochsicherheitssektor mit Risiken bezgl. Menschenleben wie der Luftfahrt! Wobei ja anscheinend diese Probleme massgeblich waren: https://www.pmoadvisory.com/project-management-webinars/project-management-in-action-a-close-examination-of-the-boeing-737-max-8/ Herbert schrieb: > An irgend einer Stelle wird der damalige Chefentwickler Jahrzehnte > später interviewt. Er meint, es sei kaum zu verstehen, wie lange die > jetzigen Entwicklungen im Vergleich zu seinem Projekt damals bräuchten, > obwohl sie Computer für die Konstruktion hätten und sie damals nur > Zeichenbretter. > ( Kleines Bonmot: Beim finalen Test des Flugzeugs wird im Film gezeigt, > wie er seine Frau ans Ende der Startbahn stellt, um zu zeigen, dass er > an das Flugzeug glaubt und es vorher abhebt ... was für ein Frauenbild > damals ). Das hab ich mich auch schon oft gefragt; in der Apollo-Raumfahrt Zeit wie schafften sie es, mit damaligen historischen Computern, aber dafür grundlegenden und gründlichen Engineering-Wissen die Mondlandung derart hinzubekommen. Wahrscheinlich ist das auch das Problem: diese Programme waren früher noch in der Komplexität noch eher beherrschbar, heutzutage hat bei solchen Mammutprojekten ein einzelner Mensch schwierig alles zu überblicken. Manager die Kosten reduzieren und "Time-to-Market" Fähigkeit durch z.B. "agile Methoden" erhöhen wollen, haben in solchen Risikoprojekten sowieso nix verloren. Eine Ausnahme, was jetzt in letzter Zeit aber gut funktioniert hat sind ja anscheinend Musks SpaceX Raketen und die Landung der Perseverance. Bringt mich jetzt zu einer Frage: Wurden in diesen kritischen Projekten (bei NASA, SpaceX..) auch agile Methoden benutzt? Die Antwort auf die Frage: anscheinend Ja https://spacenews.com/pentagon-advisory-panel-dod-could-take-a-page-from-spacex-on-software-development/ https://www.federaltimes.com/it-networks/2019/11/26/how-nasa-upended-internal-processes-to-prepare-for-its-next-lunar-mission/ klausi
klausi schrieb: > Eine Ausnahme, was jetzt in letzter Zeit aber gut funktioniert hat sind > ja anscheinend Musks SpaceX Raketen und die Landung der Perseverance. Ich hab hab da irgendwie nur Fehlschläge und Explosionen im Kopf. Hab mich damit aber auch nicht tiefgreifend beschäftigt.
D.h. am Schluss liegt es wohl gar nicht an der Methodik an sich, aber an Managementfehlern, schlechter Ausbildung, mangelndem Fachwissen, fehlenden Standards etc. Ergo, wenn ein agiles Projekt gescheitert ist, muss nicht die agile Methodik/Scrum etc. schuld sein, sondern eher darüberliegende Managementfehler, schlechte Kultur, mangelndes Fachwissen. D.h. das Scheitern wäre dann bei Wasserfall-Methodik wohl genauso passiert. klausi
Hallo, MaWin schrieb: > Die Ursachenanalyse des 737Max Problems führte zu: > > Developers with insufficient aviation domain experience; > Poor oversight compared to that for hardware and overall aerodynamics; Bei Boeing liegen die Probleme aber noch viel tiefer als "nur" bei einer fehlerhaft programmierte Software: https://www.ardmediathek.de/ard/video/die-story/boeing-das-toedliche-system/wdr-fernsehen/Y3JpZDovL3dkci5kZS9CZWl0cmFnLTY4YjQ4OTdhLTg5ZDEtNGU2NC05M2FjLTk5ZWY3ZTVmNmFkMQ/ rhf
Beitrag #6610947 wurde von einem Moderator gelöscht.
klausi schrieb: > D.h. am Schluss liegt es wohl gar nicht an der Methodik an sich, aber an > Managementfehlern, schlechter Ausbildung, mangelndem Fachwissen, > fehlenden Standards etc. Was macht dich so sicher, dass die Methode, die Menschen-Ansprüche, Bedürfnisse usw. nicht berücksichtigt und trotzdem nicht falsch sein kann? Über Kommunismus sagt man auch, dass sie nicht falsch sein könnte, nur bei der Anwendung ist immer ein wenig unglücklich, aber wenn man das richtig angewendet wäre, dann wird alles klappen. Nein. Wird es nicht. Einiges in agile ist nicht schlecht. Aber dieses existierte bereits auch in anderen Methoden. Edison bei der Entwicklung und Verbesserung seinen Lampen gibt iterative und agil vor. Vor mehr als 100 Jahren...
Valeri D. schrieb: > Was macht dich so sicher, dass die Methode, die > Menschen-Ansprüche, Bedürfnisse usw. nicht > berücksichtigt und trotzdem nicht falsch sein kann? Der Gedanke, dass die verschiedenen Methoden auch verschiedene Bedürfnisse berücksichtigen bzw. nicht berücksichtigen, der ist Dir nie gekommen? Dachte ich mir. > Über Kommunismus sagt man auch, dass sie nicht falsch > sein könnte, nur bei der Anwendung ist immer ein wenig > unglücklich, Das ist ein guter Vergleich: Jeder Diktator, jedes Arschloch, das sich "Kommunist" nennt, ist natürlich auch ein Kommunist -- während jemand, der sich "Demokrat" nennt, GANZ GENAU auf seine Gesinnung geprüft wird. Das führt natürlich zu objektiven Erkenntnissen.
klausi schrieb: > Wahrscheinlich ist das auch das Problem: diese Programme waren früher > noch in der Komplexität noch eher beherrschbar, heutzutage hat bei > solchen Mammutprojekten ein einzelner Mensch schwierig alles zu > überblicken. Komisch eigentlich, dabei sind die Aufgaben nicht schwieriger geworden. Mal eine Rechnung schreiben, einen durchblätterbaren Katalog druckreif machen, mal Zahlen im Kontenrahmenplan updaten, mal den Lagerbestand korrigieren, die Vorsteuer oder Krankenkassenbeiträge abführen. Wir reden ja bei den meisten Softwareprojekten nicht von Tomographenbildern des Mondinneren oder sonstigem high tech, sondern primitiven Webseiten oder Buchungsvorgängen. Nur mit der fachlich ahnungslosen Schar der Kinderprogrammierer heute wird selbst so was zum Problem - siehe Ausdruck eines Warenkorbs von Pollin. Es wird sich nicht mehr um Wesentliches gekümmert, sondern kaputtprogrammiert. Siehe Datei-Suchfunktion in Windows "Sprint 53: programmiert mal was nach, was genau so cool aussieht wie bei Apple".
Was hat das ganze Geschwätz hier mit agiler Transformation, was immer das auch sein mag, zu tun ?
klausi schrieb: > D.h. am Schluss liegt es wohl gar nicht an der > Methodik an sich, aber an Managementfehlern, > schlechter Ausbildung, mangelndem Fachwissen, > fehlenden Standards etc. Das ist zwar nicht falsch, aber eigentlich eine Nullaussage. > Ergo, wenn ein agiles Projekt gescheitert ist, > muss nicht die agile Methodik/Scrum etc. schuld > sein, sondern eher darüberliegende Managementfehler, > schlechte Kultur, mangelndes Fachwissen. Kann sein. Aber... > D.h. das Scheitern wäre dann bei Wasserfall-Methodik > wohl genauso passiert. ...das muss nicht so sein, nein. Meiner Meinung nach liegt der Grundfehler nämlich darin, die verschiedenen "Methoden" als im Prinzip gleichwertig und gleichermaßen vollständig anzusehen. Das sind sie aber nicht. Nimm das "Wasserfallmodell". Winston W. Royce, der angebliche "Erfinder" des Wasserfall- modells (was nicht stimmt), adressiert in seinem Artikel "MANAGING THE DEVELOPEMENT OF LARGE SOFTWARE SYSTEMS" EINEN ganz spezifischen Aspekt der Software-Entwicklung und macht für diesen Lösungsvorschläge, und er tut dies vom Blickwinkel des Projektleiters aus. Er kümmert sich nicht darum, wie die Numeriker, Operatoren (das war 1970!) und Software-Entwickler im Tagesgeschäft zusammenarbeiten -- das setzt er als gegeben voraus. Er kümmert sich auch nicht um Vertragsfragen oder die Kosten des Projektes. Er behandelt EINEN EINZIGEN Aspekt des Projektes, nämlich ganz bestimmte Risiken, die bei der Implementierung auftreten (können). Ähnlich bei Scrum: Vorausgesetzt wird eine bestimmte (mehr oder weniger hypothetische) Ausgangslage, nämlich: * einen gutwilligen, sachkundigen Kunden, * Chefetagen (eigene wie die des Kunden), die die Leute in Ruhe arbeiten lassen, * einen zusammengewürfelten Haufen fähiger, aber nicht spezialisierter Entwickler. * eine komplexe Aufgabenstellung mit (möglicherweise) zahlreichen (noch unerkannten) Risiken. Vorgeschlagen werden einfache Regeln für die Zusammenarbeit und die täglichen Abläufe. Weiter nichts. Scrum kümmert sich nicht darum, wie das Management beim Auftragnehmer die Verträge mit dem Management des Auftrag- gebers aushandeln soll; Scrum hat auch keine Sicherung gegen böswilligen Kunden (auch dort kann es Grüppchen geben, die gegeneinander arbeiten und das Projekt zu Fall bringen wollen), Kostenfragen werden von Scrum nicht betrachtet, und ein Management, das dem Entwicklerteam ständig hineinredet, kann auch alles zerstören. Eine komplett andere Gewichtsklasse sind aber Vorgehens- modelle wie PRINCE2 oder das V-Modell XT. Das sind Rahmenwerke, die sich m.o.w. um Vollständigkeit bemühen und die deshalb auch viel umfangreicher sind. Vorteil: Universeller einsatzbar, weniger Ergänzung und Improvisation notwendig. Nachteil: VIEL umfangreicher, also gerade für kleine Firmen häufig nicht praktikabel. Es hängt also immer stark vom Einzelfall ab, wer wann warum mit welcher Methode scheitert.
Egon D. schrieb: > Meiner Meinung nach liegt der Grundfehler nämlich darin, > die verschiedenen "Methoden" als im Prinzip gleichwertig > und gleichermaßen vollständig anzusehen. > > Das sind sie aber nicht. > > Nimm das "Wasserfallmodell". > Winston W. Royce, der angebliche "Erfinder" des Wasserfall- > modells (was nicht stimmt), adressiert in seinem Artikel > "MANAGING THE DEVELOPEMENT OF LARGE SOFTWARE SYSTEMS" > EINEN ganz spezifischen Aspekt der Software-Entwicklung Wow. Sehr gut beschrieben. Danke sehr. Die Gedanken sind mind. ein Buch würdig.
MaWin schrieb: > klausi schrieb: >> Wahrscheinlich ist das auch das Problem: diese Programme >> waren früher noch in der Komplexität noch eher beherrschbar, >> heutzutage hat bei solchen Mammutprojekten ein einzelner >> Mensch schwierig alles zu überblicken. > > Komisch eigentlich, dabei sind die Aufgaben nicht schwieriger > geworden. Tatsächlich?! Eine Milliarde Menschen laufen neuerdings mit einer VAX... ach, was sage ich... einer Cray X-MP in der Hosentasche herum und erwarten, mit dieser am anderen Ende der Welt in drei Sekunden eine Jacht oder eine Tüte Reis bestellen zu können -- und Du erzählst mir, die Aufgaben seien nicht komplexer geworden? > Wir reden ja bei den meisten Softwareprojekten nicht > von Tomographenbildern des Mondinneren oder sonstigem > high tech, Ja eben! Wieviel tausend Mannjahre, wieviele hundert Millionen Dollar werden für Tomagraphiebilder des Mondes ausgegeben -- und wieviel ist ein durchschnittlicher Laden bereit, für seinen neuen Web-Shop zu zahlen? Aha.
Egon D. schrieb: > Eine Milliarde Menschen laufen neuerdings mit einer VAX... > ach, was sage ich... einer Cray X-MP in der Hosentasche > herum und erwarten, mit dieser am anderen Ende der Welt > in drei Sekunden eine Jacht oder eine Tüte Reis bestellen > zu können -- und Du erzählst mir, die Aufgaben seien nicht > komplexer geworden? Na, offenkundig einfacher. Programmiere mal die Firmware eines HP65 oder Sharp1210. DA muss man sich bemühen, es gibt keine fertigen Libraries, es sind reihenweise Kunstgriffe sind wegen der beschrankten Resourcen nötig und das Display darf man auch noch multiplexen, den Drucker ansteuern, und das alles in Maschinensprache statt Java. Heute hingegen auf so einer "Hosentaschencray" einen Taschenrechner zu programmieren, sorry, Kinderspiel, das macht ein 13-jähriger (der noch nicht weiss, dass double keine befriedigenden Ergebnisse liefert, macht nix, das Programm bleibt so wenn aus 1 / 3 x 3 eben 0.999999999 rauskommt, das ist ja Stand der Technik und man hat Monate, um zu verargumentieren, warum das nun so bleibt). Und es juckt keinen, wenn die Taschenrechner-App 10 MB gross ist, jedesmal wenn sie aus dem Speicher gekickt wird ihre Zahlen vergisst, und nach 10 Stunden (nicht 10 Jahren) die Batterie leer ist. Ja, es gibt heute schicke Apps, Kamera auf Verpackung richten und japanisch oder griechisch OCR mässig erfasst, in deutsch übersetzt, und ins Bild gepastet bekommen. Die sind möglich und schwierig, aber auch herausragend.
MaWin schrieb: > Siehe Datei-Suchfunktion in Windows "Sprint 53: > programmiert mal was nach, was genau so cool aussieht wie bei Apple". Vielleicht ist das Problem, dass genau so! Aufgabenbeschreibungen aussehen. Bei so einer "Spezifikation" kann halt auch nur Müll rauskommen
MaWin schrieb: > > Heute hingegen auf so einer "Hosentaschencray" einen Taschenrechner zu > programmieren, sorry, Kinderspiel, das macht ein 13-jähriger (der noch > nicht weiss, dass double keine befriedigenden Ergebnisse liefert, macht > nix, das Programm bleibt so wenn aus 1 / 3 x 3 eben 0.999999999 > rauskommt, das ist ja Stand der Technik und man hat Monate, um zu > verargumentieren, warum das nun so bleibt). > Um Monate zu ersparen, kann man sich z.B. auch dieser Seite informieren: https://0.30000000000000004.com/ Hat nicht mit dem Thema zu tun - nur so am Rande
MaWin schrieb: > Heute hingegen auf so einer "Hosentaschencray" einen Taschenrechner zu > programmieren Heute programmiert aber niemand mehr Taschenrechner sondern eben deutlich komplexeres als das. Sicherlich ist es (verglichen mit damals) einfacher den Taschenrechner zu programmieren, aber der lockt niemand mehr hinterm Ofen vor. Oder war dein Taschenrechner von damals in der Lage, 20 Anwendungen parallel auszuführen, in der Cloud zu sein, dabei zu telefonieren und noch deine Hausautomation zu steuern?
A. B. schrieb: > Oder war dein Taschenrechner von damals in der Lage, 20 Anwendungen > parallel auszuführen, in der Cloud zu sein, dabei zu telefonieren und > noch deine Hausautomation zu steuern? Wirklich viele Grundprinzipien, Algorithmen, patterns usw. haben sich nicht verändern. Der Mix wird anders gestaltet, einige Sachen sind einfacher, die anderen dafür schwieriger zu beherrschen. Jedoch insgesamt - vieles ist ähnlich. Findest du es nicht?
Beitrag #6611374 wurde von einem Moderator gelöscht.
Valeri D. schrieb: > Wirklich viele Grundprinzipien, Algorithmen, patterns usw. haben sich > nicht verändern. Der Mix wird anders gestaltet, einige Sachen sind > einfacher, die anderen dafür schwieriger zu beherrschen. Jedoch > insgesamt - vieles ist ähnlich. Findest du es nicht? Hatte man 1975 schon Design Patterns? Natürlich kann man sagen: damals hat jemand ein Programm entworfen & codiert...heute auch. Es hat sich also nicht viel geändert. Das es so einfach nicht ist wirst du wohl kaum bestreiten Wenn alles ähnlich ist, bräuchte man den agilen Kram ja nicht. Weiter oben wurde mir noch gesagt, den bräuchte es genau deshalb da man mit den alten Methoden der Probleme nicht mehr Herr wird. Hier wird ja so unbestritten immer so getan, als ob früher alles besser war und man "da noch was geschafft hat". War dem so? Oder ist das nicht eher Vergangenheitsverklärung alternder Herren?
Beitrag #6611444 wurde von einem Moderator gelöscht.
Beitrag #6611473 wurde von einem Moderator gelöscht.
Beitrag #6611478 wurde von einem Moderator gelöscht.
Beitrag #6611504 wurde von einem Moderator gelöscht.
A. B. schrieb: > Hier wird ja so unbestritten immer so getan, als ob früher alles besser > war und man "da noch was geschafft hat". War dem so? Oder ist das nicht > eher Vergangenheitsverklärung alternder Herren? Ich würde das genau anders beschreiben. Es ist der Wunsch von den heutigen "neuen Bestreitern", nicht auf die alt bewerten Methoden zu achten, sie verteufeln alles, was davor existierte - schon alleine mit solchen Aussagen, dass Wasserfahl vollkommen falsch ist. Nicht teilweise, sondern vollständig. Sie wollen keine Bücher von "gestern" lesen, wollen nicht auf die Erfahrung von gestern hören und wollen unbedingt das Rad neu erfinden. Klar, unter einem anderem Begriff. Um doch später festzustellen zu müssen, dass dies schon längst unter einem anderen Namen immer existierte. Es ist ähnlich dem Generationsproblem, bei dem die heranwachsende Kindern glauben, total anders zu sein als ihre Eltern. Und nach einer Phase doch genau da zu landen, wofür ihre Eltern sie immer vorbereiten wollten. Danach fangen an, ähnlich zu ticken und zu denken. Die altruistische oder idealistische Vorstellungen treten in den Hintergrund und werden Werte geschätzt wie materiale Sicherheit, Profitieren durch Erfahrung. Sie gehen danach normal mit den Unterschieden zwischen dem Streben bzw. Arbeiten und dem Durchschnitt um usw. Ein anderes Beispiel. Wie lange existieren solche Programmiersprachen wie Assembler, C, C++? Schon lange. In dieser Zeit entstanden 1000-e neue Programmiersprachen. Mit großen Ansagen. Und doch wird nach wie vor C und C++ weiter verwendet. Haben sie bestimmte Nachteile? Logisch. Aber auch Vorteile. Und wenn man sich nur auf die Nachteile dieser Sprachen konzentriert und auf die Idee kommt, eine neue Sprache zu erfinden, kann es mit großen Wahrscheinlichkeit passieren, dass C bzw. C++ weiter lebt und bleibt und die neu erfundene Sprache bald verschwindet. So ist es auch mit vielen Methoden in der Software-Entwicklung. Es gibt so viele, und immer wieder kommen neue, wie Wasserfallmodell, Spiral-Modell, Extreme Programming, Planning Game, Agile Methoden und darin Scrum, Kanban, SAFE, Hybride, Pair Programming usw. Alle haben was. Auf jeden Fall. Jedoch hat jede neue Sache die Anderen nicht ersetzen können. Weil das utopisch von vorne war, daran zu glauben. Deswegen muss man einfach pragmatisch sein und nicht zulassen, dass dein Unternehmen einem aktuellen Trend so hinterher rennt, dass das eigentliche Business Ziel aus den Augen verloren geht.
A. B. schrieb: > Weiter oben wurde mir noch gesagt, den bräuchte > es genau deshalb da man mit den alten Methoden > der Probleme nicht mehr Herr wird. Ja. > Hier wird ja so unbestritten immer so getan, als > ob früher alles besser war und man "da noch was > geschafft hat". War dem so? Zum Teil. Entwicklungsarbeit war typisch "Von Fachleuten für Fachleute". Heute herrscht Goldgräberstimmung: Wer irgend einen Schotter programmiert, für den hundert Millionen Nutzer jede Woche 10 Cent bezahlen, der ist in wenigen Jahren Milliardär. Wer aber nur hundert oder tausend Nutzer hat, kämpft ums Überleben -- die Preise, die er verlangen müsste, will niemand bezahlen. > Oder ist das nicht eher Vergangenheitsverklärung > alternder Herren? Nur zum Teil. Früher sind auch reichlich Projekte gescheitert -- aber das mussten die Manager und die Anwälte dann unter sich ausmachen. Heute wird der Druck einfach an die Entwickler nach unten durchgereicht.
Valeri D. schrieb: > Sie wollen keine Bücher von "gestern" > lesen, wollen nicht auf die Erfahrung von gestern hören und wollen > unbedingt das Rad neu erfinden. Na, ich weiß ned so recht ob es auch bei Operationen gut ist das Rad immer wieder neu zu erfinden und alle über die Jahrhunderte gesammelten Erfahrungen zu ignorieren anstatt auf bewährte Methoden zurückzufallen und diese dem Fortschritt anzupassen. Jedenfalls wären mir altbewährte Operationspraktiken bei meiner Blinddarmoperation lieber wie wilde Experimentation. Warum sollte man nicht auch in der Elektronikentwicklung ähnlich denken? Was gut funktioniert soll nan pflegen und der jeweiligen Zeitepoche anpassen und neue Gedanken müssen sich erst bewähren bevor man sie in die Werkzeugkiste knallt. Nur, von wild darauf herum experimentieren, halte ich weniger. Am weitesten kommt jan mit zweigleisiger Strategie wo Neues und Altes sinnvoll das Grundgerüst darstellt. Auch hätte es mehr Sinn neue Methoden ständig sorgfältig auf ihren Wert und Nutzen zu überwachen bevor man den Müllwagen holt. Die neuen Methoden um die es hier geht darf man halt auch nicht ohne Verstand einsetzen und müssen auf die jeweiligen Verhältnisse fein abgestimmt werden. Von Industrieberatern halte ich gar nichts und werden oft von der GL als Krücke mißbraucht um dunkle Ziele zu verfolgen. Naja, mir kann es gleich sein was heutzutage verzapft wird und brauche nicht irgendwelche Luftschlösser zu verfolgen. Jedem Tierchen halt sein Pläsierchen. Wenn mit Gewalt, voller Ignoranz und naiven Wunschdenken Bewährtes mutwillig aus egoistischen Gründen zerstört muß man eben die Folgen tragen. Andere Länder gaben das längst richtig erkannt und hüten sich die Fehler die bei uns gemacht werden nachzumachen. Die Schlimmsten sind geheuerte Industrie- und Wirtschaftsberater, also angeworbene Revolverhelden. Wir leben in einem verrückten Zeitalter. Teils werden wirklich brauchbare neue Entwicklungen und Produkte gemacht. Teils wird absolut unnützes Zeugs verbreitet. Man verschwendet Millionen Mannstunden an Produktentwicklung die niemand wirklich braucht und müllt den Planeten zu und verschwendet Ressourcen. Autos werden zu wahren Götzen. Wenn man sich einige der Spitzenklassenmodelle ansieht muß man sich wundern ob man das alles braucht. Ich wette, daß in einen zeitgemässen Mercedes oder BMW mehr Software eingebaut ist als in der Space Shuttle oder vielleicht auch manche Verkehrsflugzeuge. Auch ein alter Porsche der 60er kann noch pures Fahrvergnügen vermitteln. Manchmal frage ich mich ob diese Art der Entwicklung wirklich Nutzen bringt. Apollo wurde mit notwendiger Software und Ingenieurwissen durchgezogen. Viele Entwicklungen der Gegenwart sind lediglich noch überambitionierte feuchte Träume. Aus der Sicht junger, ehrgeiziger Menschen, sind wir Alten vielleicht vertrottelt und Schnee von Gestern. Andrerseits wissen Viele Alten sehr wohl wie der Hase wirklich läuft. Was mich betrifft konnte ich als Junger von den Alten im Labor viel lernen und in meiner eigenen Arbeit verarbeiten. Jung und Alt muß ohne Vorurteile zusammenarbeiten können. Dann können ungeahnte Synergien zustandekommen. Nur wissen die Jungen es erst dann wenn bei ihnen der Bart grau wird, der Bauch wächst und die Haare ausfallen;-)
Zunächst einmal sollte man sich fragen, wer Prozesse und Geschäftsmethoden einführt und welche Intention dahinter ist. Der Auslöser für die Einführung neuer Prozesse kommt immer aus dem Management und als Entwickler muss man die Denkweise des Managements verstehen. Dort stellt sich die Sache ganz einfach dar: Man entschließt sich, ein neues Produkt zu machen und überlegt sich, was man dafür braucht. Als stellt man einen Produktingenieur ein, der den Markt analysiert und die Gewinnchancen berechnet. Danach gibt man das Produkt in die Entwicklung und die erzeugt die Dokumente für die Produktion. Damit das ganze reibungslos funktioniert braucht man einen Plan und für diesen Plan einen Prozess. Am besten nimmt man dort das V-Modell. Mit dem kann man einfach sehen, was nacheinander kommt und den Zeitaufwand und die Entwicklungskosten planen. Damit das gut klappt, brauch man einen Entwickler, der die Arbeitspakte im V-Modell genauer ausformuliert. Wenn das passiert ist, kann man für die Detailentwicklungen noch ein paar externe Ingenieure anstellen und für das Testing ein paar Inder von Tata. Wenn ich mir das so überlege, ist Produktentwicklung doch eine recht einfache und banale Sache. Man kann letztendlich sagen, dass der Erfolg einer Firma im wesentlichen im Know-How des passenden Prozesses liegt, mit dem sich Kosten und Dauer eines Projekts gut vorhersehen lassen.
Herbert schrieb: > dass der Erfolg einer Firma im wesentlichen im Know-How des passenden > Prozesses liegt, mit dem sich Kosten und Dauer eines Projekts gut > vorhersehen lassen. Ohne fähige Entwickler und Produktionsplaner kann der Prozess noch so gut sein, es wird scheitern. Umgekehrt gibt es so extrem gute Leute, die aufgrund ihrer Erfahrung und Intelligenz ein Projekt selbst ohne Prozess durchziehen können. Klar, diese Leute wären mit einem guten Prozess schneller, aber um so einen Prozess erstellen zu können braucht es erst extrem gute Leute, die zudem einen Überblick über alle relevanten Bereiche haben. In der Realität gibt es so jemanden nur extrem selten, weswegen die Prozesse oft nicht gut sind. Viele sagen dir beim Assessment auch nur was falsch ist, aber nicht wie man es besser machen könnte, weil sie es selbst nicht wissen.
A. B. schrieb: > Irgend W. schrieb: >> Die Agile-Sau wird derzeit durch alles getrieben was man irgendwie >> entwickeln kann. > > Allein das du schreibst "derzeit" lässt mich deine Äußerungen schon > etwas skeptisch betrachten. > Die agile Sau wird schon so dermaßen lange getrieben, dass sie fast > schon tot ist. Unter welchem Stein lebst du? Es währe schön wenn du recht hättest. Nur leider sieht der Alltag eher so aus das gerade in größeren Firmen diese hype derzeit erst so richtig angekommen ist und die zugehörigen "Umorganisationen" noch voll im Gange sind und noch lange nicht abgeschlossen sind. Und das schlimmste daran ist das in den Bereich die schon seit gut einem Jahr versuchen so zu Arbeiten es an allen Ecken und Enden knirscht, aber dennoch immer weitere Abteilungen "transformiert" werden.
Valeri D. schrieb: > So ist es auch mit vielen Methoden in der Software-Entwicklung. Es gibt > so viele, und immer wieder kommen neue, wie Wasserfallmodell, > Spiral-Modell, Extreme Programming, Planning Game, Agile Methoden und > darin Scrum, Kanban, SAFE, Hybride, Pair Programming usw. Alle haben > was. Auf jeden Fall. Jedoch hat jede neue Sache die Anderen nicht > ersetzen können. Weil das utopisch von vorne war, daran zu glauben. > > Deswegen muss man einfach pragmatisch sein und nicht zulassen, dass dein > Unternehmen einem aktuellen Trend so hinterher rennt, dass das > eigentliche Business Ziel aus den Augen verloren geht. Zustimmung. Nur in den Führungsbunkern herrscht leider immer noch die Meinung vor das es zu einer Zeit immer nur eine Methode geben darf - weil diese ja "Die beste der Welt" ist - und keine andere nebenher geduldet werden und das für alle Gruppen egal was sie genau machen. Die Einsicht das es keinen Sinn macht immer alles über einen Kamm scheren zu wollen und es durchaus sinnvoll sein könnte für verschiedene Gruppe die zu ihren Aufgaben passende Methoden(-mischung) anzuwenden, werde ich wohl nicht mehr mitbekommen...
Beitrag #6611726 wurde von einem Moderator gelöscht.
Herbert schrieb: > Der Auslöser für die Einführung neuer Prozesse kommt > immer aus dem Management ... und Behauptungen sind um so wahrer, je absoluter und dogmatischer sie formuliert werden. Ist das nicht toll, dass die Welt so einfach ist? > Am besten nimmt man dort das V-Modell. Mit dem kann > man einfach sehen, was nacheinander kommt und den > Zeitaufwand und die Entwicklungskosten planen. Genau. Leute, die etwas von "Entwicklungsrisiken" faseln, werden beim zweiten Mal wegen Wehrkraftzersetzung erschossen. Die Idioten, die regelmäßig die Arbeitspakete "Hellseher-Modul" und "perpetuum mobile" versemmeln, werden mit freundlichen Grüßen zu Wladimir P. geschickt, damit er die Nullen in seinem Gulag verschimmeln lässt. So geht Management! > Wenn ich mir das so überlege, ist Produktentwicklung > doch eine recht einfache und banale Sache. Genau. Alles nur "Dilettanten. Versager! Lausige Amateure!!" (Egon Olsen).
Egon D. schrieb: > Alles nur "Dilettanten. Versager! Lausige Amateure!!" > (Egon Olsen). Es wäre ja schonmal etwas, wenn jemand sagen würde "Ich habe einen Plan!" :)
Irgend W. schrieb: > Nur in den Führungsbunkern herrscht leider immer > noch die Meinung vor das es zu einer Zeit immer > nur eine Methode geben darf - weil diese ja "Die > beste der Welt" ist - und keine andere nebenher > geduldet werden und das für alle Gruppen egal was > sie genau machen. > Die Einsicht das es keinen Sinn macht immer alles > über einen Kamm scheren zu wollen und es durchaus > sinnvoll sein könnte für verschiedene Gruppe die > zu ihren Aufgaben passende Methoden(-mischung) > anzuwenden, werde ich wohl nicht mehr mitbekommen... Mich würde mal interessieren, wer diese idiotische Welle ins Rollen gebracht hat. Ich meine... es ist ja schon eine reife Leistung, einen Regelsatz, der für das Tagesgeschäft der Indianer beim Kampf mit einem komplexen Entwicklungsproblem gedacht war, zu einer universellen Management-Methode für die Häuptlinge umzudefinieren.
Hallo, Irgend W. schrieb: > Nur leider sieht der Alltag eher so aus das gerade in größeren Firmen > diese hype derzeit erst so richtig angekommen ist und die zugehörigen > "Umorganisationen" noch voll im Gange sind und noch lange nicht > abgeschlossen sind. Nur mal so aus Interesse: ist diese agile Konzept eigentlich nur für die Produktentwicklung und Fertigung gedacht oder kann man es auch z.B. auf das Management oder die Betriebswirtschaft anwenden? Und wird das eventuell auch irgendwo gemacht? rhf
Roland F. schrieb: > Nur mal so aus Interesse: ist diese agile Konzept > eigentlich nur für die Produktentwicklung Ja. > und Fertigung gedacht Nein. Agile Vorgehensweisen waren meines Wissens ursprünglich NUR für 1. innovative 2. Entwicklung in Form von 3. Entwicklungs- PROJEKTEN gedacht. Kernideen sind: 1) Es wird nicht nur "heimlich" intern, sondern ganz offen iterativ gearbeitet. Das bedeutet u.a., den Auftraggeber in die iterative Arbeitsweise einzubeziehen. 2) Viele Details der Problemlösung wie auch der Arbeits- organisation werden auf Wunsch dem Projektteam überlassen. Es ist nicht notwendig, dass ein "allwissender Planer" jedem Entwickler haarklein vorschreibt, was er zu tun hat. Das können die Entwickler in vielen Fällen viel einfacher unter sich ausmachen. 3) Das Management muss nur absichern, dass das Team vernünftig arbeiten kann, und wird ansonsten nur aktiv, wenn Kollisionen innerhalb des Teams auftreten oder wenn notwendige Arbeiten aus irgendwelchen Gründen unterbleiben. > oder kann man es auch z.B. auf das Management oder die > Betriebswirtschaft anwenden? Meiner unmaßgeblichen Meinung nach setzen agile Methoden unausgesprochen den Willen zur Kooperation innerhalb des Teams voraus. Das trifft -- ebenfalls meiner Erfahrung nach -- auf die Entwickler innerhalb eines nicht zu großen Teams zu. Agile Methoden sind Regeln für die "Indianer", ihre Zusammenarbeit so zu organisieren, dass sie eine Lösung für das Problem finden und umsetzen können. Soll heißen: Man kann meiner Meinung nach agile Methoden NICHT sinnvoll auf das klassische Management oder auf die Betriebswirtschaft anwenden -- aber das hindert offenbar niemanden daran, es dennoch zu tun.
Egon D. schrieb: > ..aber das hindert offenbar niemanden daran, es dennoch zu tun. Wie du Recht hast! Noch schlimmer, wenn du nicht "mitgehst" bzw. denen im Weg stehst - das kann sehr böse für dich enden. Denn. Willst du etwa nicht eine Innovation, eine Transparenz usw.?
Maximilian Schellenberg schrieb: > Na, ich weiß ned so recht ob es auch bei Operationen gut ist das Rad > immer wieder neu zu erfinden und alle über die Jahrhunderte gesammelten > Erfahrungen zu ignorieren anstatt auf bewährte Methoden zurückzufallen > und diese dem Fortschritt anzupassen. Jedenfalls wären mir altbewährte > Operationspraktiken bei meiner Blinddarmoperation lieber wie wilde > Experimentation. sorry, aber so ein Blödsinn. Vielleicht wäre ja schonmal ein guter Anfang, wenn jeder Einsieht, das er kein allwissender Experte ist und man sich eher zu Dingen äußert, von denen man etwas versteht. Und selbst da kommt ja oft genug Grütze bei raus. Über Jahrhunderte gesammelte Erfahrung bei Blinddarmoperationen. Ja ist klar. Dann lass du dich bitte mit der 1900er Schlachthaus Variante "operieren" während der Rest in Deutschland minimalinvasiv operiert wird. Ich weiß noch, wie wir zu Geburtszeiten meine Kindes die (gutgemeinten) Tips unserer Mütter bekommen haben, die ihr Wissen von unseren Geburten von vor 30++ Jahren preisgegeben haben. Da hat sich so dermaßen viel getan(btw: in allen Bereichen der Medizin). Da könnte man ja auch sagen: geboren wurde auch 2000 v Christus schon. Bewährt hat es sich auch über Jahrhunderte. Warum irgendwas dran ändern?
Agile Methoden funktionieren ganz gut, wenn dafür verkrustete Entscheidungshierachien zerschlagen und alle Entscheidungsbefugnisse ins Projektteam übertragen werden. Das passiert aber eher selten bzw. nie: Man lässt die Leute agile herumkaspern und behält sich weiterhin vor "von oben" reinzugrätschen.
Obstler schrieb: > Agile Methoden funktionieren ganz gut, wenn dafür verkrustete > Entscheidungshierachien zerschlagen und alle Entscheidungsbefugnisse ins > Projektteam übertragen werden. Das passiert aber eher selten bzw. nie: > Man lässt die Leute agile herumkaspern und behält sich weiterhin vor > "von oben" reinzugrätschen. ich finde deine Aussage ein wenig widersprüchlich. Denn, wenn in dem ersten Teil des Satzes steht - es funktioniert gut, und im zweiten steht - etwas dafür Notwendiges passiert deiner Meinung selten bzw. fast nie. Dann ist die erste Aussage kein Fakt, sondern mehr Wunsch. Oder?
A. B. schrieb: > Naja, aber wenn es passiert, daaaaaann lüppt es Das kennen wir schon vom Sozialismus, der hätte auch super funktioniert, wenn die Menschen nicht gewesen wären
Valeri D. schrieb: > Obstler schrieb: > >> Agile Methoden funktionieren ganz gut, wenn dafür verkrustete >> Entscheidungshierachien zerschlagen und alle Entscheidungsbefugnisse ins >> Projektteam übertragen werden. Das passiert aber eher selten bzw. nie: >> Man lässt die Leute agile herumkaspern und behält sich weiterhin vor >> "von oben" reinzugrätschen. > > ich finde deine Aussage ein wenig widersprüchlich. Denn, wenn in dem > ersten Teil des Satzes steht - es funktioniert gut, und im zweiten steht > - etwas dafür Notwendiges passiert deiner Meinung selten bzw. fast nie. Es gibt glücklicherweise genug Gelegenheiten die Vorzüge agiler Methoden außerhalb der Zwänge eines Angestelltendaseins zu erproben. Hat man das ein paar mal gemacht fallen die Missstände anderswo sofort auf.
Obstler schrieb: > verkrustete Entscheidungshierachien Bewerber und Mitarbeiter wollen im Unternehmen "Karriere machen", und das bedeutet eben auch nach jeweils erreichter Ebene gestaltete fachliche und ggf. personelle Entscheidungsbefugnisse. Es widerspricht sich eben, gleichzeitig Karrierestufen und gleichberechtigtes Handeln umzusetzen. Je größer das Unternehmen bzw. die Organisation, desto mehr Stufen hat die Karriereleiter, und um so schwieriger wird es dort, sein kleines Revier oder Königreich zu verteidigen. Wirtschaftliche Unternehmensziele und der Projekterfolg kommen in solch einer Denkweise nicht vor. Wenn es im eigenen Projekt nicht gut läuft, muss man eben dafür sorgen, dass andere Projekte noch schlechter laufen, damit man auf der Karriereleiter nicht überholt wird. Und wenn das Unternehmen dabei pleite geht, ist das auch egal. Solche hirarchischen Strukturen sind aber genau das, wonach sich viele Leute sehnen. Die einen wollen schnell aufsteigen, die anderen sich lieber ein ruhiges Plätzchen suchen und dafür lieber auf "die da oben" schimpfen. Agile Strukturen funktionieren nur im kleinen Maßstab und im überschaubaren zeitlichen Rahmen. Irgendwann werden sie zwangsweise von den verkrusteten Entscheidungshierachien geschluckt.
Andreas S. schrieb: > ... Wenn es im eigenen Projekt nicht gut läuft, muss man eben > dafür sorgen, dass andere Projekte noch schlechter laufen, damit man auf der Karriereleiter nicht überholt wird. Und wenn das Unternehmen dabei pleite geht, ist das auch egal. Ich glaube verstanden zu haben, was du meinst, trotzdem so zu denken oder zu argumentieren - finde ich irgendwie nicht gesund. Wenn ich mir selber kein Auto leisten kann, dann zerkratze ich die Autos von den Nachbarn. Ich hatte mal so einen vor vielen Jahren in der Firma erlebt. Er war stolz drauf zu zeigen, viele Mercedes-Benz-Sterne hat er demoliert. Nicht gesund....
Andreas S. schrieb: > Agile Strukturen funktionieren nur im kleinen Maßstab > und im überschaubaren zeitlichen Rahmen. Deswegen verwenden vernünftige Leute agile Methoden in Entwicklungs- Projekten . (Projekt: "Eine für einen befristeten Zeitraum geschaffene Organisation..." [PRINCE2]) "Agile Buchhaltung" oder "agile Massenproduktion" sind Schwachsinn, selbst "agile Instandhaltung" würde ich als Blödsinn einstufen.
Valeri D. schrieb: > Ich glaube verstanden zu haben, was du meinst, trotzdem so zu denken > oder zu argumentieren - finde ich irgendwie nicht gesund. Ich befürworte das beschriebene Verhalten ja nicht, erlebe es aber in den verschiedensten Kontexten immer wieder. Gerade solche satten und dekadenten Gesellschaften wie in Deutschland sind dafür auch prädestiniert. > Wenn ich mir > selber kein Auto leisten kann, dann zerkratze ich die Autos von den > Nachbarn. Das ist noch einmal etwas anderes. Dabei geht es um den bloßen Neid, aber nicht darum, persönliche Nachteile zu erleiden, wenn man sich nicht so verhält. Der Übergang zwischen den Verhaltensweisen mag teilweise fließend sein. Wer jedoch z.B. den Titel "Produktmanager des Jahres" hat, muss ihn aktiv verteidigen. Und wer selbst "Produktmanager des Jahres" werden will, muss den derzeitigen Titelinhaber aktiv verdrängen. Und dafür sind alle Mittel recht. Meist reicht es nicht, hierfür selbst gute Arbeit zu leisten, denn die wird ja wiederum von Dritten torpediert, sondern wesentlich erfolgversprechender ist es, andere zur sabotieren.
Meine Meinung nach, wird und wurde zum Thema Management von Software-Entwicklung schon viel geschrieben, aber wenig gesagt. Im Grunde hat schon Dr. Winston Royce in seinem Paper "Managing the devleopment of large software systems" erkannt, dass Softwareenwicklung nur iterativ passieren kann und es besser ist, wenn man davon ausgeht, dass man in jedem Entwicklungsschritt Fehler machen kann und wird, jedoch entsprechende Vorkehrungen trifft, diese Fehler frühzeitig zu erkennen und sie zu beheben. Für mich übrigens auch interessant, dass Royce bereits davon spricht, den Kunden möglichst früh mit der gemachten Arbeit konfrontiert (auch wenn es noch frühe Arbeit z.B. der Analyse ist). Das ist ja auch einer der Eckpfeiler der agilen Methoden. Die Erkenntnis, das man in jedem Schritt Fehler machen kann, die sich auf die nächsten Schritte auswirkt, muss man meiner Meinung durch verschiedene Maßnahmen abfangen: 1) Dokumentation! Requirements, Designentscheidungen, Architekturen usw. müssen dokumentiert werden. Ob dies in Form von formellen Dokumenten oder Akzeptanzkriterien/User Storys passiert, ist egal. Was zählt, ist der Inhalt. Nur die Dokumentation ermöglicht es mir, überhaupt Fehler zu erkennen. 2) "Agile"/Iterative Entwicklungsschritte, bei denen es eine kurze Abfolge der Schritte Analyse/Design/Implementation/Testing gibt. 3) Testing! Was entwickelt wurde, muss getestet werden. Ausnahmslos (speziell Unit Tests sind ja ein Grundpfeiler der agilen Methoden) 4) Kunden (oder was auch immer als Kunde definiert werden kann) frühzeitig einbinden. Das kann z.b. auch sein, dass man frühzeitig berechnete Werte wieder an eine Fachabteilung schickt, welche diese gegencheckt. Diese 4 Maßnahmen finden sich meiner Meinung nach in jedem Entwicklungsprozess. Egal ob V-Modell oder Scrum.
A. B. schrieb: > Über Jahrhunderte gesammelte Erfahrung bei Blinddarmoperationen. Ja ist > klar. Dann lass du dich bitte mit der 1900er Schlachthaus Variante > "operieren" während der Rest in Deutschland minimalinvasiv operiert > wird. Wollte damit nur andeuten, daß ein Unterschied zwischen wilder Experimentation und zielstrebiger Weiterentwicklung bestehender Methoden besteht. Natürlich hat man in der Medizin ungeahnte Fortschritte gemacht. Aber darum geht es nicht. Aber Manchmal ist es halt bequemer andere vielleicht vorsätzlich zu mißverstehen. Ich habe nichts gegen intelligent betriebenem Fortschritt. Habe nur etwas gegen Besserwisser und Störenfriede, die glauben, sie wüssten alles besser und es ist ihr Recht anderen ungestraft in ihre Kreise zu treten. Wer Prozesse und Methoden ändern will muß vergleichen und messen, sonst ist es doch noch nur wilde Experimentierei.
H. K. schrieb: > Für mich übrigens auch interessant, dass Royce bereits davon spricht, > den Kunden möglichst früh mit der gemachten Arbeit konfrontiert (auch > wenn es noch frühe Arbeit z.B. der Analyse ist). Das ist ja auch einer > der Eckpfeiler der agilen Methoden. Es hängt sehr davon ab, was aus Sicht der Entwickler bzw. der dahinter stehenden Organisation das verfolgte Ziel ist. Man sollte nicht so naiv sein, zu glauben, dass es immer um die zügige und hochwertige Realisierung eines erfolgreichen Produktes geht. Gerade bei großen Ausschreibungen der öffentlichen Hand geht es häufig darum, die Kosten in die Höhe zu treiben. Mir sind mehrere Projekte bekannt, in denen der Auftraggeber auf keinen Fall erfahren sollte, dass er in seine Spezifikation schwerwiegende Fehler geschrieben hat. Dann wird eben ggf. jahrelang entwickelt, und zum Schluss heißt es: "In Eurer Spezifikation sind die und die Fehler drin. Wir haben, so wie gefordert, natürlich strikt nach Spezifikation gearbeitet. Die Korrektur der Fehler kostet dann zusätzlich xxx Mio. Euro. Und Ihr dürft auch keinen Dritten mit der Überarbeitung beauftragen, siehe §53 des Vertrages." An einem der o.a. Projekte arbeiteten mehrere Bekannte, die natürlich vor einem großem Dilemma standen, da durch einen der längst bekannten Fehler eine erhebliche Gefährdung von Menschenleben verursacht wurde. Da deren Arbeitgeber nicht der Hauptauftragnehmer des Auftraggebers war, sondern von einem konkurrierenden Unternehmen unsauber ausgebootet wurde, sollte das ganze zusätzlich als Retourkutsche dienen. Mir ist nicht bekannt, ob dann bei der Inbetriebnahme der tatsächlich Menschen verletzt oder getötet wurden. Agile Methoden, bei denen der Kunde frühzeitig einbezogen wird, verunmöglichen natürlich auch das jahrelange Verschweigen solcher Mängel. > 1) Dokumentation! Requirements, Designentscheidungen, Architekturen usw. > müssen dokumentiert werden. Ob dies in Form von formellen Dokumenten > oder Akzeptanzkriterien/User Storys passiert, ist egal. Was zählt, ist > der Inhalt. Nur die Dokumentation ermöglicht es mir, überhaupt Fehler zu > erkennen. Was aber dabei häufig vergessen wird: Die Dokumentation muss natürlich der tatsächlichen Umsetzung entsprechen. Und auch die verschiedenen Detaillierungsgrade von Anforderungen und Architekturen sollten zueinander konsistent sein. > 2) "Agile"/Iterative Entwicklungsschritte, bei denen es eine kurze > Abfolge der Schritte Analyse/Design/Implementation/Testing gibt. Grundsätzlich stimme ich da zu, aber auch in einem Projekt kann es Teilaufgaben mit sehr unterschiedlichem Zeitbedarf geben, die sich auch nicht weiter herunterbrechen lassen, um in ein festes Zeitraster mit Sprints hineinzupassen. > 3) Testing! Was entwickelt wurde, muss getestet werden. Ausnahmslos > (speziell Unit Tests sind ja ein Grundpfeiler der agilen Methoden) Das stimme ich voll zu. Ich muss auch bei etlichen meiner Kunden immer wieder darauf hinweisen, dass es nicht ausreicht, die Funktionalität irgendwie zu umreißen, sondern dass wir auch entsprechende Prüfkriterien oder gar Abnahmekriterien benötigen. Oft läuft es sogar darauf hinaus, dass ich diese Prüfkriterien dann sogar selbst verfasse, obwohl dies eigentlich eine Kundenaufgabe wäre. Natürlich erfolgt das gegen Bezahlung. Vor einiger Zeit staunte ein Kunde nicht schlecht, weil das Formulieren und Entwickeln der Tests rund doppelt so teuer war wie die eigentliche Produktentwicklung. > 4) Kunden (oder was auch immer als Kunde definiert werden kann) > frühzeitig einbinden. Das kann z.b. auch sein, dass man frühzeitig > berechnete Werte wieder an eine Fachabteilung schickt, welche diese > gegencheckt. Wenn das gemeinsame Projektziel darin bestehen sollte, ein gutes Produkt zügig zu realisieren, stimme ich da voll zu. Ansonsten siehe oben.
> Kernideen sind: > 1) Es wird nicht nur "heimlich" intern, sondern ganz offen iterativ gearbeitet. Das bedeutet u.a., den Auftraggeber in die iterative Arbeitsweise einzubeziehen. > 2) Viele Details der Problemlösung wie auch der Arbeits- organisation werden auf Wunsch dem Projektteam überlassen. Es ist nicht notwendig, dass ein "allwissender Planer" jedem Entwickler haarklein vorschreibt, was er zu tun hat. Das können die Entwickler in vielen Fällen viel einfacher unter sich ausmachen. > 3) Das Management muss nur absichern, dass das Team vernünftig arbeiten kann, und wird ansonsten nur aktiv, wenn Kollisionen innerhalb des Teams auftreten oder wenn notwendige Arbeiten aus irgendwelchen Gründen unterbleiben. Danke, gut erklärt. Das klingt für mich absolut plausibel. Und warum wird daraus mit viel Bohei eine komplette Wissenschaft gemacht?
Bürovorsteher schrieb: > warum wird daraus mit viel Bohei eine komplette Wissenschaft gemacht? Na ja, was heisst iteratives Arbeiten ? Probieren. Und warum macht man das ? Weil man keine Ahnung hat, wie man es richtig machen soll. Und wie versteckt man, dass man ahnungslos ist ? In dem man es als den geilen Scheiss verkauft. Wenn man hingegen Erfahrung hat "schon 10 Mal eine Onlineshoppingseite gebaut mit demselben Toolkit" dann kann man den Auftraggeber auch gleich alles Wichtige fragen und einen Preis nennen weil man den Aufwand kennt inklusive Fertigstellungstermin. Aber die Informatiker haben halt (im Gegensatz zum Handwerksmeister in seinem Gewerk) in überwältigender Mehrzahl keine dazu ausreichende Erfahrung. Schon ihr letztes Projekt ist gescheitert weil der Elefant nur eine Maus gebar.
Maximilian Schellenberg schrieb: > daß ein Unterschied zwischen wilder > Experimentation und zielstrebiger Weiterentwicklung bestehender Methoden > besteht Also eigentlich behauptet jedes neue Framework und jede neue Methode konkrete Probleme lösen zu können, die mit anderen(alten) Mitteln so nicht möglich waren. Wie gut das funktioniert ist dann halt immer Ansichtssache
Beitrag #6614241 wurde von einem Moderator gelöscht.
Beitrag #6614381 wurde von einem Moderator gelöscht.
Wir kündigen! schrieb im Beitrag #6614381: > Scrum ist für Jungdeppen die denken das wäre modern und was > tolles. Die suchen sich gezielt die Firmen danach aus die so arbeiten. Gibt es denn überhaupt noch Unternehmen, die in der Entwicklung anders arbeiten?
Bürovorsteher schrieb: > Danke, gut erklärt. Das klingt für mich absolut > plausibel. Danke für die Blumen. > Und warum wird daraus mit viel Bohei eine komplette > Wissenschaft gemacht? Keine Ahnung. Ich selbst bin mental eigentlich eher "Wasserfall"/"Top- down"-geprägt, aber das hat für mich nie so funktioniert, wie das im Lehrbuch behauptet wurde. Als Retter in der Not hat sich dann immer mal wieder diese oder jene agile Methode erwiesen, die mir von anderen, die damit schon gute Erfahrungen gemacht hatten, persönlich vorgeschlagen wurde. Naja, und einige Jahre unter einem entscheidungsstarken, aber planlosen Chef haben dann die Erkenntnis gebracht, dass man (gerade in heterogenen Teams) sehr wohl viele Dinge der Selbstorganisation des Teams überlassen kann und sollte -- dass es aber genauso auch übergreifende Fragen gibt, die zentral von einem sachkundigen Management entschieden werden müssen. Insofern: Nein, ich habe nicht die geringste Ahnung, wer im Moment warum welche Sau durch's Dorf treibt. Ich versuche nur, eine Vorgehensweise zu finden, die für mich gut funktioniert.
MaWin schrieb: > Bürovorsteher schrieb: >> warum wird daraus mit viel Bohei eine komplette >> Wissenschaft gemacht? > > Na ja, was heisst iteratives Arbeiten ? > > Probieren. Nicht nur. Bei mir heisst es: 1. Vorausdenken und eine Frage formulieren 2. Probieren 3. die gemachten Erfahrungen auswerten Ein Schelm, wer Arges dabei denkt, dass Du die Punkte 1. und 3. "vergessen" hast... > Und warum macht man das ? Weil man keine Ahnung > hat, wie man es richtig machen soll. Korrekt. Du unterschlägst nur, dass es für dieses "keine Ahnung haben" zahlreiche völlig legitime Gründe geben kann. > Und wie versteckt man, dass man ahnungslos ist ? Stopp: Warum sollte ich das überhaupt verstecken müssen? Richtig: Das ist nur dann notwendig, wenn mein Chef keine Ahnung von Entwicklungsprojekten hat. Hätte er nämlich diese Ahnung, dann wüsste er, dass in Entwicklungsprojekten immer wieder einzelne Punkte auftauchen, über die man viel weniger weiss, als man für den Projekterfolg eigentlich wissen müsste. Man ist als gezwungen, sich dieses Wissen zu beschaffen, und von dem, was man im Moment noch nicht weiss, hängt dann auch ab, wie hinterher weiterzumachen ist. Hat er keine Ahnung, ist für ihn jedes Unwissen die Folge persönlichen Versagens, und das zwingt natürlich dazu, es zu verstecken. > Wenn man hingegen Erfahrung hat "schon 10 Mal eine > Onlineshoppingseite gebaut mit demselben Toolkit" > dann kann man den Auftraggeber auch gleich alles > Wichtige fragen und einen Preis nennen weil man den > Aufwand kennt inklusive Fertigstellungstermin. Dann handelt es sich aber auch nur um eine Auftrags- arbeit und nicht um ein Entwicklungsprojekt im engeren Sinne. (Wenn man es schon zehnmal gemacht hat, ist der Innovationsgrad nahe Null.) Niemand, der bei klarem Verstand ist, verkauft agile Methoden als Universallösungsmittel für jegliche Auftragsarbeiten.
Beitrag #6614488 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Punkte 1. und 3. "vergessen" hast... Man muss sich auf das Wesentliche konzentrieren.. Egon D. schrieb: > "keine Ahnung haben" zahlreiche völlig legitime Gründe geben kann. Dennoch wird es von Auftraggebern nicht gern gesehen. Denn Keine Ahnung hat der selber, dafür muss er nix zahlen. Egon D. schrieb: > wenn mein Chef > keine Ahnung von Entwicklungsprojekten hat. Hat er sowieso nicht. Verstecken musst du es vor dem Kunden. Egon D. schrieb: > Wenn man es schon zehnmal gemacht hat, ist der Innovationsgrad nahe Null. Man muss das Rad nicht tausendmal neu erfinden. Wenn man aber effektiv arbeiten will, ökonomisch, macht Erfahrung Sinn. Durch Übung wird man nämlich schneller. Übung macht den Meister. Dass die heutige Kinderschar nicht mehr üben will, sondern lieber dauernd basteln will und den Kunden das auch noch bezahlen lassen will, ist das Übel der Informatik. Daher sind Projekte zu teuer und dauern zu lange und werden zu schlecht. Und Scrum etc. verschlimmert das nur noch. Wenn wir beim Online-Shop bleiben: wenn ein Kunde kommt und sagt 'ich habe hier meinen Warenbestand in SAP in diesem Format mit Bildern' und möchte daraus einen WebShop mit Suche und Bezahlfunktion, dann darf das EINEN TAG kosten (Firmenname mit Logo und Impressum und Steuernummern reinschreiben, AGB durchsehen, Daten laden, fertig) denn das wurde schon hunderttausendmal gemacht.
Beitrag #6614522 wurde von einem Moderator gelöscht.
Beitrag #6614550 wurde von einem Moderator gelöscht.
MaWin schrieb: > Dass die heutige Kinderschar nicht mehr üben will, sondern lieber > dauernd basteln will und den Kunden das auch noch bezahlen lassen will, Wer träumt nicht davon, den Kunden alles bezahlen zu lassen? > ist das Übel der Informatik. Daher sind Projekte zu teuer und dauern zu > lange und werden zu schlecht. Ich sehe hier nicht den Zusammenhang mit der Informatik. Schlechte und teure Projekte gibts ja auch nicht erst seit heute und nicht nur in der IT.
MaWin schrieb: > denn das wurde schon > hunderttausendmal gemacht. Aber nicht von der selben Person... Häuser wurden auch schon 100000 gebaut. Erwartest du da auch einen Tag Bauzeit? Aber gut. Ich habs glaub verstanden: MaWin machts und der Rest schaukelt Eier denn er kann eh nicht gegen anstinken
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.