Announcement: there is an English version of this forum on Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM eingesetzt wurde, um Projekte zu managen. Meinungen zu dem System sind wilkommen. Vor allem würde mich interessieren, wo das System eingeführt oder angedacht - und dann wiede abgeschafft wurde.
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist > SCRUM eingesetzt wurde, um Projekte zu managen. Ist mittlerweile fast schon wieder ein alter Hut in der Software-Entwicklung, wurde bei uns schon vor über 5 Jahren eingeführt und hat sich bewährt.
Danke für Deine Fragen, Reinhard, die Antworten interessieren mich auch. Ich kann aus meinem Wissen und Können nur dies beisteuern: 1. Seit dem Taylorismus hat das Wissen und Können der Fachkräfte in ihrem Fach schneller und weiter zugenommen als das ihrer Manager in Sachen Management. Folge: a) Das Treffende am Dilbert-Comic. b) Der Vorschlag "ohne die dauernden Störmanöver unseres Deppen von Manager kämen wir viel schneller voran - und sein Gehalt kann gespart werden!" 2. Ungeklärt ist aber der Widerspruch zwischen Delegation / Übernahme der Verantwortung und der Forderung nach Gleichstellung aller im SCRUM-Team. Entsprechend unsicher ist die Praxis. Denn wer Verantwortung auf mehr als zwei Schultern verteilt, der erlebt, wie nachher immer der andere schuld gewesen sein soll. 3. Mir scheint, dem SCRUM-Master wird eine verlogene Aufgabe gestellt - einerseits soll er aus Sicht seines Teams eben keine Vorgesetztenfunktion haben, andererseits erwartet das Management Vorkalkulation, Zusagen und deren Einhaltung - spezifikationsgerecht, termingerecht und kostengerecht. Dieser Widerspruch ist prinzipiell unlösbar. Irgendwer muss leiden. Meine bevorzugte Arbeitsweise in der Vergangenheit bis heute ist diese: "Niemand ist gut genug, einen anderen ohne dessen Zustimmung zu regieren." (Abraham Lincoln) Würde PHB, Dilberts Boss, lernen, wie er diese Zustimmung gewinnt, müßte Dilbert nicht mehr wegen Burnout ausfallen. Ferner könnte PHB aus sämtliche Führungskompetenzen / Manipulationstechniken verzichten. Dann könnte er Dilbert + Kollegen eine echte Hilfe sein, das zu tun, was diese wegen nicht dürfen oder auch nicht können. Ciao Wolfgang Horn
Reinhard S. schrieb: > Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. Quasi jeder macht Scrum - oder was er dafür hält. Die (katastrophalen) Ergebnisse siehst du z.B. bei eBay oder vielen Onlineangeboten von Zeitungen: Ständige Änderungen und immer funktioniert es nur halb, die Fassade wird ständig umgebaut, die Fehler hinten bleiben. Die optimale (resourcen- und kosten-) Form der Softwareentwicklung (woanders auch) ist Wasserfall: Eine klare Aufgabenbeschreibung, erfahrene Umsetzung "schon 1000 mal gemacht", fertiges fehlerfreies Ergebnis (z.B. auch validiert durch kleinteilige Tests). Keine Arbeit wird doppelt gemacht, man ist sich von vorneherein über den Aufwand im Klaren. Leider gibt es diese optimalen Bedingungen selten, daher kann es keine optimale Arbeit geben, Software ist immer teurer und schlechter als erhofft. Scrum ist der Weg, mit schlechten Vorgaben doch noch zurecht zu kommen. Meiner Erfahrung nach werden durch die nun entfallende Notwendigkeit klarer Gesamtvorgaben die Ergebnisse noch schlechter, der Informationsstand der Entwickler ist noch schlechter als früher. Inzwischen ist es üblich, mit Programmen (und WebSeiten) zu kämpfen so daß sie doch noch irgendwie tun was man erreichen muss, an statt daß sie so arbeiten, wie man es von fehlerfreier und durchdachter Software erwarten würde. Beispiel für ein real existierendes Softwareprodukt: Realisierung nach Wasserfall, ausgehen von durchdachtem Pflichtenheft: 4 Mannjahre. Realisierung desselben Produktes durch eine andere Firma nach Scrum: bisher 80 Mannjahre, noch kein Ende in Sicht. Und das, obwohl hier das Endergebnis "ersetzt das alte Produkt" klar vorgegeben ist.
>Die optimale (resourcen- und kosten-) Form der Softwareentwicklung >(woanders auch) ist Wasserfall: Nein ist es nicht. Das wäre der Fall, wenn ein Entwicklungsprojekt vollständig planbar wäre. Das trifft aber maximal auf den Hausbau zu, wenn keine neuen Techniken verwendet werden und es auch sonst keine Unbekannten gibt. Die meisten Softwareprojekte bewegen sich aber im Bereich des Neuen. Dort ist das Wasserfallmodell mit vollständiger Planbarkeit zwar der Traum jedes Managers, funktioniert aber in der Praxis nie. Wechselwirkungen und Zyklen gibt es dort immer, man kann die Spezifikation nicht am Anfang hin schreiben und dann abarbeiten.
Also meiner Erfahrung nach spielt die Methodik keine große Rolle. Das Problem sind meistens Entwickler, welche nicht in der Lage sind ein Problem auf seinen Kern zu reduzieren um diesen Kern dann so zu implementieren, dass man die benötigten Zusatzfeatures dann einfach dran hängen kann. Ohne diese Fähigkeit laufen Softwareprojekte in aller Regel ungefähr so ab: https://www.youtube.com/watch?v=OJsFj9exAlc
Ich arbeite seit 5 Jahren in SCRUM-Projekten mit unterschiedlichem Erfolg. Wenn jemand mit der Einstellung "Meine Kollegen sind meine Konkurrenten bei der nächsten Gehaltsverhandlung" im Team ist, dann kann das nicht klappen. Um solche Widersprüche zu lösen, ist eigentlich die Retrospektive gedacht, aber manchmal sitzen da nur harmoniesüchtige und reden nur Positives. Es hat aber schon richtig gut funktioniert. Es gibt sehr viele Tools für Scrum (also Methoden für die Retro usw.). Die Versuchung ist echt groß, mit diesen Tools rumzuspielen, anstatt die wirklichen Ursachen der Probleme anzugehen.
Kann man mit einem soliden kommt darauf an beantworten. Prozesse sind immer nur so gut wie sie von den beteiligten Personen verstanden und gelebt werden. Habe sowohl schon gute als auch schlechte Ausprägungen gesehen.
Ich glaube, das Problem liegt weniger darin, dass man "egoistisch" denkt, sprich seine Mitarbeiter ausstechen will, sondern darin, dass man bestimmte Fehlannahmen ober Code und Werkzeuge hat. Eine typische Fehlannahme ist, dass mehr Features einer Programmiersprache sie besser machen. Deshalb gibt es auch eine ganze Gruppe von Programmiersprachen, welche Version für Version neue Features bekommen. Das Ergebnis sind Entwicklerteams die ständig mit den neuen Features herum spielen, dann damit was machen, nur um später festzustellen, dass das Feature ungeeignet ist, bzw man es vielleicht nicht richtig verstanden hat. Das Team ist ständig damit beschäftigt neue Features zu lernen und ist somit ständig auf Anfängerniveau. Eine andere Fehlannahme ist, dass man Code schreibt und das Code lesen durch Menschen nicht wichtig ist. Der Compiler kann den Code schon lesen, wichtig ist, dass ihn der Mensch lesen kann. Was scheinbar auch eine Menge Leute glauben, ist dass mehr Code besser ist. Eine Lösung eines Problems in 1000 Zeilen scheint vielen Leuten besser zu sein als das selbe Problem in 100 Zeilen zu lösen. Ja, längerer Code kann lesbarer sein als extrem kurzer Code, jedoch muss eine 100 Zeilenlösung schon sehr unlesbar sein, damit sie mit einer 1000 Zeilen Lösung konkurrieren kann.
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Meinungen zu dem System sind > wilkommen. Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. Kenn ich nicht! Oder anders gefragt: Warum sollen Projekte mit einen SW-Tool oder einer Methode die keiner versteht, besser laufen?
SCRUM (schon fast generell agil) ist einfach eine andere Kultur und eine Kulturveränderung in etablierten Strukturen ist vor allem eines: schmerzhaft "teuer" konkret sehe ich oft fehlende Grundlagen um SCRUM überhaupt einsetzen zu können: * Auftraggeber kann nicht agil mitarbeiten * Auftraggeber hat nicht die notwendige Vision und Fachexpertise * Firmenkultur betrachtet "Scheitern" als lebenslanges Brandzeichen * Firmenkultur bremst bei Entscheidungen, im Sinne von - streng hierarchisch, wenige Entscheidungsträger die noch weniger Zeit haben, wenig Vertrauen in die Mitarbeiter * Firmenkultur kann selbst nicht agil, gerne wird mal ein Team mit Scrum losgeschickt, dabei aber vergessen, dass das Umfeld mitziehen muss * das System an dem gearbeitet wird, kann nicht agil weiterentwickelt werden, im Sinne von - kleine Änderungen = große Ängste wenn dann mal die groben Rahmenbedingungen stehen, tja dann sehe ich Scrum in Verbindung mit Lean und einer angemessenen Portion Kritik zu emergenten Architekturen als extrem kostensparenden Softwareentwicklungsprozess
MaWin schrieb: > Beispiel für ein real existierendes Softwareprodukt: > Realisierung nach Wasserfall, ausgehen von durchdachtem Pflichtenheft: 4 > Mannjahre. > Realisierung desselben Produktes durch eine andere Firma nach Scrum: > bisher 80 Mannjahre, noch kein Ende in Sicht. Und das, obwohl hier das > Endergebnis "ersetzt das alte Produkt" klar vorgegeben ist. Gutes Beispiel. Es stellt sich nur die Frage warum das alte Produkt ersetzt werden soll. Oder war das genau das Problem: Lastenheft/Pflichtenheft gut durchdacht, aber in Wirklichkeit wollte der Auftraggeber das gar nicht (da er nicht weiss was er eigentlich möchte)
Dumdi D. schrieb: > Auftraggeber das gar nicht (da er nicht weiss was er eigentlich möchte) Das ist überhaupt DAS Problem. Hört sich bekloppt an, kommt aber ständig vor. Man hat ein paar konkrete Punkte die geändert werden sollen aber später "noch viel mehr" aber was genau weiss man noch nicht.
TEAM = Toll Ein Anderer Machts Mein persönliches Fazit aus der Praxis: Eine Gruppe von Leuten, die gute SW entwickeln kann, sich vertraut und eine funktionierede Kommunikation aufgebaut hat, kann "klassisch" gute Software entwickeln. und kann das auch in einem Scrum Prozess. Wenn man einfach Leute zusammenwürfelt, die nicht miteinander können, nützt auch scrum und agil nix. Scrum ist spätestens da zuende, wo der Chef auf einzuhaltende Fristen pocht und der Kunde mit Konventionalstrafe oder Abbsprung droht. Und SCRUM-Tools mögen vieleicht ein bischen nützlich sein, aber wenn ich mir die vielen Naivlinge anschaue die meinen man bräuchte nur das richtige Tool, dann klappts, dann weiss ich dass die Arbeit nie ausgehen wird.
Dumdi D. schrieb: > Es stellt sich nur die Frage warum das alte Produkt ersetzt werden soll. Es gab die Hoffnung, daß ein Rewrite zu einem schneller ablaufenden Programm führt. Phantasiezahlen wie "x20" oder gar "x1000" standen im Raum, nicht mal "x2" wird derzeit erreicht (inzwischen bringt die Hardware locker x20 auch beim alten), lediglich der Speicherbedarf ist "x20" geworden. Hauptsächlich war es das üblich Geschwätz verirrter Modejünger "moderneres Aussehen" "moderne Technologien" "Abwerfen von Ballast" "bunter blinkender und XML konform".
MaWin schrieb: > XML konform Womit es schon mal bestimmt nicht schneller wird gegenüber proprietäten aber zum Problem passenden Datenstrukturen :-)
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Vor SCRUM: Wir müssen einen weiten weg gehen. Bevor wir loslaufen planen wir jeden meter und wie wir um mögliche Hindernisse herum kommen. Das was wir nach Abarbeitung des langen Planes erreicht haben muss das Ziel sein. Mit SCRUM: wir müssen einen weiten weg gehen. Wir laufen einfach los und nach ein paar Metern schauen wir ob das Ziel näherrückt oder nicht. Dementsprachend halten wir die richtung bei oder nicht. Näherrückende Hindernisse umlaufen wir nicht, sondern melden diese dem SCRUM-Master. Der plant die nächsten Meter so das wir nicht frontal gegen das Hinderniss knallen. Damit kommen wir zwar dem Ziel nicht unbedingt näher aber immerhin treten wir nicht auf der stelle weil uns der Plan fehlt ...
hart aber weise schrieb: > Vor SCRUM: > > Wir müssen einen weiten weg gehen. > Bevor wir loslaufen planen wir jeden meter und wie wir um mögliche > Hindernisse herum kommen. In der Realität eher so: Wir machen eine Expedition in einen unbekannten Dschungel. Wir wissen nicht, was uns erwarten wird. Damit wir uns nicht verlaufen, setzen wir uns vorher zuhause 3 Monate an den Schreibtisch und malen ausführliche Landkarten.
Tom schrieb: > Damit wir uns nicht > verlaufen, setzen wir uns vorher zuhause 3 Monate an den Schreibtisch > und malen ausführliche Landkarten. Man könnte natürlich vorher ein Flugzeug oder Satellit bemühen um die Landschaft zumindest grob vorzuerkunden. Das wäre der klassische Ansatz. Die Scrum Ameisenmethode ist auch nicht der letzten Weisheit Schluß. Im Prizip macht Scrum das was eine gut eingspielte Gruppe mit funktionierender Kommunikation so oder so macht. Nur ist es in Scrum streng schematisiert und ritualisiert, so daß man nicht den eigenen Verstand benutzen muss. Halt der typisch amerikanische Checklistenansatz, mit dem auch Hilfsarbeiter klarkommen.
Der größte Fehler den man bei Scrum machen kann ist zu glauben, dass Scrum einfach ist. Ein paar wenige Aktivitäten, ein paar wenige Artefakte, was kann da schon schief gehen? Scrum ist aufwändig, braucht Einsatz und ist besonders an den Schnittellen, wie zu Kunden, Lieferanten oder der eigenen Buchhaltung, schwer durchzuhalten. Da herrscht so eine Art Impedanzfehlanpassung. Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen sabotiert. Der theoretische Lösungsansatz für so ein Problem, das Team-Miglied zu einem ex Team-Miglied zu machen funktioniert in deutschen Firmen nicht. So einfach wird man kein Team-Mitglied los. Tauschen mit anderen Teams geht selten. Dazu ist die Personaldecke zu dünn und die Personalplanung zu straff. Von US-Verhältnissen nicht zu reden. Dort entscheiden vielfach direkt Gruppenleiter über Einstellungen und Entlassungen in ihren Teams. Im Grunde wird Scrum von zwei Gruppen totgeredet. Den Fanboys, die Scrum Heils- und Erweckungskräfte zuschreiben, die es nicht hat, und den Hassern, die immer wieder neue Ausreden erfinden, warum Scrum nicht funktionieren kann. Das Wasserfall-Modell hingegen ist toll. Auf dem Papier. Es hat nur den großen Nachteil, dass es häufig nicht funktioniert, weil sich die Realität ums Verrecken nicht an das Modell anpassen möchte.
Ein Problem liegt auch darin das man meint man bräuchte nur SCRUM lernen um projecte zu managen. SCRUM Zertifikat als Lizenz zum Projekt leiten. IMHO ganz großes Trugschluss: Man wird nicht zum 3 SterneKoch nur wenn man den Küchengeräte umgehen kann. Meines erachtens betrachten einige Absolventen die SCRUM-Zertifizierung als Abkürzung in die Leitungsetage. So wie Gutenberg und Co: wer den Titel hat ist Doktor, auch wenns völlig an Talent und Verständnis mangelt.
Jay schrieb: > Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen > und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht > anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen > sabotiert Meiner Meinung nach kannst Du das Wort 'Scrum' in dem Ausschnitt durch jedes andere Wort ersetzen. Alles läuft, wenn alle am gleichen Strang ziehen, mitspielen und Verantwortung übernehmen.
Dumdi D. schrieb: > Jay schrieb: >> Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen >> und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht >> anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen >> sabotiert > > Meiner Meinung nach kannst Du das Wort 'Scrum' in dem Ausschnitt durch > jedes andere Wort ersetzen. Alles läuft, wenn alle am gleichen Strang > ziehen, mitspielen und Verantwortung übernehmen. Natürlich, aber ein Scrum-Fanboy muss ja in dem Kontext Scrum erwähnen. Immer dran denken: Wenn 90% oder gar 99% der Projekte nicht funktionieren, darf es niemals an der reinen Theorie der Methode liegen, sondern immer an den Leuten. Ist wie beim Sozialismus...
Jay schrieb: > Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen > und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht > anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen > sabotiert. Ja ja ein System, das nur funktioniert wenn alle innerer Elemente ideal sind ist ein "Scheiß" System, nämlich nicht fehlertolerant. Ein gutes System funktioniert auch dann wenn es nichtideale Bauelemente hat. Aber so schlecht will ich SCRUM und agile SW-Entwicklung gar nicht machen. Aber es ist kein Zaubermittel. In unserer Firma läuft derzeit beides nebeneinander her, und ich kann bis jetzt kein Vorteil für SCRUM feststellen, nur ein Haufen Ausreden wenn die Zeitabschätzungen trotz SCRUM weit überschritten werden.
Dumdi D. schrieb: > Jay schrieb: >> Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen >> und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht >> anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen >> sabotiert > > Meiner Meinung nach kannst Du das Wort 'Scrum' in dem Ausschnitt durch > jedes andere Wort ersetzen. Alles läuft, wenn alle am gleichen Strang > ziehen, mitspielen und Verantwortung übernehmen. bei Scrum ist es IMHO eher schwierig in die richtige Richtung zu ziehen da Ziele kurzfritig gesetzt werden (Sprints). So kann es bei Scrum schnell passieren das zwar alle am gleichen strang ziehen aber die entwicklungs im takt der Sprints hin und her irrt statt schnurrgerade auf die milestones zurast. Oder fröhlich auf der Stelle tritt und vom Hundersten ins Tausendste inkrementiert.
Ach Leute, ihr habt ausführlich demonstriert, dass ihr an Erfahrungen nicht interessiert seit, sondern nur dogmatisch auf etwas rumzuhacken was ihr nicht versteht. Daher spare ich es mir mit euch zu diskutieren.
Jay schrieb: > Ach Leute, ihr habt ausführlich demonstriert, dass ihr an Erfahrungen > nicht interessiert seit, sondern nur dogmatisch auf etwas rumzuhacken > was ihr nicht versteht. Ich glaube eher du bist ein SCRUM Fanboy, hast aber noch nie im Leben ein reales Projekt mit Hilfe von SCRUM realisiert, mit einem Kunden der geliefert haben möchte und einem Chef der mit dem Projekt auch Geld verdienen will (und muss). Ich habe hier in meiner Firma den Vergleich, mir persönlich wäre der sehr formale Prozess aber zu doof.
Mein erstes SCRUM Projekt durchlebte ich 1992. Kleines motiviertes Team. Morgendliche kurze Besprechung was jeder am Tag machen will und was er von anderen dafür braucht und Abends kurze Besprechung was davon gaklappt hat und warum nicht. 23 Jahre später hab ich dann erfahren, wie sich dieses Verfahren nennt. Es funktioniert, wenn gewisse Randbedingungen eingehalten werden (können) ganz gut, nur die Tatsache, daß jemand dieses Verfahren gegen Geld und Zertifikat eingetrichtert bekommen hat, ist keine Garantie, daß Projekte plötzlich wuppen. Karriere mäßig ist das natürlich toll, sich als SCRUM Master/Instructor/... bezeichnen zu dürfen, nur was bringt's sonst? SCRUM formalisiert Dinge, die erfolgreiche Team von alleine richtig machen, bringt vielleicht ein paar Leute auf den Trichter und hinterlässt einige ratlos, die formal alles richtig gemacht haben, aber trotzdem versagen. Und es sorgt für viel Umsatz bei den Zertifikatsverteilern.
MaWin schrieb: > Die optimale (resourcen- und kosten-) Form der Softwareentwicklung > (woanders auch) ist Wasserfall: Eine klare Aufgabenbeschreibung Von der Theorie her gebe ich Dir Recht. Aber: Gab es denn in der Geschichte der Softwareentwicklung jemals ein Projekt mit realen Kunden, wo das so funktioniert hat? In realen Projekten passieren ständig die folgenden Dinge: -Der Kunde will noch ein zusätzliches Feature eingebaut haben. Und noch eins. Und noch eins. -Der Kunde will eine bestimmte Funktionalität in der Software jetzt doch nicht haben, weil z.B. das Geld auf einmal knapp ist oder weil jetzt auf Kundenseite ein anderer für den Auftrag zuständig ist. -Der Vertrieb hat den Vertrag mit dem Kunden nicht sauber aufgesetzt und ein Feature vergessen, dass dem Kunden in den Verhandlungen mündlich zugesagt worden war. Alles schon erlebt.
:
Bearbeitet durch User
Mark B. schrieb: > Aber: Gab es denn in der Geschichte der Softwareentwicklung jemals ein > Projekt mit realen Kunden, wo das so funktioniert hat? Ja, bei uns mehrere. Kleine Projekte, wo ein Kunde ein Problem hat, das schildert, gemeinsam ein Programmvorschlag zur Lösung erarbeitet wird (1 Tag), das umgesetzt wird (2 Tage) dokumentiert wird (1 Tag), und der Kunde zufrieden mit der Lösung ist, also keine Nacharbeit. Das gab es dann für 4000 DM. Auch grössere Projekte, wo man das Pflichtenheft schreiben konnte, abgesegnet bekam, und in 1 Jahr umgesetzt hat, liefen erfolgreich, aber kleine Abweichungen "wir hätten gerne nach 3 Monaten einen Prototypen" verstiessen gegen das reine Wasserfallmodell (und kosteten den Kunden zigtausende, denn ohne so einen Schwachsinn hätte man anders effektiver programmiert). Das Produkt selbst wurde damit verkauft und eingesetzt, Fehler waren aber drin und mussten bei Entdeckung gefixt werden, das sollte ja bei reinem Wasserfall auch nicht sein. Und noch ein paar weitere. Ein Kunde, der mit Wischiwaschi kommt, und nicht mal ein Lastenheft liefern kann, fliegt gleich wieder raus. Wichtig ist, daß der Kunde mit seinem Projekt zu den Erfahrungen des Teams passt. Wer bei Aufträgen einschlägt, deren Kernaufgaben er noch nie gemacht hat, bei denen er alles erst lernen muss, kann keinen Wasserfall anbieten. Wer so was so ähnlich schon dutzendmal gemacht hat "wieder eine Shopysystem, der Kunde ist mit Funktion und Aussehen des vorherigen Kunden zufrieden", wird nicht nur rasend schnell, auch dank Recykling von Code, sondern kann auch sehr genau sagen was es kostet und wie lange es dauert.
Die Einführung von SCRUM setzt immer voraus dass der Vorgesetzte denkt dass die Mitarbeiter Dölmchen drehen oder einfach schlafen. BWL-ler lieben die Illusion mit „agilen Prozessen“ einen Entsafter einzuführen der aus den Menschen noch mehr ausquetscht. 1. SCRUM macht überwiegend Sinn für jüngere Mitarbeiter die nicht wissen wie man miteinander kommuniziert. Den Älteren/Erfahrenen Kollegen geht das auf den Sack. 2. Wenn man eingespieltes und gut funktionierendes Team hat, ist SCRUM eher ein Nachteil weil hier ein unflexibles und autoritäres System eingeführt wird. 3. Durch SCRUM neigen viele nicht ganz bodenständige Menschen (Nerds sind in der Regel so) sich selbst auszubeuten und sich in Meetings mit kürzeren Fristen zu überbieten. 4. SCRUM ist ein fast religiöses System das auf gar keinem Fall kritisiert werden darf, erinnert stark an Scientology, z.B. „Tools for Life“ und ähnliche typisch amerikanische Bevormundung. 5. SCRUM deckt in der Regel auch interne Strukturprobleme (Schwächen) des Unternehmens auf die aber kein BWL lösen wollen wird. Der Latein der BWL-ler endet exakt hier, schließlich ist SCRUM nur dafür gedacht etwas am Mitarbeiter zu „formen“. 6. Es ist viel billiger ein einfaches Tool einzusetzen wo Mitarbeiter eingeben was sie gemacht haben und wie lange, und kurze tägliche Gespräche abzuhalten. Stattdessen aber holen sich die Firmen teuere SCRUM-Berater und tagelange SCRUM-Schulungen wo außer den dämlichen denglischen Sprüchen kaum was Brauchbares erzählt wird. 7. SCRUM verschiebt einen Teil der Organisation (und Verantwortung) mit voller Absicht auf Mitarbeiterebene ohne dass dafür eine angemessene Entlohnung erhalten wird. 8. In enger Zusammenarbeit mit dem Kunden wo man flexibel reagieren muss, kaum anwendbar wenn man andauernd die Sprints ändern muss.
Du sprichts mir aus der Seele. Ich bin seit 1976 in der Entwicklung tätig und muss diesen "MURCS" auch noch über mich ergehen lassen. Tätgliche Scrum Floor Metings und dieser ganze denglische Scheiss. Täte die Firma die Entwicklung mit einer ordentlichen Personalausstattung betreiben bräuchte man diesen Mist nicht.
Christian B. schrieb: > Das Ergebnis sind Entwicklerteams die ständig mit den neuen > Features herum spielen, dann damit was machen, nur um später > festzustellen, dass das Feature ungeeignet ist, bzw man es vielleicht > nicht richtig verstanden hat Oh, wie wahr. Einem großen Teil der Softwarepakete, die uns umgeben, zeigen, dass die Entwickler sehr gerne einfach kritiklos nutzen, was da ist, ohne, dass damit eine echte Anforderung verbunden gewesen wäre. Viel Klickibunti ohne Wert. Das Fatale ist dann oft, dass wirklich nötige Funktionen nicht da sind, nicht funktionieren, weil der Fokus auf anderen Dingen lag.
Die Kommentare hier decken sich mit meiner Erfahrung: -) Scrum hat nicht viele Regeln, verlangt aber, dass diese eingehalten werden. Versteht man Scrum nicht und/oder setzt man es nur teilweise um, dann funktioniert es nicht. Sieht man gut hier in diesem Thread: da regen sich die Leute über Scrum auf mit Szenarien, die man bei Scrum gerade verhindern möchte. -) Scrum ist nicht für alle Projekte geeignet. Für die hier genannten Projekte im Ausmaß von 4 Manntagen, oder wenn eh schon alles komplett spezifiziert ist (dann kann man es gleich den Indern geben), braucht man kein Scrum. -) Scrum krempelt die Organisation stärker um als man denkt. Das klappt oft nicht. In der Firma, in der ich arbeite, setzen wir ein Subset von Scrum ein. Das funktioniert nicht, ist aber auch logisch. Aber noch immer besser als zuvor, wo wir gar keine Methode hatten. Unsere Kunden sind mindere Qualität gewohnt, daher ist das leider kein Problem. "Richtige" Scrum-Teams funktionieren meiner Beobachtung nach aber echt gut.
In der Regel ist das so dass Unternehmensberater die Chefs dazu verführen diesen Blödsinn einzuführen weil sie ihm mehr Gewinn und weniger Arbeit (für ihn selbst) versprechen, da (wie schon vorgemerkt wurde) ein Teil der Organisation nach unten rutscht. Scrum und Flexibilität passen nicht zueinander. Den Höherpunkt der Perversität habe ich mal in einem Großkonzern erlebt, dort strömen morgen früh Mitarbeiter in die Meetingsräume rein, in jedem Raum ca. 50 man. Es gibt keine Stühle in diesem Raum, alle bleiben stehen für ca. 45min. In dieser Zeit wirft man sich gegenseitig so ein kuscheliges Bällchen zu, genannt Speechtoken, und erzählt was man gestern gemacht hat und was man heute vor hat. Noch peinlicher und kindischer geht es kaum.
hal3000 schrieb: > Täte die Firma die Entwicklung mit einer ordentlichen > Personalausstattung > betreiben bräuchte man diesen Mist nicht. Hm, kommt mir bekannt vor. Wir haben einen sehr, sehr guten SW-Entwicklungsprozess über den wir qualitativ hochwertige Software entwickeln könnten, allein die Mitarbeiter fehlen, bzw. es wird dem Team mehr Arbeit aufgehalst als machbar ist. Das Ergebnis ist dann, dass am Prozess vorbei gearbeitet wird, Fehler passieren und Termine nicht eingehalten werden können. Als Reaktion darauf wurden Projektleiter (Plural) ins Boot geholt, welche noch keine Ahnung vom Thema oder dem Prozess haben, ihn aber verschlanken sollen. Der Prozess funktioniert, hat sich bewährt und ist gut, es fehlen nur die Leute. Aber statt Entwickler einzustellen werden Projektleiter geholt, der Overhead aufgeblasen und die Qualität herabgesetzt. Und gleichzeitig redet der Chef davon, dass wir unbedingt "agil" entwickeln müssen.
progger schrieb: > da > regen sich die Leute über Scrum auf mit Szenarien, die man bei Scrum > gerade verhindern möchte. Präzisiere das mal bitte. Was nützt mir ein in der Theorie toller Prozess, der in der Praxis nicht funktionieren kann, weil es immer Randbedingungen wie ein Budget und ein Abgabetermin gibt. Sorry aber das ist doch dann reine Augenwischerei, genau wie eine tolle Prinzipschaltung in Tieze Schenk, die aber nur funktioniert wenn die Bauteile max. 0,001% Toleranz haben. Carl hat es prima zusammengefasst: Carl D. schrieb: > SCRUM formalisiert Dinge, die erfolgreiche Team von alleine richtig > machen, bringt vielleicht ein paar Leute auf den Trichter und > hinterlässt einige ratlos, die formal alles richtig gemacht haben, aber > trotzdem versagen. Und es sorgt für viel Umsatz bei den > Zertifikatsverteilern. Was noch fehlt aber auch schon angesprochen wurde: SCUM ist ein schönes Bullshit Bingo Buzzword für BWLer und Vertriebler. Es gibt in der Softwareentwicklung keinen Königsweg, sondern immer mehrere Varianten, welcher der Beste ist hängt vom Projekt, den Rahmenbedingungen und den Menschen ab, die daran mitwirken.
Ich finde von SCRUM wird häufig geredet. In Wirklichkeit steht was ganz anderes dahinter. Selbst in Firmen die von fest definierten Aufträgen lebt wird intern gesagt man verwendet SCRUM(erlebe ich selbst gerade -.-). Das kann nicht funktionieren. Ich hab die Erfahrung gemacht es wird viel und oft gesagt: "Wir machen SCRUM", in Wirklichkeit ist es aber nicht so. Wenn ich ein Lastenheft habe dann wird es einfach schwierig einen wirklichen SCRUM-Prozess zu führen. Das Problem ist vor allem das in DE viele Firmen einfach nicht agil sind, sich aber selbst so sehen. Außerdem ist die SW-Entwicklung, gerade in kleineren Industriefirmen, gespickt von Quereinsteigern die in der Regel keine Ahnung von agiler SW Entwicklung haben. Dann kommt es ziemlich schnell zu Missverständnissen was das überhaupt bedeutet, es wird mit Begriffen um sich geschmissen die hinten und vorne nicht stimmen und sich dann noch modern gefühlt. SCRUM funktioniert dort wo ich eben keine starren Anforderungen habe und mich als Kunde laufend beteilige. VW geht ja auch nicht zu Bosch und sagt: "Schauts mal wie es läuft, 30 mille kriegts trotzdem.". Die sagen ja auch:"Ich will eine Abgasabschalteinrichtung bis 31.1. für 10 mille und wennst es nicht schaffst, Vertragssstrafe".
Hi, ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ Kurzzusammenfassung: Es setzt die falschen Anreize, löst die falschen Probleme und macht Programmierung und Programmierer zu einem notwendigen vehikel. Es ist im Prinzip ein permanenter Kriesenmodus.
verwundet schrieb: > Außerdem ist die SW-Entwicklung, gerade in kleineren Industriefirmen, > gespickt von Quereinsteigern die in der Regel keine Ahnung von agiler SW > Entwicklung haben. Das ist leider genau das Problem, Selber mitgemacht, in do nem kleinen KMU in der Industrie: Auf 10 j. alter Legacysoftware ( in C geschrieben ) versucht, neue Komponenten mit Scrum zu entwickeln, die meisten Entwickler abgehaut, ich war einer der Erfahreneren damals mit ca. 2 Dienstjahren bei der Firma. Schlechte Qualität war der Kunde genauso gewöhnt. Es gab nen Scrummaster wie sich das halt alles nennt, funktioniert hats im Endeffekt nicht. Jeder hat halt für sich seine Zettelchen und Tasks abgearbeitet, aber am Schluss hat alles schnittstellenübergreifend nicht funktioniert.
klausi schrieb: > Jeder hat halt für sich seine Zettelchen und Tasks abgearbeitet, aber > am Schluss hat alles schnittstellenübergreifend nicht funktioniert. Nicht funktionierende Kommunikation! Wenn jeder ein bischen über den Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das nicht passiert. Klassisches Beispiel. dass der formale Prozess alleine keine Lösung ist. Und wenn das Team gemeinsam über den Tellerrand schaut und konstruktiv miteinander redet, dann brauchst du den formalen Prozess nicht mehr.
Der Andere schrieb: > Wenn jeder ein bischen über den > Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das > nicht passiert. Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5 Sterne-Projektmanager hat managed sich jedes problem wie von alleine und zur universalen Zufriedenheit. Aber wir sind nun man Menschen und keine Götter und zerlegen deshalb Aufgaben zielführend in verdauungsgerechte Happen daran ändert auch kein SCRUM etwas.
Ecce homo schrieb: > Der Andere schrieb: >> Wenn jeder ein bischen über den >> Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das >> nicht passiert. > > Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5 > Sterne-Projektmanager hat managed sich jedes problem wie von alleine und > zur universalen Zufriedenheit. Ich sage "ein bischen über den Tellerrand blicken" Du interpretierst: "Gottgleichen IchStehÜberAllen Blick" Welches Problem hast du? Verstehendes Lesen? Kann man lernen...
Lu R. schrieb: > Der Prozess funktioniert, hat sich bewährt und ist gut, es fehlen nur > die Leute. Aber statt Entwickler einzustellen werden Projektleiter > geholt, der Overhead aufgeblasen und die Qualität herabgesetzt. Und > gleichzeitig redet der Chef davon, dass wir unbedingt "agil" entwickeln > müssen. Genau das habe ich auch oft gesehen. Ich will noch genauer auf den Punkt eingehen wo dabei noch groß geschummelt wird. Ein Prinzip in Scrum ist dass man erst einen Sprint (ungestört!!!) beenden muss bevor die nächste Aufgabe angegangen werden darf. In der Praxis funktioniert das selten, es kommen immer Aufgaben dazu die "nebenbei" anfallen, selbst das Führungspersonal das Scrum eingeführt hat, hält sich selbst nicht dran und kommt immer wieder mit dem neuen Kramm. Dann heißt es aber, man solle einen Sprint einführen der ca. 70% der Auslanstung entspricht, dann kann man nebenbei noch Aufgaben machen. In großen Firmen sehe ich immer BWL-ler die nur Scrum einführen können. Die sitzen nur da und suchen z.B. keine neue Marktanteile oder neue Möglichkeiten für die Firma. Sobald die Flaute kommt, rechnen sie um wie viele sie entlassen müssen. Darin sehen sie schon ihre Aufgabe erfüllt.
Der Andere schrieb: > Ecce homo schrieb: >> Der Andere schrieb: >>> Wenn jeder ein bischen über den >>> Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das >>> nicht passiert. >> >> Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5 >> Sterne-Projektmanager hat managed sich jedes problem wie von alleine und >> zur universalen Zufriedenheit. > > Ich sage "ein bischen über den Tellerrand blicken" > Du interpretierst: "Gottgleichen IchStehÜberAllen Blick" > > Welches Problem hast du? Verstehendes Lesen? Kann man lernen Na dann hast Du ein problem mit "verständlichen Schreiben" den Du schreibst: "das ganze Problem im Blick gehabt" den genau das geht beim Projekten die nicht von einem einzelnen bearbeitet werden nicht mehr. Das ist die Aufgabe des PM der sich bei SCRUM gern mit der bemerkung "Schaut über den tellerand" aus der verantwortung schleicht. Im im Bild zu bleiben Mit den Blick über den tellerrand erblickt man nur den Tellarand des anderen aber nicht das Problem in Gänze. Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen wird wie der Coder in seinem Cubicle.
Ecce homo schrieb: > Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen > wird wie der Coder in seinem Cubicle. Gehts nur mit Buzzwords? Und mir willst du nicht verständliches Schreiben vorwerfen? ROFL! Im Gegensatz zu dir bin ich schon über 20 Jahre im Geschäft und habe genau solche funktionierende Projekte gesehen, genauso wie Projekte die trotz oder wegen Wasserfall oder agilem Ansatz die vor die Wand gingen. Ecce homo schrieb: > Das ist die Aufgabe des PM. Der PM behält den kompletten Überblick. Aber wenn du an einer Schnittstelle rumwurstelst ohne den anderen, der für die Gegenseite verantwortlich ist, gefragt zu haben ob es so passt, dann bist du der typische Scheuklappenprogrammierer, der die Hände in den Himmel streckt und ruft "Ich wars nicht" wenn das Projekt gegen die Wand gefahren ist.
Der Andere schrieb: > Ecce homo schrieb: >> Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen >> wird wie der Coder in seinem Cubicle. > > Gehts nur mit Buzzwords? Und mir willst du nicht verständliches > Schreiben vorwerfen? ROFL! Du weisst nicht was Buzzwords sind, in den zitierten Text findet sich kein Einziges. Das Kommunikation nicht die Lösung sondern nur Mittel zum Zweck sind scheint dir auch nicht geläufig. Was das prinzip Divide et impera im Team bedeudet hast Du offensichtlich auch nicht kapiert - Hinweis Über den Tellerrand schauen und dabei kommunizieren ist kein "impera" - also Beherrschung (des problems). Der Andere schrieb: > Im Gegensatz zu dir bin ich schon über 20 Jahre im Geschäft und habe > genau solche funktionierende Projekte gesehen, genauso wie Projekte die > trotz oder wegen Wasserfall oder agilem Ansatz die vor die Wand gingen. Der gegensatz zwischen uns besteht nicht in der berufserfahrung gleich) sondern eher im Verantwortungsbewusstein und im Umgang mit Bauernschlauen Weisheiten (übern Tellerrand ...) MfG,
Ecce homo schrieb: > Der gegensatz zwischen uns besteht nicht in der berufserfahrung gleich) > sondern eher im Verantwortungsbewusstein Der Unterschied besteht wohl eher darin, dass du BWLer bist und noch nie entwickelt hast. Ich beende die Diskussion hier ist völlig sinnlos geworden.
progger schrieb: > -) Scrum ist nicht für alle Projekte geeignet. Für die hier genannten > Projekte im Ausmaß von 4 Manntagen, oder wenn eh schon alles komplett > spezifiziert ist (dann kann man es gleich den Indern geben) Ich habe noch nie ein SW-Projekt gesehen, in dem wirklich alles komplett spezifiziert war. Gibt es sowas?
Mark B. schrieb: > progger schrieb: >> -) Scrum ist nicht für alle Projekte geeignet. Für die hier genannten >> Projekte im Ausmaß von 4 Manntagen, oder wenn eh schon alles komplett >> spezifiziert ist (dann kann man es gleich den Indern geben) > > Ich habe noch nie ein SW-Projekt gesehen, in dem wirklich alles komplett > spezifiziert war. Gibt es sowas? Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil sie komplett nach Indien outgesourced werden.
Wir verwenden prinzipiell Scrum, jedoch wird das in seit einiger Zeit ein wenig vernachlässigt. Der hohe Zeitdruck im Projekt, die chronische Unterbesetzung und der ständige Richtungswechsel vom Management machen es aktuell (und in den letzten 6 Monaten) recht schwierig, Prioritäten zu setzen. Die Tasks, die jeder bearbeitet, sind mittlerweile viel zu groß und bis auf das tägliche Meeting ist nicht mehr viel von Scrum zu erkennen. Aber 2016 wird alles besser ;-)
Gästchen schrieb: > In der Regel ist das so dass Unternehmensberater die Chefs dazu > verführen diesen Blödsinn einzuführen weil sie ihm mehr Gewinn und > weniger Arbeit (für ihn selbst) versprechen, da (wie schon vorgemerkt > wurde) ein Teil der Organisation nach unten rutscht. Scrum und > Flexibilität passen nicht zueinander. Den Höherpunkt der Perversität > habe ich mal in einem Großkonzern erlebt, dort strömen morgen früh > Mitarbeiter in die Meetingsräume rein, in jedem Raum ca. 50 man. Es gibt > keine Stühle in diesem Raum, alle bleiben stehen für ca. 45min. In > dieser Zeit wirft man sich gegenseitig so ein kuscheliges Bällchen zu, > genannt Speechtoken, und erzählt was man gestern gemacht hat und was man > heute vor hat. Noch peinlicher und kindischer geht es kaum. Der Klassiker: "wir machen Scrum". Scrum setzt die Teamgröße auf 7+-2 Personen an. Hier sind es auf einmal 50 Personen. Das ist genau das Gegenteil von dem, was Scrum sagt - trotzdem lautet das Fazit "Scrum funktioniert nicht". Der Andere schrieb: > Präzisiere das mal bitte. Was nützt mir ein in der Theorie toller > Prozess, der in der Praxis nicht funktionieren kann, weil es immer > Randbedingungen wie ein Budget und ein Abgabetermin gibt. > Sorry aber das ist doch dann reine Augenwischerei, genau wie eine tolle > Prinzipschaltung in Tieze Schenk, die aber nur funktioniert wenn die > Bauteile max. 0,001% Toleranz haben. Klar kann der in der Praxis funktionieren, aber nicht immer. Scrum möchte entweder den Scope oder das Budget festsetzen. Bei einem agilen Prozess beides zu fixieren, und dann dem Kunden alle Änderungen gestatten, weil agil, geht natürlich in die Hose. Das richtige Werkzeug für die richtige Aufgabe, nicht für alles den Hammer benutzen!
Konrad schrieb: > Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil sie > komplett nach Indien outgesourced werden. Warum sollte man beim outsourcen nach Indien irgendetwas spezifizieren ? Die machen doch sowieso alles wie sie gerade lustig sind. Selbst wenn du ordentliches Englisch schreibst, wird es kulturell bedingt dort nicht gelesen aber ständig betont daß sie alles verstehen und hochrangige Experten alles detailgenau umsetzen und es kommt ein ganze anderes Produkt zurück. BTDT. Inder kannst du knicken, Ex-UdSSR ist deutlich besser.
MaWin schrieb: > Inder kannst du knicken, Ex-UdSSR ist deutlich besser. Oder Polen. Oder andere europäische Länder. Fähige Entwickler mit einem ähnlichen kulturellen Hintergrund gibt es auf unserem Kontinent nicht ganz wenige.
Jan H. schrieb: > ei einem agilen Prozess beides zu fixieren, und dann dem Kunden alle > Änderungen gestatten, weil agil, geht natürlich in die Hose. Ja klar! Kommt mir bekannt vor! Am liebsten alles dem Kunden gestatten, Anforderungen über Bord schmeißen, wir sind ja agil. Kein Problem. Die Verkäufer haben verkauft, wir Entwickler sind die blöden. Bei uns war es am Schluss gar kein Scrum mehr. Es wurden einfach Zettelchen auf ne Wand geklebt und dann wenn wer fertig wurde hat der den Zettel auf fertig gehängt. Oder es wurden welche Zettel (Tasks) vergessen ;-) Am Schluss wars einfach eine mehr oder weniger vollständige Todo Liste :-)
Gästchen schrieb: > in die Meetingsräume rein, in jedem Raum ca. 50 man. Es gibt > keine Stühle in diesem Raum, alle bleiben stehen für ca. 45min. In > dieser Zeit wirft man sich gegenseitig so ein kuscheliges Bällchen zu, > genannt Speechtoken würd gerne wissen welche firma das war ;) würd mich über ne pn mit ort und abteilungsangabe freuen lg
michl42 schrieb: > Hi, > > ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile: > > https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ Das war gut! Können wir den Thread schließen und sagen, Scrum ist ein unnützes neumodisches K*ck Zeug, womit irgendwelche Bwler damit rumwerfen und es nur für Juniorentwickler entworfen wurde, um damit sinnloses Micromanagement zu betreiben?
Hi, das wollte ich damit nicht sagen. Für eine Krisensituation ist es ok. Für eine Standard-Situation ist es aus den aufgeführten Gründen nicht mein Fall.
klausi schrieb: > Können wir den Thread schließen und sagen, Scrum ist ein unnützes > neumodisches K*ck Zeug, > womit irgendwelche Bwler damit rumwerfen und es Nö, damit beschuldigst du die Falschen. Nach meiner Erfahrung sind es aufstrebende Ingenieure und Informatiker die per reverse MURCS versuchen die Karrierleiter nach oben zu fallen. > nur für Juniorentwickler entworfen wurde, um damit sinnloses > Micromanagement zu betreiben? Das kommt der Wahrheit schon näher MfG,
Das ist nicht nur für Projekte. bei meinem oem wird das als firmen politik inklusive führung so eingeführt. Ihr könnt euch vorstellen, was das bedeutet, wenn die ganze Organisation so ist. Vielleicht muss ich doch nach anderen jobs woanders schauen..
> Da gibts ja noch Kanban, Kaizen, Lean und wie sie alle heißen....
Just-in-time nicht zu vergessen.
Jay schrieb: > Das Wasserfall-Modell hingegen ist toll. Auf dem Papier. Es hat nur den > großen Nachteil, dass es häufig nicht funktioniert, weil sich die > Realität ums Verrecken nicht an das Modell anpassen möchte. Scrum ist Wasserfall im Kleinen ohne einen Plan vom Ganzen zu haben... Oder was soll das Sprint-Planning mit Backlog + Review sonst sein? Oder zum Spaß mal in Pseudocode
1 | #define doSprint waterfall
|
2 | |
3 | while (!outOfBudget) { |
4 | doSprint(); |
5 | }
|
6 | |
7 | bool waterfall() { |
8 | requirements(); |
9 | design(); |
10 | implement(); |
11 | if (time) { |
12 | verify(); |
13 | maintain(); |
14 | }
|
15 | return true; |
16 | }
|
Hallo Kollegen, wenn ich das hier so lese, kommt mir der Eindruck, als ob 99 Prozent aller Projekte baden gehen. Das entspricht überhaupt nicht meiner Erfahrung. Ich hatte in zwanzig Jahren genau ein Projekt in dem es kritisch war, und da hatte ein Kunde die Begriffe agil und Sprint falsch verstanden. Es ist eben nicht Coden bis die Finger bluten. Aber wie gesagt, es war für mich die Ausnahme. Ich hatte erfolgreiche Projekte mit und ohne scrum. Kritisch wurde es immer dann, wenn Kollegen sich bestimmte Technologien oder Vorgehensweisen in den Kopf gesetzt hatten um sie im Projekt zu lernen anstatt mit dem, was sie konnten, pünktlich eine solide Arbeit zu liefern. Aber das war unabhängig von der Organisationsform. Ich glaube, aus vielen Aussagen hier eine gewisse Unzufriedenheit mit der eigenen Situation heraus klingen zu hören. Ist es denn wirklich so schlimm? Ich bin auch seit zwanzig Jahren dabei, und ich wäre es nicht, wenn es mir keinen Spaß machen würde.
klausi schrieb im Beitrag #4347180:
> Da gibts ja noch Kanban, Kaizen, Lean und wie sie alle heißen....
Oder im Sichherheitskritischen Bereich:
DO-178, V-Modell XT; mit Schwerpunkt auf den gesamten SW-life cycle IEEE
12207 ...
Sichherheit ensteht eben nur wenn alles aufeinanderpasst.
Der Ansatz von SCRUM widerspricht dem zum Teil. "Wir wissen nicht was
der Kunde will also zeigen wir ihm jede Woche was wir so gemacht haben
und er kann dann sagen was ihm daran gefällt." So was funktioniert bei
Wischi Waschi
Oberflächen und macht da auch bei Kunden mit geringer (visueller)
Vorstellungskraft Sinn.
IMHO kommt bei SCRUM die Team-Aufstellung, Einarbeitung und "Schaffen
des Environments"-Phase zu kurz bzw. wird komplett ignoriert. Deshalb
scheitern ja auchso viele zusammengewürfelte ANÜ-Teams vom
Dienstleister.
MfG,
Andreas E. schrieb: > und da hatte ein Kunde die Begriffe agil und Sprint falsch > verstanden. IMHO ist das die schlechteste und dümmste Ausrede bei der Projekt-Retrospective: " Der Kunde hat SCRUM falsch verstanden " Warum hat man dann SCRUM angeboten bzw. durchgezogen wenn SCRUM und die Vorstellungen des Kunden nicht zusammenpassen? Klar SCRUM verleitet dazu utopische Vorstellung des kunden über kurze Lieferfristen ernst zu nehmen, weil SCRUM ja auf vielen inkrementellen Lieferungen aufbaut: Nach jedem Sprint kann man was präsentieren und den Kunden beruhigen. Die Zeit bis zur Abschlußlieferung wird aber dadurch auch nicht mehr, über Qualität kann zu schweigen. MfG,
Andreas E. schrieb: > Ich glaube, aus vielen Aussagen hier eine gewisse Unzufriedenheit mit > der eigenen Situation heraus klingen zu hören. Ist es denn wirklich so > schlimm? Und was soll falsch sein an der Unzufriedenheit? Jeder postet seine Erfahrung dazu, ich glaube nicht dass SCRUM automatisch gute Laune verursacht, dafür wurde es schließlich nicht erfunden. PS: Übrigens ist bei SCRUM kein menschlicher Faktor drin. Kein einziger.
Gästchen schrieb: > Und was soll falsch sein an der Unzufriedenheit? Jeder postet seine > Erfahrung dazu, ich glaube nicht dass SCRUM automatisch gute Laune > verursacht Das wollte ich auch gar nicht ausdrücken. Mir ist nur das Maß der Unzufriedenheit aufgefallen, und das ist imho ziemlich hoch. Überraschend für mich, denn aus meiner täglichen Arbeit kenne ich das anders. > PS: Übrigens ist bei SCRUM kein menschlicher Faktor drin. Kein einziger. Es sind die Menschen, die Erfolg haben oder eben nicht. Nicht die Methode. Es ist wie beim Fußball, man muss auch mal dem anderen die Vorlage geben damit er das Tor machen kann, selbst wenn der dann auf dem Podium steht und man selbst nur in der Mannschaft dahinter. Hauptsache ist doch, dass das Spiel gewonnen wird. Meine besten Projekte waren agil und mehr oder weniger scrum, sie lebten von der Flexibilität, vom Team und den einzelnen Menschen, die - so unterschiedlich sie auch waren - im Team mehr wert waren als die Summe der Einzelnen. Dass für einige vorher ein Erkenntnisprozess notwendig war, ist klar, aber ohne dieses Wir-Gefühl kann keine agile Methode funktionieren. Fpga K. schrieb: > Nach jedem Sprint kann man was präsentieren und den Kunden beruhigen. > Die Zeit bis zur Abschlußlieferung wird aber dadurch auch nicht mehr, > über Qualität kann zu schweigen. Genau das ist falsch, man muss dem Kunden klar machen dass er erst ab einer gewissen Vorarbeit etwas sehen kann, sonst wird gemockt dass die Schwarte kracht, und der Aufwand steigt ins Unermessliche. Wenn man die Cojones hat, dies zu tun, wird kein Kunde mit Unverständnis reagieren. Wer das nicht versteht, der hat mich nicht verdient. Punkt. Der nächste, bitte... Ich bin doch kein Kindermädchen für ahnungslose Manager.
Andreas E. schrieb: > Mir ist nur das Maß der Unzufriedenheit aufgefallen, > und das ist imho ziemlich hoch. Überraschend für mich, > denn aus meiner täglichen Arbeit kenne ich das anders. Ach naja, die Erklärung ist, glaube ich, nicht kompliziert: 1) Wir sind hier in "Ausbildung, Studium & Beruf". Hier muss aus Prinzip ALLES in Grund und Boden diffamiert werden. 2) Offensichtlich wird von diversen Führungskräften viel Schotter unter der Flagge "SCRUM" verkauft, der mit dem ursprünglichen Geist der Methode wenig bis nichts gemeinsam hat. Wenn z.B. eine von SCRUM Betroffene klagt, dass "das Vorbereiten der täglichen Präsentation unheimlich viel Zeit kostet", dann fragt man sich schon ernsthaft, welches Märchenbuch deren Chefs gelesen haben. Wo im agilen Manifest steht etwas von täglichen Präsentationen? > Meine besten Projekte waren agil und mehr oder weniger > scrum, sie lebten von der Flexibilität, vom Team und > den einzelnen Menschen, die - so unterschiedlich sie > auch waren - im Team mehr wert waren als die Summe > der Einzelnen. Dass für einige vorher ein Erkenntnisprozess > notwendig war, ist klar, aber ohne dieses Wir-Gefühl > kann keine agile Methode funktionieren. Ja. Ich denke, der Schlüssel liegt in der Erkenntnis, dass agile Methoden weder für alle Aufgabenstellungen noch für alle Teams gleichermaßen geeignet sind. > [...] sonst wird gemockt dass die Schwarte kracht, > und der Aufwand steigt ins Unermessliche. Das ist wohl kein Privileg agiler Methoden. Nimm mal an einem halbfertigen Wasserfall-Projekt eine halbwegs tiefgreifende Änderung vor und beobachte den Aufwand... Ach so, nochmal was anderes: Was sagst Du zu der Kritik, SCRUM sei abzulehnen, weil es sich lediglich um einen permanenten Krisenmodus handele?
Andreas E. schrieb: > Das wollte ich auch gar nicht ausdrücken. Mir ist nur das Maß der > Unzufriedenheit aufgefallen, und das ist imho ziemlich hoch. > Überraschend für mich, denn aus meiner täglichen Arbeit kenne ich das > anders. Du verwechselst hier etwas. Die Postings über Scrum sagen gar nichts über Zufriedenheit/Unzufriedenheit allgemein. Es kann sein dass man im Allgemeinen zufrieden ist aber Scrum Scheisse findet weil man sich davon gestört fühlt. Ich finde nicht dass es sich widerspricht. Und zum Thema "agil", was soll das eigentlich sein? Jedes Projekt was in guter Zusammenarbeit und unter Zeitdruck läuft, läuft agil. Man tut so als hätte man vorher geschlafen und jetzt höchst offiziell ganz "agil" und superschnell ist. So etwas kann doch nur ein BWL-ler glauben. Ohne den Quatsch mit Rechtfertigungen was man getan hat, Floor-Meetings und Zettelchen hatte man vorher mehr Zeit für eigentliche Arbeit.
Gästchen schrieb: > Und zum Thema "agil", was soll das eigentlich sein? Moment. Verstehe ich das richtig: Du diskutierst über agile Methoden, ohne zu wissen, was agile Methoden sind? > Jedes Projekt was in guter Zusammenarbeit und unter > Zeitdruck läuft, läuft agil. Quark. Einer der wesentlichen Pfeiler agiler Methoden ist das iterative Vorgehen. Um es einfach und bildhaft zu machen: "iterativ (agil)" - Heranwachsen eines Kindes "klassisch (Wasserfall)" - Montage eine Lokomotive > Man tut so als hätte man vorher geschlafen und jetzt > höchst offiziell ganz "agil" und superschnell ist. Au Mann... > So etwas kann doch nur ein BWL-ler glauben. Also, wenn Deine Chefs (oder gar Du selbst?) nicht den geringsten Schimmer haben, was die Kernidee agiler Methoden ist, dann sollte man das nicht den agilen Methoden anlasten...
Possetitjel schrieb: > Ach so, nochmal was anderes: Was sagst Du zu der Kritik, > SCRUM sei abzulehnen, weil es sich lediglich um einen > permanenten Krisenmodus handele? Das sehe ich überhaupt nicht so. Im Gegenteil, Scrum ist in der Lage, das Aufkommen von Krisen wirksam zu vermeiden. Gerade bei umfangreichen Projekten läßt sich der Ablauf weder vorhersagen, noch vorher bestimmen, und die kurzen Intervalle ermöglichen frühes Gegensteuern. Sei es, dass erkannt wird, dass ein Teilnehmer mit einer Teilaufgabe nicht klar kommt, sei es dass festgestellt wird, dass ein bestimmter Weg in dem speziellen Fall nicht gangbar ist, eine Aufgabe länger dauert als geschätzt, oder in kürzerer Zeit erledigt ist, im gleichberechtigten Team findet sich immer ein Weg der das Projekt nach vorne bringt. Und - was auch ganz wichtig ist - es findet sich für jede Teilaufgabe jemand, der sie gern übernimmt. Dazu gehört natürlich ein Team, das dies auch lebt, demokratisch und unambitioniert an die Sache heran geht. Wobei unambitioniert in dem Sinn zu verstehen ist, dass Teilnehmer ihre Begeisterung für ihre Ideen nicht in eine Hartnäckigkeit bei der Diskussion ausufern lassen. "Wenn ich eine Idee habe, dann stelle ich sie zur Diskussion und lasse die anderen entscheiden ob sie für das Projekt gut ist oder nicht" ist der einzige heilsbringende Weg. In dieser Weise gelebt ist scrum keine permanente Krise, sondern der Nährboden für eine zielführende, pragmatische und kreative Durchführung umfangreicher Entwicklungsprojekte. Was heute mit scrum gemacht wird, ist allerdings oft auch nicht im Sinne des Erfinders, die Instumentalisierung und Ideologisierung schadet dem Begriff und führt viele Vorgehensweisen ad absurdum. Ich verstehe daher auch die Ablehnung einiger. Die Vorgehensweise der Selbstorganisation von Teams in einem Projekt war ja schon vorher gang und gäbe, ich habe scrum gemacht lange vor dem agilen Manifest, weil es sich als Methode der effizienten Softwareentwicklung in kleinen Teams quasi von alleine ergab. Nun hat das Kind einen Namen und die Sache läuft aus dem Ruder. Es ist ein Schlagwort für Verkäufer geworden, das mit der Methodik - ob nun durch Zufall und Pragmatismus entstanden oder durch eine allgemeine Beschreibung einer Vorgehensweise - nich mehr wirklich viel zu tun hat.
Warum Scrum keine gute Idee ist, Projekt-Destruktor und
Motivations-Killer ist:
1. Agilität? -> :-) der Mensch kann gar nicht agil sein, der Mensch ist
keine Maschine, jede Person hat sein Charakter, unterschiedliche
Erfahrungen,
Gefühle usw. usw. Der Mensch wird krank.....
2. Die meisten Scrum Projekte scheitert, weil:
Man produktions/fertiguns-Methodiken 1:1 übernommen hat, bei denen ja
grundsätzlich Material/Grundlagen-Forschung, Produktionsplanung,
Rohstoffe usw. usw. komplett entwickelt und fertig sind, per Knopfdruck
passiert alles reibungslos("generell"). Aus dem Gründen die im 1. Punkt
genannt sind kann der Mensch all das garnicht realisieren, Krankheit,
keine kompletten Vorgehensweisen, falsche Implementierungen, Dokus sind
evtl. vorhanden aber nur Theorie geschweige denn praktisch 1:1
umsetzbar, große Abhängigkeiten die Zeitkosten verursachen.
3. Scrum wird vor allem vom bezogenem Management ausnahmslos missbraucht
und zwar von allen und in allen Projekten, Druck auszuüben und zu
kontrollieren.
4. Commitments werden ignoriert
usw.
usw..
usw...
zunächst mal Verzeihung, dass ich erst jetzt wieder zurückkehre. Das Thema bleibt spannend. Wir haben uns in den letzen 6 Monaten schwer getan, mit dem Thema etwas Sinnvoll an zufangen. Egal, was unterrichtet und erklärt wird, das Verhalten ist eigentlich immer gleich: Jeder weiß eigentlich, was gemeint ist, kann aber konkret nichts an seiner Arbeitstechnik finden, die er anpassen oder ändern könnte, um dem mehr gerecht zu werden. Will meinen, die meisten denken, sie arbeiten bereits nach optimierten Methoden. Bis jetzt hat es noch nichts gebracht, außer Arbeitsunterbrechungen für die Scrum-Schulungen. :-) Mehr Meinungen erbeten.
Ist halt das übliche Modependel in der IT. Zuerst hat man einfach drauflosentwickelt. Dann stellte man fest, daß das ins Chaos führt. Daraufhin hat man Prozesse eingeführt, um festzustellen, daß man dann nicht mehr flexibel ist und der Overhead wächst. Dann will man die Prozesse wieder reduzieren und bemerkt, wieso man sie noch gleich eingeführt hatte. Kurzum: Der Wunsch, immer komplexere Projekte einfach und berechenbar zu haben, ist einfach neben der Spur. Aber eine ganze Berater-Industrie lebt davon, die Illusion der Wunscherfüllung in immer neuen, wenn auch leeren Verpackungen zu verkaufen.
Nop schrieb: > Ist halt das übliche Modependel in der IT. Zuerst hat man einfach > drauflosentwickelt. Dann stellte man fest, daß das ins Chaos führt. > Daraufhin hat man Prozesse eingeführt, um festzustellen, daß man dann > nicht mehr flexibel ist und der Overhead wächst. Dann will man die > Prozesse wieder reduzieren und bemerkt, wieso man sie noch gleich > eingeführt hatte. Richtig. Ohne Prozesse hat man Chaos und beliebige Arbeitsergebnisse. Mit Prozessen hat man Verwaltungsaufwand, der einen davon abhält die eigentliche Arbeit zu machen. > Kurzum: Der Wunsch, immer komplexere Projekte einfach und berechenbar zu > haben, ist einfach neben der Spur. So ist es. Es gibt keine Vorgehensweise, die immer und für jegliche Art von Projekt passt. Sei es nun SCRUM oder irgend etwas anderes. Reinhard S. schrieb: > Mehr Meinungen erbeten. Eine clever agierende Firma wird sich anschauen, was für Möglichkeiten es gibt um ein Softwareprojekt zu organisieren. Von diesen Möglichkeiten wird man eine auswählen, die man für das aktuelle Projekt für geeignet hält. Abhängig davon, welche Rückmeldungen die eigenen Leute geben, wird man entsprechend nachjustieren. Wenn eine Firma saudumm ist, wird sie die eigenen Leute ignorieren und ihnen irgendeinen Prozess überstülpen, egal ob der nun passt oder nicht. Meistens passt er dann nicht. SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will, kann man ihm nach jedem Sprint eine Software ausliefern und seine Rückmeldungen in den nächsten Sprint einfließen lassen. Das setzt freilich voraus, dass der Kunde aktiv am Projekt mitarbeitet und regelmäßig entsprechende Rückmeldungen gibt. Für Projekte mit vertraglich klar festgelegtem Leistungsumfang, bei denen etliche Normen und Zulassungsregeln für die Software einzuhalten sind, ist SCRUM eher weniger geeignet.
:
Bearbeitet durch User
Ich kenne übrigens sowohl prozeßlastige Arbeitsweisen wie auch eher lose strukturierte. Letzteres hieß im Wesentlichen, daß die Entwickler sich selber organisiert haben. Witzigerweise war das Endergebnis genau andersrum, als man es glauben würde. Aus strukturierten Prozessen wurde Chaos, weil Dinge nicht rechtzeitig bedacht wurden und die Leute entweder nicht miteinander geredet haben oder keiner wirklich den Weitblick hatte, die Spec auch wirklich tauglich zu schreiben. Und dann waren die Prozesse im Weg, um die Versehen schnell wieder geradezuziehen. Das eigentlich unorganisierte Chaos wurde dagegen gut, weil die Entwickler sich geeinigt haben, welcher Teilcode wem "gehörte", wodurch man immer erst um Erlaubnis fragen mußte, wenn man da ranwollte. Das kam eigentlich zunächst als Notbehelf gegen Mergekonflikte, wuchs sich dann aber effektiv bis zu Designreviews aus. Völlig ungesteuert vom Management wohlgemerkt, welches diese Entwicklung einfach nur mit wöchentlichen abteilungsweiten Frühstücks"meetings" unterstützt hat, das war Selbstorganisation. Nur, dazu braucht man halt auch die entsprechenden Leute.
Nop schrieb: > Nur, dazu braucht man halt auch die entsprechenden Leute. Ja. Wenn man lauter fähige Leute hat, mag das gehen.
D. I. schrieb: > ann man mit einem soliden kommt darauf an beantworten. Prozesse sind > immer nur so gut wie sie von den beteiligten Personen verstanden und > gelebt werden. > Habe sowohl schon gute als auch schlechte Ausprägungen gesehen. Je mehr die Prozesse den MAs nutzen um so mehr werden diese genutzt und gelebt.
Agile Entwicklung ist durchaus weit verbreitet.
SCRUM ist eine Variante davon.
Meine Erfahrung ist, dass der Begriff "Agile Entwicklung" von Managern
vielschichtiger Konzerne gerne missbraucht wird, um geregelte Prozesse
zu umgehen und die Schuld für Versagen den Entwicklern am unteren Ende
der Hierarchie zuzuschieben.
Wenn Zeit oder Geld knapp werden, verfällt man plötzlich in flexible
"agile" Arbeitsweisen, wo man auf Projektleitung und Dokumentation
verzichtet. Wenn dann außenstehende erste Sorgen äußern, weist man
darauf hin, dass SCRUM doch eine bewährte Methode sei und wir machen
jetzt SCRUM. Was allerdings eine glatte Lüge ist.
> Mir scheint, dem SCRUM-Master wird eine verlogene Aufgabe gestellt
Allerdings, leider habe ich das häufig so erlebt.
Womit ich allerdings sehr gute Erfahrung gemacht habe, ist die
"Matrixorganisation", die bei Vodafone in der Technik eingeführt wurde.
Jeder Abteilungsleiter hatte für seine Abteilung spezifische Ziele für
deren Erreichung er belohnt wurde. Und die hat er auf seine Mitarbeiter
verteilt. Also hat sich jede Abteilung gewollt primär um die Erfüllung
dieser Ziele gekümmert. Damit waren Zeit und Budget in der Regel auch
schon ausgelastet.
Nun gab es technische Projekte, an denen Mitarbeiter zahlreiche
Abteilungen zusammen arbeiten mussten. Da aber die eigenen Interessen
Vorrang hatten, liefen diese Projekte immer schlecht. Und doch hat jeder
genau das getan, was man von ihm verlangte. Wer sich zu tief in ein
Projekt reinhängte, vernachlässigte zwangsläufig die Ziele seiner
Abteilung und brachte damit seinen Vorgesetzten um seinen Bonus.
In der danach neuen Matrixorganisation verdoppelte man quasi die
Führungskräfte. Die Abteilungsleiter unterschrieben Urlaubsanträge und
die neuen technischen Projektleiter waren nur jeweils 1-2 Projekte
zuständig. Zu hatten dazu Budget und Weisungsbefugnisse. Wenn mein
Abteilungsleiter mich für irgendeine Aufgabe haben wollte, musste er
sich mit dem Projektöleiter abstimmen. Bei Ressourcen-Konflikten mussten
sich die Projektleiter untereinander abstimmen - was wöchentlich
regelmäßig passierte.
Es gab damals viele starke Bedenken gegen diese Matrix-Organisation
(auch von mir), aber letztendich hat sie sich bewährt.
Warum ich das schreibe: In einer Matrix Organisation kann der technische
Projektleiter den SCRUM Master spielen, denn er hat die dazu nötigen
Mittel.
Meine Erfahrung mit Scrum, wie auch mit Prince und PMI sind leider eher mittelgut. Wenn im Change-Management auf einmal ein riesiges Fass aufgemacht wird, es zwanzig Beteiligte gibt, das Kick-In schon 2 Wochen dauert und es eigentlich nur einen Tag "Extreme Programming" durch einen der Treiberentwickler oder GUI-Leute benötigt hätte, dann besteht der Hund zu 95% nur noch aus Schwanz. Die echt guten Projekte mit solchen Managementsystemen (in Reinform) waren große Projekte die irgendwas aus dem Nichts erschaffen haben und wo der Projektleiter ein Externer war, der echt nur das Projekt fair geleitet hat. Oft werden in echten Firmen und echten Projekten eigene Middleware-Frameworks und hauseigene Standardtechniken eingesetzt, die dann zu Produkten führen. Wenn man sowas zu sehr in die Prozesse einer Projektleitung durch den Kunden zwingt wird einfach nur Geld verbraten. Auch ITIL und andere Servicemanagementsysteme können übertrieben eingesetzt werden.
>> Ich habe noch nie ein SW-Projekt gesehen, in dem wirklich alles komplett >> spezifiziert war. Gibt es sowas? > Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil > sie komplett nach Indien outgesourced werden. Habe ich erlebt. Da wurde eine tabellarische Ansicht von Datensätzen skizziert, mit Buttons für Löschen und Ändern. Nur hatte man vergessen, zu erklären, dass der "Löschen" Button den Datensatz daneben löschen soll. Die "Inder" Lieferten also ein Web-Interface mit Löschbutton, der keine Funktion hatte. War ja so bestellt. Wenn das die einzige Macke dieser Art gewesen wären, könnte man ja noch drüber lachen. Aber leider lief es so, dass nach Ablieferung ein Team in DE noch weitere 2 Jahre an dem Programm arbeiten musste, um es überhaupt benutzbar zu machen. 2 Jahre Zeit und Geld über dem Ziel - ein Desaster! Und als wir dann fertig waren, guckten wir in 20 Enttäuschte Gesichter bei den Anwendern, da sich die Prozesse im Unternehmen inzwischen geändert haben und das neue Programm ist nun (mangels Anpassung) gar nicht besser, als das alte.
> SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum > Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will, > kann man ihm nach jedem Sprint eine Software ausliefern und seine > Rückmeldungen in den nächsten Sprint einfließen lassen. Das setzt > freilich voraus, dass der Kunde aktiv am Projekt mitarbeitet und > regelmäßig entsprechende Rückmeldungen gibt. Sehr gut, das müsste man in jede Ausgabe des Manager Magazins schreiben.
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Ich kennen keinen Laden mehr der das NICHT einsetzt, jede kleine Klitsche nutzt das inzwischen. > Meinungen zu dem System sind wilkommen. Hatten wir das nicht erst. > Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. Ich kenne keinen Laden wo das wieder abgeschafft wurde. Vielleicht etwas in den Details ewtwas angepasst aber im Prinzip immer noch SCRUM.
Rasenmäher schrieb: >> Vor allem würde mich interessieren, wo das System eingeführt >> oder angedacht - und dann wiede abgeschafft wurde. > Ich kenne keinen Laden wo das wieder abgeschafft wurde. Vielleicht etwas > in den Details ewtwas angepasst aber im Prinzip immer noch SCRUM. Das halte ich für ein Gerücht. Nicht überall kann man irgendetwas lauffähiges ständig verbesserbares herstellen und alle sind gleichgut auch in der Lage eine Software zu Testen oder deren Architektur zu überblicken. Sowas setzt man eher in kleineren "Läden" ein um eine bestimmte Sache zu erledigen zu der es ein fertiges Pflichtenheft gibt. Bei steigender Teamgröße und Komplexität und bei steigender Spezialisierung der Projektteilnehmer bremst das reine SCRUM enorm aus.
Mir kommt es vor, als wäre SCRUM von und für Entwickler ausgedacht worden, aber die ganze Firma und der Kunde sollen mitspielen. Denn sonst funktioniert SCRUM nicht. Nur: In welcher Welt bestimmen die Entwickler, wie es läuft? In meiner nicht. Also beschränkt man sich bei der Anwendung von SCRUM auf den Bereich der Entwickler, und genau deswegen funktioniert es nicht. Agile Entwicklung ist Ok, aber nach SCRUM Methode hatte ich leider noch kein Erfolgreiches Projekt miterleben dürfen.
Stefan U. schrieb: > Mir kommt es vor, als wäre SCRUM von und für Entwickler ausgedacht > worden Nein, es ist vor allem so bliebt, um die Leistung der Programmiererschaft in betriebswirtschaftlichen Zahlen messen zu können, "Velocity" ist wichtig, die Richtung in die es geht eher nicht. Stefan U. schrieb: > Agile Entwicklung ist Ok Nicht wirklich. Jede Änderung der Aufgabenstellung kann ggf. zur zunichtemachung aller bisherigen Arbeit führen, bedeutet also deutliche Mehrarbeit, verlängerte Projektlaufzeit, mehr Kosten, Arbeit für die Katz. Mit einer Entwicklung anzufangen, obwohl Kunden und Architekten nicht klar ist was das Projekt enthalten soll, ist halt voreilig. Agil ist nur nötig, wenn man es mit Leuten zu tun hat die nicht wissen was sie wollen oder können, (das hat man natürlich oft genug). Mark B. schrieb: > SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum > Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will, > kann man ihm nach jedem Sprint eine Software ausliefern und seine > Rückmeldungen in den nächsten Sprint einfließen lassen. Jein. Wer regelmässig etwas vorzeigbares abliefern soll, baut keine Strukturen die einen guten Unterbau liefern, sondern baut schnell in die Höhe. Auch wenn ihm dann die Hilfsmittel fehlen, um den zeiten Turn daneben mit weniger Aufwand setzen zu können. Typischer Fall sind Dialoge oder Datenbanken: Da wird Dialog für Dialog gebaut, oder Datenbanktabelle für Datenbanktabelle, bloss mit den Hilfsmitteln die sowieso schon vorlagen also vom Softwarehersteller (ob Microsoft oder SAP, ..) , weil das ja vorzeigbarer Fortschritt ist, an statt erst mal Strukturen zu schaffen, die dann Dialoge und Datenbanktabellen im Idealfall automatisch generieren, zumidnest aber deren Daten automatisch hinein und hinaustransportieren. Weil dieser Unterbau ja für sich nicht lauffähig und vorzeigbar ist.
MaWin schrieb: > Weil dieser Unterbau ja für sich nicht lauffähig und vorzeigbar ist. Vor allem nicht vorzeigbar. Hauptsache man hat jede Woche etwas was man dem Chef, dem Vertriebler, dem Kunden oder sonstigen Personen für die ein Taschenmesser schon high tech ist "zeigen" kann.
MaWin schrieb: > Mark B. schrieb: >> SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum >> Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will, >> kann man ihm nach jedem Sprint eine Software ausliefern und seine >> Rückmeldungen in den nächsten Sprint einfließen lassen. > > Jein. Wer regelmässig etwas vorzeigbares abliefern soll, baut keine > Strukturen die einen guten Unterbau liefern, sondern baut schnell in die > Höhe. Auch wenn ihm dann die Hilfsmittel fehlen, um den zeiten Turn > daneben mit weniger Aufwand setzen zu können. Typischer Fall sind > Dialoge oder Datenbanken: Da wird Dialog für Dialog gebaut, oder > Datenbanktabelle für Datenbanktabelle, bloss mit den Hilfsmitteln die > sowieso schon vorlagen also vom Softwarehersteller (ob Microsoft oder > SAP, ..) , weil das ja vorzeigbarer Fortschritt ist, an statt erst mal > Strukturen zu schaffen, die dann Dialoge und Datenbanktabellen im > Idealfall automatisch generieren, zumidnest aber deren Daten automatisch > hinein und hinaustransportieren. Weil dieser Unterbau ja für sich nicht > lauffähig und vorzeigbar ist. Man könnte wohl argumentieren, dass das Problem "Kunde weiß nicht so genau was er will" auch anders gelöst werden kann. Indem fähige Entwickler, die keine Vollnerds sind sondern die mit Menschen sprechen können :-) mit dem Kunden reden und ihm Vorschläge für seine Aufgabenstellung machen. Wenn in großen Firmen Leute im Vetrieb sitzen, die von Software keine Ahnung haben, dann wird das natürlich schwierig.
> Agil ist nur nötig, wenn man es mit Leuten zu tun hat > die nicht wissen was sie wollen Ist das nicht fast immer der Fall? Deswegen meine ich ja, dass agile Entwicklung Ok ist. Denn wer nicht mit macht, sitzt draußen vor der Türe. > Weil dieser Unterbau ja für sich nicht lauffähig und vorzeigbar ist. Die wichtigen Personen interessieren sich ohnehin eher für Powerpoints, die super komplex und doch nachvollziehbar wirken. Ich sage nur SAP Hybris... > Indem fähige Entwickler, die keine Vollnerds sind sondern die > mit Menschen sprechen können :-) mit dem Kunden reden und ihm > Vorschläge für seine Aufgabenstellung machen. Ich bin immer dankbar, wenn es solche Menschen im Projekt gibt, die mir (kommunikationsmuffel, nerd, programmierer) den Rücken frei halten.
Rasenmäher schrieb: > Ich kenne keinen Laden wo das wieder abgeschafft wurde. Vielleicht etwas > in den Details ewtwas angepasst aber im Prinzip immer noch SCRUM. Meine Erfahrung ist eine andere. Viele behaupten sie würden nach SCRUM arbeiten. In Wirklichkeit wursteln sie einfach dahin, und Leute wie Mawin glauben dann der Schrott wäre SCRUM.
Jan H. schrieb: > Leute wie Mawin glauben dann der Schrott wäre SCRUM. Hallo Trottel. Hättest du meine Beiträge gelesen MaWin schrieb: > Quasi jeder macht Scrum - oder was er dafür hält. würdest fu meinen Namen hier nicht nennen. Aber Trottel wie du sondern ja meist auch nur einen Sstz ab: "Wenn Scrum schief geht, liegt es nur daran, dass ihr nicht 100% Scrum nach der reinrn Lehre gemacht habt - denn Scrum ist per Definition unfehlbar, nur die Mitarbeiter unfähig" Das ist dann so wie mit dem Sozialismus dem du noch nachweinst...
Man hat schon des öfteren gehört, dass Firmen behaupten sie würden nach SCRUM entwickeln. In Wahrheit haben sie ihrer chaotischen und planlosen Vorgehensweise einfach nur einen neuen Namen gegeben. ;-)
MaWin schrieb: > Hallo Trottel. Ui, da habe ich ja einen wunden Punkt erwischt :) > Aber Trottel wie du sondern ja meist auch nur einen Sstz ab: > "Wenn Scrum schief geht, liegt es nur daran, dass ihr nicht 100% Scrum > nach der reinrn Lehre gemacht habt - denn Scrum ist per Definition > unfehlbar, nur die Mitarbeiter unfähig" Nein, ich sage wenn man irgendetwas macht, SCRUM draufschreibt, und dann geht es in die Hose, dann ist nicht SCRUM schuld. Meiner Erfahrung nach machen nur die wenigsten, die es behaupten, wirklich SCRUM. Diejenigen, die es ordentlich durchziehen, fahren sehr gut damit. Aber wir drehen uns in diesem Thread eh im Kreis, alles wurde schon mehrmals geschrieben. > Das ist dann so wie mit dem Sozialismus dem du noch nachweinst... Was soll denn das mit dem Thema zu tun haben, hast du schon das Alter erreicht in dem bei Stress die Russenangst aufkommt?
Reinhard S. schrieb: > Meinungen zu dem System sind > wilkommen. Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. Hallo Reinhard, in der Regel wird Scrum dort eingeführt (wenn man es überhaupt richtig aufsetzt) wo gleichwertige wiederkehrende Tätigkeiten anfallen, z.B. im Softwarebereich. Scrum macht eher Sinn für unerfahrene Mitarbeiter die richtige Kommunikation noch nicht drauf haben, Erfahrene brauchen Scrum nicht und ihre Arbeitsergebnisse sind sogar ohne Scrum besser da Scrum hier eher Grundlast ist. Bei enger Zusammenarbeit mit Kunden mit hoher Flexibilität ist Scrum nicht möglich, so viel muss gesagt werden. Es gibt auch Härtefälle mit Scrum: oft fallen die Chefs auf das Versprechen der Unternehmensberater rein dass der Gewinn größer wird und dass sie und die Führungskräfte weniger arbeiten werden (die Organisation rutscht in Scrum nach unten ab) und Scrum wird als universelle neoliberale Wunderreligion verstanden die alle Probleme löst, und wird dort eingeführt wo sie nichts zu suchen hat. Scrum hat keinen menschlichen Faktor drin und sieht eher einen Akkord-Ablauf vor, auch jegliche Kritik für Scrum ist nicht zugelassen. (Diktat) Fazit: bei Scrum wird typischerweise aus einer Mücke ein Elephant gemacht. Für effizientes Arbeiten mit nachvollziehbaren Tätigkeiten und angemessener Kommunikation reichen schon ein Paar einfache Tools, die Pseudoreligion der Basarwirtschaft ist hier kein Muss.
Liebe Mitarbeiter, heute stellen wir unsere Entwicklung auf SCRUM, UML und NoSQL Datenbanken um. Sie werden alle drei Wochen geschult und danach werden wir das Vorbild für die Industrie 5.0 im internationalen Markt sein. Die Kosten für die Schulungen werden Ihnen vom nächsten Leistungsbonus abgezogen - Wirtschaftliche Rahmenbedingungen zwingen uns leider zu diesem Schritt. James, bitte fahren Sie den Jaguar vor und lassen sie den Schneider kommen, ich möchte heute Abend beim Meeting auf den Seychellen angemessen erscheinen. Ach und Frau Meier, stornieren Sie das Essen im Steigenberger, ich muss noch den Heli für die Benefizgala auswählen. Nun denn, liebe Mitarbeiter: Frohes schaffen!
Jan H. schrieb: >> "Wenn Scrum schief geht, liegt es nur daran, dass ihr nicht 100% Scrum >> nach der reinrn Lehre gemacht habt - denn Scrum ist per Definition >> unfehlbar, nur die Mitarbeiter unfähig" > > Nein, ich sage wenn man irgendetwas macht, SCRUM draufschreibt, und dann > geht es in die Hose, dann ist nicht SCRUM schuld. > Meiner Erfahrung nach machen nur die wenigsten, die es behaupten, > wirklich SCRUM. Diejenigen, die es ordentlich durchziehen, fahren sehr > gut damit. Vielen Dank für die Bestätigung meiner Vermutung.
Hier im Forum können die wesentlichen Probleme, die man mit Scrum Projekten (oder agil im Allgemeinen) so haben kann und die zu negativen Denken darüber führen, ziemlich genau beobachtet werden :). Wir entwickeln embedded Projekte nach Scrum, und auch hier kann man relativ gut damit arbeiten. Zu den Problemen, die meiner Meinung nach hier implizit geäußert wurden, und die zu einem eher negativen Meinung führen: 1) Scrum wird (von unwissendenden) gerne als Allheilmittel gesehen. Das ist es aber nicht. Auch eignet sich Scrum nicht für jedes Projekt (Projekte die ein festes Pflichten-/Lastenheft mit festen Zeitpunkten haben sind eher nicht geeignet). Da das hier aber eher ein Forum für Ingenieure ist, ist tendentiell IMHO die falsche Zielgruppe betroffen (es soll möglichst viel planbar sein, deswegen auch Pflichten-/Lastenheft). Scrum ist ein Vorgehensmodell das, richtig angewendet, sehr zielstrebig funktioniert. Leider soll aber nicht der Kunde sagen können, ich will das xy bis zum 10.12. fertig ist. Das ist eher eine Entscheidung des Teams, was für viele Softwareprodukte überhaupt kein Problem ist (z.B. Officeprogramme: Feature xy gibts vielleicht in Release 1.2, wenns aber erst in 1.21 kommt ist das auch nicht schlimm), aber für typische Embeddedprodukte einfach nicht funktioniert. 2) Scrum wird gerne als "Unorganisiert" dargestellt, das einem Planung abnimmt. Meiner Meinung nach (ich habe sowohl positive als auch in Firmen negative Erfahrungen gemacht), ist es eher umgekehrt. Scrum braucht unglaublich viel Disziplin und Planung, aber nicht alles in einer Hand. Der Product Owner muss sich darum kümmern um mit dem Kunden auszumachen, welche Features er haben will (inkl. Priorisierung). Aber das Team entscheidet, bei welchem Sprint was mit reinkommt. D.h. der Kunde hat keinen direkten Einfluss darauf, was gemacht wird. Durch die kurzen Zyklen muss gleichzeitig das ganze Team sehr strukturiert arbeiten, weil schwere Fehler in max. 4 Wochen quasi nicht behebbar sind. Scrum verlangt viel Planung, aber diese ist in kürzen Abständen (eigentlich leichter planbar). Gleichzeitig braucht man auch einen groben Gesamtplan. 3) Gruppengröße. Kurz und Knapp. Ein Scrum Master + Product Owner ist Pflicht, dazu noch 4- 7 Entwickler. Mehr macht keinen Sinn. Hier wollen Firmen gerne sparen und machen größere Gruppen oder wollen sich den Scrum Master (der ja effektiv nicht direkt für die Firma was erbringt) sparen. Das ist Bullshit. Oder der Scrum Master ist ein Entwickler. Auch das ist nicht förderlich, sondern macht das Ding kaputt. 4) Managment: In größeren Firmen geben Vorgesetzte ungern Verantwortung nach unten ab. Geht da nämlich was schief, rollen Köpfe. Das ist ein weiteres Problem. Mangelndes Vertrauen, jeder will sich immer nur absichern (kommt auch schon mal innerhalb des Teams vor). Dann funktioniert sowas natürlich nicht. Leitende Angestellte mischen sich dann ein, erteilen "Befehle" (Feature xy muss noch rein, wenn das nicht passiert, dann gibts aufn Latz). Sowas ist scheiße und zeugt davon, dass derjenige von Scrum keine Ahnung hat. Dann braucht man sich nicht wundern wenn was schiefgeht. 5) Erfahrung: Bei meiner BA haben die Abteilungen auch nach "Scrum" gearbeitet. Natürlich nur so halb... Nach meiner Frage, wer den der Scrum Master ist: "Den brauchen wir nicht. Bei Problemen geh doch zu deinem Vorgesetzten". Genau das macht Scrum kaputt.
ui schrieb: > Wir entwickeln embedded Projekte nach Scrum, und auch hier kann man > relativ gut damit arbeiten. > Das ist > eher eine Entscheidung des Teams, was für viele Softwareprodukte > überhaupt kein Problem ist (z.B. Officeprogramme: Feature xy gibts > vielleicht in Release 1.2, wenns aber erst in 1.21 kommt ist das auch > nicht schlimm), aber für typische Embeddedprodukte einfach nicht > funktioniert. Sehe ich da einen leichten Widerspruch? ;-) Ansonsten stimmt es was Du sagst. SCRUM kann man für manche Arten von Projekt einsetzen, aber eben nicht für alle. Die typische PC-Software wie etwa Office, Browser, Bildbearbeitung usw. kann man nach SCRUM entwickeln. Bei Software, die Sicherheitsanforderungen genügen muss und die einen langwierigen Zulassungsprozess hat, ergibt SCRUM keinen Sinn.
:
Bearbeitet durch User
Mark B. schrieb: > Man hat schon des öfteren gehört, dass Firmen behaupten sie würden > nach SCRUM entwickeln. In Wahrheit haben sie ihrer chaotischen und > planlosen Vorgehensweise einfach nur einen neuen Namen gegeben. ;-) kommt mir bisweilen auch so vor. Hauptsache man klingt international - Englisch.
Stefan U. schrieb: > Liebe Mitarbeiter, > > heute stellen wir unsere Entwicklung auf SCRUM, UML und NoSQL > Datenbanken um. Sie werden alle drei Wochen geschult und danach werden > wir das Vorbild für die Industrie 5.0 im internationalen Markt sein. Hallo, vielleicht als Tipp für einen angehenden "Scrummer": stelle sicher dass eure Sprints für 100% Auslastung ausgelegt werden. Wenn das nicht so ist, werdet ihr neben eure Sprints noch Nebenaufgaben erledigen müssen, wenn beispielsweise euer Gescrumme auf 70% Auslastung ausgelegt ist. So guckt manch ein "Scrummer" ganz schön erstaunt aus der Wäsche wenn er zum Sprint noch eine schöne Aufgabe bekommt. Schöner Trick, was? Gruß.
Gästchen schrieb: > vielleicht als Tipp für einen angehenden "Scrummer": Vielleicht als Tipp für Profi-Scummer: Der zitierte Beitrag war Ironie. Kann man natürlich während eines "Sprints" mal übersehen.
Mark B. schrieb: > ui schrieb: >> Wir entwickeln embedded Projekte nach Scrum, und auch hier kann man >> relativ gut damit arbeiten. > >> Das ist >> eher eine Entscheidung des Teams, was für viele Softwareprodukte >> überhaupt kein Problem ist (z.B. Officeprogramme: Feature xy gibts >> vielleicht in Release 1.2, wenns aber erst in 1.21 kommt ist das auch >> nicht schlimm), aber für typische Embeddedprodukte einfach nicht >> funktioniert. > > Sehe ich da einen leichten Widerspruch? ;-) Schon leicht. Da wir aber (als Team) von Anfang an die Dinge richtig geregelt haben (auch nach "oben" hin), funktioniert das bei uns (bis jetzt, ca. 9 Monate) richtig gut.
> Ich krieg jeden Tag meherere solcher Mails.
Was für Mails? Meinst du Werbung für SCRUM Seminare?
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Meinungen zu dem System sind > wilkommen. Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. SCRUM ist doch nur eine weiterer schwachsinniger Hype, von Consultants, Fachzeitschreiften, Buchverlagen und Softwareherstellern inszenizert, weil die ständig eine neue Sau durchs Dorf treiben müssen, um Geld zu verdienen. Bei uns wurde SCRUM eingeführt und dann wieder abgeschafft, weil es nicht funktioniert hat. Später nach einem Projektleiterwechsel wurde es erneut eingeführt. Aber ich musste Gott sei Dank nicht mehr an diesen schwachsinnigen Meetings teilnehmen, wo sowieso immer nur dieselben zwei, drei Leute ihr Maul aufgerissen haben. Aber da ich nicht mehr teilnehme, weiß auch nicht, ob es diese Meetings überhaupt noch gibt oder ob das schon wieder abgeschafft wurde.
Alles halb so wild, man muss nicht einmal wissen, dass man daran teilnimmt. Mein liebstes Scrumerlebnis war als jemand bei einer Abschlusssitzung (Kick-Off-Meeting, g) voll von höchstem Lob über mich äußerte, dass ich ein guter "Product Owner" war und das "Backlog" total super, wobei ich nicht einmal wusste, dass die Scrum einsetzen und dass es ein Backlog gibt. Es gab nur ein detailliertes Lastenheft, welches ich mit dem Endkunden erfasst und denen weitergegeben hatte.
Wenn ich das so lese, kann ich nur sagen, dass jeder offenbar ein völlig anderes Bild von SCRUM hat und es überall unterschiedlich gelegt wird. Und: Ich sehe, dass wieder viel bullshit bingo betrieben wird. Neue Begriffe für alte Fakten in neuen Schläuchen!
Reinhard S. schrieb: > Wenn ich das so lese, kann ich nur sagen, dass jeder offenbar ein völlig > anderes Bild von SCRUM hat und es überall unterschiedlich gelegt wird. SCRUM ist sehr eng definiert. Meiner Beobachtung nach gibt es einerseits die Leute, die das verstehen und beachten, und die haben dann auch ein sehr ähnliches Bild davon. Und dann gibt es viele, die SCRUM auf ihre bisherige Wurstelei draufschreiben und sich dann darüber beschweren, dass es nicht funktioniert.
Ich habe mich inzwischen näher damit befasst. Allerdings sehe Ich bei eigenen Erfahrungen und auch in der Literatur so richtig Neues nicht.
Jan H. schrieb: > SCRUM ist sehr eng definiert. Meiner Beobachtung nach gibt es einerseits > die Leute, die das verstehen und beachten, und die haben dann auch ein > sehr ähnliches Bild davon. Gibt es vielleicht ein/zwei gute Bücher als Empfehlung.
Bücher kann Ich Dir da keine empfehlen, wenngleich es etliche gibt, aber eine Latte an Erfahrungen mit dem Thema habe Ich, die Ich Dir gerne weitergebe: SCRUM ist für mich nichts anderes, als dem unorganisierten Chaos in vielen Firmen einen Namen zu geben, damit es besser klingt. Die Methoden sind oft nicht wirklich "agil" oder gar "schnell", sondern es ist oftmals langsamer und weniger effektiv. Von den ständigen und vor allem täglichen Abstimmungen halte Ich überhaupt nichts. Da stehen nur alle passiv in der Gegend herum und erzählen, was sie gerade gemacht haben und was sie tun wollen. Richtig in die Tiefe geht das nicht und nutzen tut es auch keinem wirklich, weil es nur der Aufgabendeklaration und -Verfolgung dient. Kaum einer hat wirklich Überblick, was der andere wirklich tut und kann ihm auch nicht helfen oder gar Tipps geben. Meist kommen nur kluge Kommentare und allseitiges Kopfnicken, was aber oberflächlich und oft falsch ist. Nur fundiertes Wissen über Details befähigt zur Stellungnahme. Alle anderen halten bei dem detaillierten Vorgehen besser die Klappe und kümmern sich um ihr Arbeitspaket. Sinn macht es im Grunde nur für den Projektleiter, damit er die Infos beitreiben kann, um die Koordination zu leisten, aber das könnte er auch anders tun. Viele "Scrum Master" machen es so, dass sie ganze Wände mit bunten Zetteln vollkleben, auf denen die Aufgaben und Stati notiert sind, damit es schön dynamisch aussieht. Ausser in den Meetings kuckt da aber keiner drauf, um Fortschritte an Projektaufgaben zu erkennen und sich darauf takten zu können, daher ist der Wert Null. Real meldet man das Ende eines Tasks dann doch, wenn er fertig ist, damit der andere es direkt erfährt und nicht erst am nächsten Tag im Meeting. Vor allem ist es zeitlich sehr ineffektiv: Während einer redet, hören die anderen zu, können aber mit der Info nichts rechtes anfangen, weil sie die Details nicht kennen und von dem lediglichen Beschluss einer Aufgabenstarts nichts haben. Stattdessen unterhalten sie sich privat, schaukeln auf dem Stuhl herum, bis sie dann sind und überlegen sich bis dahin, wie sie am intelligentesten ihre Defizite an ihrem Vorankommen verstecken können und sich trotzdem toll präsentieren können, um eventuelle Rückfragen zu vermeiden. Kritisches Nachfragen zu Lösungen wird ohnehin abgewimmelt, teils zu Recht - teils zu unrecht. Egal wie, am Ende wurschtelt doch wieder jeder vor sich hin und organisiert sich selber, weil irgendwas anders läuft, er es nicht geplant hat, nicht voraussehen können oder weil ihm was fehlt. Besser ist es, man organisiert die Arbeitspakete so, dass die Leute mal 3 Tage arbeiten können, ohne sich synchen zu müssen. Nur das ist effektiv. Dann kann jeder ungebremst durch SCRUM seine eigenen Planänderungen lokal durchziehen ohne andere mit abzubremsen. SRUM ist daher mit der Art der Durchführung eine Methode, die ihrem eigenen Anspruch im Wege steht! Statt grobe short- und long-Task in "sprints" und "claims" zu organisieren und diese stündlich zu überwachen um ständig die Orga anzupassen, wäre es besser, die Tasks genauer zu beschreiben, diese länger aufzuziehen und eine Person gleichzeitig auf 3 Tasks zu setzen, die sie mit den jeweiligen members lokal organisiert, um auf deren Schwankungen einzugehen. Ich als Selbständiger habe dann auch nicht das Problem, ständig anwesend zu sein, um dann doch nichts vom Meeting zu haben, ausser irgendwo eingeplant zu werden, was dann doch nicht funktioniert, weil das team member überzieht, nicht anwesend ist und mir dann schnell was anderes zugewiesen wird, damit ich keinen Leerlauf habe. 30% der Zeit geht so fürs Planen drauf und fürs Umplanen und Ändern oder das Wegwerfen nutzloser Vorausarbeit oder Vorausdenken oder Absprachen eines Tasks, der schon einen Tag später wieder verworfen wird. Die Task selber sind dabei aber so überflächlich definiert, dass die formelle Darstellung am Tableau eher verwirrt und Chaos verursacht, z.T. zu Fehlschlussfolgerung führt. Was hingegen nötig wäre, ist eine sinnvolle Aufteilung der Arbeit in kleine abgeschlossene Blöcke, die aber ausreichend lang sind umd dann selbständig und alleine ohne andere geleistet werden können, damit die Anzahl der Schnittstellen und Absprachen klein bleibt. Das eigentliche Ziel einer Projektleitung muss daher sein, das Projekt zu "entscummen", d.h. die Notwendigkeit der Absprachen zu reduzieren. Innerhalb einer solchen long term Aufgabe muss sich dann jeder selber organisieren und sich ad hoc mit den anderen absprechen. Das geht aber nicht im daily scrum meeting. Das nimmt den Leuten nur Arbeitszeit weg und mindert die Leistung. Es blockiert auch die Terminoptionen für gegenseitige Absprachen untereinander. Diese sind aber die wichtigen und sie müssen dann geführt werden, wenn sie anfallen. Wenn Ich aber sehe, wie oft die Leute (vor allem der PL und der TL) in den standardisierten meetings sitzen, hat kaum einer die Chance, irgendwas zu planen oder zu organisieren. Die rennen dann alle schnell zurück zum Arbeitspaket und machen dann dort weiter, wo es gerade geht und versuchen dabei krampfhaft den nächsten Termin zu schaffen. Je mehr Orga-meetings es gibt, desto weniger gut ist die Orga und desto unorganisierter ist das Projekt. Am Ende hängt es nämlich einzig daran, wie effektiv die Einzelnen sich Ausserhalb des Meetings absprechen und das geht nicht so, dass man alle halbe Stunde quatscht! Das geht nur so, dass man sich mal eine halbe Stunde zusammensetzt, ein Ziel dfiniert und dann die nächsten Tage gezielt drauf hingearbeitet wird. Für die wirklich wichtigen Dinge gibt es nämlich schrifltiche Doku wie Lasten-, Pflichten- und Designhefte, in denen die Anforderungen hineingeschrieben werden und zwar bitte detailliert und richtig. So hat es dort nur oberflächliche und falsche Darstellungen, die einem nicht helfen. Weder bei der täglichen Arbeit noch bei deren Organisation. Die Themen Integration und IB, welche traditionell die Loops aufwerfen, fordern sowie ein bug tracking System, wo die Tester was reinspielen können. Das alles geht online, über Datenbanken und gleichzeitigen Zugriff!
Bin genau deiner Meinung. Und würde noch folgendes hinzufügen. Selbständiger schrieb: > SRUM ist daher mit der Art der Durchführung eine Methode, die ihrem > eigenen Anspruch im Wege steht! Statt grobe short- und long-Task in > "sprints" und "claims" zu organisieren und diese stündlich zu überwachen > um ständig die Orga anzupassen, wäre es besser, die Tasks genauer zu > beschreiben, diese länger aufzuziehen und eine Person gleichzeitig auf 3 > Tasks zu setzen, die sie mit den jeweiligen members lokal organisiert, > um auf deren Schwankungen einzugehen. > > Was hingegen nötig wäre, ist eine sinnvolle Aufteilung der Arbeit in > kleine abgeschlossene Blöcke, die aber ausreichend lang sind umd dann > selbständig und alleine ohne andere geleistet werden können, damit die > Anzahl der Schnittstellen und Absprachen klein bleibt. Das eigentliche > Ziel einer Projektleitung muss daher sein, das Projekt zu "entscummen", > d.h. die Notwendigkeit der Absprachen zu reduzieren. Ich finde, dass Scrum lediglich die Inkompetenz bzw. Faulheit derjenigen kaschiert, die eigentlich für die Anforderungserstellung und die Definition der Aufgaben zuständig sind. Das betrifft sowohl den Auftraggeber als auch den Bearbeiter/Auftragnehmer. Anstatt sich mal länger hinzusetzen und zu überlegen, was man denn haben möchte, wird damit argumentiert, dass man es selber (also der Kunde selbst) nicht genau weiß und somit die Arbeit umgeht, sich mit dem System/Produkt/Ziel auseinanderzusetzen und zu sagen, xyz möchte ich haben. So flattern nach jedem Treffen mit dem Auftraggeber/Kunde immer wieder neue Anforderungen/Features rein oder Änderungen, die man umsetzen soll. Diese sind dann aber wieder nicht genau definiert, weil man (Kunde und Auftragnehmer/Product Owner etc) seine Arbeit, also sich mal mit seinem System auseinaderzusetzen, nicht erledigt hat. > Für die wirklich wichtigen Dinge gibt es nämlich schrifltiche Doku wie > Lasten-, Pflichten- und Designhefte, in denen die Anforderungen > hineingeschrieben werden und zwar bitte detailliert und richtig. So hat > es dort nur oberflächliche und falsche Darstellungen, die einem nicht > helfen. Weder bei der täglichen Arbeit noch bei deren Organisation. Genau das is doch das Problem. Diejenigen, deren Aufgabe es ist, Anforderungen, Designs, Architekturen zu erstellen, machen ihre Aufgabe nicht richtig aus verschiedensten Gründen (Inkompetenz, Faulheit, keine Erfahrung etc). Aber auch der Kunde ist zu faul - anstatt zu sagen, was er denn haben möchte, lässt er den Auftragnehmer mal machen und schiebt dann seine Wünsche nach. Nicht falsch verstehen: Es ist mir klar, dass man nciht von Anfang an eine komplette Spezifikation abgeben kann und dass es zu Änderungen kommt. Aber ich finde, dass es gerade wegen Scrum/agiler Entwicklung, dies immer mehr dazu führt, dass man sich immer weniger Gedanken über sein System/Produkt macht.
Ich habe mehrfach die Erfahrung gemacht, daß Agile Entwicklung zu guten Ergebnissen führen kann. Auch dann, wenn das Produkt erst während der Entwicklung definiert oder gar geändert wird. Kompliziert wird es, wenn vor dem Beginn der Entwicklung schon der Zieltermin und Preis festgelegt werden, aber noch keiner so richtig weiß, was er eigentlich bauen soll. Für die Entwickler ist es in solchen Fällen wichtig klar zu stellen, was man bis wann zu welchem Preis erledigen kann. Häufig hat man dann auch recht lange Listebn von Unsicherheiten, die man klar kommunizieren sollte. Denn wenn es am Ende länger dauert und teurer wird, sollte dem Auftraggeber klar sein, daß er es selbst Schuld ist. Agile Entwicklung ist für mich das mehr oder weniger organisierte alltägliche Chaos. Oder wie ich zu sagen Pflege: Der ganz normale Wahnsinn. Nicht wirklich erquickend, aber man wird dafür bezahlt. Scrum lehne ich in einigen Punkten ab. Die täglichen Meetings sind zu kruz, um Sinn zu ergeben und zu häufig um nicht von der Arbeits abzuhalten. Ein vernünftiger Projektleiter wird dann Meetings einberufen, wann sie angebracht sind. Die richtige Dauer und Häufigkeit will ich mir nicht von einem Buch vorgeben lassen. Ebensowenig die Anzahl der Tage pro Sprint. Scrum ist mir viel zu starr. Zugleicht verlangt Scrum aber 100% Einhaltung der Regeln weil es sonst angeblich nicht funktioniert. Eine selbsterfüllende Prophezeiung. Es erinnert mich an die viele Gesetze der Juden. Sie dienen hauptsächlich dem Zweck, den Menschen ihre Unvollkommenheit vor Augen zu führen. Nach dem Motto: Alle Juden sind unvollkommen, wiel sie Gesetze brechen. Alle Scrum Projekte laufen schlecht, weil sie die Regeln mißachten. Wirklich flexible Entwickler hängen sich nicht an so ein striktes Regelwerk. Und Flexibilität ist gefragt. Scrum ist nur ein Buzzword. Es reicht, ein Scrum Buch gelesen zu haben. Richtig anwenden kann man es danach zwar nicht, aber das erwartet auch niemand. Man soll ja auch gar nicht 100% Scrum machen.
Ich habe mich im vorigen Post unklar ausgedrückt: Ich glaube daß Scrum absichtlich so starre und kaum einzuhaltende regeln festlegt, damit man sie nicht einhalten kann. So kann der Erfinder von Scrum sehr einfach sagen "Dein Projekt ist gescheitert, weil du die Regeln von Scrum nicht eingehalten hast". An Scrum selbst kann es nicht gelegen haben. So wie das Judentum nicht Schuld an unvolkommenen Menschen sein will, zugleich jedoch Vorschriften macht, die kein mensch vollständig einhalten kann. Das meinte ich mit dem Juden-Vergleich.
Vielleicht funktioniert Scrum auch nur in USA gut, wo die Leute kaum Fehltage haben und von 7 bis 7 die halbe Stunde täglich eher als Warm-up zu sehen ist.
Stefan U. schrieb: > Ich glaube daß Scrum absichtlich so starre und kaum einzuhaltende regeln > festlegt, damit man sie nicht einhalten kann. So kann der Erfinder von > Scrum sehr einfach sagen "Dein Projekt ist gescheitert, weil du die > Regeln von Scrum nicht eingehalten hast". An Scrum selbst kann es nicht > gelegen haben. Genau das ist eben nicht der Sinn von SCRUM. Wenn du es so kennst, hast du es nicht verstanden, wenn du Leute kennst, die es so praktizieren, haben sie es ebenfalls nicht verstanden und machen es falsch. Stefan U. schrieb: > So wie das Judentum nicht Schuld an unvolkommenen Menschen sein will, > zugleich jedoch Vorschriften macht, die kein mensch vollständig > einhalten kann. Was für ein dämlicher Vergleich. Viel dir wirklich nichts Besseres ein?
Achim S. schrieb: > Vielleicht funktioniert Scrum auch nur in USA gut, wo die Leute > kaum > Fehltage haben und von 7 bis 7 die halbe Stunde täglich eher als Warm-up > zu sehen ist. Nö. Wenn man SCRUM richtig praktiziert, führt es eben zu einer entspannten Arbeitsumgebung. Verschiebungen sind durchaus erlaubt. Wir arbeiten mit mehr als 40 Leuten in 3 Teams an vielen Requirements, die auf die Sprints so verteilt werden, dass es eben nicht zu dieser Überbelastung kommt. Chaotisches Projektmanagement und Umsetzung der Anforderungen, wo am Ende erst auffällt, dass wichtige Dinge fehlen und zum Chaos und Panik führen, bleibt so aus. Voraussetzung: Man hält sich an die Regeln, die SCRUM definiert. Und natürlich, dass man weiß, wovon man spricht, und eben nicht am Ende doch ein paar Begriffe mitbekommen hat, ohne zu verstehen, worum es geht. Unsere Teams arbeiten ziemlich erfolgreich, die Fa. nimmt es auch in anderen Abteilungen an. Und ich bin weiß Gott kein Verfechter von solchen Dingen, nur muss ich als einfacher Entwickler nach vielen Jahren Berufserfahrungen in diversen Firmen doch anerkennen, dass es viele Projekte besser laufen lässt, als dort, wo es dies nicht gab. Meine anfängliche Skepsis und gewisse Vorurteile, die ich hatte, habe ich nach reichlicher Beobachtung doch zurückgefahren, und kann dem Ganzen einige gute Eigenschaften abgewinnen. Dazu muss man allerdings sagen, dass die bei uns damit betrauten Leute dies auch mit Herzblut umsetzen und dies als kein "nice to have" betrachten. Zu guter Letzt: die Stimmung unter den Leuten in diesen 3 Teams habe ich noch nie so gesehen: sie ist so gut, dass man gerne zur Arbeit geht. So, und bevor hier mal wieder rumgetrollt wird: nein, ich verfolge keine kommerziellen Ziele, nur weil ich mal optimistischere Töne anschlage.
Wir haben im letzten Projekt ebenfalls SCRUM eingeführt und Ich muss sagen, Ich erlebe da zweierlei: 1) Viele sind enthusiastisch, weil sie ihre formellen Prozesse beiseite lassen können, die eh nie richtig gelebt wurden. Alle sind entspannt und haben endlich eine Begründung, so arbeiten zu können wie sie wollen. Quasi die Erlaubnis zum Spontanarbeiten. 2) Es wird versucht, irgendwie die formellen Prozesse von SCRUM einzuhalten und alle machen mit, versuchen aber trotzdem irgendwie zu arbeiten, wie sie es gewohnt sind. So richtig kapiert, was SCRUM sein soll, hat offenbar keiner. Damit wurde der formelle Prozess ALT gegen einen neuen Prozess SCRUM ausgetauscht. Geändert hat sich aber garnichts. Die Probleme sind dieselben, die Lösungen auch und das eigentlich Wichtige, nämlich die Festlegung von gemeinsamen Zielen geschieht immer noch nicht in ausreichender Weise, weil dafür keiner Zeit hat. Er muss ja SCRUM machen, Reports schreiben und ins meeting. Ich sehe in Scrum nichts anders, als eine feinere Planung mit kürzeren Laufzeiten. Ob die sinnvoll sind, hängt von der Aufgabe und Situation ab. Entscheidend ist, dass es klare Absprachen gibt an die man sich hält. SCRUM verführt leider dazu, alles aus dem Stehgreif zu machen und weniger niederzulegen und verbindlich aufzuplanen. Für die hemdsärmelige U30-Franktion sicher die richtige Arbeitstechnik.
> Für die hemdsärmelige U30-Franktion
Sei vorsichtig, was du von Dir gibst.
Reinhard S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Meinungen zu dem System sind > wilkommen. Vor allem würde mich interessieren, wo das System eingeführt > oder angedacht - und dann wiede abgeschafft wurde. Hier! Bei uns wurde es zwei Mal eingeführt und dann wieder abgeschafft. Beim ersten Mal wurde sogar extra ein völlig überbezahlter "Consultant" dafür eingestellt. Das Geld hätte man sich sparen können. Am Ende ist die Firma haarscharf an der Pleite vorbei geschrammt. Jetzt, nachdem alle Consultants und Freelancer rausgeschmissen wurden, macht die Firma nach Jahren das erste Mal Gewinn. Ich glaube aber nicht, dass HR und Geschäftsführung daraus etwas gelernt haben. Am effektivsten war die Zusammenarbeit im direkten Vier-Augen-Gespräche zwischen Entwicklern, Projektleitern und Kunden. Und nicht durch irgendwelche schwachsinnigen vorgegebenen Meetings, Sprints etc., wo sowieso immer nur dieselben Schaumschläger am Labern sind. Aber die unerfahrenen Grünschnäbel halten sich halt für besonders modern, wenn sie sich sklavisch an irgendwelche Vorgaben halten, die ihnen von narzisstischen Consultants und sogenannten "Speakern" eingetrichtert wurden, die nur Geld verdienen wollen, indem sie regelmäßig eine neue Sau durchs Dorf treiben.
Scrum-Teilnehmer schrieb: > Genau das ist eben nicht der Sinn von SCRUM. Wenn du es so kennst, hast > du es nicht verstanden, wenn du Leute kennst, die es so praktizieren, > haben sie es ebenfalls nicht verstanden und machen es falsch. Wenn das so ist, kannst Du doch bestimmt die (schon laenger offene) Frage nach guter Literatur beantworten. Hilft die Diskussion zu versachlichen und verhindert das 10 Leute 15 verschiedene Sachen unter scrumm verstehen.
Scrum-Teilnehmer schrieb: > Dazu muss man allerdings sagen, dass die bei uns damit betrauten Leute > dies auch mit Herzblut umsetzen Das ist genau der Schlüssel. Aber wenn die Leute mit Herzblut dabei wären, bräuchte man nicht unbedingt Scrum, welches meiner Meinung nach die Faulheit, Inkompetenz, Unerfahrenheit der Leute kaschiert/rechtfertigt und gerade auch verstärkt. Denn ein Team, welches nach Prozess X erfolgreich entwickelt, wird auch nach Prozess Y erfolgreich entwickeln.
Scrummer schrieb: > Das ist genau der Schlüssel. Aber wenn die Leute mit Herzblut dabei > wären, bräuchte man nicht unbedingt Scrum, welches meiner Meinung nach > die Faulheit, Inkompetenz, Unerfahrenheit der Leute > kaschiert/rechtfertigt und gerade auch verstärkt. > Denn ein Team, welches nach Prozess X erfolgreich entwickelt, wird auch > nach Prozess Y erfolgreich entwickeln. Was daran liegt dass Scrum bzw. die gesamte Agile Entwicklung kein Prozess sondern eine Art Geisteshaltung ist. Eine grundlegende Einstellung zum Thema SW-Entwicklung.
Cyblord -. schrieb: > Was daran liegt dass Scrum bzw. die gesamte Agile Entwicklung kein > Prozess sondern eine Art Geisteshaltung ist. Eine grundlegende > Einstellung zum Thema SW-Entwicklung. Und? Auch keine Literaturempfehlung, die das bestaetigen wuerde?
Beitrag #5117279 wurde von einem Moderator gelöscht.
Beitrag #5117296 wurde von einem Moderator gelöscht.
Wichtig finde ich, daß nicht einfach ein manager im laufenden Projekt sagt "So liebe Leute, hier ist das Buch über SCRUM, ab Montag machen wir das so". Denn die Methode setzt voraus, daß andere Abteilungen dabei mit machen. Leider musste ich mehrfach erleben, daß Manager meineten, SCRUM sei eine Arbeitsmethode für die Softwareentwickler, aber alle anderen können drauen bleiben.
Was für romantische, verträumte und unrealistische Vorstellungen hier über sog. "agiles SCRUM-" Projektmanagement herrscht. In großen Firmen und großen gruppenweiten Projekten kann garnicht alles und jede Abteilung dabei sein. Auch das jeder in jeder Kleingruppe bei jedem Sprint zum Architekt wird ist eine Träumerei. Es gibt bei ganz vielen Vorgängen in der Produktentwicklung Leute die etwas beitragen aber ganz genaue Vorgaben brauchen und immer nur einen gleichartigen Prozess ausführen. Es muss nach jedem Abschnitt ein Prototyp verfügbar sein? Na dann :) "Daily Scrum" und "Produkt-Backlog" klappt auch nur bei sehr ähnlich ausgebildeten Leuten die gleichberechtigt in einer Kleingruppe an einem gemeinsamen Thema arbeiten.
Chris F. schrieb: > In großen Firmen Richtig, den Konzernbeamten ist das alles zuwider. Die wollen gefälligst in Ruhe die Jahre bis zur Rente überstehen und nicht so neumodischen Schnickschnack lernen, geschweige denn auch noch seine Geisteshaltung ändern. Damit Scrum funktioniert braucht man ziemlich homogene Teams. Die findet man halt im Konzernumfeld nicht.
djm schrieb: > [...] Geisteshaltung ändern. [...] > > Damit Scrum funktioniert braucht man ziemlich homogene Teams. Damit bestätigst Du ja meine Ansichten und setzt noch obendrauf, dass es sich um eine "Geisteshaltung" handelt. Das habe ich nicht geschrieben. Es ist aber offensichtlich für einige eine Ideologie und nicht nur eine Vorgehensweise beim Projektmanagement die vor allem bei der Softwareentwicklung eingesetzt wird. Mir ist das, auch als vermeintlicher Beamter ;-P, übrigens schnurz ob ein Teilprojekt das Software erstellt nun SCRUM, Domain-Driven, Kanban, XP-Yagni oder sonstwas einsetzt oder ob bei denen die Sourcen auf SVN, Git oder Mercurial liegen. Hauptsache die liefern.
Ich wollte deine Aussage ja nicht widerlegen, sondern eher untermauern. Das Problem an der Verwendung von Scrum ist, dass (gerade vom Management aus) immer alles Heil im Agilen gesucht wird. Dabei ist eher das Gegenteil der Fall. Wenn agil nicht richtig umgesetzt wird (oder werden kann), wird es eher zu ner Effizienz-Bremse. Und in Konzernstrukturen rennen einfach zu viele Beamte (natürlich nicht nur) rum, sodass agil dort nicht funktionieren kann. Das was "Selbstständiger" oben beschreibt sind eben nicht die Schwachpunkte von Scrum, sondern die Fehlverwendung von Scrum. Wenn jemand vor mir auf der Autobahn schleicht ist in den meisten Fällen auch nicht das Auto Schuld, sondern der Fahrer.
Dumdidum schrieb: > Wenn das so ist, kannst Du doch bestimmt die (schon laenger offene) > Frage nach guter Literatur beantworten. Hilft die Diskussion zu > versachlichen und verhindert das 10 Leute 15 verschiedene Sachen unter > scrumm verstehen. Ein lobenswürdiger Beitrag. Ich hatte die Frage tasächlich schon gestellt, aber die Antwort ist offen! Chris F. schrieb: > "Daily Scrum" und "Produkt-Backlog" klappt auch nur bei sehr ähnlich > ausgebildeten Leuten die gleichberechtigt in einer Kleingruppe an einem > gemeinsamen Thema arbeiten. Das ist auch meine Beobachtung. Ich habe es schon gesehen, daß die halbe Abteilung im Halbkreis stand und jeder seine Ideen vortrug, am Ende gingen die 2 SW-Entwickler raus und haben sich nochmal extra zusammengesetzt und alles wieder überworfen. Mini-SCRUM! djm schrieb: > Ich wollte deine Aussage ja nicht widerlegen, sondern eher untermauern. > Das Problem an der Verwendung von Scrum ist, dass (gerade vom Management > aus) immer alles Heil im Agilen gesucht wird. Dabei ist eher das > Gegenteil der Fall. Wenn agil nicht richtig umgesetzt wird (oder werden > kann), wird es eher zu ner Effizienz-Bremse. Dann würde Ich Dir hiermit bitten, einige Regeln aufzustellen, wie man das handhaben sollte und was man unterlassen sollte. ?
Reinhard S. schrieb: > Dann würde Ich Dir hiermit bitten, einige Regeln aufzustellen, wie man > das handhaben sollte und was man unterlassen sollte. Warum soll ich da Regeln aufstellen? Das Vorgehen gemäß Scrum ist definiert. Da gibt's sogar deine heiß geliebte Literatur dazu. Danach muss man leben. Und wenn dann zwei SW-Entwickler meinen, im Privaten alles über den Haufen werfen zu müssen, gibt's halt Klassenkeile. Das ist genau das was ich mit Geisteshaltung gemeint hab. Entweder ich will Scrum machen, dann klappt das auch. Oder ich hab da keinen Bock drauf, dann kann man es vergessen. Und zum Thema Literatur: http://www.scrumguides.org/
SCRUM ist extreme Programming fuer arme, aber immer noch besser als Wasserfallmodelle, letzteres war urspruenglich ein Negativbeispiel wie man es NICHT machen sollte. Wasserfall ist eben sehr unflexibel, kann man nur erfolgreich machen wenn man nicht innovativ ist und eben nicht auf Aenderungen regiert weil man seit Jahren dasselbe macht, viel Papier, wenn etwas falsch laeuft merkt man das viel zu spaet, passt eben super zum "OEM Modell", wie es oft in den "sterbenden Industrien" zu finden ist. Selbst Auswuechse wie das V-Modell XT, ein verkapptes Wasserfall Modell, musste einen alternativen agilen Prozess einfuehren um nicht komplett unterzugehen.
Das scheint ein Kernpunkt in der SCRUM Lehre zu sein: "Wasserfall ist der Teufel". Und deswegen ist SCRUM auch garantiert 100% anders. Bloss nichts wie beim Wasserfall Modell machen, denn sonst müsste man ja eingestehen, daß dieses "feindliche" Modell auch positive Seiten hat. Das Wasserfall Modell wird häufig von Auftraggebern verlangt. Es gibt dem Auftraggeber die Sicherheit, daß er zum Zieltermin im Rahmen der kalkulierten Kosten das erwartete Produkt erhält. Außerdem ist es so möglich, das Personal für QA und Betrieb erst später am Ende des Entwicklungsprozesses zu belegen. So weit die Theorie. In der Praxis habe ich in jedem Projekt erlebt, daß während der Entwicklung wesentliche Änderungen angefordert werden (oder sich als Notwendig ergeben, weil der Plan fehlerhaft war). An diesem Punkt verhandelt man über Vereinfachungen, was man weg lassen kann oder später nach dem Zieltermin (gegen Aufpreis) nachliefern kann. Hier soll man bitte nicht den Fehler machen, an der Dokumentation zu sparen! Wenn diese nicht von Anfang an VOR oder WÄHREND der Entwicklung erstellt wird, dann endet es sonst oft damit, die Dokumentation einfach weg zu lassen. Zugleich wird dann aber erwartet, daß man künftige Änderungen ohne Mehraufwand umsetzen kann und daß man die Funktionsweise des Produktes OHNE Dokumentation jederzeit vollständig mündlich erklären kann. Das ist jedoch nicht Möglich. Ich halte es für äußerst hilfreich, wenn man während der Software-Entwicklung alle paar Wochen (aber nicht wöchentlich) den aktuellen Stand abliefert. So können die Benutzer das Produkt ausprobieren und Änderungswünsche äußern, die letztendlich der Qualität dienen. Man erkennt frühzeitig viele Fehler, noch bevor der Test/Abnahmeprozess beginnt. Wenn man schonmal etwas zum "anfassen" vorliegen hat, kommen meistens die besten Ideen. Ich halte es auch für wichtig, dass ein technisch versierter Projektleiter oder Architekt (oder beide) die Verhandlungen mit dem Auftraggeber durchführen, damit sie den Entwicklern den Rücken frei halten. Es wäre ein Unding, wenn einzelne Entwickler mit dem Auftraggeber Details aushandeln müssten. SCRUM geht einfach davon aus, daß alle Entwickler gleiches KnowHow und gleiche Talente haben. Jeder Entwickler müsste zugleich Programmierer, Tester, Dokumentierer, Händler und Betriebler sein. Das ist in der Praxis jedoch selten der Fall. Deswegen ist der Personalaufwand sehr viel größer, wenn man sich an die Regeln von SCRUM hält. Bezüglich der Dokumentation möchte ich empfehlen, diese als Wiki anzulegen. Die Möglichkeit, alles kreuz und quer zu verlinken, erspart eine Menge Tipparbeit. Man sollte sich nicht mit einer starren Formatvorlage behindern. Wichtig ist doch, DASS alles irgendwo dokumentiert und durchsuchbar ist, nicht WIE. Ich habe in 25 Jahren noch keinen einzigen Kunden erlebt, der eine lockere Form reklamiert hatte. Das heisst zum Beispiel, daß man keine endlos großen Diagramme von DB Strukturen aufmalt, sondern einfach die "create table" Statements in die Doku kopiert. Dazu noch ein paar Zeilen Text, was man sich dabei gedacht hat, falls das überhaupt nötig ist. Normalerweise sollte sich der Programmcode selbst erklären. Ich muss bei der Funktion Customer.blockLoginUntil(Date) nicht erklären, was sie macht. Ich muss aber irgendwo zusammenhängend erklären, wann und warum wir Kunden blocken und wie man sie ent-blocken kann. Eben die Geschäftslogik, und die kann man in der Regel nicht 1:1 aus dem Quelltext heraus lesen. Dementsprechend sehe ich DoxyGen und JavaDoc als mittlerweilen fast überflüssiges* Hilfsmittel für die Programmierer an, jedoch nicht als Tool, die Dokumentation für die nicht-Programmierer zu erstellen. * fast Überflüssig deswegen, weil jede IDE diese eingebetteten Dokumentationen irgendwie schön anzeigt, so daß man sie nicht mehr als HTML, PDF oder was auch immer separat vorhalten muss. Die eingebettete Doku ist natürlich weiterhin nötig. Und selbst da würde ich auf die Dokumentation von völlig offensichtlichen Funktionen und Parametern verzichten.
Stefan U. schrieb: > SCRUM geht einfach davon aus, daß alle Entwickler gleiches KnowHow und > gleiche Talente haben. Jeder Entwickler müsste zugleich Programmierer, > Tester, Dokumentierer, Händler und Betriebler sein. Das ist in der > Praxis jedoch selten der Fall. Deswegen ist der Personalaufwand sehr > viel größer, wenn man sich an die Regeln von SCRUM hält. Nein, davon geht Scrum eben nicht aus: Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; Warum sollte der Personalaufwand von Scrum dadurch höher sein als bei anderen Vorgehen? Ob ich jetzt im Wasserfall oder Scrum nen Betriebler oder Tester braucht, ändert nix an meinem Personalbedarf. Mit Scrum kann man tendenziell sogar mit geringeren PErsonalkosten arbeiten, da man die einzelnen Leute präziser "buchen" kann.
Wasserfall ist in der Theorie super und in der Praxis untauglich weil: - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind - Die Kundenrückkopplungsschleife viel zu lange ist - Entweder nicht alle Anforderungen von vornherein klar sind oder sie sich im Laufe ändern Wir im Konzern in unserem Projekt fahren SCRUM (so gut es halt in den Strukturen geht) und meiner Beobachtung nach hängt vieles am Product Owner, ohne ein vernünftig priorisiertes Backlog (was im Wesentlichen den Anforderungen entspricht) ist das alles Scheiße. Egal ob SCRUM oder Wasserfall. Wenn es aber ein vernünftiges Backlog gibt, dann läuft das wunderbar. Die Schätzungen für einzelne Pakete sind viel feingranularer und damit präziser. Der Kunde / Product Owner hat damit die Möglichkeit gut zu steuern, was er unbedingt haben möchte oder was nice-to-have is wenns noch ins Budget passt. Feedback kann frequenter eingeholt werden, nicht selten ist die erste Idee die man hatte ein Scheiß in der Praxis (kann man den Button nicht lieber so und so machen, weil ich habe festgestallt, dass ...). Wenns normal läuft, kann man sagen, der Kunde kriegt das was ins vorgegebene Budget passt und hätte mit Wasserfall auch nicht mehr bekommen, das zeigt die Praxis. Wir im Team und auch die anderen Teams im Projekt haben SCRUM an ihre Modalitäten angepasst (gesunder Menschenverstand!) und es funktioniert doch recht ordentlich. Dailies machen wir nicht daily, dafür häufiger Backlog Refinement, dadurch schrumpft das Planungsmeeting nur noch zu einem "was machen wir als nächstes, Herr Product Owner". Unser Team ist bunt gemischt, sowohl vom Alter (30-60), als auch vom Erfahrungsstand innerhalb des Projekts (manche sind schon Jahre dabei und haben entsprechendes Domänenwissen, manche erst ein paar Monate). Wie schon gesagt wurde, der Erfolg hängt auch im Wesentlichen davon ab, ob man einen sturen Stinkstiefel im Team hat (den es bei uns glücklicherweise nicht gibt) oder nicht, aber es ist dann Aufgabe der Führungskraft so jemand ordentlich zu polen. Aber meiner Beobachtung nach, sind die fähigsten Leute auch mit die, die offen für Neues sind und nicht nach Schema F immer wieder auf ihrem alten Scheiß beharren ohne dabei jedem Hype hinterherzulaufen oder sich für Weltenretter halten.
Selbständiger schrieb: > SCRUM ist für mich nichts anderes, als dem unorganisierten Chaos in > vielen Firmen einen Namen zu geben, damit es besser klingt. Ja, so wird es meistens gemacht. Aber was kann die Methode dafür? Selbständiger schrieb: > Von den ständigen und vor allem täglichen Abstimmungen halte Ich > überhaupt nichts. Da stehen nur alle passiv in der Gegend herum und > erzählen, was sie gerade gemacht haben und was sie tun wollen. Richtig > in die Tiefe geht das nicht und nutzen tut es auch keinem wirklich, weil > es nur der Aufgabendeklaration und -Verfolgung dient. Es soll ja auch nicht in die Tiefe gehen. Das ist nur eine kurze Abstimmung. Ein paar Minuten täglich. Wenn man etwas konkretes genauer besprechen muss, dann macht man das separat, da müssen nicht alle Teammitglieder dabei sein. Selbständiger schrieb: > Sinn macht es im Grunde nur für den Projektleiter Bei SCRUM gibt es keinen Projektleiter. Aber das ist halt der Klassiker: auf die bestehende Organisation wird SCRUM geschrieben. Um die Methode wirklich einzusetzen, muss man schon bei der Organisation ansetzen, aber in einem Großteil der Fälle will man das ja gar nicht. Selbständiger schrieb: > Real meldet man das Ende eines Tasks dann doch, wenn er fertig ist, > damit der andere es direkt erfährt und nicht erst am nächsten Tag im > Meeting. Sowieso, warum sollte man damit warten? Selbständiger schrieb: > SRUM ist daher mit der Art der Durchführung eine Methode, die ihrem > eigenen Anspruch im Wege steht! Statt grobe short- und long-Task in > "sprints" und "claims" zu organisieren und diese stündlich zu überwachen > um ständig die Orga anzupassen, wäre es besser, die Tasks genauer zu > beschreiben, diese länger aufzuziehen und eine Person gleichzeitig auf 3 > Tasks zu setzen, die sie mit den jeweiligen members lokal organisiert, > um auf deren Schwankungen einzugehen. Du scheinst nicht viel über SCRUM zu wissen. Selbständiger schrieb: > Was hingegen nötig wäre, ist eine sinnvolle Aufteilung der Arbeit in > kleine abgeschlossene Blöcke, die aber ausreichend lang sind umd dann > selbständig und alleine ohne andere geleistet werden können Genau das macht man doch vor jedem Sprint. Selbständiger schrieb: > sie anfallen. Wenn Ich aber sehe, wie oft die Leute (vor allem der PL > und der TL) in den standardisierten meetings sitzen Bei SCRUM gibt es weder Projektleiter noch Teamleiter - siehe oben. Selbständiger schrieb: > Am Ende hängt es nämlich einzig daran, wie effektiv die Einzelnen sich > Ausserhalb des Meetings absprechen und das geht nicht so, dass man alle > halbe Stunde quatscht! Das geht nur so, dass man sich mal eine halbe > Stunde zusammensetzt, ein Ziel dfiniert und dann die nächsten Tage > gezielt drauf hingearbeitet wird. Das kann man doch eh machen. Selbständiger schrieb: > Für die wirklich wichtigen Dinge gibt es nämlich schrifltiche Doku wie > Lasten-, Pflichten- und Designhefte, in denen die Anforderungen > hineingeschrieben werden und zwar bitte detailliert und richtig. So hat > es dort nur oberflächliche und falsche Darstellungen, die einem nicht > helfen. Weder bei der täglichen Arbeit noch bei deren Organisation. Die > Themen Integration und IB, welche traditionell die Loops aufwerfen, > fordern sowie ein bug tracking System, wo die Tester was reinspielen > können. Das alles geht online, über Datenbanken und gleichzeitigen > Zugriff! Was hat das denn mit SCRUM zu tun?
Wasserfall oder V-Modell hat seine Berechtigung. Nämlich genau da, wo
von Anfang an feststeht, was am Ende rauskommen soll. Die 61508
("SIL-Norm") verlangt es daher für sicherheitsgerichtete Funktionen. Zu
Recht.
Denn a) kann man dafür nur bekannte Funktionalität verwenden (nichts
neues, kreatives),
und b) ist die zu erfüllende Funktion am Anfang bekannt.
Für ein neues Produkt oder eine Weiterentwicklung ist Wasserfall
natürlich Quatsch und war es auch schon immer. Scrum wurde erst
notwendig, als die Manager ohne Programmierkenntnisse mitspielen wollten
und auf Wasserfall, Ablaufdiagramme oder UML-Design ansprangen.
Dann könnte man sagen: SCRUM ist für die Forschung und V-MODELL für Auftragsentwicklungen?
Reinhard S. schrieb: > Dann könnte man sagen: SCRUM ist für die Forschung und V-MODELL für > Auftragsentwicklungen? Unsinn.
Abradolf L. schrieb: > Wasserfall ist in der Theorie super und in der Praxis untauglich weil: So so. > - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind Welche Schätzung ? Kosten ? Gehört nicht ins Pflichten/Lastenheft. > - Die Kundenrückkopplungsschleife viel zu lange ist Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das auch bei Software, die einen wirklichen Zweck erfüllen soll. > - Entweder nicht alle Anforderungen von vornherein klar sind oder sie > sich im Laufe ändern Du meinst, wenn Dumm und Dümmer zsuammen ein Projekt stemmen wollen ? Klar, dann ist das so. Wie schon geschrieben wurde: Dort, wo es wichtig ist, ist SCRUM sowieso unzulässig. Die Firmen, die es nutzen, wie eBay, Onlineportale und viele Tageszeitungen, haben normalerweise kaputte untaugliche Software. Schau mal, wie viele Sachen bei eBay im Argen liegen, z.B. Inkonsistenten zwischen WEB und Mobilangebot, Inkonsistenzen zwischen ständig geänderten Seiten vorne und den nicht mehr dazu passenden Seiten weiter hinten dort wo es ans Eingemachte geht.
Michael B. schrieb: >> - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind > > Welche Schätzung ? Kosten ? Gehört nicht ins Pflichten/Lastenheft. In der echten Welt liegt jedem Projekt ein Budget zugrunde und das Pflichten/Lastenheft sollte dazu passen. Und ob es passt oder nicht, ist eine Schätzung am Anfang. Und die liegt oft genug meilenweit daneben. Michael B. schrieb: > Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein > Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es > aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das > auch bei Software, die einen wirklichen Zweck erfüllen soll. Da du offensichtlich nur mit Software mit der Komplexität eines Zaungitters zu tun hast, übersteigt die Realität wohl dein Auffassungsvermögen was Software betrifft. Und "was ein wirklicher Zweck" einer Software ist oder nicht, bestimmst auch nicht du alleine. Michael B. schrieb: > Wie schon geschrieben wurde: Dort, wo es wichtig ist, ist SCRUM sowieso > unzulässig. Was für ein Unsinn. Was ist denn "wichtig"? FuSi gibt es halt Vorschriften, aber ist nicht das einzig "wichtige". Michael B. schrieb: > Die Firmen, die es nutzen, wie eBay, Onlineportale und viele > Tageszeitungen, haben normalerweise kaputte untaugliche Software. Schau > mal, wie viele Sachen bei eBay im Argen liegen, z.B. Inkonsistenten > zwischen WEB und Mobilangebot, Inkonsistenzen zwischen ständig > geänderten Seiten vorne und den nicht mehr dazu passenden Seiten weiter > hinten dort wo es ans Eingemachte geht. Und als ausgewiesener Software- und Prozessexperte kannst du natürlich vollumfassend beurteilen, dass es am Entwicklungsprozess gelegen hat, ... Du solltest halt nur über Dinge labern von denen du was zu verstehen scheinst wie Elektroinstallationen.
Beitrag #5123915 wurde von einem Moderator gelöscht.
Beitrag #5124062 wurde von einem Moderator gelöscht.
Beitrag #5124781 wurde von einem Moderator gelöscht.
Das Gefetzte zwischen Michael und der Person, die sich "Abr-adolf" nennt ist wieder mal ein schönes Beispiel, das bei den "Diskussionen" zwischen Entwicklern sehr schnell ins Persönlich abgedriftet wird, statt die Inhalte anzugehen. Und genau dasselbe erleben wir aucg mit scrum: Die wird das Aufweichen bestehender Normen in den Himmel gehoben, so als seien damit alle Probleme gelöst und sogleich durch neue normierte Vorgehensweisen ersetzt. Das Ergebnis sind endlose Diskussionen, in die sich jeder unvorbereitet einschaltet und dabei Meinungen vertritt. Was dann am Ende gemacht wird, ist davon abhängig, wer gerade am Meeting teilnimmt und wer nicht. Sind zwei Vertreter der Meinung X im Urlaub, wird auf Y umgeschwnkt, um es dann Wochen später wieder anders zu entscheiden, weil sich die Diskutanten geändert haben und es nicht mehr gelingt, eine temporäre Meinung durchzusetzen. Also haben wir einen gewaltigen Eiertanz und Zickzackkurs und jeder nutzt scrum als Entschuldigung dafür, nicht geradeaus zu arbeiten, nichts hinzuschreiben und sich ja nicht festzulegen. So weiss jeder alles und nichts und es ist niemand da, der Entscheidungen mal verbindlich fällt und Festlegungen trifft, die eine Weile halten.
Meine persönliche Erfahrung am eigenen Leib ist: Wer mit anderen menschen nicht gut zurecht kommt, hat gute Chancen, sich mit Maschinen anzufreunden. Also auch Computer. Ich glaube, daß daher auch der Begriff "Computer-Freak" stammt. Viele Computer Fachleute sind Freaks. Seit ich mich damit abfinde, fühle ich mich besser. Im übrigen sind die schlimmsten Straftäter häufig Normalos, die wo alle Nachbarn sagen "Ich bin fassungslos, er war doch immer so ein ruhiger unauffäliger Typ". Die Freaks sind die, vor denen man sich am wenigsten fürchten muss. Allerdings sind sie dennoch schwierige Menschen, was den Umgang angeht. Das will ich gar nicht abstreiten. Jedenfalls gilt das für mich.
Äh, ja - schön, dass Du mal darüber gesprochen hast. Aber wo ist der Bezug zum Thema SCRUM? Sollte dies eine Antwort auf meinen Beitrag gewesen sein, so lege Ich wert auf die Feststellung, dass Ich ein sehr kommunikationsfreudiger Computerfreak bin. Allerdings ändert das nichts an der Tatsache, daß bei SCRUM (um wieder zum Thema zu kommen) ein EFfekt auftritt, bei dem sich speziell gute Redenschwinger mit ihren Ideen und Vorschlägen durchsetzen können. Das sind dann oft Leute, die sonst wenig Tiefgang haben und ihre Zeit nur die Präparation ihres MINI-Vortrags bei SCRUM verwenden und hinerher abschlaffen. So können sie glänzen, andere an die Wand reden und ins Hintertreffen bringen. Leute die mehr Denken, als Reden. Und es ist so, daß dort eben oft ad hoc unsauber, oberflächlich und ungenau diskutiert wird, Vieles aus dem Stand kommt und unausgereift ist.
Abradolf L. schrieb: > Michael B. schrieb: >>> - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind >> >> Welche Schätzung ? Kosten ? Gehört nicht ins Pflichten/Lastenheft. > > In der echten Welt liegt jedem Projekt ein Budget zugrunde und das > Pflichten/Lastenheft sollte dazu passen. Und ob es passt oder nicht, ist > eine Schätzung am Anfang. Und die liegt oft genug meilenweit daneben. Die Schätzungen passen meist schon, zumindest solange keine Sonderwünsche nachgeschoben werden.
Michael B. schrieb: > Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein > Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es > aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das > auch bei Software, die einen wirklichen Zweck erfüllen soll. Michael B. schrieb: >> - Entweder nicht alle Anforderungen von vornherein klar sind oder sie >> sich im Laufe ändern > > Du meinst, wenn Dumm und Dümmer zsuammen ein Projekt stemmen wollen ? > Klar, dann ist das so. Naja, grau ist halt jede Theorie. Sobald man den Elfenbeinturm mal kurz verlässt und reale Projekte bearbeitet sollte man aufhören, auf die Lehrbuchmeinung zu pochen. Man könnte sonst enttäuscht sein.
Anderer Punkt: Was z.B: soll man tun, wenn man in einer Entwicklungsabteilung sitzt, Aufträge von Draußen bekommt, sei es das eigene Produktmanagement oder eine externer Abnehmer und die nicht in der Lage sind, ihre Anforderungen zu formulieren? Da kommt allenthalben einen neue Idee, eine Änderung oder etwas wird weggelassen, weil jemand merkt, dass er sich verzettelt hat oder einfach etwas vergessen hat.
Michael B. schrieb: > Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein > Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es > aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das > auch bei Software, die einen wirklichen Zweck erfüllen soll. Yo, bis die Frau um die Ecke kommt und sagt "Du Schatz, ich hab mir das mit dem Zaungitter nochmal überlegt...".
Michael B. schrieb: > Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein > Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es > aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das > auch bei Software, die einen wirklichen Zweck erfüllen soll. Deine Zaungitter sind aber schon entwickelt und mehrfach produziert. Da brauchst du keine Entwicklung mehr sondern Produktion. In der Softwarewelt entspricht das dem Kauf einer Office-Version. Da brauche ich keine Programmierer und kein SCRUM. WS schrieb: > Anderer Punkt: Was z.B: soll man tun, wenn man in einer > Entwicklungsabteilung sitzt, Aufträge von Draußen bekommt, sei es das > eigene Produktmanagement oder eine externer Abnehmer und die nicht in > der Lage sind, ihre Anforderungen zu formulieren? Im Idealfall nachfragen und genauer spezifizieren. Oft ist das nur eingeschränkt möglich, dann bleibt eh nur noch ein Ansatz mit vielen Zwischenversionen zum Ansehen (z.B. SCRUM). Oder man verweigert den Auftrag einfach - gerade konzernintern geht das ab und zu, wenn die Entwicklungsabteilung stark ist.
Jan H. schrieb: > wenn die > Entwicklungsabteilung stark ist. Das machst Du aber auch nur ein- oder zweimal, dann kriegst Du gar keine Aufträge mehr, weil es an den BU-Manager eskaliert wurde, der die Freigabe erteilt, extern zu bestellen, wovon der Geprellte dann auch eifrig Gebrauch macht. Ergebnis ist dann die Reduktion der Entwicklung.
Jan H. schrieb: > Im Idealfall nachfragen und genauer spezifizieren. Oft ist das nur > eingeschränkt möglich, dann bleibt eh nur noch ein Ansatz mit vielen > Zwischenversionen zum Ansehen (z.B. SCRUM). Das Problem daran ist, daß die Abnehmer zwar jede Menge Zeit verbrennen mit solchen Anguckversionen, weil sie nicht wissen, was sie wollen, dann aber nur die finale Version und deren Aufwand bezahlen wollen.
Allen beteiligten sollte klar sein, daß die Entwicklung nicht weiter arbeiten kann, wenn die Arbeit nicht bezahlt wird. Das bezahlen fällt dem Auftraggeber leichter, wenn er versteht, warum die kosten gestiegen sind. Deswegen sollte man zu Projektbeginn klar machen, welche Leistungen in der Kostenabschätzung enthalten sind und daß warscheinlich unschätzbare Mehraufwände wegen Plan-Änderungen dazu kommen werden. Die muss man natürlich sauber dokumentieren. Das ist zwar lästig, aber kein Problem. Software-Entwicklung besteht meiner Erfahrung nach ungefähr zu 50% aus Testen und 40% Arbeiten an anderen Dingen als dem Programm-Quelltext.
Stefan U. schrieb: > Software-Entwicklung besteht meiner Erfahrung nach ungefähr zu 50% aus > Testen und 40% Arbeiten an anderen Dingen als dem Programm-Quelltext. Bei mir ist das bei vielen Projekten eher so: 70% Gerede das nichts mit dem Thema zu tun hat, 28% Erklärungen, Beschwichtigungen (projektbezogen), 1% Architekturplan und Aufgabenverteilung, 1% Code-Revision.
Chris F. schrieb: > Bei mir ist das bei vielen Projekten eher so: > 70% Gerede das nichts mit dem Thema zu tun hat, Dann musst Du eben die privaten Sachen mal weglassen. :-) Das ist schon eher realistisch: Stefan U. schrieb: > oftware-Entwicklung besteht meiner Erfahrung nach ungefähr zu 50% aus > Testen und 40% Arbeiten an anderen Dingen als dem Programm-Quelltext. Nur wenn man ein echtes Projekt-Managment mit Planung und Nachbetrachtung hat, lernen die Entwickler, ihre Aufwände richtig einzuschätzen. Wer das nicht genau protokolliert, hat meist kein Gefühl oder ein falsches. Viele kleine Sachen werden weggelassen oder runtergeredet. Im ersten Umlauf wird meistens: 10% geplant, 50% programmiert, 20% getestet und 20% inbetriebgenommen Dann kommen nochmal Änderungen für die Fehler hinzu und viele Änderungen, wiel die Planung nicht gestimmt hat. Im zweiten Umlauf sind es dann mehr Planungsstunden, als Programmierstunden und eine Menge Test. 40% geplant, 60% programmiert, 70% getestet, 60% inbetriebgenommen Dann kommen die Änderungen durch das PM und alle Positionen müssen nochmal überarbeitet werden. 100% Planung, 70% Programmierung, 110% Test, 150% Inbetriebgenommen. Programmierung inklusive Doku sind also nicht einmal ein Viertel.
E. M. schrieb: > Das machst Du aber auch nur ein- oder zweimal, dann kriegst Du gar keine > Aufträge mehr, weil es an den BU-Manager eskaliert wurde, der die > Freigabe erteilt, extern zu bestellen, wovon der Geprellte dann auch > eifrig Gebrauch macht. Dann ist die IT-Abteilung nicht stark. So einfach geht das nicht überall. Wenn die IT die Hand auf den SAP-Systemen hat oder Richtlinien einzuhalten sind, dann kommt man mit der Brechstange nicht weit. Nop schrieb: > Das Problem daran ist, daß die Abnehmer zwar jede Menge Zeit verbrennen > mit solchen Anguckversionen, weil sie nicht wissen, was sie wollen, dann > aber nur die finale Version und deren Aufwand bezahlen wollen. Ein agiles Projekt zum Fixpreis ist fast immer eine Katastrophe. So etwas würde ich nur nach Aufwand machen. Klar, das akzeptiert nicht jeder Kunde.
Fuer sehr kleine Projekte wird es bei uns eingesetzt, fuer groessere Projekte ist es durchaus ungeeignet.
Bei rewe digital wird scrum eingesetzt. Wir sind >200 Entwickler. Es funktioniert.
Agile Prozesse funktionieren genau so lange wie Abgabetermin und Kosten genauso variabel sind wie das Pflichtenheft. Praktisch will der Kunde aber irgendwann das Produkt auch mal verkaufen und muss dann auch wissen wieviel Entwicklungsumlage man auf den Endpreis legen muss. Außer an Unis, Förderprojekten und Berliner Flughäfen funktioniert sowas selten und endet meistens im Streit oder damit das eine Partei drauf zahlt
nnn schrieb: > Bei rewe digital wird scrum eingesetzt. Entwickelt ihr denn dann wirklich für einen Auftraggeber? Also, legt ein anderer fest, was genau ihr machen sollt? Oder sind die Stakeholder innerhalb Eurer Organisation?
Die Stakeholder sind innerhalb der Organisation, was natürlich ein Vorteil gegenüber einem "echten" Kunden ist. Trotzdem war es zu den Anfangszeiten schwierig zu vermitteln, dass das ganze anders als Wasserfalls funktioniert. Auch heute noch sind IT und Stakeholder teilweise zwei unterschiedliche Welten. Trotzdem kann und darf es auch bei Scrum feste Termine geben, das muss sich nicht widersprechen.
Das deckt sich mit meiner Erfahrung. Bei internen Projekten wo man nicht unbedingt in Stein gemeiselte Erwartungen hinsichtlich Features und Preis hat und man notfalls nach einiger Zeit einfach einstampfen kann hat man agil den wenigsten Streß. Wenn's dann vorbei ist kann man aufs unfähige Managements schimpfen das kurz vorm großen Durchbruch immer abbricht ;-)
nnn schrieb: > Trotzdem kann und darf es auch bei Scrum feste Termine geben, das muss > sich nicht widersprechen. Naja, schon wenn nur drei oder vier Sprints dazwischen liegen wird's schwierig das erwartete pünktlich zu liefern weil es eingangs an irgend einer wichtigen Anforderung fehlte.
Das passiert nicht, wenn die grobplanung passt und Abhängigkeiten zwischen Teams vorher geklärt sind. Zu dem Zeitpunkt gibt es nur eine grobe Schätzung aus dem refinement an der Story (welche n mal, bei jedem Team) vorkommen kann. Die endgültige Schätzung kommt im Sprintplanning dran.
Von meiner Seite ist das Thema erledigt. Meine Kollegen dürfen seit dem ersten Oktober alleine weiterscrummen. :D
michl42 schrieb: > ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile: > > https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ > > Kurzzusammenfassung: Es setzt die falschen Anreize, löst die falschen > Probleme und macht Programmierung und Programmierer zu einem notwendigen > vehikel. Es ist im Prinzip ein permanenter Kriesenmodus. Endlich mal ein Betrag der die Fakten bennent! Den habe Ich mal direkt weitergeleitet, an gewisse Personen. Mal schauen, wie sie sich dazu stellen!
Ich bin etwas erstaunt, dass der thread eingeschlafen ist, zumal das Thema doch recht interessant ist. In der jüngeren Vergangenheit wurde bei uns SCRUM sehr stark intensiviert. Eine kritische Reaktion auf meine Hinterfragung, wie ich sie o.a. angekündigt hatte, erfolgte kaum. Hinter vorgehaltener Hand meckern zwar Viele und hinterfragen den Sinn, weil sie das Management sehen, das bei rauskommt, trauen sich aber nicht, es offen zu äußern. Scrum scheint sich auszubreiten wie ein Virus. Und befallen werden in erster Linie Firmen, die wissen, dass sie im Chaos arbeiten und sich diesen Strohhalm greifen, um sich aus dem Sumpf zu ziehen. Gott Sei Dank, habe ich das in Kürze hinter mir!
> Und befallen werden in erster Linie Firmen, die wissen, dass sie im > Chaos arbeiten und sich diesen Strohhalm greifen, um sich aus dem Sumpf > zu ziehen. > Gott Sei Dank, habe ich das in Kürze hinter mir! Viel besser kan man es nicht zusammenfassen !!! SEHR GUT !!!
> Bei rewe digital wird scrum eingesetzt. Wir sind >200 Entwickler. Es > funktioniert. REWE Aktien verkaufen , kann dazu nur sagen !!!
Hi-Tech-Progger S. schrieb: > SCRUM SCRUM? Taylorismus? Gewachsene Strukturen sag ich! Nach dem Strohfeuer der ungeregelten technischen Entwicklung hat sie sich nun der Lichtgeschwindigkeit angenähert. Immer kleinere Schritte erfordern einen immer größeren Aufwand.
Zu Organisation eines teams finde ich es gar nicht schlecht. Es erzeugt Transparenz und 2Wochen Sprints kann man einigermaßen planen(theoretisch) Die Gründe für das scheitern liegen mMn nicht unbedingt an scrumm selbst sondern an den Menschen die es benutzen. Je nach Team gibt's da immer queer schiessende die es geil finden möglichst tief zu schätzen, in retros wird sich nur Honig ums maul geschmiert, aus Fehlern nicht gelernt usw. Scrumm erfordert viel zwischenmenschliche Kommunikation und das in Bereichen wo IT asberger Nerd Autisten arbeiten. Ziemlich schlechte voraussetzungen
Wer sowas wie Scrum verwendet ist nur zu blöd um seine eigene Methode zu entwickeln Schon mal darüber nachgedacht weshalb es in Bereichen wie Maschinenbau und Elektro-Konstruktion keine derartigen Vorgehensmodelle gibt. Na, klingelt es schon langsam. Aber die IT Fuzzis fallen auf so etwas gerne herein...
Einfach unverbesserlich schrieb: > Schon mal darüber nachgedacht weshalb es in Bereichen > wie Maschinenbau und Elektro-Konstruktion keine > derartigen Vorgehensmodelle gibt. Natürlich: 1. Maschinenbau und Elektro-Konstruktion haben bei weitem nicht das Innovationstempo, das die angewandte Informatik hat. Nach Moores Gesetz ist die Rechenleistung seit meiner Jugend (also in den letzten 30 Jahren) um den Faktor 1'000'000 gewachsen. Die Kenntnisse über Arbeitsteilung und Arbeitsorganisation haben schlicht nicht mit der technischen Entwicklung mitgehalten. 2. Die Komplexität selbst relativ einfacher Software ist viel größer als die von Maschinen oder elektrischen Anlagen. Es ist völlig klar, dass das auch andere Methoden der Arbeitsorganisation erfordert.
Für Dinge, wie extreme programming z.B. ist SCRUM sehr gut. Man muss sich aber immer vor Augen führen, dass es eine Art Notlösung ist, um im chaotischen, nicht geplanten stil etwas zusammenzuschrauben und sich dabei zu synchronisieren. Ob dabei starre 2 Wochen Perioden sinnvoll sind, muss aber bereits bezweifelt werden. Hinzu kommt, dass SCRUM oft auf alle Softwareprojekte ausgeweitet wird, also fehlerhafterweise auch auf solche, die man gut planen hätte können. Damit wird alles an Projekten, egal, wie gross, wie lang und wie komplex auf ein und dasselbe Raster gepresst. Es liegt auf der Hand, dass das nicht stimmig sein KANN! Vielmehr müssen komplexere und anspruchsvollere Projekte in kleineren Zeiträumen einem Monitoring unterzogen werden und brauchen eine lange vorgeschaltete Vorlaufphase der Gesamtplanung. Nur flache, gleichmäßig in der Komplexität verlaufende Projekte wie längere Software, kann mit solchen gleichmäßigen Perioden getaktet werden und man kann recht schnell starten. Komplett unsinnig ist es, das nun auch auf das gesamte Projekt ausweiten zu wollen, weil die Entwicklung von Mechanik, Hardware und dem Gesamtprojekt einen völlig anderen Komplexitätsverlauf hat, als Softwareentwicklung. Bei Mechanik z.B. aber auch ASICs, muss sehr früh sehr genau gedacht werden, weil hintendrein fast nichts mehr zu reparieren oder zu ändern ist, während man bei SW bis zum Schluss noch ändern kann (auch wenn es nicht klug ist, zu viel offen zu lassen.) Genau das passiert aber: Wie bei der Software wird an alles drangesprungen, um es mit SCRUM zu starten und zu managen, so als wäre es Software. Die meisten Projektteile, wie z.B. Resourenplanung vertragen aber keine Vorgehensweise wie bei SCRUM!
Ich habe SCRUM in mehreren Firmen negativ erlebt, weil es von oben herab einer einzigen Abteilung (der Softwareentwicklung) auf diktiert wurde. Das Problem dabei war stets, dass alle anderen um uns herum nicht wirklich agil arbeiten wollten: - Es gab einen festen Liefertermin. - Die Kosten standen vor Projektbeginn fest. - Der Auftraggeber stand nicht zur Klärung von Detail-Fragen zur Verfügung (z.B. ob man etwas anders machen darf, weil es einfacher ist). - Getestet wurde nur einmal nach der Abgabe am Liefertermin, vorher stand dazu weder Personal noch Infrastruktur zur Verfügung. - Die Benutzer wurden bereits vor dem Liefertermin an einer Alpha Version geschult. - Aber die Anforderungen wurden nach und nach vervollständigt. Der letzte Punkt spiegelt wieder, was diese Unternehmen von SCRUM erwarten: - Die Softwareentwicklung kann schon bei Projektstart beginnen. - Anforderungen können Schrittweise bis zum letzten Liefertermin formuliert werden. - Anforderungen können beliebig oft geändert werden. - Für die Einhaltung des Zieltermins und der Kosten ist die Softwareentwicklung ganz alleine verantwortlich. - Für die Dokumentation ist die Softwareentwicklung ganz alleine zuständig. Irgendwer zieht offenbar durch dieses Land und erzählt den Managern, dass SCRUM das Unmögliche möglich macht und dass es eine Arbeitsmethode für die Softwareentwickler sei. So wie ich SCRUM erlebt habe, funktioniert es nicht. So wie es im Buch steht könnte es klappen. Aber die Manager (die ich erlebt habe) übersehen offenbar, das SCRUM weit mehr Personen involviert, als nur die Softwareentwickler. Vielleicht wurden sie schlecht beraten.
Egon D. schrieb: > 1. Maschinenbau und Elektro-Konstruktion haben bei > weitem nicht das Innovationstempo, das die > angewandte Informatik hat. Egon D. schrieb: > Die Komplexität selbst relativ einfacher Software ist > viel größer als die von Maschinen oder elektrischen > Anlagen. Man tendiert immer dazu das eigene Fachgebiet höher zu bewerten als das was man nicht so gut kennt. Wenn du dir einen modernen Prozessor anschaust dann ist die Hardware genauso komplex wie ein Betriebssystem, mindestens. Von einem Gesamtsystem "Auto" gar nicht zu reden. Da ist die Software von dutzenden von µCs oder auch dickeren Prozessoren nur ein Teil der Gesamtkomplexität. Wenn du dir auf ein modernes Flugzeug anschaust, oder dem bau eines Wolkenkratzers gilt das noch mehr. Und dort arbeiten (oder entwickeln) z.T 1000de von Personen zusammen. Also überschätze mal Software nicht so maßlos.
Udo S. schrieb: > Wenn du dir auf ein modernes Flugzeug anschaust, oder dem bau eines > Wolkenkratzers gilt das noch mehr. > Und dort arbeiten (oder entwickeln) z.T 1000de von Personen zusammen. Ja, das Argument der Komplexität war falsch, bzw. nicht ganz richtig. Der Unterschied ist nicht die Höhe der Komplexität, sondern die fehlende (bzw. kostenlose) Produktion. Da wo der Maschinenbauer einen Handwerker für Prototypen braucht, der Architekt Referenzprojekte, drückt der SW-Entwickler auf den Compile-button und hat direkt die neuste Version vor sich. Wo Erstellungs-Kosten (haus, Auto, HW) in Entwicklung oder Produktion hoch sind, gibt es mehr Planung, weniger Iterationen, weniger Komplexität pro Entwicklerstunde. Und komm bitte niemand mehr, die eigentliche Entwicklung seien die paar UML-Skizzen des Architekten, und Codemonkeys nur Handwerker. Das galt vielleicht Mal zu Lochkarten-zeiten oder datentypisten heute.
...wir wurden vor 3 Jahren bei der Entwicklung des "applikativen (kundenrelevanten) Anteils einer größeren Softwarearchitektur im automotive Bereich" (OEM - ja, wir entwickeln den Code SELBST) auch dazu gezwungen, SCRUM einzuführen. Mein Ziel war es dabei, sich die sinnvollen Aspekte rauszugreifen und den Rest "wie immer" zu machen. Zumal wir vorher eigentlich schon agiler (nicht unbedingt chaotischer) unterwegs waren, als SCRUM es ermöglicht. Fazit ist, das hat gut funktioniert, ich sehe folgende Vorteile bei der Fusion beider Welten: + deutlich strukturierteres Projekt + feste Taktung durch Sprints (aktuell noch 6 Wochen, weil es gut zu anderen Artefakten passte - ist aber eigentlich etwas zu lang) + Zwang zu besserer doku & Abstimmung + Schätzung der Karten gibt bessere Planbarkeit + wir wissen schon jetzt dass wir nachweislich nicht fertig werden :) - SCRUM per se ist ein akademischer Ansatz der mit der Realität in großen, gewachsenen Konzernen nichts zu tun hat - man muss das Mgmt so hinbiegen, dass sie zufrieden sind mit dem was man aus SCRUM nutzt und immer schön alles loben ;) - deutlich mehr Orga (was aber letztendlich in positiven Effekten endet) Das dazu von meiner Seite, freue mich über weitere Erfahrungsberichte! Euer PO.
PO schrieb: > Mein Ziel war es dabei, sich die > sinnvollen Aspekte rauszugreifen und den Rest "wie immer" zu machen. Das ist eigentlich schon falsch, denn genau das verbietet SCRUM ausdrücklich. Zumindest sollte man danach nicht behaupten, man würde SCRUM anwenden.
Egon D. schrieb: > Maschinenbau und Elektro-Konstruktion haben bei > weitem nicht das Innovationstempo, das die > angewandte Informatik hat. Nach Moores Gesetz ist die > Rechenleistung seit meiner Jugend (also in den letzten > 30 Jahren) um den Faktor 1'000'000 gewachsen. Die > Kenntnisse über Arbeitsteilung und Arbeitsorganisation > haben schlicht nicht mit der technischen Entwicklung > mitgehalten Maschinenbauer oder Elektrotechniker verdienen aber in der Regel deutlich mehr als IT Fuzzis in Softwareklitschen Wenn aber die IT Arbeit deutlich anspruchsvoller wäre dann müsste das Gegenteil der Fall sein. von daher stimmt dieses Argument nicht Außerdem kopieren doch die meisten Softwerker nur Code aus aus Google zusammen
Einfach unverbesserlich schrieb: > Außerdem kopieren doch die meisten Softwerker nur Code aus aus Google > zusammen Und die Maschinenbauer schrauben Teile zusammen, die ihnen fertig geliefert werden. Sorry Mann, du hast keine Ahnung, was gute Softwareentwickler alles leisten müssen.
A. S. schrieb: > Udo S. schrieb: >> Wenn du dir auf ein modernes Flugzeug anschaust, oder >> dem bau eines Wolkenkratzers gilt das noch mehr. >> Und dort arbeiten (oder entwickeln) z.T 1000de von >> Personen zusammen. > > Ja, das Argument der Komplexität war falsch, bzw. nicht > ganz richtig. Das stimmt. Das kommt halt heraus, wenn ich mich mal kurzfassen und nicht ewig schwafeln will. > Der Unterschied ist nicht die Höhe der Komplexität, sondern > die fehlende (bzw. kostenlose) Produktion. Das stimmt -- aber das eine bedingt das andere. Je produktiver die Produktion ist, desto größer ist die Komplexität, die ein einzelner Entwickler beherrschen muss. Das geht schon im Sondermaschinenbau los, wo heute eben komplizierte Einzelteile auf der CNC-Fräse hergestellt werden, was in dieser Weise von 50 Jahren schlicht unmöglich war. In der Softwerkerei ist das noch schlimmer; dort ist die "Produktion" mit dem Ende des Compilerlaufes (nahezu) abgeschlossen. > Da wo der Maschinenbauer einen Handwerker für Prototypen > braucht, der Architekt Referenzprojekte, drückt der > SW-Entwickler auf den Compile-button und hat direkt die > neuste Version vor sich. Genau. > Wo Erstellungs-Kosten (haus, Auto, HW) in Entwicklung > oder Produktion hoch sind, gibt es mehr Planung, weniger > Iterationen, weniger Komplexität pro Entwicklerstunde. Nicht nur das -- es gibt dort auch mehr Kommunikation, mehr technische Dokumentation, mehr Bewusstsein für Qualität.
Udo S. schrieb: > Man tendiert immer dazu das eigene Fachgebiet höher zu > bewerten als das was man nicht so gut kennt. ??? Ich habe Mechatronik gelernt und Elektrotechnik studiert.
Einfach unverbesserlich schrieb: > Maschinenbauer oder Elektrotechniker verdienen aber in der Regel > deutlich mehr als IT Fuzzis in Softwareklitschen Informatiker arbeiten halt meistens in kleinen Klitschen und nicht in IGM-Konzernen. Viele IGM-Konzerne lagern ihre Softwareentwicklung in Tockterfirmen aus, damit sie keinen IGM-Tarif zahlen müssen. > Wenn aber die IT Arbeit deutlich anspruchsvoller wäre dann müsste das > Gegenteil der Fall sein. von daher stimmt dieses Argument nicht Bist du denn in der Lage, einen Investment-Bot zu schreiben, der dich reich macht?
F. B. schrieb: > Bist du denn in der Lage, einen Investment-Bot zu schreiben, der dich > reich macht? Er nun wieder mit seinem Aktienscheiss....
Franko S. schrieb: > F. B. schrieb: >> Bist du denn in der Lage, einen Investment-Bot zu schreiben, der dich >> reich macht? > > Er nun wieder mit seinem Aktienscheiss.... Ja. Mein Investment-Bot war heute wieder sehr erfolgreich. Wer noch täglich zur Arbeit gehen muss, um sich seinen Lebensunterhalt zu verdienen, der hat es nicht weit gebracht im Leben.
> Autor: F. B. (finanzberater) > Datum: 03.10.2019 12:10 Da bist du Quatschkopp ja. Habe dich schon vermisst, dachte dieses Wochenende gibt es keinen Freigang für dich.
Was mich an Finanzberatern mal interessiert, wenn sie so tolle Geldanlagetips haben müssten sie doch durch Umsetzen dieser soviel Schmodder gemacht haben, daß sie ganzjährig auf den Bahamas Urlaub machen und nicht als Finanzberater arbeiten. Und die Scrum-Consultants müssten doch auch alle eine sehr gut laufende Softwarefirma haben und die Methoden derer Organisation mehr oder weniger für sich behalten ;-)
Die warten noch auf den großen Durchbruch. Das Geschäft der allermeisten Finanzberater ist sicher genau so unerfreulich wie das von Schauspielern und Models.
Das Dumme ist und bleibt bei solchen "agilen" Methodenwerken, dass dabei so getan wird als wären alle gleich motiviert und befähigt und es gäbe eine durchgehende Anwendung davon im ganzen Projekt von Auftrag bis Typabnahme. Das ist nie der Fall und klappt auch schon innerhalb größerer Abteilungen in einer Firma nicht. Ich habe bisher noch kein Projekt erlebt bei dem diese "Total-Agil-Ideologie" wirklich richtig funktioniert hat.
Hallo loeti2, loeti2 schrieb: > Was mich an Finanzberatern mal interessiert, wenn sie so tolle > Geldanlagetips haben müssten sie doch durch Umsetzen dieser soviel > Schmodder gemacht haben, daß sie ganzjährig auf den Bahamas Urlaub > machen und nicht als Finanzberater arbeiten. Deine Analyse ist vollkommen richtig. Finanzberater sind primär Verkäufer und leben typischerweise als Parasit von der Verwaltung FREMDER Vermögen. Ich kenne nur einen amerikanischen Hedge Fonds, der keine fremden Gelder einwirbt und nur eigene Gelder, bzw. das seiner Angestellten mehrt. > Und die Scrum-Consultants müssten doch auch alle eine sehr gut laufende > Softwarefirma haben und die Methoden derer Organisation mehr oder > weniger für sich behalten ;-) Scrum-Consultants verkaufe Scrum. Sie leben nicht von erfolgreicher Softwareentwicklung, behaupten aber ohne eigenen Erfolgsnachweis, anderen erfolgreiche Softwareentwicklung beibringen zu können.
:
Bearbeitet durch User
Chris F. schrieb: > Ich habe bisher noch kein Projekt erlebt bei dem diese > "Total-Agil-Ideologie" wirklich richtig funktioniert hat. Ich auch nicht! Gerade jetzt wieder in einer einigermaßen großen Bank: Agil wurde gehypt wie verrückt, gab viele "agile Scrum Coaches", nicht nur das, wurde sogar auf "Management 3.0" umgeschaltet... Das Ergebnis: voll cool, man hat einen Riesen-Release gestemmt, in Produktionssysteme gespielt. Mit dem Ergebnis: mehrere Tage Ausfall des Ebanking, Kunden verärgert, und Support Hotline hat keine Ahnung über den firmeneigenen Ausfall..!
Chris F. schrieb: > Das Dumme ist und bleibt bei solchen "agilen" Methodenwerken Ich finde das dümmste dabei, dass agile Methoden oft als Lösung gegen Überlastung des Personals eingeführt wird. Als ob die Softwareentwickler dadurch dreimal so schnell würden und zugleich entspannter wären. Agile Entwicklung bringt ein gewisses Maß an Flexibilität, was auch oft ein Grund für die Einführung der Methode ist. Allerdings werden hier die Erwartungen oft zu hoch gesteckt. Man pickt sich das gute (Flexibilität) heraus, und ignoriert, dass jede Planänderung Zeit und Geld kostet. "Aber ihr seid doch jetzt Agil", heißt es dann, wenn die Entwickler um mehr Zeit bitten.
Peter M. schrieb: > Scrum-Consultants verkaufe Scrum. > Sie leben nicht von erfolgreicher Softwareentwicklung, behaupten aber > ohne eigenen Erfolgsnachweis, anderen erfolgreiche Softwareentwicklung > beibringen zu können. Amen. Es gibt Dinge, die unsere Welt nicht braucht. Diese Berater gehören dazu.
Hi-Tech-Progger S. schrieb: > Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM > eingesetzt wurde, um Projekte zu managen. Ich kenne keine Abteilung, die sich zu >50% mit Softwareentwicklung befasst, die Scrum NICHT benutzt. Allerdings gib't es schon extreme Unterschiede, wie es gelebt wird.
Irgendwie hat jeder zweite einen Scrum Lehrgang in LinkedIn absolviert und nennt sich jetzt dort stolz "SCRUM MASTER". Sogar in WhatsApp oder Instagram schreiben die M.Sc. Scrum Master usw. Meistens sind es Frauen. Warum ist das so? Warum ist das der neueste Shit im Berufsleben? Ich höre überall nur noch agil, agil, agil, SAFe, SAFe, SAFe, Scrum hier, Product Owner da, Function Owner dort... Ich kanns nicht mehr sehen und lesen...
Aufreger schrieb: > Warum ist das so? Warum ist das der neueste Shit im Berufsleben? Es ist halt ein Titel wenn du sonst keinen Titel hast. In Xing oder LinkedIn sind doch 90% aller Titel gelogen. Das ist doch jeder Manager von irgendwas.
:
Bearbeitet durch User
Aufreger schrieb: > Warum ist das der neueste Shit im Berufsleben? Ist schon wieder Schnee von gestern, bzw. so normal geworden dass man es nicht extra erwähnen muss. Aber heute sind alle "Manager" und "Master" von irgendwas, sogar Putzfrauen. Bei uns bewerben sich zur Zeit zahlreiche "Spezialisten", die ihn ihrem Spezialgebiet keine 2 Jahre Erfahrung haben und auch keine entsprechende Ausbildung/Studium hatten. Das ist lächerlich.
kann man drehen wie man will: Sachbearbeiter bleibt Sachbearbeiter, ganz egal ob Scrum-Master oder Product-Owner etc.
Abrissbirne schrieb: > kann man drehen wie man will: > Sachbearbeiter bleibt Sachbearbeiter, ganz egal ob Scrum-Master oder > Product-Owner etc. Sachbearbeiter klingt aber total unsexy und nach Beamtentum, daher möchte das keiner sein. Feel-Good-Manager klingt da gleich viel besser und moderner.
Egon D.(Gast) schrieb
> In der Softwerkerei ist das noch schlimmer; dort ist die
"Produktion" mit dem Ende des Compilerlaufes (nahezu)
abgeschlossen.
Das machen allenfalls Bastler so. Dann kommt das Deployment. Oft muss
man sich noch um die Dokumentation nach aussen und Kompatibilitaeten
kuemmern. Versionsnummern. Konfigurationsfiles. Allenfalls, wie kommt
die Software an den Anwendungsort.
Pandur S. schrieb: > Das machen allenfalls Bastler so. Dann kommt das Deployment....> Dokumentation Und der Test, und die intensive Beobachtungsphase nach dem Deployment.
Stefan ⛄ F. schrieb: > Und der Test, und die intensive Beobachtungsphase nach dem Deployment. Das überlässt der moderne Softwerker schliesslich dem Kunden.
MaWin schrieb: > Das überlässt der moderne Softwerker schliesslich dem Kunden. Leider. Wann immer es geht (und das ist fast immer) testet bei uns erstmal der Programmierer selbst samt Protokoll. Dann ein anderer Programmierer, der schau auch in die Quelltexte. Dann übergeben wir an die QA zum offiziellen Test (wieder mit Protokoll). Und die übergeben an den Betrieb, wo nochmal kurz die normalen Fälle getestet und protokolliert werden. Die speziellen Corner-Case und Fehlerfälle lässt der Betrieb beim letzten Test aus. Erst danach darf bei uns Software in die Produktions-Umgebung. Dieser Aufwand ist nicht übertrieben sondern notwendig. Bei unseren Anwendungen werden persönliche Daten (Ausweisdokumente) und Bezahlvorgänge verarbeitet. Wir haften für alle Verluste durch Design-, Software- und Hardware-Fehler. Wenn jemand den Ablauf par ordre du mufti abkürzt, werde ich immer sehr nervös.
Pandur S. schrieb: > Das machen allenfalls Bastler so. Dann kommt das Deployment. Ich habe keine Ahnung, wo Du Egon zitiert hast, aber er hat vollkommen recht. Deployment und Co gibt es bei anderen Produkten auch, sind aber unabhängig von der Produktion. In seinen Worten steckt konzentriert der wesentliche Unterschied zwischen SW und anderen Produkten.
A. S. schrieb: > Vielleicht funktioniert Scrum auch nur in USA gut, wo die Leute kaum > Fehltage haben und von 7 bis 7 die halbe Stunde täglich eher als Warm-up > zu sehen ist. Ich glaube eher, dass es deshalb funktioniert, weil die Amis eh gerne hemdsärmelig arbeiten und zudem auch eine durchschnittlich schlechtere Ausbildung haben, als wir hierzulande. Strategien sind da weniger verbreitet und daher ist jede neue besser, als gar nichts. Warum man sich hier in DE ausgerechnet da dranhängen muss, ist mir nicht plausibel! Ich beobachte SCRUM und das, was manche dafür halten, seit 2008 und kann sagen, dass es schon deshalb nicht funktioniert, weil jeder etwas anseres darunter versteht. Obendrein kommen viele aus Strukturen, die besser funktionieren und müssen mit SCRUM ein downgrade durchführen, oder sie haben zumindest das Gefühl, dass dem so ist. Es gab und gibt eine Reihe von unbenannten Vorgehensweisen in der Produktentwicklung, die bestens funktionierten. Beispiel: Stefan ⛄ F. schrieb: > Erst danach darf bei uns Software in die Produktions-Umgebung. > Dieser Aufwand ist nicht übertrieben sondern notwendig. Ja, das kennt man aus gut sortierten Firmen, die SW herstellen, die sicherheitsrelevant ist. Nur um das zu tun, braucht man kein SCRUM, weil es hier - wie an vielen Stellen - nur ein neues Wort für altes tun ist.
Beitrag #6869366 wurde von einem Moderator gelöscht.
Beitrag #6869438 wurde von einem Moderator gelöscht.
Beitrag #6869468 wurde von einem Moderator gelöscht.
Beitrag #6869485 wurde von einem Moderator gelöscht.
Jürgen S. schrieb: > Ich beobachte SCRUM und das, was manche dafür halten, seit > 2008 und kann sagen, dass es schon deshalb nicht funktioniert, weil > jeder etwas anseres darunter versteht. Das beobachte ich auch. Wobei SCRUM eine sehr genaue Definition hat. Eine Zahl >90% der "SCRUM"-Projekte die ich gesehen habe waren weit davon weg - kein Wunder, dass das nicht funktioniert, wenn man auf sein bestehendes Chaos nur "SCRUM" draufschreibt.
Jan H. schrieb: > Das beobachte ich auch. Wobei SCRUM eine sehr genaue Definition hat. > Eine Zahl >90% der "SCRUM"-Projekte die ich gesehen habe waren weit > davon weg - kein Wunder, dass das nicht funktioniert, wenn man auf sein > bestehendes Chaos nur "SCRUM" draufschreibt. Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu 100% befolgst ? Nie ausprobiert ? Es funktioniert rein gar nicht. Du musst auch ein glückliches Leben haben, wenn du zu 100% nach Bibel oder Koran lebst.
MaWin schrieb: > Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu > 100% befolgst ? Ich bin nicht der gefragte aber als ich das damals lernen musste stand genau diese Behauptung im Lehrbuch und wurde in der Schulung propagiert. Scrum funktioniert nur wenn man sich vollständig an das Konzept hält. Genau daran scheiterte es dann auch. Also scheint die Behauptung wohl richtig zu sein. Man kann aber anders agil arbeiten, es muss nicht unbedingt nach SCRUM sein.
MaWin schrieb: > Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu > 100% befolgst ? Weil ich es gesehen habe. > Nie ausprobiert ? Es funktioniert rein gar nicht. Warum sollte es nicht funktionieren? > Du musst auch ein glückliches Leben haben, wenn du zu 100% nach Bibel > oder Koran lebst. Ja, ich halte mich an Regeln. Wenn ich mich nicht an die C-Syntax halte und irgendwas hinschreibe dann: * Kann ich nicht behaupten, in C zu entwickeln * Wird nur Unsinn herauskommen Wenn ich mich also dafür entscheide ein Projekt mit SCRUM durchzuführen, dann sollte ich es auch mit SCRUM machen und nicht irgendwie. Logisch, oder?
Beitrag #6869634 wurde vom Autor gelöscht.
Stefan ⛄ F. schrieb: > Ich bin nicht der gefragte aber als ich das damals lernen musste stand > genau diese Behauptung im Lehrbuch und wurde in der Schulung propagiert. Das "kein wahrer Schotte"-Phänomen: https://de.wikipedia.org/wiki/Kein_wahrer_Schotte Kennt man aus Religionen und Ideologien.
Jan H. schrieb: > Warum sollte es nicht funktionieren? Weil auch das mit dem Sozialismus nicht funktioniert hat. Und weil auch der Koran nicht zum Leben passt. Religionen sind Wahnvorstellungen, keine Lösungen. Scrum ist eine Religion. Und wer es je ausprobiert hat, gecoatcht, geschult, weiss, dass es nicht funktioniert.
MaWin schrieb: > Jan H. schrieb: >> Warum sollte es nicht funktionieren? > > Weil auch das mit dem Sozialismus nicht funktioniert hat. > > Und weil auch der Koran nicht zum Leben passt. > > Religionen sind Wahnvorstellungen, keine Lösungen. > > Scrum ist eine Religion. > > Und wer es je ausprobiert hat, gecoatcht, geschult, weiss, dass es nicht > funktioniert. Also hast du eine religiös-nebulöse Abneigung gegen SCRUM die du nicht konkretisieren kannst.
Jan H. schrieb: > Also hast du eine religiös-nebulöse Abneigung gegen SCRUM die du nicht > konkretisieren kannst. Nein, weil ich 20 Jahre in mehreren Firmeninkarnationen die immer strikter befolgte Umsetzung von Scrum miterleben durfte, und die immer dürftigeren Ergebnisse bewundern konnte. Die ersten Schulungen waren noch für SixSigma, dann kam das agile Chaos. Scrum Fanboys von der Realität zu berichten ist ähnlich sinnlos wie einen Pfarrer zum Atheismus bekehren zu wollen.
Wir haben in der automotive Serienentwicklung bewusst auch mal Projekte mit Scrum aufgesetzt zum Lernen und Erfahrung sammeln. Unterm Strich kam raus dass sowohl SCRUM als auch V-Modell (egal ob wenige grosse V oder viele kleine V) saubere Ergebnisse liefern können, ebenso kann man ASPICE und ISO26262 mit beiden Modellen abbilden. Genauso kann man mit kleinen V auch sich weiterentwickelnde Anforderungen gut abdecken. Und mit beiden Prozessen kann man auch problemlos ein Projekt gegen die Wand fahren. Je nach Teamstruktur (Charaktäre, Integration der Stakeholder uvm.) kracht es an anderen Stellen. Kosten und zeitmässig war nicht viel Unterschied. Scrum in einer V-Modell Firma ans Laufen zu bekommen hat einiges an Zeit gekostet, in beiden Welten ist der Aufwand um den Prozess auch in schwierigen Situationen einzuhalten ähnlich hoch. Scrum-Fundamentalisten oder bedingungslose Fanboys die nichts anderes machen wollen hatten wir bei V-Modell aber bei weitem nicht so ausgeprägt. ASPICE Zertifizierung für den Scrumprozess war vom Aufwand her auch nicht anders als für den V-Modell Prozess.
Stefan ⛄ F. schrieb: > Scrum funktioniert nur wenn man sich vollständig an das Konzept hält. Nun ja, eigentlich gilt das für alle Rezepte und Methoden, daß sie nur dann das gewünschte Ergebnis liefern, wenn man sich dran hält. Neben dem schon festgestellten Umstand, daß sich viele eben nicht 100% an die Methoden halten, kommt eben hinzu, dass die Methode selber nicht alles abdeckt. Ich sehe z.B. das Problem, daß man Vorgehensweisen, die man für SW-Projekte erdacht hat und die in Teilen auch funktionieren mögen, kritiklos und unreflektiert auf das gesamte Projektgeschen ausdehnt, was regelmäßig scheitern muss, weil weite Teile von Entwicklungsaktivitäten außerhalb der Sw eben grundsätzlich andere Bedarfe haben. Auch das ist ja bereits erkannt wurden. Und deshalb, weil viele erkennen, dass SCRUM-Methoden für ihren Bereich nicht taugen, wird bewusst oder unbewusst drum herum gearbeitet, was mithin wiederum der Grund dafür ist, daß SCRUM auch dort nicht funktioniert, wo es funktionieren hätte können.
Stefan ⛄ F. schrieb: > Genau daran scheiterte es dann auch. Also scheint die Behauptung wohl > richtig zu sein. Man kann aber anders agil arbeiten, es muss nicht > unbedingt nach SCRUM sein. Das ist aber bei jeder Religion so: Entweder es klappt oder man hat sich nicht 100% daran gehalten. Woher kommt eigentlich der Glaube, dass ein paar Männer etwas allgemeingültiges gefunden haben. Bei Diäten, Religionen, Yoga, ... geschenkt.
A. S. schrieb: > Woher kommt eigentlich der Glaube, dass ein paar Männer etwas > allgemeingültiges gefunden haben. Ich glaube es liegt daran, wer das ist und wer ihm nachhängt. Es reicht, wenn irgendein abgetakelter Schaubudenhengst (= Professor für irgendwas) lautstark auf einem Kongress etwas Tolles vorstellt und es wird kritiklos als Allheilmittel übernommen. Dipl Ing ( FH ) schrieb: >> Und befallen werden in erster Linie Firmen, die wissen, dass sie im >> Chaos arbeiten und sich diesen Strohhalm greifen, um sich aus dem Sumpf >> zu ziehen. > Viel besser kan man es nicht zusammenfassen !!! > SEHR GUT !!! Ich schließe mich an! Unser lieber Konzernboss hat erst vor Tagen wieder verkündet, die gesamte Firma auf agil umzustellen und jetzt werden Scrum-Master ausgebildet, was das Zeug hält. Jeder, der zum intensiven Denken zu bequem oder zu alt ist, um sich mit den Details neuer Technologien zu befassen, meldet sich als potenzieller Master, um seine Zeit mit managing und Verwaltung zu vertrödeln, weil er das als bequemer ansieht.
Chris R. schrieb: > Wir haben in der automotive Serienentwicklung bewusst auch mal Projekte > mit Scrum aufgesetzt zum Lernen und Erfahrung sammeln. Interessante Auflistung. Was ist das Ergebnis? SCRUM beibehalten? Global oder projektweise?
SCRUM funktioniert dann gut, wenn es ohne auch gut funktioniert. Wenn das Team passt und die Leute kompetent sind, dann bekomme ich mit jeder Methode gute Software hin. Wenn das nicht der Fall ist, hilft SCRUM leider auch nicht.
Stefan ⛄ F. schrieb: > Scrum funktioniert nur wenn man sich vollständig an das Konzept hält. Wirklich praktikable und robuste Prozesse erkennt man daran, daß die auch dann stabil funktionieren, auch wenn nicht alles genau nach Plan läuft. Oliver
Cyblord -. schrieb: > SCRUM funktioniert dann gut, wenn es ohne auch gut funktioniert. So ist es, nur ist es dann eigentlich ein überflüssiges Korsett. Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen als "agil" preist also wendig, schnell an geänderte Problemstellungen anpassbar, aber dazu voraussetzt dass das nur dann funktioniert wenn man sich stur und zu 100% an diese starre Konzept hält.
●DesIntegrator ●. schrieb: > Stefan ⛄ F. schrieb: >> Putzfrauen > purge-coordinator Unterschätze die Putzfrauen nicht: Die Kollegen in einer Abteilung, die mit SCRUM arbeiteten, wunderten sich des Öfteren, warum Tasks die eigentlich abgearbeitet waren, auf der TODO-Spalte wieder auftauchten und umgekehrt in Arbeit befindliche Teilprojekte als "erledigt" standen, was immer wieder zu Verdruss und Missverständnissen führte. Bisweilen passierte es sogar, dass Aufgaben komplett verschwanden oder solche, die schon im virtuellen Papierkorb waren, wieder auftauchten. Es dauerte eine Weile, aber irgendwann konnte ich mit eigenen Augen sehen, was passierte: 3x die Woche kam abends die Putzfrau, welche feucht durchwischte und danach immer das Fenster öffnete, um den Zitrusduft rauszulassen. Dabei wurden Zettel runtergeweht und landeten auf dem Boden. Die Putzfrau war fleißig und pflichtbewusst und hängte die bunten Zettelchen einfach wieder auf, ohne um die Wirkung der Position der Notizzettel zu wissen. Man fasst es eigentlich nicht, dass da keiner drauf gekommen war, aber es stimmte: Die Putzfrau agierte ungewollt als Scrum-Master.
Udo S. schrieb: > Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen als "agil" > preist also wendig, schnell an geänderte Problemstellungen anpassbar, > aber dazu voraussetzt dass das nur dann funktioniert wenn man sich stur > und zu 100% an diese starre Konzept hält. Eigentlich nicht, denn sich formell an etwas zu halten, das inhaltlich "Weichheit" vorgibt, ist keineswegs starr. Viele Schluderer sind ja auch sehr konsequent schludrig :-) Das Problem das ich mit SCRUM habe ist dreierlei: a) inhaltlich gesehen wird ein fester Zeittakt vorgeben, der nicht notwendigerweise auf das Vorgehen passt. Es gibt Aufgaben die sehr viel enger getaktet werden müssen, um sie zu synchen und umgekehrt. b) es wird vielfach alter Wein in neuen Schläuchen verkauft und so getan, als sei das erstmalige Einführen einer Methode automatisch eine Verbesserung, was bekanntlich nur dann stimmt, wenn eine bereits existierende Methode auch wirklich verbessert wird. Da SCRUM aber eher dazu dient, einen zuvor unorganisierten ->Haufen zu koordinieren, ist das wie beim Autopilot im Sportflugzeug: Ein erfahrener Pilot steuert besser und genauer und ist faktisch tatsächlich der agilere c) da SCRUM praktisch eine Koordination vorgibt, die eine gewisse Dynamik vorgibt, neigen viele Nutzer dazu, sich noch weniger Gedanken über vorausschauendes Handeln in Projekten zu machen, als sie es ohnehin schon tun und bei der steigenden Komplexität heutiger Projekte braucht es IMO eher mehr Vorausdenken und Vorausplanung, als früher. Damit führt die Nutzung von SCRUM (ungewollt) zu mehr Chaos, das es aber nicht in der Lage ist, wegzukompeniseren. Auch der SRUM-Master hat nicht das Potenzial dazu und ist streng genommen auch nicht derjenige, der das zu leisten hätte. Mithin habe ich auch mit dem Titel des SCRUM-Masters ein Problem, wenn ich sehe, dass solch ein Titel in Wochenendseminaren erworben werden kann. Ich habe große Probleme, mir vorzustellen, dass man in 2 Tagen etwas lernen kann, das einen befähigt, einen Entwicklerhaufen zu koordinieren, oder sich ihn selber koordinieren zu lassen, damit eine Art von Ordnung entstehen kann, die über das signifikant hinaus geht, was sich erfahrene Entwickler über Jahre an Vorgehensweisen angeeignet haben.
Man kann sogar noch weiter gehen und feststellen, dass diejenigen Entwickler, die ein funktionierendes Konzept für die Umsetzung von Projekten haben, als starr und unflexibel hingestellt werden, auch wenn es genauer und ausgefeilter ist. Nimmt man z.B. eine typische Geräteentwicklung mit Mechanik, Elektronik und Software, dann gibt es ganz bestimmte Zyklen und Punkte, an denen das synchronisiert werden muss und es gibt Schleifen, die innen in den Komponentensträngen laufen. Wo diese Punkte jeweils sind, hängt von der Balance der 3 Komponenten und damit vom Gerät ab. Es gibt Systeme, die stark mechaniklastig sind, z.B. Optiken, Präzisionsmechaniken und Ähnliches, die zu anderen (früheren) Zeitpunkten eine rudimentäre Elektronik und Software brauchen, um sie zu testen und optimieren zu können. Dagegen gibt es Systeme, die das gar nicht brauchen und erst alle Iterationen in der Elektronik und Software vollzogen sein müssen (oder dürfen) bevor man es zusammenwirft. Hinzu kommt, dass je nach Projekt unterschiedliche Komponenten schon teilfertig aus Vorprojekten übernommen werden. Solche Dinge aufzuplanen erfordert entsprechendes Knowhow der Systemtechnologen und genaues Wissen um die Abläufe. An der Stelle könnte man ein SCRUM-System einsetzen, um die Ideen, die Vorschläge und die Konzepte gemeinsam in engen Zeitschleifen zu formulieren und zu optimieren, um dann etwas weitgehend Durchdachtes an die Entwickler zu geben. Stattdessen läuft es oft genau umgekehrt: Man springt mit 2 DIN-A4-Seiten an Konzept in die Abteilungen und lässt dann alle längs und quer-synchronisieren und verschiebt das SCRUMing so in die Abteilungen, wo das halb Angedachte dann ausreifen soll. Da denken dann aber oft zu viele- und nicht selten auch die falschen Personen mit und entwickeln lokale Lösungen, die dann wieder Aufgaben für anderen aufwerfen. Damit steigt der Koordinationsaufwand und die Nutzung von SCRUM rechtfertigt sich zu 50% selber. SCRUM mag zur Lösung einer definierten Aufgabe gut sein, an denen ein eng begrenzter Personenkreis mit gleichem Wissen und Befähigung arbeitet, damit man Aufgaben schnell umverteilen kann, was ja aus Projektleitersicht sehr wichtig ist. Es macht aber IMHO keinen Sinn, solche Konzepte quer über alle Abteilungen zu ziehen, wo jeder etwas anderes tut und anderes Wissen hat und damit auch Elektroniker, Tester und Mechaniker mit einzubeziehen, so als sei die gesamte Entwicklungsabteilung aus 30 Leuten ein Riesen-Team, wo jeder ständig über alles Bescheid wissen muss, um über die nächsten Schritte mit zu entscheiden. Das ist definitiv nicht nur nicht erforderlich sondern auch kontraproduktiv. Genau das sehe ich aber in vielen Firmen: Da stehen 10 und mehr Personen in einer Runde zusammen und berichten dem Projektleiter über ihre Fortschritte und jeweils N-1 davon hören mit, während deren Zeituhren nutzlos laufen, weil sie mit dem Projektfortschritt des Kollegen Müller von gestern auf heute nichts anzufangen wissen. Selbst wenn der Herr Müller auch Software macht und sogar am gleichen Paket arbeitet, hat es auf die eigene Arbeit keinen direkten Einfluss und das breit verteilte Wissen um seine Probleme hilft ihm nicht weiter, da man ihm praktisch keine Tipps geben kann, ohne sich seine Sachen wirklich ganz genau anzusehen. Daher läuft es oft auf die typischen Tipps aus der Hüfte hinaus, die aus gleich mehreren Kehlen kommt. Wichtiger wäre die Definition klarer milestones mit Zeitpunkt und Inhalt, damit alle gerade drauf zu arbeiten können und der Synch-Aufwand klein bleibt und nicht einer etwas macht, was zu große Auswirkungen auf andere hat, die erst beim Umsetzen auftauchen, statt sie sich vorher zu überlegen. Schon wenn Elektronik-Entwicklung und Softwareerstellung nicht gut genug entkoppelt sind, gibt es Chaos und beide Seiten müssen unproduktive Änderungen machen, weil man feststellt, dass das Konzept nicht passt. Die Denkarbeit in den Projekten muss so weit als möglich von der Umsetzung entkoppelt werden damit ein Ziel, das definiert ist ohne große Änderungen erreicht wird. Iterationen im Projekt müssen mit milestones abgefangen werden, z.B. wenn mitten drin neue Anforderung kommen. Alle Team-Mitglieder müssen sich neu und spontan ergebende Aspekte frühzeitig melden, sie müssen erst abgestimmt werden und nach Beschluss Eingang in einen kommenden zu definierenden milestone haben. Innerhalb eines Projektteilziels sehe ich das nur bei der Umsetzung von einer Software, wo drei-vier Leute dran arbeiten - dort macht das Sinn. Wenn der Softwerker aber etwas macht, was dann HW-Änderungen zur Folge haben sollte, ist was falsch gelaufen. Daher muss der Projektleiter derjenige sein, der die Übersicht behält und die Fortschritte der Mitglieder im Auge hat. Damit das aber klappt, braucht es detaillierte Umsetzungspläne, also eine Vorschrift, was Müller, Meier und Schulze zu tun haben und zu tun gedenken und das müssen sie selber aufplanen und auch selber pflegen. So etwas kann man auch elektronisch gestützt machen, indem man sich eine TODO-List aufbaut, die Zeiten und Erfüllungsprozente enthält. Dann hat man jederzeit eine Übersicht, über das was geleistet ist und wann der nächste milestone erfüllt sein wird. Das sieht dann auch der Projektleiter, wenn er es spontan abfragt, um zu checken , wo jeder steht kann gfs. umplanen. Das muss er aber nicht jeden Tag und auch nicht bei Jedem. Elektronisch gestützt sollte auch ein SCRUM-Management selbst sein. Sofern keine andere Software vorliegt, empfehle ich meinen Kunden immer, EXCEL zu verwenden. Dort lassen sich die bunten Zettel sauberer beschreiben, mit Inhalten und Dokumenten verlinken, als Taskt leicht verschieben und es lässt sich auch einfacher mit MS Teams arbeiten, sodass niemand auf die Idee kommen muss, das Bunte-Zettel-Board nach dem Meeting abzufotografieren, um es durch die Welt zu schicken (was ich schon miterlebt habe!) Und: Es fallen vor allem keine Zettel aus dem Excel raus, sodass die Putzfrau zum Scrum-Master wird: Beitrag "Re: Verbreitung von SCRUM"
Scrum-Geschädigter schrieb: > Unser lieber Konzernboss hat erst vor Tagen wieder > verkündet, die gesamte Firma auf agil umzustellen und jetzt werden > Scrum-Master ausgebildet Das muss sich um VW handeln :)
Beitrag #7091430 wurde von einem Moderator gelöscht.
Beitrag #7091531 wurde von einem Moderator gelöscht.
Udo S. schrieb: > Cyblord -. schrieb: >> SCRUM funktioniert dann gut, wenn es ohne auch gut >> funktioniert. > > So ist es, nur ist es dann eigentlich ein überflüssiges > Korsett. Nicht notwendig. Es gibt in der Realtität mehr als "Schwarz" oder "Weiss". Scrum versucht -- wie jede andere Methodik -- auch nur, das lehrbar und lernbar zu machen, was talentierte Leute "einfach so" können. > Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen > als "agil" preist also wendig, schnell an geänderte > Problemstellungen anpassbar, aber dazu voraussetzt dass > das nur dann funktioniert wenn man sich stur und zu 100% > an diese starre Konzept hält. Der Satz enthält m.E. mindestens drei inhaltliche Fehler.
Jürgen S. schrieb: > a) inhaltlich gesehen wird ein fester Zeittakt vorgeben, > der nicht notwendigerweise auf das Vorgehen passt. Das ist zwar richtig, aber ich würde diesen Punkt nicht dramatisieren. Das ist m.E. ein Zugeständnis an die Einfachheit der Methode; sie soll ja praktikabel bleiben. > Es gibt Aufgaben die sehr viel enger getaktet werden > müssen, um sie zu synchen und umgekehrt. Ich habe das so aufgefasst, dass die Methode nur ein Minimum an Zeremonien VORGIBT. Dass sich Teile des Teams -- oder auch alle -- öfter treffen, als die Methode vorschreibt, wird ja nicht verboten. > b) [...] Da SCRUM aber eher dazu dient, einen zuvor > unorganisierten ->Haufen zu koordinieren, ist das wie > beim Autopilot im Sportflugzeug: Ein erfahrener Pilot > steuert besser und genauer und ist faktisch tatsächlich > der agilere Das ist sachlich richtig -- aber ein unsinniger Vergleich. Eine eingespielte Truppe ist NATÜRLICH besser als ein zusammengewürfelter Haufen -- ist das jetzt echt so verwunderlich? Soweit ich gehört habe, sind bei den Amis ad hoc zusammen- gewürfelte Teams noch häufiger als bei uns. Es hat wenig Sinn, eine dort entstandene Methode unreflektiert auf hiesige Verhältnisse zu übertragen. > c) da SCRUM praktisch eine Koordination vorgibt, die > eine gewisse Dynamik vorgibt, neigen viele Nutzer dazu, > sich noch weniger Gedanken über vorausschauendes Handeln > in Projekten zu machen, als sie es ohnehin schon tun > und bei der steigenden Komplexität heutiger Projekte > braucht es IMO eher mehr Vorausdenken und Vorausplanung, > als früher. Dem zweiten Teil (Komplexität) stimme ich zu; dennoch denke ich, dass Du das Pferd vom Schwanz her aufzäumst. Meiner (durchaus beschränkten) Erfahrung nach können nur die allerwenigsten Leute kurz und prägnant erklären, wie Entwicklungsarbeit funktioniert -- und das betrifft m.E. Entwickler (!) genauso wie Manager. Das führt dann dazu, dass wechselseitig unsinnige Vorgaben gemacht oder Wundertaten verlangt werden, die nicht zu leisten sind. Eine besondere Gruppe sind die alten Kämpfer -- sie können es zwar auch nicht immer erklären, wissen dafür aber aus Erfahrung, was zu tun ist. Da ihre Intuition aber nicht Kraftpunkt-fähig ist, werden ihre Ansichten einfach vom Tisch gewischt... > Damit führt die Nutzung von SCRUM (ungewollt) zu > mehr Chaos, das es aber nicht in der Lage ist, > wegzukompeniseren. Ich denke, die Lage ist noch etwas schlimmer: In einem "Wasserfall"-Projekt kann man während der Projekt- laufzeit ganz gut arbeiten, wenn die Führungstruppe ihr Handwerk versteht. Das böse Erwachen kommt dann erst ganz am Schluss des Projektes, wenn nix aneinanderpasst, am Markt vorbei- entwickelt wurde und dergleichen. Das ist dann primär das Problem der Chefetage -- und erst sekundär das der Indianer. Da die Häuptlinge den "big bang" unbedingt vermeiden möchten, aber andererseits nicht die leiseste Ahnung davon haben, was die Nerds eigentlich MACHEN, wenn sie entwickeln, bietet sich "agil" als Rettung an: Jeder muss sich ständig mit jedem abstimmen, keine Festlegung ist verlässlich. Wenn die Entwickler reihenweise in der Klappsmühle landen, ist das ja ihr PERSÖNLICHES Problem, kein BETRIEBLICHES. Privatisierung gesellschaftlicher Risiken. Ich denke aber nicht, das Scrum das primäre Problem ist; das ist eher ein hilfloser Versuch der Lösung. Das Problem ist m.E. die unglaublich gestiegene Komplexität der Aufgaben. Ironischerweise verschlimmert die Automatisierung geistiger Routineaufgaben das Problem, statt es abzuschwächen -- das, was vor 50 Jahren eine ganze Abteilung geleistet hat, muss heute ein einzelner Entwickler beherrschen. Die Folge sind heterogene Team -- da arbeitet eben ein Mechaniker und ein Programmierer und ein Digitalentwickler und ein HF-Mensch an einem Gerät, und der Chef ist ein Physiker. Folge: Der "allwissende Planer", der vor fünfzig Jahren vielleicht noch funktioniert hat, ist zur Illusion geworden; die Projektsteuerung muss (zumindest teilweise) auch vom Team gemacht werden, weil das von einem Einzelnen in vielen Fällen nicht mehr beherrschbar ist. Genau das wird aber nirgendwo gelehrt. > Ich habe große Probleme, mir vorzustellen, dass man in > 2 Tagen etwas lernen kann, das einen befähigt, einen > Entwicklerhaufen zu koordinieren, oder sich ihn selber > koordinieren zu lassen, damit eine Art von Ordnung > entstehen kann, die über das signifikant hinaus geht, was > sich erfahrene Entwickler über Jahre an Vorgehensweisen > angeeignet haben. Kann man ganz sicher nicht. Es wäre ja schon etwas gewonnen, wenn man keine 20 Jahre Erfahrung mehr bräuchte, sondern mit einem Jahr Training und Anleitung auskäme... Man muss kein Top-Entwickler sein, um eine Entwicklertruppe zu führen. Man muss nur wissen, wie Entwickler ticken, muss ihnen die Verwaltungsarbeit abnehmen und den notwendigen Input liefern. Die Probleme LÖSEN können sie dann schon allein... Der beste Chef, den ich bisher hatte, war... ein Kaufmann. Man sollte es kaum glauben...
Egon D. schrieb: > Man muss kein Top-Entwickler sein, um eine Entwicklertruppe > zu führen Doch Ein Trainer muss auch zum immer ein top Fußballer (gewesen) sein. Ein Chefentwickler muss top Entwickler sein. So ist es auch in erfolgreichen Firmen. Natürlich gibt es auch Projektleiter, die die Entwickler entlasten und Verwaltungsarbeit abnehmen. Die führen dann aber nicht. Der Führende muss nicht in jeder Disziplin top sein, nicht Mal in einer der gerade verwendeten. Aber er braucht diese Erfahrung, notfalls aus einer anderen Disziplin.
Egon D. schrieb: > Soweit ich gehört habe, sind bei den Amis ad hoc zusammen- > gewürfelte Teams noch häufiger als bei uns. Genau darauf wollte ich mit meinem Beispiel hinaus: Eine Methode, die an einer Stelle für eine Gruppe entwickelt wurde, passt nicht automatisch auf eine andere, in einem anderen Land. Gerade die amerikanische Methode der kurzen Ausbildung und der hemdsärmeligen Besetzung von Stellen, wo Mr. Miller auf Empfehlung von Mr. Meyer eingestellt wird, weil ein Teamleiter für die Besetzung "seines" Teams alleinverantwortlich ist, führt zu heterogenen Besetzungen, obwohl sie homogener sein könnten. In Deutschland haben wir einen anderen Bildungsfokus und Arbeitsstile, die sich ja bisher durchaus bewährt haben. Oder sagen wir "hatten", bis man auf die Methode USA gesetzt hat. Ein Punkt z.B. ist, dass Ingenieure in DE immer sehr viel selbständiger, fachübergreifender und verantwortlicher arbeiteten, als in vielen anderen Ländern. Diese Diskrepanzen sehe ich im Übrigen auch bei der Betrachtung von Methoden wie KANBAN und KAIZEN, die aus Japan kommen. In Japan wird sehr stark Top-Down gedacht und dort entscheidet oft alleinig der Boss.
Jürgen S. schrieb: > ●DesIntegrator ●. schrieb: >> Stefan ⛄ F. schrieb: >>> Putzfrauen >> purge-coordinator > > Unterschätze die Putzfrauen nicht: > > Die Kollegen in einer Abteilung, die mit SCRUM arbeiteten, wunderten > sich des Öfteren, warum Tasks die eigentlich abgearbeitet waren, auf der > TODO-Spalte wieder auftauchten und umgekehrt in Arbeit befindliche > Teilprojekte als "erledigt" standen(...) > Es dauerte eine Weile, aber irgendwann konnte ich mit eigenen Augen > sehen, was passierte: 3x die Woche kam abends die Putzfrau, welche > feucht durchwischte und danach immer das Fenster öffnete, um den > Zitrusduft rauszulassen. Dabei wurden Zettel runtergeweht und landeten > auf dem Boden. Die Putzfrau war fleißig und pflichtbewusst und hängte > die bunten Zettelchen einfach wieder auf(...) (ᐛ) Ich hätte gedacht, dasss die modernen Arbeitsweisen dazu führen sollten, eben KEINE Zettelwirtschaft mehr zu haben
A. S. schrieb: > Egon D. schrieb: >> Man muss kein Top-Entwickler sein, um eine Entwicklertruppe >> zu führen > > Doch > > Ein Trainer muss auch zum immer ein top Fußballer (gewesen) sein. Ein > Chefentwickler muss top Entwickler sein. So ist es auch in erfolgreichen > Firmen. Mourinho, Nagelsmann, Sampaoli, Sacchi, Benitez, Villas-Boas, um nur einige Gegenbeispiele zu nennen, die mir auf Anhieb einfallen.
A. S. schrieb: >> Man muss kein Top-Entwickler sein, um eine Entwicklertruppe >> zu führen > Doch Das habe ich aber anders erlebt. Der mit Abstand beste Projektleider mit dem ich (als Softwareentwickler) den vergangenen 30 Jahren zu tun hatte, hat noch nie eine einzige Zeile programmiert.
Stefan F. schrieb: > Projektleider :-) Stefan F. schrieb: > hat noch nie eine einzige Zeile programmiert. die sind bei Vielen sehr beliebt, weil sie denen alles unterjubeln können. Mir sind die Kompetenten lieber, weil die ihre Grenzen und die Komplexität des Themas verstehen und meine Lösungsansätze nachvollziehen können, statt sich auf die einfachen und schnellen Vorschläge stürzen, weil sie aus Unsicherheit nichts überschauen und "sichere" Wege gehen wollen.
Pleitegeier schrieb: > Mourinho, Nagelsmann, Sampaoli, Sacchi, Benitez, Villas-Boas allesamt Erst- und Zweitliga-Spieler in ihren Ländern gewesen- also eher schlechtes Gegenbeispiel.
Statt ein (Fachfremder) Scrum "master", hätte ich gern ein weiterer Entwickler im Team. Jemand der im Meetings sitzt, Zeug delegiert, und mich fragt "welches Tier bin ich", brauche ich wirklich nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.