Wie bekommt man Software wieder schlank?

[RMC]

Ich suche Rat von erfahrenen Software Entwicklern.

Ich habe in den letzten Jahren mit dem Fokus auf C# in mehreren Teams und Firmen Projekte kennengelernt, bei denen die Software selbst sehr agil war, die Prozesse allerdings nicht. Was ich darunter verstehe ist: Kleine Änderungen an der Software konnten schnell gemacht werden und es war wenig Aufwand notwendig, trotz einer gewaltigen Komplexität.
Die Prozesse allerdings waren dann eher Richtung "wir machen irgendwas mit Scrum". Vieles war nicht definiert, holprig, oder hat komplett gefehlt. Tests gab es teilweise und auch wieder nicht.

Heute steht es in einem anderen Team ganz genau andersrum: Die Prozesse sind lange gereift und wirklich gut, von Scrum, TDD, Pair Programming über Requirement Engineering und Code Reviews ist alles dabei. Die Entwicklung ist agil und kann schnell reagieren.
Allerdings: Die Software ist alles andere als agil und jede triviale Änderung dauert lange, obwohl die Software selbst gar nicht so komplex ist.

Ich gebe ein Beispiel:

Ein Device hat ein Property (bool), das in einer UI mit einem Schalter visualisiert wird. Die Änderung am Schalter soll ans Device übertragen werden.

Das ist ziemlich straight-forward, übersichtlich und sollte als Erweiterung schnell machbar sein auf dem Papier. In jeder Software.

Allerdings ist es in der Realität so, dass mehrere Schichten (Adapter, Proxys, MessagingSystem, Listeners, etc. etc.) angefasst werden müssen und jede muss durchgetestet sein. Trotz aller Prozesse wird die scheinbar simple Änderung zur Herausforderung, was ziemlich absurd ist. Es ist genau das Gegenteil von agil.

Verwendet wird Java, alles ist in OOP durchexerziert mit Patterns und sämtlichen Prinzipien wie SOLID etc. durchdesigned. Es sollte also alles in der Theorie gut passen. Aber am Ende ist halt leider unterm Strich von der Einfachheit gar nichts mehr da, wenn man für jede Änderung 2 Tage braucht. Sieht man auch an der Velocity.

Fazit: Agile Software Development ja, Agile Software nein.

Ich denke, eine der notwendigen Maßnahmen ist Refactoring und Entschlackung, um die Simplizität wieder in Gang zu kriegen, wegzukommen von all den bloated Codeklassen und ihren Suffixen und Namen, die eigentlich alles so lange abstrahieren bis keiner mehr weiss wo die Funktionalität eigentlich ist (AbstractSingletonProxyFactoryBean lässt grüssen, danke an Ganon). Das ist halt eine der Krankheiten von übermäßiger Object Orientation. Das widerspricht möglicherweise aber wiederum einigen Designansätzen.

Daher auch meine Frage an die erfahrenen Entwickler die sowas schon durchgemacht haben: Wie kriegt man Software wieder in Gang, deren Einfachheit durch zahlreiche Massnahmen so verloren gegangen ist?

Wie verringert man Komplexität ohne irgendwelche Prinzipien über Bord zu werfen und macht Software wieder schlank und einfacher, fokussiert auf Funktionalität?

[EPIC_FAIL]

Ein Device hat ein Property (bool), das in einer UI mit einem Schalter visualisiert wird. Die Änderung am Schalter soll ans Device übertragen werden.

...

Allerdings ist es in der Realität so, dass mehrere Schichten (Adapter, Proxys, MessagingSystem, Listeners, etc. etc.)

Das klingt jetzt aber nach schlechter Architektur. Gerade wenn irgendwas am Messaging aktiv geschraubt werden muss um eine einfache UI Erweiterung zu schreiben. Was verwendet ihr denn für Technologien?

[RMC]

Das klingt jetzt aber nach schlechter Architektur. Gerade wenn irgendwas am Messaging aktiv geschraubt werden muss um eine einfache UI Erweiterung zu schreiben. Was verwendet ihr denn für Technologien?

Die Software ist schon vor einiger Zeit entwickelt worden und vieles ist aus "historischen Gründen" gewachsen, eben auch in der Architektur, was ich aber irgendwo auch als absurd empfinde im Sinne von Agile SWD. Zum Thema Technologie kann ich nur sagen, dass Java und Standard Toolchains eingesetzt werden.

[josefYY]

Bei mir auf der Arbeit habe ich ein ähnliches Problem aber mit umgekehrter Ursache.
Vorgänger war wohl langjähriger C-Programmierer.
Hat wohl zum ersten Mal in Java/JSF eine Anwendung geschrieben.
Komplett ohne OO.
Die 'Main'-Bean hat 20.000 Zeilen!
Die muss ich nun Refactorn :(

[Mosher]

Wir hatten mal so ein ähnliches Problem. Die Software war ursprünglich sehr schlank, irgendeine GUI zur Fernsteuerung eines Geräts in QT erstellt und genau auf das zu bedienende Gerät abgestimmt.
Wie es halt so ist, änderte sich sowohl das Gerät, als auch die Anforderung an die SW ständig.

Es wurde seitens des Kunden auf das V-Modell verzichtet, also entwickelte man "agil" und "wird schon irgendwie gehen". Es gab kaum noch validierende Tests und keine Zeit mehr für Codepflege. Das Dilemma, wenn man sich zu sehr für den Kunden verbiegt: Er gewöhnt sich dran, dass er jedes Feature zum Spottpreis auf Knopfdruck bekommt. Wenn dann beim Zulieferer die Übersicht verloren geht, interessiert es den Kunden nicht.

Der "Code" hat mittlerweile über 15.000 Zeilen in einer einzigen Klasse, ist eigentlich nicht mehr wartbar. Bei jedem neuen Feature betet man mehr oder weniger, dass sich eine Neuerung nicht auf 3/4 des Codes auswirkt. Mittlerweile haben auch zu viele Leute ihre Finger im Spiel.

Man sollte sich also gar nicht auf solche Spielchen einlassen, bzw. wenn der Kunde ein wichtiger ist, muss man halt versuchen, transparent zu bleiben und solche Dinge an einem Tisch besprechen. zB Beim nächsten größeren Release müssen wir mal eine längere Refactoring-Runde einplanen. Dadurch werden zukünftige Projekte wieder einfacher, schneller, billiger..

Wenn's natürlich "nur" für inhouse ist, ist natürlich nie Budget für sowas vorhanden.

Ich sage, machbar ist es immer, kritisch wird's dann, wenn der Aufwand, einfach alles neu zu schreiben, geringer ist, als 20.000 Zeilen aufzuräumen und man das dann vor irgendwem rechtfertigen muss.

[Monger]

Die gute Nachricht ist: das Phänomen ist eigentlich gut erforscht, Stichwort https://de.wikipedia.org/wiki/Technische_Schulden .

Die schlechte: ich kämpf jetzt seit vier Jahren in dem Projekt hier gegen abfallende Produktivität, und selbst wenn man weiß was zu tun ist, ist es echt nicht einfach da was zu reißen. Da geht es auch ganz viel um menschliche Faktoren.

Ich kenn dein Projekt nicht, aber mal ins Blaue geraten, ein paar mögliche Ursachen:
- Schlechte Teststrategie
- Lange Feedbackzyklen durch Branching/Übergabeverfahren etc.
- Geringe Kohäsion, hohe Kopplung
- Langes Feedback durch schwaches Tooling, z.B. komplexe und lange Builds

1) nehme ich bei dir einfach mal als gegeben an. 2) hast ja gesagt, ihr habt eure Prozesse eigentlich gut im Griff.

Zu 3)
Das schwierigste ist erstmal, das sichtbar und dann messbar zu machen. Aber um mal irgendwo anzufangen:
- Wieviele JAR Pakete kompiliert ihr? (oder Assemblies, o.ä.)
- Wieviele Abhängigkeiten besitzt jedes Paket? (Ausgenommen JDK. Minimum, Maximum, Durchschnitt - lässt sich oft mit nem simplen XML Tool o.ä. rausfinden)
- Welche Pakete haben ähnliche Abhängigkeiten? (Pakete mit ähnlichen/gleichen Abhängigkeiten sind eigentlich ein Smell für schwache Kohäsion)
- Welche Pakete werden besonders oft referenziert?

Ich trommel hier sehr stark für das Thema https://de.wikipedia.org/wiki/Inversion_of_Control , einfach weil es eine gute Methode ist um den Kopplungsgrad sichtbar zu machen. Sobald man das sieht, kann man Code durch die Gegend schieben, erst um Klassen, und dann irgendwann Pakete neu zu ordnen. Irgendwann brechen dann allmählich die Abhängigkeiten weg, und die Wege werden kürzer. Das heißt auch dass Änderungen für ein Feature stärker lokal begrenzt sind, statt mit der Schrotflinte quer durch den Code zu ballern.

Zu 4)
Man darf auch nicht unterschätzen was eine gute Toolchain bewirken kann, Stichwort https://de.wikipedia.org/wiki/DevOps
Dazu kann man sich mal folgende Fragen stellen:
- Wie lange dauert es, bis ein Entwickler eine Zeile Code ändert, und feststellen kann was diese Änderung bewirkt hat?
- Wieviel Zeit benötigt ein Entwickler, um sich einen stabilen Stand vom gesamten Produkt zu holen und ausprobieren zu können?

Änderungen an der Build Chain bzw. den Quality Gates haben meiner Erfahrung nach massive Auswirkungen auf die Produktivität - sowohl negativ als auch positiv. Mit kleinteiligeren und besser zugeschnittenen Builds kann man das Entwicklungstempo potentiell deutlich steigern, dafür muss aber auch die Architektur passen.

[#44]

Um an das Thema Toolchain anzuknüpfen: Manchmal ist eine gewisse Komplexität für sauberen Code unerlässlich, aber es wird zu wenig auf Code-Generatoren gesetzt. Z.B. Konverter, die auf Ebene der Geschäftsobjekte Instanzen von JPA Klassen in Instanzen der Webservice Klassen wandeln. Sowas muss eigentlich niemand von Hand schreiben. Einmal den Konverter Programmieren und die Klassen entsprechend annotieren und jegliche Änderung am Datenmodell kann automatisiert mitgezogen werden.

[Frucht-Tiger]

Ich hatte auch schonmal ein ähnliches Problem in einem Projekt, hatte GWT als GUI (bringt sehr viele Pattern/Abstraktionen als "best practices" mit) und hintendran eine Spring Backend mit "allen" Pattern, Abstraktionen und OOD/IoC Konzepten die man sich so vorstellen kann. Wollte man eine neue Spalte von der DB auf die Oberfläche bringen, musste man mehrere Dutzend Klassen anpassen. Hat auch viel Wissen über die Technologien benötigt und jede Menge Zeit gekostet.

Ich/wir fanden es auch sehr schwierig davon wegzukommen. Die meisten Guides und Bücher legen dir ja gerade genau nahe so einen Kram einzuführen um produktivere und wartbare Software zu bekommen. Vielleicht sollte man eine Warnung einbauen, dass man nicht "alle" einführen sollte =)

Bei dem Projekt haben wir am Ende die Software neu geschrieben, bzw. neue Features in einem neuen System entwickelt und den alten Kram über ein iframe für den Übergang eingebunden.

Bei der neuen Software haben wir dann nur noch Libs/Frameworks/Pattern eingeführt wenn wir sie wirklich gebraucht haben. Dazu haben wir alles nach TDD implementiert und sind wirklich streng immer den simpelsten Weg gegangen. Das Ergebnis war wirklich sehr gut, die Produktivität hervorragend.

Es war aber kein einfacher Weg, versuch mal einem Java Entwickler zu erzählen er soll kein JPA benutzen sondern das SQL selbst schreiben und ein Mapping zur DB implementieren nur mit JDBC ;D

Im Gegensatz zu #44 würde ich also empfehlen, lieber mal wieder den Code selbst zu schreiben. Das ist auch einfacher zu testen als die Config des Konverter/Generierungs Klimbims.

[Exxtreme]

Hi,

also für mich klingt das alles so als ob die Prozesse ala TDD, Scrum etc. mehr im Vordergrund standen denn die eigentliche Programmierung. Die Prozesse scheinen mehr ein Selbstzweck gewesen zu sein denn ein Werkzeug. Ich programmiere eine ERP-Anwendung bei uns in der Firma. Und die Firma, die externe das Projekt ursprünglich gemacht hat hat es aufgegeben. Weil sie nicht mehr in der Lage waren Features einzubauen ohne was Anderes dabei unbrauchbar zu machen. Jedes neues Feature war deshalb ein Hin und Her mit vielen Bugreports. Eine neue Datenbankspalte ins Frontend durchzureichen dauerte manchmal Wochen.

Nachdem ich durch den Quellcode so halbwegs durchgestiegen bin weiss ich auch warum. Dutzende verkettete und kaskadierende Abstraktionen, "Gottesklassen" ala selbst gebastelter Cache weil sie sie starke Performance-Probleme hatten etc. ziehen sich durch das Projekt. Man hat immer den Eindruck da wurde auf Verdacht abstrahiert weil das irgendwann mal vielleicht nützlich sein könnte.

Ich brauche für eine neue Datenspalte ins Frontend jetzt ein paar Minuten. Warum? Weil ich kaum Abstraktionen nutze. Ich programmiere zwar damit mehr oder weniger am eigentlichen System vorbei aber ich zerschieße keine vorhandene Funktionalität. Praktisch jede neue Funktionalität, die ich einbaue ist deshalb praktisch immer ohne Effekte auf andere Komponenten im Programm.

Und das würde ich dem TE auch evtl. empfehlen. Neue Features ohne die selbstgebastelten vorhandenen bzw. nur die von div. Frameworks vorgegeben Abstraktionen nutzen. Ist evtl. hier und da mehr Code dafür aber weniger Auswirkungen auf das restliche System.

Es war aber kein einfacher Weg, versuch mal einem Java Entwickler zu erzählen er soll kein JPA benutzen sondern das SQL selbst schreiben und ein Mapping zur DB implementieren nur mit JDBC ;D

JPA hat durchaus so seine Vorzüge abseits dessen, dass es Java ist. Oder man sollte sich nicht wundern wenn man sich SQL injections einfängt wenn man das SQL direkt gegen die Datenbank wirft. Wenn man aber trotzdem ein SQL Fan ist dann ist vielleicht jooq (http://jooq.org) eine Alternative. Leider schweineteuer wenn man keine OSS-DBs nutzt.

[Monger]

Bei der neuen Software haben wir dann nur noch Libs/Frameworks/Pattern eingeführt wenn wir sie wirklich gebraucht haben.
Das ist auch so eine Lektion die wir auf die harte Tour gelernt haben: das Risiko was man sich durch Zulieferungen einhandelt, unterschätzt man furchtbar schnell.

Es ist okay 3rd Party Sachen zu nehmen, aber erst nach einer ausführlichen Evaluierung, und niemals ohne Plan B. Selbst namhafte und etablierte Zulieferer sind keine Garantie, dass man sich nicht damit einen Strick dreht.

[Frucht-Tiger]

JPA hat durchaus so seine Vorzüge abseits dessen, dass es Java ist. Oder man sollte sich nicht wundern wenn man sich SQL injections einfängt wenn man das SQL direkt gegen die Datenbank wirft. Wenn man aber trotzdem ein SQL Fan ist dann ist vielleicht jooq (http://jooq.org) eine Alternative. Leider schweineteuer wenn man keine OSS-DBs nutzt.
Es geht ja gar nicht darum, dass es keine Vorzüge hat, sondern darum, dass man die Nachteile ignoriert und keine Alternativen zulässt. Es muss einfach immer die "Enterprise-Lösung" sein für jedes Problem. Auch JDBC lässt sich ohne irgendwelche Probleme gegen Injections schützen, wer dafür ein riesen ORM-Tool einführt tut sich keinen Gefallen.

Wenn man das ein paar Jahre durchzieht landet man in der Situation von der ich denke das RMC sie beschreibt und ich sie auch schon mal erlebt habe. Man hat alles "richtig" gemacht aber die Software lässt sich einfach nicht mehr weiterentwickeln in einem vernünftigen Rahmen.

[RMC]

Vielen Dank für eure zahlreichen Antworten. Technical debt zahlt man sicher etwas mit, weil ich mitbekommen habe, dass große Refactorings nicht an der Tagesordnung stehen und auch nicht Mal eben die eine oder andere Woche zum Aufräumen eingeschoben wird. Was man auch nicht sollte: Agile SWD soll ja Refactorings implizieren während man Code schreibt. Wenn ein Entwickler etwas sieht was nicht gefällt, sollte es sofort refactored werden.

Feature Creeping gibt's nicht. Es wird nichts ohne Requirement implementiert, also dass man irgendwas "für alle Fälle" einbaut ist nicht gegeben. Was gut ist.

3rd Party Code bzw Abhängigkeiten über die man wenig Kontrolle hat sind wenig drin. Ich sehe das Problem mehr hausgemacht.

Das Thema Tools will ich eigentlich außen vor lassen. Ja, man kann mit Code Generation etc auch die Boilerplates generieren lassen, aber das macht den Code ja nicht schlank sondern lässt dich mit dem Problem nur leichter leben.

@Monger
Die Teststrategie ist eigentlich gut, ebenso die Buildkette. Die Architektur ist imho an einigen Stellen fragwürdig. Cohesion leider sicher, weil momentan von einer Änderung viele (interne) Module betroffen sind. Das sollte nicht sein.

@Exxtreme
Ich bin nicht der Ansicht dass es ein reiner Selbstzweck ist. Das Team ist sehr diszipliniert in dieser Sache und das meine ich positiv. Hab ich so noch nicht erlebt.

@Frucht-Tiger:
Also von "nicht mehr weiterentwickeln lassen" sind wir da weit weg. Aber es wird zunehmend zäher und gerade bei Agile sollte das ja nicht so sein.

Die Architektur könnte definitiv weniger komplex sein in Anbetracht der Features. Mit TDD hat man die Basis, Refactorings überhaupt machen zu können. Ohne Tests könnte man das gar nicht.

Und schließlich, wegen der Architektur, wäre noch das Thema OOP und Abstraktion. Das hier kennen sicher einige von euch. Es zeigt gut eine der Kernproblematiken der Sache. Es ist Teil der "Bloated Software Problematik" wie ich es empfinde:

https://pics.me.me/the-world-seen-by-an-obtect-oriented-programmer-ymanayo-bedegate-in-30501704.png

Ich glaube folgendes könnte helfen:

1. Delayed Refactoring verhindern. Refactorings fix in den Prozess integrieren. Sonst kann man das nicht Agile nennen.
2. Abstraktionen minimieren und wieder mehr Richtung direkter Funktionalität streben mit möglichst wenigen Ebenen. Ich denke dass das die Architektur vereinfachen könnte.
3. Patterns nicht überall einpflanzen sondern mit Bedacht. Hier kommts halt auf den Hausverstand an.

Meinungen?

[Monger]

1. Delayed Refactoring verhindern. Refactorings fix in den Prozess integrieren. Sonst kann man das nicht Agile nennen.

Du weißt ja: TDD heißt "Make it red, make it green, refactor". Tests sind ja dazu da, um Refactoring zu ermöglichen.
Die Herausforderung wird sein, alle davon zu überzeugen dass viele kleine Refactorings viel günstiger sind als ein großes.


2. Abstraktionen minimieren und wieder mehr Richtung direkter Funktionalität streben mit möglichst wenigen Ebenen. Ich denke dass das die Architektur vereinfachen könnte.

Jein. Hohe Cohäsion und niedrige Kopplung resultieren in weniger Code Redundanz. Wenn du viele Abstraktionsebenen hast, dann wahrscheinlich deshalb weil die bestehenden Abstraktionsebenen das Ziel der Abstraktion verfehlt haben.
Wird also weniger wenn mans richtig macht, aber bitte erzähl keinem dass Abstraktion überflüssig ist.


3. Patterns nicht überall einpflanzen sondern mit Bedacht. Hier kommts halt auf den Hausverstand an.

Natürlich. Du drehst ja auch nicht Schrauben mit einem Hammer ein.

[Ganon]

JPA hat durchaus so seine Vorzüge abseits dessen, dass es Java ist. Oder man sollte sich nicht wundern wenn man sich SQL injections einfängt wenn man das SQL direkt gegen die Datenbank wirft. Wenn man aber trotzdem ein SQL Fan ist dann ist vielleicht jooq (http://jooq.org) eine Alternative. Leider schweineteuer wenn man keine OSS-DBs nutzt.

Das hat weniger was mit SQL-Fan zu tun, imo. JPA ist ein bisschen doll über das Ziel hinaus geschossen und die Criteria API ist einfach mal direkt unleserlich. Es ist halt unsinnig eine API mit einer API zu abstrahieren, wenn das Endergebnis dann unleserlich ist. Und der, der von Datenbanken keine Ahnung hat, handelt sich über ORM-Frameworks eine Menge N+1 Probleme ein.

Neben dem kann man gerne noch Probleme mit dem Object-Cache kriegen, alles nur, damit das alles schön "the Java Way" ist. Weil "naiv" müsste er alle Nase lang erst mal sämtliche Queries generieren und dann hat man auch noch damit zu tun, dass die resultierende Query auch noch effizient ist.

Ich hab den ganzen Scheiß irgendwann auch rausgeworfen. Das mag, wenn man "von oben" kommt, schwierig aussehen, ist es aber nicht. Datenbankschema ordentlich definiert, mit Foreign Keys, Constraints und ggf. Triggern und schon KANN dein Java Code, oder irgend ein anderer Code gar nichts mehr falsch machen, selbst wenn er wollte. Man kann den ganzen DB-Layer Krams rauswerfen und schickt einfach vernünftige Anweisungen an die Datenbank. Es besteht auch überhaupt gar keine Notwendigkeit alles immer in irgendwelche Java-Klassen/Objekte zu stopfen. Man kann Datenwerte eines ResultSets auch lesen, ohne dass man sie zuerst in eine Klasse stopf.

[Exxtreme]

Das hat weniger was mit SQL-Fan zu tun, imo. JPA ist ein bisschen doll über das Ziel hinaus geschossen und die Criteria API ist einfach mal direkt unleserlich. Es ist halt unsinnig eine API mit einer API zu abstrahieren, wenn das Endergebnis dann unleserlich ist. Und der, der von Datenbanken keine Ahnung hat, handelt sich über ORM-Frameworks eine Menge N+1 Probleme ein.
Jein. JPA hat den Nachteil, es eine spürbare "leaky abstraction" ist und ein wichtiges Versprechen deshalb nicht einhalten kann: schreibe wie gewohnt deinen Java-Code, ich kümmere mich um das SQL. Will man effiziente Abfragen dann muss man SQL dann doch recht gut kennen und auch wissen wie man das JPA API nutzt damit dieses auch rauskommt. Der Graben zwischen Java und SQL ist halt doch recht breit. Aber wenn man das weiss dann lässt sich damit IMHO recht gut arbeiten. Witzigerweise finde ich das Criteria API sogar recht einfach zu verstehen. Das Stream API ist davon sogar inspiriert.

Was mich eher stört, ist dass sie beim generierten SQL gefühlt bei SQL92 stehen geblieben sind. Sprich, sowas wie UNION oder INTERSECT oder LEFT JOIN auf eine Subquery ist damit leider nicht möglich. Klar kann man das nachbauen aber das artet dann richtig aus.

Aber wer weiss, vielleicht geht die Entwicklung als Jakarta EE hier weiter. Zumal Eclipse Link das seit Jahren schon kann. Nur in den JPA Standard ist das nie eingeflossen.

Ich hab den ganzen Scheiß irgendwann auch rausgeworfen. Das mag, wenn man "von oben" kommt, schwierig aussehen, ist es aber nicht. Datenbankschema ordentlich definiert, mit Foreign Keys, Constraints und ggf. Triggern und schon KANN dein Java Code, oder irgend ein anderer Code gar nichts mehr falsch machen, selbst wenn er wollte. Man kann den ganzen DB-Layer Krams rauswerfen und schickt einfach vernünftige Anweisungen an die Datenbank. Es besteht auch überhaupt gar keine Notwendigkeit alles immer in irgendwelche Java-Klassen/Objekte zu stopfen. Man kann Datenwerte eines ResultSets auch lesen, ohne dass man sie zuerst in eine Klasse stopf.

Das hat wiederum den Nachteil, dass du Teile deiner Geschäftslogik in die DB verlagerst. Das wird schonmal viel komplizierter mit Unit Tests. Und Fehler werden auch erst zur Laufzeit sichbar. Was man mit einer statisch typisierten Sprache wie Java eigentlich nicht will. Sonst würde man Python oder so nehmen.

Hat halt alles Vor- und Nachteile.

[Ganon]

Das hat wiederum den Nachteil, dass du Teile deiner Geschäftslogik in die DB verlagerst. Das wird schonmal viel komplizierter mit Unit Tests. Und Fehler werden auch erst zur Laufzeit sichbar.

Das hängt von der Datenbank ab, aber SQL ist ja im Regelfall von den Daten abhängig. Typ-Probleme sind nach meiner Erfahrung eher das geringste Problem. Ein Compiler kann halt auch keine Daten prüfen. Das Ausführen und Durchtesten der Query bleibt, egal wann und wie du sie aufrufst.

Dadurch, dass die Query fest ist und nicht andauernd On-The-Fly generiert wird und auch nicht durch irgendwelche Typen beeinflusst wird, ist sie auch deutlich stabiler.
Und meine Unit-Tests rufen halt auch einfach nur die Query auf mit entsprechenden Daten und prüft die Rückgabewerte. Ich wüsste jetzt nicht wo es da jetzt komplizierter ist. Zusätzlich steht einem das ganze Spektrum von SQL zur Verfügung. Es ist nicht immer im engen Korsett des ORM Mappings. Besonders wenn das ResultSet vom eigentlichen POJO abweicht, ist man schon wieder nah am 08/15 JDBC. Bei PostgreSQL (in meinem Fall) kannst du sogar dein Ergebnis direkt in JSON umwandeln und ggf. einfach durchreichen, je nach Anwendungsfall.

Klar, unverständlich sind die Criteria API nicht. Aber Queries sehen absolut grauenvoll aus und bis man eine komplexe, geschriebene Query versteht... die SQL-Variante dagegen ist einfach zig mal lesbarer und leichter verständlich. Wie gesagt, sobald es komplexer wird.

Ich finde es auch immer lustig, dass man bei OOP immer predigt, dass Daten und Funktionen zusammengehören, aber bei Datenbanken diese Idee schon wieder aus dem Fenster wirft.

Will auch gar nicht sagen, dass ORM jetzt immer total sinnlos ist, gerade wenn das Datenbank-KnowHow nicht ganz so intensiv ist. Aber es gibt nicht wenig Leute die ORM nutzen, "weil man das halt so macht"...

[exxo]

Wie kriegt man Software wieder in Gang, deren Einfachheit durch zahlreiche Massnahmen so verloren gegangen ist?

Wie verringert man Komplexität ohne irgendwelche Prinzipien über Bord zu werfen und macht Software wieder schlank und einfacher, fokussiert auf Funktionalität?

Es gibt das schöne Sprichwort das einfacher Code gerne umgebaut und komplexer gemahct wird, weil er anfangs so einfach strukturiert war. Komplexer Code wird so gelassen wie er ist, weil er nicht sonderlich gut lesbar ist und niemand genau wissen kann was passiert wenn man Modifikationen einbringt.

Mit anderen Worten, ihr seid schon sehr spät dran für ein Refactoring. Desweiteren wurde das Design von eurer Software anscheinend nicht mit zukünftigen Modifikationen im Hinterkopf entworfen. Wenn überhaupt etwas entworfen wurde.


Ich bin nicht der Ansicht dass es ein reiner Selbstzweck ist. Das Team ist sehr diszipliniert in dieser Sache und das meine ich positiv. Hab ich so noch nicht erlebt.


Eure Prozesse müssen auch kein Selbstzweck sein. Mir kommen solche Projekte allerdings immer sehr Kopflastig vor. Ohne Daily Standups und Projektmanager passiert wahrscheinlich auch nicht viel bei Euch. *No Offense*

Das es keine Feature Creep gibt, ist super, kann aber auch ein Indikator dafür sein das jeder nur das macht wofür er beauftragt wurde. Jeder baut in der Ecke die ihm zugeteilt wurde und solange die Sprints in time abgeschlossen werden ist alles gut. Die Qualität der Ergebnisse ist erst mal egal solange die vom PL vorgegebene Funktionalität implementiert wurde.

Ihr solltet eure Projektleitung davon überzeugen das ihr in Zukunft zwischen den Sprints jeweils eine Woche für das refactoring des Code einlegt, der im nächsten Sprint für neue Features modifiziert werden soll. Ansonstn wird der Code Rot in eurem Projekt zu immer größeren Verzögerungen führen....

[maximAL]

Um mal auf das ursprüngliche Thema zurück zu kommen:
Ein Device hat ein Property (bool), das in einer UI mit einem Schalter visualisiert wird. Die Änderung am Schalter soll ans Device übertragen werden.
Muss das Property explizit in jedem Layer auftauchen? Ich könnte mir hier eine eher generische Liste von Properties vorstellen, damit müsste man die Zwischenschichten beim Einführen neuer Properties nicht ändern. Evtl. auch nicht das UI, wenn das Property keiner Sonderbehandlung bedarf.

Wenn das nicht geht, dann befürchte ich, dass es sich nicht ganz vermeiden lässt, dass sich so eine Änderung durch das halbe System zieht. Immerhin ändert man hier wohl die High-Level Entity, von der die anderen Komponenten im System abhängen sollten.
Viel größer wäre das Problem, wenn diese Abhängigkeit falsch herum modelliert wäre und eine Änderung im UI bis zum Device durchschlagen würde.

[RMC]

Mit anderen Worten, ihr seid schon sehr spät dran für ein Refactoring. Desweiteren wurde das Design von eurer Software anscheinend nicht mit zukünftigen Modifikationen im Hinterkopf entworfen. Wenn überhaupt etwas entworfen wurde.

Das sehe ich auch so, vorallem das mit der "zukünftigen Modifikation": Es wird nicht groß im Voraus gedacht, weil Code der nicht verlangt wird soll gar nicht einfließen, also wozu drüber nachdenken. Natürlich verhindert das impliziten Feature Creep und andere Ungewolltheiten.

Das prallen imho irgendwo zwei Welten aufeinander: Einerseits ist Vorausdenken sehr wertvoll, da eben auch das Design dann mehr zusammenpasst - andererseits YAGNI aka "brauch ma net - mach ma net" und so siehts dann eben aus.



Ihr solltet eure Projektleitung davon überzeugen das ihr in Zukunft zwischen den Sprints jeweils eine Woche für das refactoring des Code einlegt, der im nächsten Sprint für neue Features modifiziert werden soll. Ansonstn wird der Code Rot in eurem Projekt zu immer größeren Verzögerungen führen....

Ich denke eher, wie schon angemerkt, dass es wertvoller ist das Team dazu zu bringen, während dem Entwickeln zu refactoren. Das ist halt Teil von echtem Agile Software Development und hat den Vorteil, dass es sich langfristig in den Schätzungen gut manifestiert und man das auch dem Management besser verkaufen kann als "Wir machen jetzt mal eine Woche nichts an der Software weiter sondern räumen nur mal auf"

Um mal auf das ursprüngliche Thema zurück zu kommen:

Muss das Property explizit in jedem Layer auftauchen?

Nein muss (und sollte) es meiner Meinung nach auch nicht, wenn das Design stimmt. Das ist halt eben etwas fürs Thema Refactoring.

[noid]

Agile, TDD und der dergleichen sind doch ideale Ausreden kein Design zu machen.
Hätte jemand mal einmal vorher nen Plan gemacht, dann wäre das nicht passiert.

Hatte mal eine TDD Schulung. Der Trainer meinte doch ernsthaft, dass ich erstmal nur das erste Requirement umsetzen solle ohne die anderen zu lesen. Kam natürlich Quark raus. Oh Wunder....

[Monger]

Hatte mal eine TDD Schulung. Der Trainer meinte doch ernsthaft, dass ich erstmal nur das erste Requirement umsetzen solle ohne die anderen zu lesen. Kam natürlich Quark raus. Oh Wunder....
Das ist schon richtig so. Agile Entwicklung ist stark getrieben durch Risikomanagement. Man macht keine großen Pläne, weil man davon ausgeht dass alle Pläne scheitern werden. Also agiert man so, dass man auf möglichst alle Eventualitäten reagieren kann, auch die die man nicht kennt.

Deshalb ist das YAGNI Prinzip auch völlig okay. Man sollte halt nur so Code schreiben, dass man hintendran zu schnellen Refactorings in der Lage ist.

Wenn das bei dir in die Hose ging, ist das - sorry - ein Layer 8 Fehler. Aber ist natürlich normal, wenn man mit dem Konzept noch keine Erfahrung hat.

[Monger]

Das prallen imho irgendwo zwei Welten aufeinander: Einerseits ist Vorausdenken sehr wertvoll, da eben auch das Design dann mehr zusammenpasst - andererseits YAGNI aka "brauch ma net - mach ma net" und so siehts dann eben aus.

Wie gesagt: wenn du in der Lage wärst mit vertretbarem Aufwand jederzeit deine Architektur neu aufzustellen, dann darf sie auch Grütze sein. Es geht nicht darum Fehler zu vermeiden, sondern die Wirkung von Fehlentscheidungen zu begrenzen.
Aber nach deiner Aussage vermischen sich halt die zwei schlechtesten Aspekte beider Welten: Planlosigkeit, und Unbeweglichkeit.

[registrierter Gast]

Agile, TDD und der dergleichen sind doch ideale Ausreden kein Design zu machen.
Hätte jemand mal einmal vorher nen Plan gemacht, dann wäre das nicht passiert.

Hatte mal eine TDD Schulung. Der Trainer meinte doch ernsthaft, dass ich erstmal nur das erste Requirement umsetzen solle ohne die anderen zu lesen. Kam natürlich Quark raus. Oh Wunder....
Ich kann da Monger nur zustimmen. Wer für die Zukunft entwickelt, weil er weiß, was noch für Requirements kommen, entwickelt sich in ein zu starres (Denk)Konstrukt und ist aufgeschmissen, wenn sich die Requirements ändern oder entfallen.

Bei uns auf Arbeit heißt es immer: “Nicht für die Zukunft entwickeln.“ und damit fahren wir sehr gut.

Das muss man natürlich erst mal eine Zeit Leben und seine Art zu Entwickeln darauf anpassen. Das klappt ggf. nicht beim ersten Anlauf.

[#44]

Das sehe ich auch so, vorallem das mit der "zukünftigen Modifikation": Es wird nicht groß im Voraus gedacht, weil Code der nicht verlangt wird soll gar nicht einfließen, also wozu drüber nachdenken. Natürlich verhindert das impliziten Feature Creep und andere Ungewolltheiten.
[...]
YAGNI aka "brauch ma net - mach ma net" und so siehts dann eben aus.
Ich schließe mich Monger auch an.

Wie passen YAGNI und die ganzen, komplizierten/überflüssigen Abstraktionen zusammen, die du beschrieben hast?
Meiner Erfahrung nach entstehen diese Abstraktionen ja aus der Idee, dass man damit Später eine gewisse Flexibilität hat. (Interfaces, deren Implementierungen man austauschen könnte; Gekapselte Funktionalitäten, die anderswo wiederverwendet werden können; etc.)
Wurden die bei euch tatsächlich nur eingebaut, weil man das ja so macht?

[noid]

Das mag für manche Software ja gelten, aber wenn ich funktionale Sicherheit und Schnittstellen requirements alle schon habe, dann macht das wenig Sinn. Ist ja viel bekannt. Was soll man denn da wild rumprogrammieren?

Also um es noch mal klar zu formulieren: ich hatte zehn requirements, und sollte die anderen erst gar nicht lesen. Sollte das die Übungen sein für später?

[RMC]

Ich schließe mich Monger auch an.

Wie passen YAGNI und die ganzen, komplizierten/überflüssigen Abstraktionen zusammen, die du beschrieben hast?

...
Wurden die bei euch tatsächlich nur eingebaut, weil man das ja so macht?

Also dass einiges nicht zusammenpasst ist da der Grund warum ich hier schreibe :)

Da es stets von Release zu Release geht vermute ich, dass immer lediglich zu einem Set von Features/Requirements hin designed wurde, ohne groß auf Zukünftiges zu achten.

Wenn schließlich das nächste Set ankam könnte es sein, dass nicht im Sinne der Gesamtheit refactored wurde. Natürlich gibt es Abstraktionen der Features willen, aber in Summe gibts dann Schicht um Schicht. Durchparsen geht schneller als Refactoren.

Und bisher ist auch niemand auf die Idee gekommen zu hinterfragen, wieso man eben für ein simples Device-Property in der UI plötzlich 5 Schichten angreifen muss.

[Monger]

Das mag für manche Software ja gelten, aber wenn ich funktionale Sicherheit und Schnittstellen requirements alle schon habe, dann macht das wenig Sinn. Ist ja viel bekannt. Was soll man denn da wild rumprogrammieren?

Wenn deine Anforderungen so konkret ausformuliert sind dass du sie nur noch runterhacken musst, und sie auch so unbeweglich sind dass du alle in einem Rutsch umsetzen kannst - gut für dich!
Allerdings frage ich mich dann wozu man dich dann noch braucht. Wenn jemand so detailliert seine Anforderungen auf Papier bringt, kann er sie gleich selber in Code gießen.

Anforderungen sind normalerweise aktuell oder präzise, aber nicht beides gleichzeitig.

Also um es noch mal klar zu formulieren: ich hatte zehn requirements, und sollte die anderen erst gar nicht lesen. Sollte das die Übungen sein für später?
Ja, genau. Weil in der Realität haben sich von den 9 Anforderungen mindestens eine geändert, bis du mit der ersten fertig bist.

[#44]

Die Alternative Situtation wäre, dass es organisatorisch beim Design des Systems oder beim strukturiertem Herunterbrechen/Gruppieren der Anforderungen mangelt.

Wenn du eine Anforderung Design-/Architekturkonform umsetzt, solltest du dir als Programmierer keine Gedanken mehr machen müssen, wie du das auf abstrakter Ebene mit Cross Cutting Concerns wie Sicherheit vereinbarst oder wie sich Schnittstellen in das Gesamtsystem integrieren.

Wenn das nicht möglich ist, wurden auf Anforderungsebene gff. Dinge getrennt, die zusammen gehören oder Dinge zusammengefasst, die getrennt gehören.

[Monger]

Und bisher ist auch niemand auf die Idee gekommen zu hinterfragen, wieso man eben für ein simples Device-Property in der UI plötzlich 5 Schichten angreifen muss.
Das ist auch so ein Phänomen: Agile Entwicklung setzt sehr stark auf systematisches Lernen, nach dem Motto: Entwickler haben den inneren Antrieb sich Arbeit zu sparen, also suchen sie bei Stress automatisch nach effizienteren Wegen.

Meine Erfahrung aber ist eine andere. Ist etwas arg qualvoll und langwierig, sucht man gerne die Schuld bei anderen, macht aber 1:1 weiter. Manchen Leuten scheint es wichtiger zu sein, beschäftigt zu sein als etwas zu bewirken.

Ich glaub, um das zu erklären bräuchte man einen Psychologen. Normalerweise ist Selbstwirksamkeit etwas positives, aber manche Menschen fühlen sich eigenartig entlastet, wenn sie keine Kontrolle über ihre Arbeit haben.
Ich glaube mittlerweile, überkomplexe Lösungen sind nicht immer Zufall. Es gibt Leute, die profitieren von unkontrollierbarem Chaos.

Übertragen auf dich: Es wäre sehr wichtig die Frage zu beantworten, warum das bisher niemanden gestört hat.

[noid]

Ich glaube die Antwort ist ganz einfach: einige Leute wollen lieber eine Lösung produzieren die schnellste wirklich fertig ist als sich Gedanken zu machen wie sie lang und mittelfristig effizient sind. Da werden z.b. lieber Dinge wiederholt per Hand gemacht anstatt sich dafür einen effizienten Weg zu suchen in Form eines generators Punkt und das sind nicht Dinge die man wirklich nur einmal macht sondern die über Monate wiederholt auftreten Punkt weil diese Menschen dann denken ihr Chef wäre nicht begeistert wenn sie nicht produktiv Code entwickeln.

Aber noch mal zu meinem Problem: vielleicht habe ich an der Stelle durchaus noch Chancen. requirements sind nicht immer alle komplett, aber ich denke die Schnittstelle Anforderung sind durchaus fix. Wobei die Logik der Funktion stellenweise wirklich variabel ist über die Zeit. Vielleicht probiere ich das mal aus.

[RMC]

Übertragen auf dich: Es wäre sehr wichtig die Frage zu beantworten, warum das bisher niemanden gestört hat.

Und die werde ich hoffentlich in den nächsten Tagen/Wochen klären können :)

Vielen Dank soweit für eure Beitrage und Meinungen zu dem Thema!

[Demirug]

Ich gebe hier jetzt mal den Ketzer. Ich bin mir dabei völlig bewusst das man die Spieleentwicklung nicht 100% mit anderen Bereichen der Softwareentwicklung vergleichen kann. Was ich bisher jedoch bei jedem Projekt beobachten konnte war das der Versuch Scrum als Prozess zu benutzten gründlich in die Hose gegangen ist. Gewundert hat mich das allerdings nie. Ich bin kein Psychologe habe mich aber im Rahmen von solchen Dingen wie Vokabeltrainer mal ausführlicher mit dem Thema Verhaltens- und Lernpsychologie auseinander gesetzt. Unter diesen Gesichtspunkten macht Scrum so gut wie alles falsch.-

[Monger]

Ich bin kein Psychologe habe mich aber im Rahmen von solchen Dingen wie Vokabeltrainer mal ausführlicher mit dem Thema Verhaltens- und Lernpsychologie auseinander gesetzt. Unter diesen Gesichtspunkten macht Scrum so gut wie alles falsch.-
Interessante These. Weil? Falsche Anreize?

[Demirug]

Interessante These. Weil? Falsche Anreize?

Ein primäres Problem von Scrum ist das es nur einen negativen Feedbackloop hat. Was zwangsläufig dazu führt das man ein Scrumteam unterbewusst dazu erzieht die Bestrafung zu vermeiden. Das führt mittelfristig zu zwei Dinge die man eigentlich nicht haben will. Das Team wird immer konservativer was die Zeitschätzungen angeht. Da aber auch eine zu großzügige Schätzung als Fehler angesehen wird neigt man dann (ebenso unterbewusst) dazu die Zeit auch wirklich zu benötigen.

Ein anderes Problem ist der ständig wechselnden "Druck" dadurch das man am Anfang eines Sprints die Taskliste füllt und diese dann im Verlauf immer kleiner wird. Das führt dazu das im Verlauf eines Sprints solange man im Plan liegt die Entspannung immer weiter zunimmt. Läuft es dagegen nicht gut steigt der Stress beständig an. Beides will man eigentlich vermeiden weil es negativ für die Produktivität ist.

Die Sprintdauer als solches ist ebenso ein Problem da dadurch die regulative Kraft welche ein Entwicklungsprozess haben soll viel zu träge macht.

Burndowndiagramme sind btw auch nicht optimal. Fallenden Linien sind eher negative assoziert. Wenn man Diagramme braucht sollte man die erledigten Tasks mit einer steigenden Linie visualisieren.

Ich weiß das ist böse aber ich habe inzwischen einen Ausdruck mit dem Schriftzug "Scrum" und einem Postit "Done" darüber an meiner Pinnwand hängen. Wie gesagt es mag sein das es außerhalb der Spielentwicklung besser funktioniert aber bisher hat jeder Projektmanager mit dem ich zu tun hatte früher oder später aufgegeben.

Ja ich weiß das man sagt das Scrum nur deswegen nicht funktioniert weil man es falsch macht oder zu früh aufgegeben hat. Meine Meinung ist aber das man dadurch nur irgendwann den Punkt erreicht an dem man das Team unterbewusst so weit konditioniert hat das es so aussieht als würde es funktionieren. Dadurch aber gleichzeitig eine Menge potenzial verschwendet.

[clm[k1]]

Mit anderen Worten, ihr seid schon sehr spät dran für ein Refactoring. Desweiteren wurde das Design von eurer Software anscheinend nicht mit zukünftigen Modifikationen im Hinterkopf entworfen. Wenn überhaupt etwas entworfen wurde.

Geh mal ans Telefon. Die 90er rufen an - sie wollen ihr "Big Design Up Front" zurück. :tongue:

Aber jetzt mal ohne Mist: woher willst du wissen, wie "zukünftigen Modifikationen" aussehen werden? Oder ob es überhaupt welche geben wird?
Warum das Projekt mit Code zumüllen, welcher Annahmen trifft, die wahrscheinlich nie eintreten werden?

Was spricht dagegen, die Änderungen dann zu machen, wenn sie erfordlich werden? Wir reden nicht ohne Grund von Software - weil sie vergleichsweise einfach und schnell zu ändern ist.

Jetzt sagst du vielleicht, dass es länger dauert, die Architektur erst dann anzupassen, wenn es nötig wird. Ich sage: ein neues Feature in eine aufgebläte Architektur einzupassen, welche für dieses Feature gar nicht ausgelegt ist, dauert länger! (Und macht das ganze Projekt schwerer wartbar - was ja genau das Problem ist, was der TE hat)


Ihr solltet eure Projektleitung davon überzeugen das ihr in Zukunft zwischen den Sprints jeweils eine Woche für das refactoring des Code einlegt, der im nächsten Sprint für neue Features modifiziert werden soll. Ansonstn wird der Code Rot in eurem Projekt zu immer größeren Verzögerungen führen....
Das geht wahrscheinlich in die Hose! Und es verschleiert zusätzlich den Aufwand der Features. Wenn das Feature ein umfangreiches Refactoring erfordert um es "richtig" zu machen, und dadurch 3x so lange dauert, dann ist das eben so!
Davon ab, kann ich mir nicht vorstellen, wie ein Refactoring funktionieren soll, ohne das Feature, für dass es gedacht ist, direkt mit umzusetzen ...das aber erst im nächsten Sprint kommen soll. Das passt irgendwie nicht zusammen.

Besser wäre eher folgender Ansatz: da ihr ja sicher immer brav eure technical-dept issues pflegt, solltet ihr darauf hinwirken/bestehen, dass immer eine gewisse Anzahl davon mit in den Sprint aufgenommen wird.


just my 2 cent

[clm[k1]]

Ein primäres Problem von Scrum ist das es nur einen negativen Feedbackloop hat. Was zwangsläufig dazu führt das man ein Scrumteam unterbewusst dazu erzieht die Bestrafung zu vermeiden. Das führt mittelfristig zu zwei Dinge die man eigentlich nicht haben will. Das Team wird immer konservativer was die Zeitschätzungen angeht. Da aber auch eine zu großzügige Schätzung als Fehler angesehen wird neigt man dann (ebenso unterbewusst) dazu die Zeit auch wirklich zu benötigen.

Ein anderes Problem ist der ständig wechselnden "Druck" dadurch das man am Anfang eines Sprints die Taskliste füllt und diese dann im Verlauf immer kleiner wird. Das führt dazu das im Verlauf eines Sprints solange man im Plan liegt die Entspannung immer weiter zunimmt. Läuft es dagegen nicht gut steigt der Stress beständig an. Beides will man eigentlich vermeiden weil es negativ für die Produktivität ist.

Das klingt alles danach, als hättet ihr kein Sprintziel, und würdet euch stattdessen auf die möglichst perfekte Abarbeitung des Sprints fokusieren. Das ist natürlich tödlich und führt zwangsläufig zu Frustration!
Das Sprintziel sollte niemals darin bestehen, eine "Punktlandung" zu machen!
Nehmt euch das (oder die) wichtigsten Themen des Sprints und commited euch darauf, diese fertig zu bekommen. Das wird euer Sprintziel.
Ihr werdet feststellen, dass etwaige Umfangsänderungen oder zu viel oder zu wenig Stories im Sprint auf einmal gar nicht mehr so schlimm sind, und sich auch nicht mehr so negativ auswirken.

Wir hatten das Problem vorher auch. Seit wir mit vernünftigen Sprintzielen arbeiten, ist es um Welten besser geworden und allen Beteiligten macht es auch wieder Spaß.

Leider wird bei Scrum-Schulungen immer auf alle möglichen anderen Sachen eingangen, die penibel einzuhalten sind, aber auf sowas wichtiges selten.


Die Sprintdauer als solches ist ebenso ein Problem da dadurch die regulative Kraft welche ein Entwicklungsprozess haben soll viel zu träge macht.

Kannst du das näher ausführen?


Burndowndiagramme sind btw auch nicht optimal. Fallenden Linien sind eher negative assoziert. Wenn man Diagramme braucht sollte man die erledigten Tasks mit einer steigenden Linie visualisieren.

Volle Zustimmung! Und das gibt es auch schon! Nennt sich Burn-up Chart!
Und da es für gewöhnlich mit 2 Linien statt einer "bestückt" wird, entkoppelt man dadurch auch direkt die erledigte Arbeit und die Umfangsänderungen!
Umfangsänderungen machen einem dadurch nicht mehr die Linie mit der erledigten Arbeit zunichte.


just my 2 cent

[Demirug]

;11649288']Das klingt alles danach, als hättet ihr kein Sprintziel, und würdet euch stattdessen auf die möglichst perfekte Abarbeitung des Sprints fokusieren. Das ist natürlich tödlich und führt zwangsläufig zu Frustration!
Das Sprintziel sollte niemals darin bestehen, eine "Punktlandung" zu machen!
Nehmt euch das (oder die) wichtigsten Themen des Sprints und commited euch darauf, diese fertig zu bekommen. Das wird euer Sprintziel.
Ihr werdet feststellen, dass etwaige Umfangsänderungen oder zu viel oder zu wenig Stories im Sprint auf einmal gar nicht mehr so schlimm sind, und sich auch nicht mehr so negativ auswirken.

Wir hatten das Problem vorher auch. Seit wir mit vernünftigen Sprintzielen arbeiten, ist es um Welten besser geworden und allen Beteiligten macht es auch wieder Spaß.

Leider wird bei Scrum-Schulungen immer auf alle möglichen anderen Sachen eingangen, die penibel einzuhalten sind, aber auf sowas wichtiges selten.

Ich kann dir hier nicht ganz folgen. Was unterscheidet bei euch ein Sprintziel von einer Story? Am eigentlich Problem ändert sich aber soweit ich das sehen kann nichts. Das Team muss sich nach wie vor für ein Ziel des Sprints commiten. Dieses wird nun entweder erreicht oder nicht. Da ja erwartet wird das man es erreicht ist das ein neutrales Feedback. Erreicht man es aber nicht hat man ein negatives Feedback was dazu führt das man eben noch vorsichtiger bei weiteren Commitments wird. Ein positives Feedback ist bei Scrum einfach nicht möglich den dazu müsste man ja mehr erreichen als man commited hat. Dafür wiederum müsste man zusätzliche Tasks/Stories aus dem Backlog holen und das sieht Scrum während eines Sprints nicht vor. Zudem würde das ja auch bedeuten das man schlecht geplant hat.

Wie gesagt ich sehe nicht wie man bei Scrum ohne den Prozess zu modifizieren jemals gewinnen kann. Aber wenn man den Prozess modifiziert ist es ja kein Scrum mehr. Die Scrumleute verstehen was das angeht keinen Spaß.

Aber im aktuellen Projekt haben es die Projektmanager ja erst mal wieder eingesehen das es nicht funktioniert was bedeutet das ich erst mal wieder meine Ruhe davor habe.

;11649288']Kannst du das näher ausführen?

Ich meine damit das der Scrumprozess auf Situationsänderungen während eines Sprints erst im nächsten Sprint reagieren kann.

[noid]

Also the scrum master kann jedoch auch noch korrigieren. Mit welchen elektronischen Hilfsmitteln wird bei euch eigentlich Scrum durchgeführt ?

[RMC]

Dafür wiederum müsste man zusätzliche Tasks/Stories aus dem Backlog holen und das sieht Scrum während eines Sprints nicht vor. Zudem würde das ja auch bedeuten das man schlecht geplant hat.

Dass das Scrum nicht vorsieht kann ich mir nicht denken. Was macht man denn wenn man zu wenig geplant hat - etwa nichts?

Das Nachziehen von Stories hab ich bisher in allen Teams in denen ich gearbeitet habe erlebt. Natürlich wäre es optimal immer den Punkt gut zu erwischen, das funktioniert auch meistens mit der Zeit besser. Aber ich sehe das so ähnlich wie clm[k1]: Man committed sich gemeinsam auf ein Ziel, das kann auch relativ klein sein wenn man will. Denn im Sprint sollten auftauchende ActionItems, Bugs und Refactorings ja miterledigt werden.


Aber wenn man den Prozess modifiziert ist es ja kein Scrum mehr. Die Scrumleute verstehen was das angeht keinen Spaß.

Bei den Unfähigen ist das so, ja. Und davon hab ich in meiner damaligen Zeit als Spielentwickler echt viele davon gesehen.

Vorallem habe ich bemerkt, dass Scrum nicht für jeden etwas ist. Damals haben sich bei uns vor allem die Artists mit diesem Framework immer schwer getan, denn ihre Arbeitsweise unterscheidet sich nun mal eben von den Programmierern. Leider haben die Scrumleute und Teamleiter nicht eingesehen, dass Menschen über den Prozessen stehen müssen und haben probiert, alle ihren Textbook-Prozess aufzuzwängen, den sie selbst gar nicht verstehen.

Dass das nicht funktioniert liegt auf der Hand, das haben alle verstanden, nur der Teamleiter nicht.

Seit dem bin ich der Ansicht, dass die Arbeitsweise der Menschen im Vordergrund liegen soll und der Prozess darauf abgestimmt werden muss und nicht umgekehrt. Aber es ist auch nicht schlimm, seine Arbeitsweise zu überdenken und ggf weiterzuentwickeln.
Ich bin der Meinung, Änderungen an Scrum dürfen nicht verboten sein. Was immer funktioniert, funktioniert.

[#44]

@Demirug: In drastischen Fällen ist ein Abbruch des Sprints vorgesehen. Damit kann man sofort reagieren.
(Nicht, dass SCRUM deswegen immer gut funktioniert... Auch als Auftragnehmer in Zusammenarbeit mit einem Auftraggeber hat SCRUM so seine Probleme - weil es rechtliche Belange in Dtl. nicht berücksichtigt)

Natürlich wäre es optimal immer den Punkt gut zu erwischen, das funktioniert auch meistens mit der Zeit besser.
Ich habe das immer so verstanden, dass das eine Kernphilosophie von SCRUM ist: Nicht zu lange mit dem Schätzen aufhalten, sondern das Bauchgefühl entscheiden lassen.
Natürlich mit ordentlicher Vorbereitung (Refinement) - die aber nicht am Entwicklerteam hängt.

Wenn es zu viel war, wandert es in den nächsten Sprint bzw. zurück in's Backlog. Wenn es "zu wenig" war -> Sprint abschließen (oder nachziehen, wenn man terminlich nicht flexibel sein kann).

Die Punktlandung ist gar nicht das Ziel.

Mmn. missverstehen viele das Versprechen, dass die Softwareentwicklung effektiver wird mit einer permanent erhöhten Auslastung der Entwickler.
SCRUM ist kein Werkzeug um Druck hoch zu halten oder die Leute langfristig am Limit laufen zu lassen. Wenn überhaupt, dann soll es das eher verhindern.

[clm[k1]]

Ich kann dir hier nicht ganz folgen. Was unterscheidet bei euch ein Sprintziel von einer Story?

Das bestätigt meinen Verdacht.


Am eigentlich Problem ändert sich aber soweit ich das sehen kann nichts. Das Team muss sich nach wie vor für ein Ziel des Sprints commiten. Dieses wird nun entweder erreicht oder nicht. Da ja erwartet wird das man es erreicht ist das ein neutrales Feedback. Erreicht man es aber nicht hat man ein negatives Feedback was dazu führt das man eben noch vorsichtiger bei weiteren Commitments wird. Ein positives Feedback ist bei Scrum einfach nicht möglich den dazu müsste man ja mehr erreichen als man commited hat. Dafür wiederum müsste man zusätzliche Tasks/Stories aus dem Backlog holen und das sieht Scrum während eines Sprints nicht vor. Zudem würde das ja auch bedeuten das man schlecht geplant hat.

Genau hier liegt der Denkfehler, weil das immer schlecht vermittelt wird.
Zum einen: Änderungen des Umfangs (zusätzliche Stories rein nehmen oder welche wieder raus werfen) ist nicht per se verboten, es sollte nur minimiert werden.

Jetzt zum Thema Sprintziel:
Nehmen wir an, wir planen einen Sprint mit 10 Stories, 4 davon größer als die anderen. Dann suchen wir uns die 2 wichtigsten davon raus, und sagen: diese beiden Themen umzusetzen ist unser Sprintziel.
D.h.: von den anderen, kleinen Stories kann zur Not ruhig was raus fliegen, oder es kann noch ein oder zwei weitere kleine Stories während des Sprint dazu kommen, solange das Sprintziel dadurch nicht gefährdet wird!

Insofern kann man durchaus positives Feedback erzeugen. Sei es, in dem man mehr schafft als gedacht, oder weil man ein zusätzliches technical-dept-issue eliminieren konnte.
Man sollte auch nicht die Wichtigkeit von Retrospektiven unterschätzen, wo man solche Dinge besprechen kann/soll. Dafür sollte man sich auch locker mal 2 Stunden Zeit nehmen. Einfach in 10 Minuten den Sprint zu resümieren ist keine Retro und führt zu nix.


Wie gesagt ich sehe nicht wie man bei Scrum ohne den Prozess zu modifizieren jemals gewinnen kann. Aber wenn man den Prozess modifiziert ist es ja kein Scrum mehr. Die Scrumleute verstehen was das angeht keinen Spaß.

Scrum ist jetzt eigentlich nicht so unflexibel. Aber im Endeffekt: wenn es dann halt nicht mehr Scrum genannt werden kann, ist das scheiß egal, solange es für euch funktioniert! Das ist das wichtigste: es muss für euch funktionieren! Wenn ihr dafür Scrum etwas modifizieren müsst, ist das legitim!


Aber im aktuellen Projekt haben es die Projektmanager ja erst mal wieder eingesehen das es nicht funktioniert was bedeutet das ich erst mal wieder meine Ruhe davor habe.

Ich meine damit das der Scrumprozess auf Situationsänderungen während eines Sprints erst im nächsten Sprint reagieren kann.
Wenn die Änderungen akut sind (im Sinne von: uns geht massiv Geld verloren wenn wir es nicht tun, oder schlimmer) dann muss es in den Sprint aufgenommen und was anderes raus geworfen werden. Oder der Sprint muss abgebrochen werden. Alles andere kann auch bis zum nächsten Sprint warten.


just my 2 cent

[Demirug]

Also the scrum master kann jedoch auch noch korrigieren. Mit welchen elektronischen Hilfsmitteln wird bei euch eigentlich Scrum durchgeführt ?

Verschiedene physikalische und elektronische Tasksboards. Das war aber nie das Problem.

Dass das Scrum nicht vorsieht kann ich mir nicht denken. Was macht man denn wenn man zu wenig geplant hat - etwa nichts?

Nach der reinen Scrum Lehre sollen dann die Leute die nichts mehr zu tun haben den anderen helfen. Das das nicht immer geht wird nicht berücksichtigt.

Das Nachziehen von Stories hab ich bisher in allen Teams in denen ich gearbeitet habe erlebt. Natürlich wäre es optimal immer den Punkt gut zu erwischen, das funktioniert auch meistens mit der Zeit besser. Aber ich sehe das so ähnlich wie clm[k1]: Man committed sich gemeinsam auf ein Ziel, das kann auch relativ klein sein wenn man will. Denn im Sprint sollten auftauchende ActionItems, Bugs und Refactorings ja miterledigt werden.

Wie gesagt reines Scrum erlaubt das nachziehen nicht da nur Dinge im Sprint Backlog stehen dürfen welche durch die Sprint Planung dort gelandet sind. Und was die Menge der Dinge im Sprintbacklog angeht ist meine Thease das man nicht wirklich besser mit dem Abschätzen wird sondern lediglich konservativer und dann die Zeit einfach ausnutzt. Nicht absichtlich sondern unterbewusst.

Bei den Unfähigen ist das so, ja. Und davon hab ich in meiner damaligen Zeit als Spielentwickler echt viele davon gesehen.

Vorallem habe ich bemerkt, dass Scrum nicht für jeden etwas ist. Damals haben sich bei uns vor allem die Artists mit diesem Framework immer schwer getan, denn ihre Arbeitsweise unterscheidet sich nun mal eben von den Programmierern. Leider haben die Scrumleute und Teamleiter nicht eingesehen, dass Menschen über den Prozessen stehen müssen und haben probiert, alle ihren Textbook-Prozess aufzuzwängen, den sie selbst gar nicht verstehen.

Dass das nicht funktioniert liegt auf der Hand, das haben alle verstanden, nur der Teamleiter nicht.

Seit dem bin ich der Ansicht, dass die Arbeitsweise der Menschen im Vordergrund liegen soll und der Prozess darauf abgestimmt werden muss und nicht umgekehrt. Aber es ist auch nicht schlimm, seine Arbeitsweise zu überdenken und ggf weiterzuentwickeln.
Ich bin der Meinung, Änderungen an Scrum dürfen nicht verboten sein. Was immer funktioniert, funktioniert.

In dem Punkt sind wir uns einig nur wie gesagt wenn du an Scrum etwas änderst ist es nach Ansicht der Scrumerfinder eben kein Scrum mehr weil es ihrer Ansicht nach nur genau so funktioniert.

@Demirug: In drastischen Fällen ist ein Abbruch des Sprints vorgesehen. Damit kann man sofort reagieren.

Ich weiß. Was bei uns aber dann zu abbrüchen bei mehr als 75% der Sprints geführt hätte.

Ich habe das immer so verstanden, dass das eine Kernphilosophie von SCRUM ist: Nicht zu lange mit dem Schätzen aufhalten, sondern das Bauchgefühl entscheiden lassen.
Natürlich mit ordentlicher Vorbereitung (Refinement) - die aber nicht am Entwicklerteam hängt.

Ich bin ein großer Freund davon überhaupt nicht zu schätzen aber wenn man ein Sprintbacklog füllen muss kommt man nicht darum. In wie weit das Refinement komplett ohne das Team funktionieren soll ist mir ehrlich gesagt nicht klar.

Wenn es zu viel war, wandert es in den nächsten Sprint bzw. zurück in's Backlog. Wenn es "zu wenig" war -> Sprint abschließen (oder nachziehen, wenn man terminlich nicht flexibel sein kann).

Die Punktlandung ist gar nicht das Ziel.

Mmn. missverstehen viele das Versprechen, dass die Softwareentwicklung effektiver wird mit einer permanent erhöhten Auslastung der Entwickler.
SCRUM ist kein Werkzeug um Druck hoch zu halten oder die Leute langfristig am Limit laufen zu lassen. Wenn überhaupt, dann soll es das eher verhindern.

Zurückschieben ist negatives Feedback und nachziehen wie gesagt eigentlich nicht erlaubt. Und etwas als Versprechen (Commitment) zu bezeichnen wenn es dann doch nicht so wichtig ist das man sich daran hält ist eine sehr schlechte Wortwahl.

Ich habe nicht gesagt das man die Leute am Limit laufen lassen soll. Ich sprach von einem gleichmäßigem "Druck". Ich nennen das immer "Das Gefühl der Dringlichkeit"

;11649389']Das bestätigt meinen Verdacht.

Genau hier liegt der Denkfehler, weil das immer schlecht vermittelt wird.
Zum einen: Änderungen des Umfangs (zusätzliche Stories rein nehmen oder welche wieder raus werfen) ist nicht per se verboten, es sollte nur minimiert werden.

Die reine Lehrer verbietet es und wenn man davon abweicht ist es kein Scrum mehr. Ja ich bin mir bewusst das die meisten Leute Scrum trotzdem modifizieren nur sollten sie dann eben auch Scrumartig nennen.

;11649389']Jetzt zum Thema Sprintziel:
Nehmen wir an, wir planen einen Sprint mit 10 Stories, 4 davon größer als die anderen. Dann suchen wir uns die 2 wichtigsten davon raus, und sagen: diese beiden Themen umzusetzen ist unser Sprintziel.
D.h.: von den anderen, kleinen Stories kann zur Not ruhig was raus fliegen, oder es kann noch ein oder zwei weitere kleine Stories während des Sprint dazu kommen, solange das Sprintziel dadurch nicht gefährdet wird!

Insofern kann man durchaus positives Feedback erzeugen. Sei es, in dem man mehr schafft als gedacht, oder weil man ein zusätzliches technical-dept-issue eliminieren konnte.

Womit wir wieder bei dem Punkt sind das ihr von Scrum abweicht um einen positiven Feedbackloop einzubauen. Ich kenne jetzt eure Sprintergebnisse natürlich nicht habe jetzt aber mal den Verdacht das ihr fast immer eure eigentliche Ziele erreicht und zusätzlich auch noch optionale Tasks abarbeiten könnt.

;11649389']JMan sollte auch nicht die Wichtigkeit von Retrospektiven unterschätzen, wo man solche Dinge besprechen kann/soll. Dafür sollte man sich auch locker mal 2 Stunden Zeit nehmen. Einfach in 10 Minuten den Sprint zu resümieren ist keine Retro und führt zu nix.

Ich war in vielen stundenlangen Retros die dann zu nichts geführt haben weil das Projektmangment einfach noch nicht so weit war einzusehen das die Lösung ist Scrum komplett aufzugeben da es in unserem Umfeld nicht funktioniert.

;11649389']Scrum ist jetzt eigentlich nicht so unflexibel. Aber im Endeffekt: wenn es dann halt nicht mehr Scrum genannt werden kann, ist das scheiß egal, solange es für euch funktioniert! Das ist das wichtigste: es muss für euch funktionieren! Wenn ihr dafür Scrum etwas modifizieren müsst, ist das legitim!

Wenn es kein Scrum mehr ist sollte man es auch nicht mehr Scrum nennen. Unser Prozess ist so weit weg von Scrum das es eine absolute Lüge wäre das noch Scrum zu nennen.

;11649389']Wenn die Änderungen akut sind (im Sinne von: uns geht massiv Geld verloren wenn wir es nicht tun, oder schlimmer) dann muss es in den Sprint aufgenommen und was anderes raus geworfen werden. Oder der Sprint muss abgebrochen werden. Alles andere kann auch bis zum nächsten Sprint warten.

Das Problem ist Zeit (und damit indirekt natürlich Geld). Ich habe nur sehr wenige Sprints erlebt in denen nicht etwas unvorhergesehenes passiert ist was dazu führte das man plötzlich massiv umplanen musste. Dazu gehören Dinge wie das ein externe Dienstleister nicht wie vereinbart liefert. Jemand krank wird. Festgestellt wird das ein Design überhaupt nicht funktioniert.Bemerkt wird das in einem Tool ein Feature fehlt das mehrer Leute daran hindert an ihren eigentlichen Tasks zu arbeiten. usw usw.

Ein agiler Prozess sollte und muss damit umgehen können. Scrum kann es nicht wirklich. Das ganze ist jetzt inzwischen auch über 20 Jahre alt und für einen ersten Versuch war es nicht schlecht.

[#44]

Ich bin ein großer Freund davon überhaupt nicht zu schätzen aber wenn man ein Sprintbacklog füllen muss kommt man nicht darum. In wie weit das Refinement komplett ohne das Team funktionieren soll ist mir ehrlich gesagt nicht klar.
Ganz ohne das Team nicht - nur eben ohne die Entwickler. Zwischen PO, PL und Scrummaster. Zumindest bei uns haben die untereinander genug Fach- und Programmierkentnisse, dass da ordnetlich vorbereitete Tickets bei rum kommen.
Wenn mal ein Ticket nicht passt, geben die Entwickler das dann wieder mit einem kleinen Kommentar zurück.

Zurückschieben ist negatives Feedback und nachziehen wie gesagt eigentlich nicht erlaubt.Dann schließt man den Sprint ab. SCRUM sag nicht, dass man den Sprint in die länge ziehen muss. Nur, dass er Timeboxed ist.
Wer das trotzdem macht (um mal auf deine Argumentation aufzuspringen) macht dann kein SCRUM. Dann ist's auch egal, wenn man Tickets nachzieht...

Und etwas als Versprechen (Commitment) zu bezeichnen wenn es dann doch nicht so wichtig ist das man sich daran hält ist eine sehr schlechte Wortwahl.
Das soll natürlich nicht der Regelfall werden. Andererseits gibt es immer unvorhergesehenes, auf das man eben reagieren muss. Bei SCRUM konkret nicht mit Überstunden und Druck, sondert mit der Einsicht, dass der Plan halt scheiße war. Oder das die Projektumstände nicht in Stein gemeißelt sind. Eben Agil. Aber das gilt dann halt auch für andere Projekt-Aspekte. Mit einer harten Deadline zu der Vollständigkeit gefordert ist, ist man nicht agil.

Die Grundannahme das Pläne immer schaffbar sind/sein müssen, empfinde ich als furchtbares Managementdenken.
Das ist eines der Grundprobleme der Softwareentwicklung.
Deswegen wird nämlich bei Code-Qualität/Tests/Doku beschissen - damit man irgendwie den heiligen Plan halten kann. Und damit wären wir dann (vielleicht) wieder am Anfang des Threads.

Ich habe nicht gesagt das man die Leute am Limit laufen lassen soll. Ich sprach von einem gleichmäßigem "Druck". Ich nennen das immer "Das Gefühl der Dringlichkeit"
Erst mal: Das war gar nicht voll auf dich Bezogen - ich hab' das nur als Anstoß aufgenommen.

Aber was soll das denn bitte heißen? Fangen die Leute bei euch an, sich anderweitig zu beschäftigen, wenn man ihnen nicht hinterherläuft? Hören die dann auf zu arbeiten?

[Monger]

Oh cool, eine psychologische Diskussion hier im Forum - das ich das nochmal erleben darf!
Ein primäres Problem von Scrum ist das es nur einen negativen Feedbackloop hat.

Inwiefern?
Das Sprint Review Meeting z.B. ist ja dazu da, um gemeinsam Erfolge zu feiern. Die Retrospektive greift ganz explizit auch gelungene Strategien auf. Das erreichen von konkreten Zielen hat ja allgemein etwas befriedigendes. Es ist nicht alles "Problem-talk", oder wie hast du das gemeint?


Das Team wird immer konservativer was die Zeitschätzungen angeht. Da aber auch eine zu großzügige Schätzung als Fehler angesehen wird neigt man dann (ebenso unterbewusst) dazu die Zeit auch wirklich zu benötigen.

Ich finde, Fehleinschätzungen sind so ein riesiges Problem in der Softwareentwicklung, dass Effizienz ruhig n bissl runter gehen darf. Mir wurde auf Arbeit auch eingetrichtert: Liefertreue ist nicht gleich Lieferfähigkeit, aber Liefertreue ist wichtiger. Ist okay wenn jemand 6 Monate auf sein Auto wartet, solange man es ihm korrekt angekündigt hat.


Ein anderes Problem ist der ständig wechselnden "Druck" dadurch das man am Anfang eines Sprints die Taskliste füllt und diese dann im Verlauf immer kleiner wird. Das führt dazu das im Verlauf eines Sprints solange man im Plan liegt die Entspannung immer weiter zunimmt. Läuft es dagegen nicht gut steigt der Stress beständig an. Beides will man eigentlich vermeiden weil es negativ für die Produktivität ist.

Sicher? Langläufige Routine nagt erst recht an der Konzentration, siehe z.B. am Flughafen, wo die Kontrolleure regelmäßig mit Fake-Bomben überrascht werden, weil es einfach unmöglich ist über Stunden, Tage und Wochen der Ereignislosigkeit den selben Level zu halten.
Überraschungen will man natürlich vermeiden, aber 4 Wochen sind ein Zeitraum den man noch gefühlt überblicken kann. Wenn man in dem Zeitrahmen einen Beginn und ein Ende erkennen kann, hat man wenigstens das Gefühl von Fortschritt.

Die Sprintdauer als solches ist ebenso ein Problem da dadurch die regulative Kraft welche ein Entwicklungsprozess haben soll viel zu träge macht.

Du kannst und solltest zu Beginn jedes Sprints die Sprintdauer neu festlegen. Das Ziel ist ja Planbarkeit und Selbstwirksamkeit. Es ist nicht schlimm wenn man ein paar Tage daneben liegt, wenn man ein paar Monate oder Jahre daneben liegt, schon.
Hat natürlich auch damit zu tun, wie weit die Fehlerkultur in einer Firma gereift ist. Wenn da jeder Tag Fehlplanung gleich abgestraft wird, ist das natürlich kein innovationsfreundliches Klima. Dann dienen andere Prozesse aber eher der Verschleierung als wirklich der Behebung dieses Zustands.
Scrum sagt eigentlich auch, dass ein Stück weit Leerlauf gut und nützlich ist. Es sollten nicht immer alle Leute voll ausgelastet sein.


Burndowndiagramme sind btw auch nicht optimal. Fallenden Linien sind eher negative assoziert. Wenn man Diagramme braucht sollte man die erledigten Tasks mit einer steigenden Linie visualisieren.

Sehe ich anders. Zu ordnen, aufzuräumen und zu putzen ist für viele Menschen hochbefriedigend. Tetris war nicht zuletzt deshalb so ein Suchtspiel, weil man nicht den Turm hoch, sondern runter baut. Für Menschen sind eigentlich nur zwei Skalenpunkte intuitiv erfassbar: Null, und 100 Prozent. Prozentangaben sind aber irreführend, weil wenn das Ziel sich verschiebt, kann es sein dass man trotzdem viel mehr geschafft hat, und trotzdem dem Ziel nicht näher rückt. Bei Absolutbalken ist es aber schwierig zu argumentieren, warum es denn so wichtig ist von 350 Storypoints auf 350 zu kommen, und nicht nur auf 330.


Wie gesagt es mag sein das es außerhalb der Spielentwicklung besser funktioniert aber bisher hat jeder Projektmanager mit dem ich zu tun hatte früher oder später aufgegeben.

Ne, das ist kein Phänomen der Spieleentwicklung, wobei ich - sorry - als Außenstehender das Vorurteil pflege, Spielesoftwarefirmen sind "arm, aber sexy", und Softwareentwicklung spielt da im Vergleich zum restlichen Design eine untergeordnete Rolle. So viel Code ist das ja an industriellen Maßstäben gemessen meist nicht. In der restlichen Softwareindustrie steckt mMn hier und da mehr Geld und mehr Erfahrung.

Ja ich weiß das man sagt das Scrum nur deswegen nicht funktioniert weil man es falsch macht oder zu früh aufgegeben hat. Meine Meinung ist aber das man dadurch nur irgendwann den Punkt erreicht an dem man das Team unterbewusst so weit konditioniert hat das es so aussieht als würde es funktionieren. Dadurch aber gleichzeitig eine Menge potenzial verschwendet.
Wenn Konditionierung funktioniert, ist doch super.
Aber ich gebe dir recht, dass Scrum keinen so wirklichen Weg dorthin vorzeichnet: entweder man ist da oder nicht, es gibt nichts so rechtes dazwischen. Man hört viel von Problemen, aber wenig über Erfolge. Die Firmen die erfolgreich Scrum betreiben, waren vorher auch schon irgendwie erfolgreich, und der Mindset war eh schon da.

[ottoman]

Womit wir wieder bei dem Punkt sind das ihr von Scrum abweicht um einen positiven Feedbackloop einzubauen. Ich kenne jetzt eure Sprintergebnisse natürlich nicht habe jetzt aber mal den Verdacht das ihr fast immer eure eigentliche Ziele erreicht und zusätzlich auch noch optionale Tasks abarbeiten könnt.

Das Definieren von Zielen in einem Sprint ist ganz normal bei Scrum.

[Demirug]

Ganz ohne das Team nicht - nur eben ohne die Entwickler. Zwischen PO, PL und Scrummaster. Zumindest bei uns haben die untereinander genug Fach- und Programmierkentnisse, dass da ordnetlich vorbereitete Tickets bei rum kommen.
Wenn mal ein Ticket nicht passt, geben die Entwickler das dann wieder mit einem kleinen Kommentar zurück.

Bei uns nicht. Zu viele Spezialisten.

Dann schließt man den Sprint ab. SCRUM sag nicht, dass man den Sprint in die länge ziehen muss. Nur, dass er Timeboxed ist.
Wer das trotzdem macht (um mal auf deine Argumentation aufzuspringen) macht dann kein SCRUM. Dann ist's auch egal, wenn man Tickets nachzieht...

Ich habe mich wohl nicht ganz klar ausgedrückt. Es geht hier nicht darum das das ganze Team zu früh fertig ist. Das ist bei uns nie passiert. Es geht darum das Teile des Teams nichts mehr zu tun haben da für ihr Skillset keine Tasks mehr im Sprintlog sind.

Das soll natürlich nicht der Regelfall werden. Andererseits gibt es immer unvorhergesehenes, auf das man eben reagieren muss. Bei SCRUM konkret nicht mit Überstunden und Druck, sondert mit der Einsicht, dass der Plan halt scheiße war. Oder das die Projektumstände nicht in Stein gemeißelt sind. Eben Agil. Aber das gilt dann halt auch für andere Projekt-Aspekte. Mit einer harten Deadline zu der Vollständigkeit gefordert ist, ist man nicht agil.

Bei uns ist das unvorhersehbare leider die Regel und damit war bei Scrum nahezu jeder Sprintplan "scheiße". Wenn man innerhalb eines Sprints mehrmals umplanen muss braucht man auch keinen Sprint und damit auch kein Scrum mehr.

Die Grundannahme das Pläne immer schaffbar sind/sein müssen, empfinde ich als furchtbares Managementdenken.
Das ist eines der Grundprobleme der Softwareentwicklung.
Deswegen wird nämlich bei Code-Qualität/Tests/Doku beschissen - damit man irgendwie den heiligen Plan halten kann. Und damit wären wir dann (vielleicht) wieder am Anfang des Threads.

Wenn man einen Plan (auch wenn er nur für 2 Wochen ist) nicht als wirklich verbindlich ansieht braucht man in eigentlich auch nicht. Dann ist ein Ziel völlig ausreichend. Und natürlich ist das Managmentdenken. Womit wird aber beim gleichen Punkt sind. Wenn man der Ebene darüber keinen Plan zeigt erzeugt man erst gar nicht die Erwartungshaltung. Ich bin mir bewusst das das ein Problem ist da diese Ebene bzw. der Kunde gerne vorher wissen möchte wie lange etwas dauert und was es kosten wird.

Aber was soll das denn bitte heißen? Fangen die Leute bei euch an, sich anderweitig zu beschäftigen, wenn man ihnen nicht hinterherläuft? Hören die dann auf zu arbeiten?-

Das Phänomen ist hier eher das je kleiner das Sprintbacklog wurde desto mehr Zeit wird in einen Task investiert. In unserem Fall sind viele Tasks keine exakte Wissenschaft entsprechend kann man da leicht endlos iterieren oder "Research" betreiben. Aber selbst wenn man dabei Endpunkt erreicht hat kann man häufig nicht einfach einen weiteren Task aus dem Projektbacklog zaubern da nötige Vorarbeiten von anderen noch nicht erledigt wurden. In dem Fall bleibt den entsprechenden Personen wirklich nichts anderes übrig als sich anderweitig zu beschäftigen.

Nur das wir uns hier nicht falsch verstehen. Mir ist es im Prinzip völlig egal welchen Entwicklungsprozess jemand in seinen Projekten benutzt. Mein Argument war nur das wenn etwas nicht so läuft wie man es eigentlich möchte man auch einen genauen Blick auf den Prozess werfen sollte. Selbst wenn dieser erst einmal scheinbar nicht das Problem ist. Vor allem wenn etwas schon sehr lange so gemacht wird neigt man dazu sich damit zu arragieren.

[#44]

Spannend. Das ist tatsächlich sehr weit von meiner Erfahrungswelt weg.
Und einen weiteren Vorteil von Agile könnt ihr vermutlich auch nicht so recht ausspielen: Continuous Delivery

Zumindest wüsste ich außerhalb der Indie-Szene kein Projekt, dass derart iterativ arbeitet.
Man will (und muss) ja eine gewisses Gesamterlebnis abliefern.

Wenn man einen Plan (auch wenn er nur für 2 Wochen ist) nicht als wirklich verbindlich ansieht braucht man in eigentlich auch nicht. Dann ist ein Ziel völlig ausreichend.
Realistisch gesehen hat man (also bei uns) ja auch nicht mehr. Zumindest würde ich das Resultat von 1-2 Stunden "Planning" so bezeichnen.

[Demirug]

Das Definieren von Zielen in einem Sprint ist ganz normal bei Scrum.

Ja das Ziel war immer das am Ende des Sprints bestimmte Stories erledigt sein sollten.

Inwiefern?
Das Sprint Review Meeting z.B. ist ja dazu da, um gemeinsam Erfolge zu feiern. Die Retrospektive greift ganz explizit auch gelungene Strategien auf. Das erreichen von konkreten Zielen hat ja allgemein etwas befriedigendes. Es ist nicht alles "Problem-talk", oder wie hast du das gemeint?

Was ich meine ist das das erreichen der Sprintziele der Erwartungsfall (neutral) ist. Erreicht man sie nicht ist das ein negatives Ereignis. Ist man nun aber schneller fertig als ursprünglich geplant ist das auf den ersten Blick ja ein positives Ergebnis. Das Problem dabei ist nur das es gleichzeitig auch zeigt das man eigentlich bei der Planung des Sprints einen Fehler gemacht hat. Entsprechend kann man einfach nicht gewinnen.

Um es dabei aber noch einmal ganz klar zu sagen. Mir geht es hier primär um die unterbewusste Wahrnehmung.

Ich finde, Fehleinschätzungen sind so ein riesiges Problem in der Softwareentwicklung, dass Effizienz ruhig n bissl runter gehen darf. Mir wurde auf Arbeit auch eingetrichtert: Liefertreue ist nicht gleich Lieferfähigkeit, aber Liefertreue ist wichtiger. Ist okay wenn jemand 6 Monate auf sein Auto wartet, solange man es ihm korrekt angekündigt hat.

Wir schätzen nicht mehr. Funktioniert sowieso nicht

Da wir wissen das wir sowieso nicht 100% liefern können ist das Ziel so viel wie möglich davon zu liefern wenn das Budget aufgebraucht ist.

Sicher? Langläufige Routine nagt erst recht an der Konzentration, siehe z.B. am Flughafen, wo die Kontrolleure regelmäßig mit Fake-Bomben überrascht werden, weil es einfach unmöglich ist über Stunden, Tage und Wochen der Ereignislosigkeit den selben Level zu halten.
Überraschungen will man natürlich vermeiden, aber 4 Wochen sind ein Zeitraum den man noch gefühlt überblicken kann. Wenn man in dem Zeitrahmen einen Beginn und ein Ende erkennen kann, hat man wenigstens das Gefühl von Fortschritt.

Den Fortschritt kann man bei uns sehr gut direkt am Produkt selbst erkennen.Ich weiß ja nun nicht wie bei euch die Tasks aussehen. Aber bei uns sagt man das wenn man immer wieder den gleichen Code schreibt man die entsprechenden Teile Datadriven machen soll damit der "Kunde" nicht jedesmal einen Coder braucht. Entsprechend sind unsere Tasks eigentlich so unterschiedlich das die Gefahr von Routine nicht wirklich besteht,.

Du kannst und solltest zu Beginn jedes Sprints die Sprintdauer neu festlegen. Das Ziel ist ja Planbarkeit und Selbstwirksamkeit. Es ist nicht schlimm wenn man ein paar Tage daneben liegt, wenn man ein paar Monate oder Jahre daneben liegt, schon.
Hat natürlich auch damit zu tun, wie weit die Fehlerkultur in einer Firma gereift ist. Wenn da jeder Tag Fehlplanung gleich abgestraft wird, ist das natürlich kein innovationsfreundliches Klima. Dann dienen andere Prozesse aber eher der Verschleierung als wirklich der Behebung dieses Zustands.
Scrum sagt eigentlich auch, dass ein Stück weit Leerlauf gut und nützlich ist. Es sollten nicht immer alle Leute voll ausgelastet sein.

Ich sehe jetzt nicht welchen Vorteil es bringen soll die Sprintdauer ständig zu variieren. Ich rede jetzt nicht davon das es externe Kritik gibt wenn man seine Sprintziele nicht erreicht. Wenn dem so ist kommt das noch erschwerenden hinzu. Mir geht es hier mir um den inneren Effekt den es hat wenn man sein Versprechen nicht einhält. Ich habe da zwei Verhaltensmuster beobachtet. Der einen Gruppe war es irgendwann egal da es sowieso keine wirklichen Konsequenzen gab. Die andere Gruppe hat dagegen ihre Bereitschaft etwas zu Versprechen immer weiter reduziert.

Ich kann mich jetzt nicht erinnern das Scrum selbst etwas dazu aussagt wie viel Leerlauf leute haben sollen.


Sehe ich anders. Zu ordnen, aufzuräumen und zu putzen ist für viele Menschen hochbefriedigend. Tetris war nicht zuletzt deshalb so ein Suchtspiel, weil man nicht den Turm hoch, sondern runter baut. Für Menschen sind eigentlich nur zwei Skalenpunkte intuitiv erfassbar: Null, und 100 Prozent. Prozentangaben sind aber irreführend, weil wenn das Ziel sich verschiebt, kann es sein dass man trotzdem viel mehr geschafft hat, und trotzdem dem Ziel nicht näher rückt. Bei Absolutbalken ist es aber schwierig zu argumentieren, warum es denn so wichtig ist von 350 Storypoints auf 350 zu kommen, und nicht nur auf 330.

Das scheint mir eine Frage von Stapel vs. Linien zu sein. Bei einem Stapel stimme ich dir zu das man dort eher eine Befriedigung sieht wenn man in abträgt. Bei Linien werden nach meiner Erfahrung steigende positiver wahrgenommen als fallenden.

Ne, das ist kein Phänomen der Spieleentwicklung, wobei ich - sorry - als Außenstehender das Vorurteil pflege, Spielesoftwarefirmen sind "arm, aber sexy", und Softwareentwicklung spielt da im Vergleich zum restlichen Design eine untergeordnete Rolle. So viel Code ist das ja an industriellen Maßstäben gemessen meist nicht. In der restlichen Softwareindustrie steckt mMn hier und da mehr Geld und mehr Erfahrung.

Ich bin seit 10 Jahren raus aus der Industrie. Habe also keine aktuellen Erfahrungen aus erster Hand. Entsprechend kenne ich da aktuelle Projektgrößen (Entwickler; Budgets) nichts. Von dem was ich so höre hatte ich aber den Eindruck das man sich dort eher in Richtung kleinerer Projekte bewegt.

Bei der Spielentwicklung muss man ganz massiv zwischen Independent und großen Studio Produktionen unterscheiden.

Wenn Konditionierung funktioniert, ist doch super.
Aber ich gebe dir recht, dass Scrum keinen so wirklichen Weg dorthin vorzeichnet: entweder man ist da oder nicht, es gibt nichts so rechtes dazwischen. Man hört viel von Problemen, aber wenig über Erfolge. Die Firmen die erfolgreich Scrum betreiben, waren vorher auch schon irgendwie erfolgreich, und der Mindset war eh schon da.

Konditionierung ist nicht zwangsläufig gut wenn man auf ein unerwünschtes Ziel konditioniert. Wenn mein Prozess dazu führt das sich ein Team bewusst oder unbewusst selbst unterschätzt ist das eine schlechte Konditionierung.

Spannend. Das ist tatsächlich sehr weit von meiner Erfahrungswelt weg.
Und einen weiteren Vorteil von Agile könnt ihr vermutlich auch nicht so recht ausspielen: Continuous Delivery

Es gibt natürlich keine externen Deliveries. Interne an unsere "Kunden" (Producer/Creative Director) haben wir aber in der Regel mehrmals täglich.

Zumindest wüsste ich außerhalb der Indie-Szene kein Projekt, dass derart iterativ arbeitet.
Man will (und muss) ja eine gewisses Gesamterlebnis abliefern.

Natürlich muss man am Ende was liefern. In der Spielentwicklung ist das aber sowieso nie das was man sich am Anfang des Projekts mal vorgestellt hat. Am Ende hat man nämlich immer nicht genügend Zeit und Budget das alles umzusetzen was man möchte. Zudem merkt man auch häufig das was sich zuerst einmal toll angehört hat am Ende keinen Spaß macht und geändert werden muss.

Realistisch gesehen hat man (also bei uns) ja auch nicht mehr. Zumindest würde ich das Resultat von 1-2 Stunden "Planning" so bezeichnen.

Bei uns war das wegen der massiven Abhängikeiten jedesmal eher ein ganzer Tag für einen zwei Wochen Sprint.

[RMC]

In dem Punkt sind wir uns einig nur wie gesagt wenn du an Scrum etwas änderst ist es nach Ansicht der Scrumerfinder eben kein Scrum mehr weil es ihrer Ansicht nach nur genau so funktioniert.

Mag von mir aus sein, aber wohin soll das führen?

Es ist auch etwas weit von meiner praktischen Erfahrung mit Scrum weg, und meine Akzeptanz gegenüber Scrum/Scrumleute/Leader die 1-2 Bücher lesen und meinen dass es genauso zu funktionieren hat ist nach Erfahrungen auch enden wollend.

Der erste Satz des Agile Software Development Manifests ist: "Individuals and interactions over processes and tools". Sogar Jeff Sutherland hat daran teilgenommen. Damit ist eigentlich schon viel gesagt.

Es darf sich alles weiterentwickeln. Sogar die Scrumleute werden gscheiter, hoffentlich.

[Demirug]

Mag von mir aus sein, aber wohin soll das führen?

Es ist auch etwas weit von meiner praktischen Erfahrung mit Scrum weg, und meine Akzeptanz gegenüber Scrum/Scrumleute/Leader die 1-2 Bücher lesen und meinen dass es genauso zu funktionieren hat ist nach Erfahrungen auch enden wollend.

Wie? Ich dachte nach einem 2 Tages Kurs ist man ein voll qualifizierter Scrummaster? ;)

Der erste Satz des Agile Software Development Manifests ist: "Individuals and interactions over processes and tools". Sogar Jeff Sutherland hat daran teilgenommen. Damit ist eigentlich schon viel gesagt.

Wenn man den Geschichten glaubt die andere Teilnehmer erzählen dann wurde das Manifest wohl am Ende noch schnell zusammengeschustert. Man wollte sich nicht schon wieder ohne ein Ergebnis trennen.

Es darf sich alles weiterentwickeln. Sogar die Scrumleute werden gscheiter, hoffentlich.

Die Scrum Industrie hat kein Interesse daran das sich da irgendwas weiterentwickelt.

[medi]

Ich glaube die Antwort ist ganz einfach: einige Leute wollen lieber eine Lösung produzieren die schnellste wirklich fertig ist
Einige Leute? Ka was euer täglich Brot ist aber bei uns zählt immer die billigste Lösung beim Kunden. Da kalkuliert man schon mit dem Skalpell und dann wird man durch dein Einkauf noch mal gedrückt. Qualität zählt nur bei der Abnahme aber nicht beim Angebot. Wenn ich nicht selbst einen gewissen Anspruch hätte was meinen geschriebenen Code angeht - dem Kunden wäre es egal so lange er läuft und möglichst wenig kostet. Wartbarkeit? Egal! Flexibilität? Egal! Robustheit? Egal - so lange es nicht zu großen Problemen führt.

[Mosher]

An dieser Diskussion sieht man finde ich wunderschön, dass es überhaupt nichts bringt, an solchen starren Konstrukten und festen Begrifflichkeiten im Projektmanagement festzuhalten.

Zugegeben, unser Kerngeschäft ist Elektronik, aber auch da gibt es Software und nicht selten liefern wir ein eigenständiges Softwareprodukt mit.

Ich war und bin schon immer ein Fan davon, sich als Projektmanager die Freiheit zu nehmen, für jedes einzelne Projekt einen ganz individuellen Prozess zu definieren, wie wann was wie oft released wird. Unsere Kunden einer bestimmten Sorte interessiert es im Endeffekt einen Kehrricht, ob wir das Ding jetzt "SCRUM" oder Supergeiles Modell Y nennen.

Es geht nur um Effizienz und Zufriedenheit.

Der eine Kunde kann gut damit leben, 6 Monate auf einen Bugfix zu warten, weil es ein festes Raster gibt, der andere darf so und so viele high prio Tickets erstellen, von denen pro Monat dann garantiert so und so viele abgearbeitet werden müssen.

Etc.

Bevor ich meine Projekte da in ein Schema pressen lasse, passe ich lieber unser Vorgehen an und das - in aller Bescheidenheit - nicht wenig erfolgreich.

Letztlich gillt für das Projekt als ganzes, aber auch für jede Codezeile: "Mach, dass es geht"
Einige Leute? Ka was euer täglich Brot ist aber bei uns zählt immer die billigste Lösung beim Kunden. Da kalkuliert man schon mit dem Skalpell und dann wird man durch dein Einkauf noch mal gedrückt. Qualität zählt nur bei der Abnahme aber nicht beim Angebot. Wenn ich nicht selbst einen gewissen Anspruch hätte was meinen geschriebenen Code angeht - dem Kunden wäre es egal so lange er läuft und möglichst wenig kostet. Wartbarkeit? Egal! Flexibilität? Egal! Robustheit? Egal - so lange es nicht zu großen Problemen führt.
So ticken auch die meisten unserer Kunden, wobei ich mich nicht nur mit großem Widerwillen in einen Modus ohne Qualitätssicherung drücken lasse. Das fällt einem immer auf die Füße, also entweder wird einfach hart verhandelt, bis auch der ungeliebte "Overhead" bezahlt wird, oder man einigt sich auf Risikozuschläge, die auch solche Fälle abdecken, dass man irgendwann seinen Codemurks aufräumen muss, bevor es neue Features gibt.

Wie gesagt, 20 verschiedene Kunden, 100 verschiedene Projekte...

Industriekunden sind natürlich meistens anders. Die wissen meistens, dass Qualität halt kostet. Dafür sind die Projekte oft langweilig und staubtrocken :D

[Ectoplasma]

Ohne den Thread jetzt gelesen zu haben. Aber ich lese hier mehrfach SCRUM. Ernsthaft jetzt? SCRUM ist für Anfänger die Führung brauchen. Sorry, meine Meinung. Alles was es braucht, sind erfahrene und vernünftige Leute in den Fachabteiliungen und in der Entwicklung, die fähig sind ein Team zu bilden und Verantwortung zu übernehmen. Das einzig doofe daran ist, dass man damit keine Romane über Trottel-Gerechte Vorgehensmodelle schreiben kann, die man einem ahnungslosen Manager als Gesamtpaket zur Weiterbildung seiner natürlich komplett inkompetenten Entwicklungsabteilung verkaufen kann.

Mittlerweile hat aber bereits jeder Halbaffee verstanden, dass der Erfolg eines Projektes nicht mit den auferlegten Strukturen, sondern einfach mit den entsprechenden Leuten steht und fällt und bei "schwierigen" Mitarbeiten, eine gute Sozialkompetenz des Projektleiters oder einzelner Teammmitglieder viel wichtiger sind, um solche Mitarbeiter in ein Team einzubringen.

[noid]

Das stimmt. Das einzige was ich an scrum aber ok finde ist die Taktung der deliveries. Gerade wenn du mehrere Gruppen hast, die zusammen liefern. Continuous delivery/nightly builds ersetzen halt keine echten Grenzen für PSIs

Sagen wir mal ab 50 Leuten machen feste sprints schon Sinn. Die metriken sind halt nur bedingt nutzbar, aber Teamretros sind wertvoll weil man sich Zeit nimmt.

[Monger]

Was ich meine ist das das erreichen der Sprintziele der Erwartungsfall (neutral) ist. Erreicht man sie nicht ist das ein negatives Ereignis. Ist man nun aber schneller fertig als ursprünglich geplant ist das auf den ersten Blick ja ein positives Ergebnis. Das Problem dabei ist nur das es gleichzeitig auch zeigt das man eigentlich bei der Planung des Sprints einen Fehler gemacht hat. Entsprechend kann man einfach nicht gewinnen.

Ja, aber zu früh fertig zu werden, IST ja auch höchstwahrscheinlich ein ernsthaftes Problem. Kann ja eigentlich nur zwei Ursachen dafür geben: entweder du hast die Komplexität der Aufgabe deutlich überschätzt (passiert sehr, SEHR selten), oder dir sind die Aufgaben ausgegangen. Ein leeres Backlog ist fatal, das bedeutet das entweder das Anforderungsmanagement nicht hinterher kommt, man auf Zulieferungen wartet oder keine Kunden hat.
Wenn wir frühzeitig fertig werden, ziehen wir uns halt die nächsten Aufgaben ausm Backlog, oder kümmern uns um eigene Projekte, oder lassen es mal n bissl ruhiger angehen, etc. pp. . Man weiß ja, der nächste Sprint kommt bestimmt.


Wir schätzen nicht mehr. Funktioniert sowieso nicht
...
Da wir wissen das wir sowieso nicht 100% liefern können ist das Ziel so viel wie möglich davon zu liefern wenn das Budget aufgebraucht ist.

Naja, mindestens derjenige der euer Budget und eure Termine festlegt, schätzt. Und ich wette drauf, seine Schätzungen sind schlechter als eure.
Du argumentierst ja mit Motivation. Aber wenn die Messlatte ist, "so viel wie möglich" zu liefern bis das Geld ausgeht, ist das nicht erst recht ein Anreiz die Arbeit einfach schleifen zu lassen, und das Entwicklungstempo unbewusst zu reduzieren? Wozu sich für ein Ziel stressen, was so unpräzise formuliert ist? Und über ein Jahr hinweg (oder wie lange auch immer eure Budgetplanung geht) reichen kaum wahrnehmbare Veränderungen pro Woche aus, um am Ende im Schneckentempo zu kriechen.

Dein Argument ist ja, wenn ich es richtig verstehe, dass du die ständige Demotivation durch das Verpassen von Zielen für destruktiv hältst. Aber was ist die Alternative? Von vorneherein Ziele als unerfüllbar zu deklarieren? Das soll motivierender sein?



...Entsprechend sind unsere Tasks eigentlich so unterschiedlich das die Gefahr von Routine nicht wirklich besteht,.

Das meinte ich nicht. Wenn du jahrelang ohne konkrete Ziele und ohne Kunden vor dich hin entwickelst, verlierst du allmählich die Identifikation zum Produkt. Es ist dann nur noch Arbeit der Arbeit willen, das Resultat ist wurscht.
Das kann man bekämpfen, indem man einen sehr direkten Kontakt zum Kunden pflegt (der treibt dann automatisch), oder halt überschaubare Zwischenziele formuliert, ergo Sprints. Beides ist hilfreich.


Mir geht es hier mir um den inneren Effekt den es hat wenn man sein Versprechen nicht einhält. Ich habe da zwei Verhaltensmuster beobachtet. Der einen Gruppe war es irgendwann egal da es sowieso keine wirklichen Konsequenzen gab. Die andere Gruppe hat dagegen ihre Bereitschaft etwas zu Versprechen immer weiter reduziert.

Agile Methodik geht davon aus, dass Leute ein inneres Interesse daran haben, gute Arbeit zu liefern. In einem gesunden Arbeitsumfeld musst du niemanden dazu treten.
Was du beschreibst, ist eigentlich ein typisches Anzeichen für inneren Widerstand, ergo: Unzufriedenheit mit der Firma, mit den Umständen etc. .

Seit 5 Jahren bin ich jetzt auf Arbeit in dieser Transition von Wasserfall zu agiler Entwicklung hin, und je mehr wir lernen, desto weitere Kreise zieht das. Das ist mit die Krux: es ist eben keine einfache Prozessänderung, so wie von V Modell auf RUP, oder ähnliches. Wenn du Teams als handlungsfähige Einheit verstehst, hat das tiefe Implikationen für - alles: das rüttelt ganz massiv am Status Quo, angefangen beim Thema Gehalt und Weiterentwicklung, bis hin zu den Hierarchiestufen und der Organisationsform der Firma. Du kannst nicht gleichzeitig quasi-demokratische Strukturen etablieren, und gleichzeitig eine streng hierarchische Befehlskette haben.
Und das ist für mich der eigentliche Grund warum agile Methodiken so oft versagen: der innere Widerstand der zu überwinden ist, ist gewaltig. Es gibt sehr viele Verlierer solcher Änderungen. Wenn es läuft, steigt die Produktivität deutlich, aber man kann nicht einfach einen Prozess drauf nageln und es läuft, sondern man muss an die Unternehmenskultur ran.


Ich bin seit 10 Jahren raus aus der Industrie. Habe also keine aktuellen Erfahrungen aus erster Hand. Entsprechend kenne ich da aktuelle Projektgrößen (Entwickler; Budgets) nichts. Von dem was ich so höre hatte ich aber den Eindruck das man sich dort eher in Richtung kleinerer Projekte bewegt.
...
Bei der Spielentwicklung muss man ganz massiv zwischen Independent und großen Studio Produktionen unterscheiden.


Ich bin ja jetzt auch nicht repräsentativ. Ich bin im Bereich Pharma, Chemie, Wasser, Kraftwerkssparte unterwegs, und die fangen ja eigentlich erst richtig an, ins Thema Software einzusteigen. Da werden die Projekte immer riesiger. Das letzte Projekt in dem ich saß, hat von der Planung bis zum ersten Release an den Kunden rund 2 Milliarden Euro verbraten, mein aktuelles Projekt wird net ganz so teuer, aber fast. Aber dreistellige Millionenbeträge sind weg wie nix. Keine Ahnung in welchen Dimensionen EA bei AAA Produkten steht.

[Monger]

Wenn man den Geschichten glaubt die andere Teilnehmer erzählen dann wurde das Manifest wohl am Ende noch schnell zusammengeschustert. Man wollte sich nicht schon wieder ohne ein Ergebnis trennen.

Die agile Welt ist riesig, und alles andere als widerspruchsfrei. Und richtig, das agile Manifest war quasi der Mindeststandard auf den man sich einigen konnte.


Die Scrum Industrie hat kein Interesse daran das sich da irgendwas weiterentwickelt.
Scrum ist ja eine geschützte Marke. Es ist eine sehr populäre Variante des ganzen agilen Methodenkoffers, aber eben nur eine.

[Monger]

Mittlerweile hat aber bereits jeder Halbaffee verstanden, dass der Erfolg eines Projektes nicht mit den auferlegten Strukturen, sondern einfach mit den entsprechenden Leuten steht und fällt und bei "schwierigen" Mitarbeiten, eine gute Sozialkompetenz des Projektleiters oder einzelner Teammmitglieder viel wichtiger sind, um solche Mitarbeiter in ein Team einzubringen.
Ja, aber ein dazu passender Prozess kann ein guter Treiber sein, um überhaupt gute Teams aufzubauen.

Oft werden Teams ja recht wild zusammengewürfelt: da werden Kopfzahlen jongliert, und die Leute mit der Gießkanne über die Projekte verteilt. Was ich in den letzten Jahren festgestellt habe: je besser unser Teamverständnis gewachsen ist, desto mehr wert legen wir wer denn konkret ins Team kommt. Dieses Selbstverständnis und die Ermächtigung damit kam aber erst mit den Daily Standup Meetings. Ich hatte 10 Jahre lang auf Arbeit eigentlich immer einen Busfaktor von 1: egal wer weggefallen ist, es war immer ein Totalverlust. Aber seitdem wir mehr agile Methoden fahren, weicht das stärker auf. Mittlerweile gibt es eigentlich für jedes Thema im Team mindestens mal zwei Leute die einspringen können.

Also, ich bin nun wirklich niemand der in der Anwendung von Prozessen und Tools das große Heilsversprechen sieht. Man muss verstehen und fühlen was man da anwendet, sonst ist es von geringem Wert. Aber umgekehrt ist es manchmal sehr schwer aus alten Gewohnheiten auszubrechen, wenn man keine geeigneten Mittel hat.

Mal so grob gesagt: in Firmen werden persönliche Attribute regelmäßig überschätzt, und systemische Gründe unterschätzt. Wenn ein Team gut funktioniert, dann gefühlt weil sich da zufällig eine Menge Genies zusammengefunden haben, und nicht weil gute Umstände dazu geführt haben, dass Mitarbeiter sich frei entfalten, weiterentwickeln und zusammenfinden konnten.

[Demirug]

Ja, aber zu früh fertig zu werden, IST ja auch höchstwahrscheinlich ein ernsthaftes Problem. Kann ja eigentlich nur zwei Ursachen dafür geben: entweder du hast die Komplexität der Aufgabe deutlich überschätzt (passiert sehr, SEHR selten), oder dir sind die Aufgaben ausgegangen. Ein leeres Backlog ist fatal, das bedeutet das entweder das Anforderungsmanagement nicht hinterher kommt, man auf Zulieferungen wartet oder keine Kunden hat.
Wenn wir frühzeitig fertig werden, ziehen wir uns halt die nächsten Aufgaben ausm Backlog, oder kümmern uns um eigene Projekte, oder lassen es mal n bissl ruhiger angehen, etc. pp. . Man weiß ja, der nächste Sprint kommt bestimmt.

Ich weiß ich wiederhole mich. Aber wenn ihr aus dem Produktbacklog Tasks/Stories nachzieht ist das kein Scrum mehr sondern was eigenes was Ideen von Scrum benutzt. Glaubt man den Vertretern der reinen Lehre kann das nicht funktionieren.

Naja, mindestens derjenige der euer Budget und eure Termine festlegt, schätzt. Und ich wette drauf, seine Schätzungen sind schlechter als eure.
Du argumentierst ja mit Motivation. Aber wenn die Messlatte ist, "so viel wie möglich" zu liefern bis das Geld ausgeht, ist das nicht erst recht ein Anreiz die Arbeit einfach schleifen zu lassen, und das Entwicklungstempo unbewusst zu reduzieren? Wozu sich für ein Ziel stressen, was so unpräzise formuliert ist? Und über ein Jahr hinweg (oder wie lange auch immer eure Budgetplanung geht) reichen kaum wahrnehmbare Veränderungen pro Woche aus, um am Ende im Schneckentempo zu kriechen.

Da wir nicht nur Code sondern auch noch jede Menge andere Sachen brauchen gibt es niemanden der das wirklich schätzen kann.

btw. Ich musste mir erst vor kurzem von einem Scrumguru anhören das wenn du immer noch Budget und Terminplanung hast machst du kein Scrum sondern das wäre dann Water-Scrum-Fall (mit einem verächtlichen Ton in der Stimme).

Weiter unten schreibst du das die agilen Methoden davon ausgehen das man gute Arbeit liefern will. Wenn dem so ist sollte das Tempo ja nicht geringer werden wenn man die Demotivationen entfernt.

Dein Argument ist ja, wenn ich es richtig verstehe, dass du die ständige Demotivation durch das Verpassen von Zielen für destruktiv hältst. Aber was ist die Alternative? Von vorneherein Ziele als unerfüllbar zu deklarieren? Das soll motivierender sein?

Wenn man das Gesamtziel für unerreichbar hält fängt man das Projekt erst gar nicht an.

Das meinte ich nicht. Wenn du jahrelang ohne konkrete Ziele und ohne Kunden vor dich hin entwickelst, verlierst du allmählich die Identifikation zum Produkt. Es ist dann nur noch Arbeit der Arbeit willen, das Resultat ist wurscht.

Das kann man bekämpfen, indem man einen sehr direkten Kontakt zum Kunden pflegt (der treibt dann automatisch), oder halt überschaubare Zwischenziele formuliert, ergo Sprints. Beides ist hilfreich.

Also meine Kunden sitzen entweder im gleichen Büro oder haben meine email.

Seit 5 Jahren bin ich jetzt auf Arbeit in dieser Transition von Wasserfall zu agiler Entwicklung hin, und je mehr wir lernen, desto weitere Kreise zieht das. Das ist mit die Krux: es ist eben keine einfache Prozessänderung, so wie von V Modell auf RUP, oder ähnliches. Wenn du Teams als handlungsfähige Einheit verstehst, hat das tiefe Implikationen für - alles: das rüttelt ganz massiv am Status Quo, angefangen beim Thema Gehalt und Weiterentwicklung, bis hin zu den Hierarchiestufen und der Organisationsform der Firma. Du kannst nicht gleichzeitig quasi-demokratische Strukturen etablieren, und gleichzeitig eine streng hierarchische Befehlskette haben.
Und das ist für mich der eigentliche Grund warum agile Methodiken so oft versagen: der innere Widerstand der zu überwinden ist, ist gewaltig. Es gibt sehr viele Verlierer solcher Änderungen. Wenn es läuft, steigt die Produktivität deutlich, aber man kann nicht einfach einen Prozess drauf nageln und es läuft, sondern man muss an die Unternehmenskultur ran.

Da stimme ich dir zu. Das Problem ist nur das in der Spielentwicklung die Hierarchien schon immer sehr flach waren. Die Organisation als Grund für das Versagen von Scrum funktioniert da nicht so gut.

Möglicherweise liegt hier auch ein Missverständnis vor. Ich sage nicht das man zu Waterfall und Co. zurück gehen soll. Die funktionieren ja auch nicht. Ich sage lediglich das aus meiner Erfahrung heraus Scrum (so wie es gepredigt wird) auch nicht funktioniert. Meiner persönlichen Erfahrung nach funktionieren Flow orientierte Methoden wie Kanban und continuous delivery einfach besser.

[Monger]

Ich sage lediglich das aus meiner Erfahrung heraus Scrum (so wie es gepredigt wird) auch nicht funktioniert. Meiner persönlichen Erfahrung nach funktionieren Flow orientierte Methoden wie Kanban und continuous delivery einfach besser.
Zustimmung, ich bin jetzt auch kein Fan von Scrum, machen wir selber auch nicht, ich halte aber im großen und ganzen der Trend weg von Wasserfall hin zu agilen Methodiken schlicht für notwendig.
Aber wenn du hier quasi verschiedene agile Methoden gegeneinander stellst, klagst du ja bereits auf extrem hohem Niveau.

[Ectoplasma]

Das stimmt. Das einzige was ich an scrum aber ok finde ist die Taktung der deliveries.

Ja, aber ein dazu passender Prozess kann ein guter Treiber sein, um überhaupt gute Teams aufzubauen.



Das stimmt was ihr sagt. Man kann sich durchaus die Venünftigen Dinge herauspicken und in ein Projekt einbringen.

Was das Wasserfallmodell anbelangt, so war ich in den letzten 20 Jahren noch nie in einem Projekt, in dem danach gearbeitet wurde. Andererseits ist das arbeiten mit Sprints jetzt auch kein Vorgehen aus der Neuzeit, man hatte nur andere Namen dafür.

[Exxtreme]

Zustimmung, ich bin jetzt auch kein Fan von Scrum, machen wir selber auch nicht, ich halte aber im großen und ganzen der Trend weg von Wasserfall hin zu agilen Methodiken schlicht für notwendig.
Aber wenn du hier quasi verschiedene agile Methoden gegeneinander stellst, klagst du ja bereits auf extrem hohem Niveau.
Wobei das Wasserfall-Modell auch agile Elemente enthält wenn auch bei weitem nicht so ausgeprägt wie "pure" agile Methoden. Was so richtig linear ist ist das V-Modell. Ist wohl deshalb auch in Behörden so beliebt.

[Mosher]

Wobei das Wasserfall-Modell auch agile Elemente enthält wenn auch bei weitem nicht so ausgeprägt wie "pure" agile Methoden. Was so richtig linear ist ist das V-Modell. Ist wohl deshalb auch in Behörden so beliebt.

Da muss ich doch eigentlich ziemlich vehement widersprechen.
Auch im reinen V-Modell laufen viele Prozesse parallel und in der Praxis wird es eh wieder anders gelebt, als es das Modell vorgibt.

Wir entwickeln "normalerweise" nach dem V-Modell, haben aber in so gut wie jedem Projekt agile Elemente, Sonderlösungen,...

Und genau aus dem Grund finde ich es affig, sich an solchen Begriffen festzubeißen.

Auch die "ganz großen", mit denen wir zusammenarbeiten, geben nach außen zwar immer vor, dass nach Modell X entwickelt wird, wenn man mal mehr mit denen zu tun hat, stellt man fest, dass die auch nur mit Wasser kochen - was jedes Mal eine sehr erfrischende Erkenntnis ist und das Projekt extrem auflockert. Da werden dann auch mal während eines Telefonats Anforderungen für ein Produkt, das kurz vor der Serienproduktion steht, fallengelassen. Ist halt so. Muss man deshalb gleich sein komplettes Vorgehen in Frage stellen? Ich denke nicht.
Was mir sehr gut gefällt, ist durchgehend transparantes - es folgen mehrere ANglisizsmen, es tut mir leid - Requirement tracing und bug tracking. Ob DOORS, Jira, Exceltabelle,DB, zunächst mal scheißegal. Hauptsache es geht nix verloren. Wir arbeiten bei uns gerade an Automatismen, die die komplette Kette von der Anforderung bis zur Validierung mit möglichst wenig manuellen Eingriffen abbilden können, so dass am Schluss immer eine Art ToDo rausfällt, die dann regelmäßig nach Dringlichkeit, Aufwand, Risiko, Kosten etc. bewertet wird. So können wir uns gemeinsam jedes Mal überlegen, wann wie was umgesetzt werden soll, müssen aber nicht jede Kleinigkeit ausdiskutieren, spezifizieren, freigeben..., sondern können auch "einfach mal machen".

Das spart unglaublich viel ineffizientes blabla. Bisher hat sich noch kein Kunde darüber beschwert, dass er weniger für's Gleiche bezahlen muss.


Ich verstehe den Sinn, nach Möglichkeit an seinem Modell festzuhalten. Aber ich sehe viel mehr den Bedarf, in geeigneter Art davon abzuweichen, wenn es Situation X oder Y erfordert, solange die Eckpfeiler der Entwicklung dabei nicht umgestoßen werden. Komplett verbiegen wollen wir uns nicht, wenn dadurch das Risiko unkalkulierbar wird, aber Spielraum ist auf jeden Fall immer vorhanden.
Das ist mehr oder weniger die ganze Kunst und der Spagat.

[RMC]

Übertragen auf dich: Es wäre sehr wichtig die Frage zu beantworten, warum das bisher niemanden gestört hat.

Wir hatten ein kleines Gespräch über eben jene Frage. Das Team zeigte sich großteils reuig darüber, die Dinge oft aus Betriebsblindheit gar nicht mehr so wahrzunehmen und äußerten sich auch froh darüber, dass jemand mal frisch "von außen" einen Beitrag dazu liefert. Generell waren sie auch bereitwillig die Dinge gemeinsam anzugehen, was wir dann auch ausarbeiten werden. Natürlich gabs auch ein paar trotzige Stimmen dazwischen, aber damit hab ich auch gerechnet.

[Ectoplasma]

Wir hatten ein kleines Gespräch über eben jene Frage. Das Team zeigte sich großteils reuig darüber, die Dinge oft aus Betriebsblindheit gar nicht mehr so wahrzunehmen und äußerten sich auch froh darüber, dass jemand mal frisch "von außen" einen Beitrag dazu liefert. Generell waren sie auch bereitwillig die Dinge gemeinsam anzugehen, was wir dann auch ausarbeiten werden. Natürlich gabs auch ein paar trotzige Stimmen dazwischen, aber damit hab ich auch gerechnet.

Es ist doch so. Wenn der Drang eine Software aufzuräumen nicht aus einem selber kommt, ist oft fraglich, welche Qualität die Aufräumaktion hat. Das Aufräumen einer Software ist eine Aufgabe, die Konzentration und Sorgfalt erfordert. Es kann schnell passieren, dass etwas hinterher nicht mehr funktioniert.

[Monger]

Wir hatten ein kleines Gespräch über eben jene Frage. Das Team zeigte sich großteils reuig darüber, die Dinge oft aus Betriebsblindheit gar nicht mehr so wahrzunehmen und äußerten sich auch froh darüber, dass jemand mal frisch "von außen" einen Beitrag dazu liefert. Generell waren sie auch bereitwillig die Dinge gemeinsam anzugehen, was wir dann auch ausarbeiten werden. Natürlich gabs auch ein paar trotzige Stimmen dazwischen, aber damit hab ich auch gerechnet.
Das freut mich, aber was war denn die Antwort auf die Frage? Faulheit? Betriebsblindheit? Einfach nicht realisiert?

Halte ich ehrlich gesagt für wenig glaubwürdig. Ihr seid sicher alles kluge Köpfe, und du hast es garantiert nicht nur einmal erwähnt. So ein Refactoring sollte euch doch Arbeit sparen, und normalerweise sollten alle daran interessiert sein, Arbeit zu sparen.
Es gibt für jedes Verhalten normalerweise gute Gründe, und sei es nur um Stress ausm Weg zu gehen, weil man für Fehler nicht verantwortlich gemacht werden will, weil der Nutzen nicht unmittelbar erkennbar ist etc. pp. .
Viele Architekturfehlentscheidungen bei uns sind auf persönliche Konflikte zurückzuführen: Architekt A mag Architekt B nicht, deshalb vermeiden die es nach Möglichkeit, zusammenzuarbeiten. Sind oft triviale Gründe, aber wichtige.

Also: Toi toi toi dass sich jetzt was bessert, aber ohne die Ursachen zu kennen ist die Gefahr groß, dass die Anstrengungen im Sande verlaufen.

[Mosher]

Es gibt für jedes Verhalten normalerweise gute Gründe, und sei es nur um Stress ausm Weg zu gehen, weil man für Fehler nicht verantwortlich gemacht werden will, weil der Nutzen nicht unmittelbar erkennbar ist etc. pp. .
Viele Architekturfehlentscheidungen bei uns sind auf persönliche Konflikte zurückzuführen: Architekt A mag Architekt B nicht, deshalb vermeiden die es nach Möglichkeit, zusammenzuarbeiten. Sind oft triviale Gründe, aber wichtige.



Kenne ich auch oft so.

- Entwickler A will den Code von Entwickler B nicht anfassen, der wiederum ist aber nicht mehr greifbar.

- Der ausführende Entwickler fürchtet, dass das Aufräumen zu viel Zeit kostet und wenig prestigeträchtig ist, will lieber an was neuem arbeiten. Somit wird es immer weiter aufgeschoben.

- Der Entwickler hat Angst, dass er das vielleicht ungeliebte Projekt für ewig an der Backe hat, wenn er derjenige ist, der es jetzt von Grund auf neu aufbauen muss.

Ich kann alles sehr gut verstehen (=wichtige Gründe), aber die Arbeit muss halt getan werden. Wir setzen uns dann idR bei solchen Situationen mit den Entwicklern zusammen und erarbeiten einen Schlachtplan, mit dem jeder leben kann. zB eben, indem ihn darum bittet, für einen Zeitraum von X Wochen/Monaten 20% der Arbeitszeit dem Refactoring zu widmen. Oder einen Stichtag weit genug in der Zukunft definiert und ihm völlige Freiheit in der Zeiteinteilung lässt. Wichtig finde ich immer, dem Entwickler dafür auch irgendeine Art Ausgleich zu bieten, also zB das Zugeständnis, nach getaner Arbeit zunächst nicht mehr für solche ungeliebten Jobs eingesetzt zu werden.
Dann steigt idR auch die Bereitschaft.

[RMC]

Das freut mich, aber was war denn die Antwort auf die Frage? Faulheit? Betriebsblindheit? Einfach nicht realisiert?

Halte ich ehrlich gesagt für wenig glaubwürdig. Ihr seid sicher alles kluge Köpfe, und du hast es garantiert nicht nur einmal erwähnt. So ein Refactoring sollte euch doch Arbeit sparen, und normalerweise sollten alle daran interessiert sein, Arbeit zu sparen.
Es gibt für jedes Verhalten normalerweise gute Gründe, und sei es nur um Stress ausm Weg zu gehen, weil man für Fehler nicht verantwortlich gemacht werden will, weil der Nutzen nicht unmittelbar erkennbar ist etc. pp. .
Viele Architekturfehlentscheidungen bei uns sind auf persönliche Konflikte zurückzuführen: Architekt A mag Architekt B nicht, deshalb vermeiden die es nach Möglichkeit, zusammenzuarbeiten. Sind oft triviale Gründe, aber wichtige.

Also: Toi toi toi dass sich jetzt was bessert, aber ohne die Ursachen zu kennen ist die Gefahr groß, dass die Anstrengungen im Sande verlaufen.

Es gab natürlich keine direkte Antwort darauf, aber auf die Frage "warum hat das bisher keinen gestört?" kam wie gesagt der Erklärungsversuch der "Betriebsblindheit" zum Tragen.

Dann habe ich, auch schon öfters im Zusammenhang mit Architektur, Sätze vernommen wie zB "Das ist mit der Zeit so entstanden", "Wir haben uns damals für die Variante entschieden", "Wir haben Termindruck gehabt", etc.

Solche Phrasen sind leicht dahingedroschen und stufe ich als einfache Ausreden ein. Im professionellem Umfeld sollte jedem klar sein, dass man sich so nicht das Refactoring kleinreden kann, zumal es ja offensichtlich Vorteile mit sich bringt die Basis möglichst clean und aufgeräumt zu halten.

Das hab ich auch versucht klar zu machen und hab eigentlich fast ausschließlich positives Feedback geerntet.

[Mosher]

Es gab natürlich keine direkte Antwort darauf, aber auf die Frage "warum hat das bisher keinen gestört?" kam wie gesagt der Erklärungsversuch der "Betriebsblindheit" zum Tragen.

Dann habe ich, auch schon öfters im Zusammenhang mit Architektur, Sätze vernommen wie zB "Das ist mit der Zeit so entstanden", "Wir haben uns damals für die Variante entschieden", "Wir haben Termindruck gehabt", etc.

Solche Phrasen sind leicht dahingedroschen und stufe ich als einfache Ausreden ein. Im professionellem Umfeld sollte jedem klar sein, dass man sich so nicht das Refactoring kleinreden kann, zumal es ja offensichtlich Vorteile mit sich bringt die Basis möglichst clean und aufgeräumt zu halten.

Das hab ich auch versucht klar zu machen und hab eigentlich fast ausschließlich positives Feedback geerntet.
Ich weiß, was du meinst, aber auf Professionalität zu pochen, ist imho der falsche Weg.
Die meisten Menschen sind nicht gottgegeben professionell, sondern lernen das mehr oder weniger gut mit der Zeit.
Du kannst einem Entwickler noch so oft sagen, er soll Kritik an seiner Arbeit nicht persönlich nehmen, ganz wird er es wohl nie schaffen.

Und dann ist es Aufgabe der Teamleiter, auch die menschlichen Schwächen Eigenschaften mit zu Berücksichtigen und zu versuchen, das Team/einzelne Leute entsprechend ihrer Persönlichkeit auszusteuern.


Das was du als "Ausreden" bezeichnest, finde ich durchaus valide Gründe. Niemand will halt der Depp / der Schuldige sein, wenn es sonst keinen Anreiz gibt, diese ungeliebte Aufgabe zu erfüllen. Mit "verhaltet euch professionell" machst du es dir hier zu einfach imho. Und klar wird ein dir übergeordneter Chef jederzeit sagen, dass du Recht damit hast, irgendwas billiger/besser/schneller zu machen. Damit ist es aber halt nicht getan.
Du musst mit deinen Leuten arbeiten und zwar gezielt, du musst die Knöpfe finden, die man drücken kann, dann klappt das auch mit so wenig prestigeträchtigen Aufgaben.

Anders kann ein Team imho nicht funktionieren, so sehe und handhabe ich es zumindest.

[Ectoplasma]

Du kannst einem Entwickler noch so oft sagen, er soll Kritik an seiner Arbeit nicht persönlich nehmen, ganz wird er es wohl nie schaffen.


Vorsicht aber, es gibt Leute die meinen es mit der Zeit wirklich persönlich. Es kommt immer auf die Art und Weise an.

[Mosher]

Vorsicht aber, es gibt Leute die meinen es mit der Zeit wirklich persönlich. Es kommt immer auf die Art und Weise an.
Das ist wohl richtig und kommt leider auch vor. Wenn man anfängt, an jemandes Kompetenz zu zweifeln, ist die Grenze zwischen Arbeit und Person sowieso schon sehr weich.

[medi]

So ticken auch die meisten unserer Kunden, wobei ich mich nicht nur mit großem Widerwillen in einen Modus ohne Qualitätssicherung drücken lasse. Das fällt einem immer auf die Füße, also entweder wird einfach hart verhandelt, bis auch der ungeliebte "Overhead" bezahlt wird, oder man einigt sich auf Risikozuschläge, die auch solche Fälle abdecken, dass man irgendwann seinen Codemurks aufräumen muss, bevor es neue Features gibt.

Wie gesagt, 20 verschiedene Kunden, 100 verschiedene Projekte...

Industriekunden sind natürlich meistens anders. Die wissen meistens, dass Qualität halt kostet. Dafür sind die Projekte oft langweilig und staubtrocken :D

So läuft das bei uns leider nicht und wir haben eigentlich ausschließlich Industriekunden (GE, Siemens, BASF, Wacker, Westinghouse ...)
Bei uns läuft das meist folgendermaßen ab: Die Technik bei denen hat einen Wunsch und lässt sich von uns ein Angebot erstellen. Dazu müssen immer noch 2 weitere Angebote von Marktbegleiter eingeholt werden. Ab da entscheidet der Einkauf wer den Zuschlag bekommt. Wir hatten schon den Fall, dass wir um 30% im Preis gedrückt wurden, weil einer unserer Martkbegleiter einfach blödsinn angeboten hat, der null komma null der Anfrage entsprach aber der Einkauf letztendlich darauf bestand, dass wir den Preis drücken müssen weil zwar die Technik möchte, dass wir uns der Sache annehmen und unser Konzept am Besten ankam, aber bei so einer großen Preisdifferenz (wir waren 60% teurer) könne der Einkauf da nix machen...
Rückblickend wären wir nicht mehr auf so einen deal angegangen aber damals hatten wir keine Wahl und haben für den Auftrag gut bluten dürfen ... und gebracht hat es null da uns wenig später firmenpolitische Entscheidung komplett aus der Dienstleisterliste des Unternehmens gekickt haben.

[Mosher]

Sowas gibt's hier auch manchmal, aber meistens geht es unschmutzig zu. Wir sind zum Glück nicht so abhängig von solchen Kunden und ich lege schon auch einfach mal auf, wenn mich ein schmieriger Einkäufer verarschen will.

Was ich damit meinte, bei kleinen Kunden ist es eher die Geldnot, die sie um solche Posten wie Qualitätssicherung feilschen lässt, bei größeren halt Feilschen um des Feilschens Willen.
Ich bin da aber viel zu stur und gönne solchen Einkäufern schlicht ihren Erfolg nicht.
Ich kann wunderbar damit leben, dass wir manchen Zuschlag nicht bekommen, ich dafür aber auch meine Leute nicht knechten muss, um aberwitzigen Zusagen gerecht zu werden. Unsere Mitbewerber machen das auch nicht ewig mit.

[PHuV]

Das ist lobenswert, und, das wissen wir beide, auch an der falschen Stelle gespart. Ich/meine Firma haben auch schon einige Aufträge verloren, weil ich die Zeiten realistisch geschätzt hatte, und mal lieber sich jemand anders holte. Ich sage immer: Qualität kostet Zeit, und ich liefe lieber nix als schlechte Qualität.

@TS

Warum macht Ihr das eigentlich nicht komplett neu, sprich refactoring?

[RMC]

Ich weiß, was du meinst, aber auf Professionalität zu pochen, ist imho der falsche Weg.
Die meisten Menschen sind nicht gottgegeben professionell, sondern lernen das mehr oder weniger gut mit der Zeit.
Du kannst einem Entwickler noch so oft sagen, er soll Kritik an seiner Arbeit nicht persönlich nehmen, ganz wird er es wohl nie schaffen.


Ich gebe dir vollkommen recht. Ich bin ja selbst so einer. Darum würde ich auch nie jemanden persönlich wegen seiner Arbeit angreifen und ich drücke mich schon sehr vorsichtig aus bei diesen Dingen.


Das was du als "Ausreden" bezeichnest, finde ich durchaus valide Gründe. Niemand will halt der Depp / der Schuldige sein, wenn es sonst keinen Anreiz gibt, diese ungeliebte Aufgabe zu erfüllen. Mit "verhaltet euch professionell" machst du es dir hier zu einfach imho. Und klar wird ein dir übergeordneter Chef jederzeit sagen, dass du Recht damit hast, irgendwas billiger/besser/schneller zu machen.

Natürlich, das ist ein absolut valider Grund und das hab ich auch so kommuniziert. Ich sehe zu 100% ein, dass Zeitdruck, Legacy etc. alles sehr gute Gründe sind, warum der Code eben so aussieht.

Und gleichzeitig darf man darum aber erst recht nicht in Selbstmitleid versinken und mantraartig diese Gründe jedesmal im Reflex runterbeten. Das Muster wiederholt sich und hier kann man ansetzen. Man muss das als Chance sehen, es ab sofort mit Refactoring besser zu machen um dann in Zukunft gar nicht mehr diese Gründe anführen zu müssen.



Warum macht Ihr das eigentlich nicht komplett neu, sprich refactoring?


Komplett neu und Refactoring sind für mich zwei ganz verschiedene Dinge.
Zweiteres machen wir.

[Exxtreme]

@TS

Warum macht Ihr das eigentlich nicht komplett neu, sprich refactoring?
Refactoring funktioniert nur mit einer sehr guten Testabdeckung. Wenn man das nicht hat dann wird es u. U. eklig.

[Mosher]

Ich gebe dir vollkommen recht. Ich bin ja selbst so einer. Darum würde ich auch nie jemanden persönlich wegen seiner Arbeit angreifen und ich drücke mich schon sehr vorsichtig aus bei diesen Dingen.



Natürlich, das ist ein absolut valider Grund und das hab ich auch so kommuniziert. Ich sehe zu 100% ein, dass Zeitdruck, Legacy etc. alles sehr gute Gründe sind, warum der Code eben so aussieht.

Und gleichzeitig darf man darum aber erst recht nicht in Selbstmitleid versinken und mantraartig diese Gründe jedesmal im Reflex runterbeten. Das Muster wiederholt sich und hier kann man ansetzen. Man muss das als Chance sehen, es ab sofort mit Refactoring besser zu machen um dann in Zukunft gar nicht mehr diese Gründe anführen zu müssen.




Komplett neu und Refactoring sind für mich zwei ganz verschiedene Dinge.
Zweiteres machen wir.
Puh, freut mich, dass du das so siehst. Hatte ehrlich gesagt befürchtet, mich im Ton vergriffen zu haben, denn beim nochmaligen Durchlesen klang mein Zeug schärfer als beabsichtigt.

Auch wenn es wie ein Facebook-Nachdenkliche-Sprüche-Klischee klingt: Ein Problem ist ganz häufig eine getarnte Gelegenheit und entsprechend stimme ich deinem letzten Ansatz auch voll und ganz zu.

Aus Erfahrung weiß ich, dass viele gut gemeinte Ansätze trotzdem wieder irgendwo versanden und man wieder in einen schlampigeren Modus zurückfällt, doch genau deshalb muss man halt einfach immer wieder hinterhersein, bis irgendwann jeder ein paar mal entweder aus dem Fehler, oder dem Erfolg gelernt hat und da wären wir wieder bei den Charakteren. :)

[DR.ZEISSLER]

Oldversion.com :)

[][immy]

Meine Erfahrung mit Scrum etc ist eher, das ganze klappt nur mit kleinen Projekten oder Diensten.
Alles andere wird über die Zeit so komplex das du einfach keinen Überblick mehr darüber bekommst, selbst wenn du alles abtestest. Und spätestens wenn die Tests eine Ewigkeit dauern wird alles wieder langsamer.

Daher kann man eigentlich alles nur klein halten, am besten in kleinen Modulen (wenn möglich). Was auf der anderen Seite häufig zu eigenen Diensten führt die wiederum untereinander Kommunizieren müssen und daher alles extrem langsam wird.

Durch TDD und Scrum kannst du in einem Komplexen System nicht wirklich schneller entwickeln, sie sorgen nur dafür das du während der Entwicklung ein wenig mehr Struktur rein bekommst und der Aufwand steigt ja sogar. Dafür hast du aber hinterher mit weniger Bugs zu kämpfen und dadurch weniger support. Schneller macht es die Entwicklung definitiv nicht.

Und ganz ehrlich, mich stören die ganzen Meetings und Besprechungen die durch Scrum aufkommen ganz erheblich. Mit geht das ganze einfach auf den Keks. Gefühlt hat man dadurch mehr zu tun als vorher und am Ende kommt auch nichts anderes bei rum.
TDD ist da auch sehr zweischneidig. TDD kannst du schnell vergessen, wenn jemand dir Plötzlich druck macht und die Führung ist dann sowieso davon überzeugt das man Tests auch noch später schreiben könnte.
Auf der anderen Seite macht es gerade Node.js zu Pflicht tests zu schreiben, denn hier gibt es ja nicht mal compilerseitige Typsicherheit. Typescript hilft dann auch nur begrenzt weiter da es immer wieder stellen gibt, wo dann doch wieder mit "any" gearbeitet wird und es hält später niemanden davon ab doch die Komponente Zweckentfremdet zu verwenden. Ich kann da einfach nicht verstehen wieso sich JavaScript grad so extrem durchsetzt wo es doch alle Fehler der Vergangenheit wiederholt.

Es gab natürlich keine direkte Antwort darauf, aber auf die Frage "warum hat das bisher keinen gestört?" kam wie gesagt der Erklärungsversuch der "Betriebsblindheit" zum Tragen.

Dann habe ich, auch schon öfters im Zusammenhang mit Architektur, Sätze vernommen wie zB "Das ist mit der Zeit so entstanden", "Wir haben uns damals für die Variante entschieden", "Wir haben Termindruck gehabt", etc.

Solche Phrasen sind leicht dahingedroschen und stufe ich als einfache Ausreden ein. Im professionellem Umfeld sollte jedem klar sein, dass man sich so nicht das Refactoring kleinreden kann, zumal es ja offensichtlich Vorteile mit sich bringt die Basis möglichst clean und aufgeräumt zu halten.

Das hab ich auch versucht klar zu machen und hab eigentlich fast ausschließlich positives Feedback geerntet.
Ich wäre mal froh wenn ich für vernünftiges Refactoring Zeit hätte. Aber dafür wird nur Zeit eingeplant wenn es dann tatsächlich Probleme mit der Performance oder so gibt. Klar entsteht Code über die Zeit und ich kann keinen Codestand der über 10 Jahre gewachsen ist immer Refactoren. Das klappt einfach nicht. Man lernt halt mit der Zeit dazu. In dem Code wird zwar auch nichts mehr sein wie vor 10 Jahren, weil man es inzwischen überarbeitet hat, aber höchstens aufgrund von Kundentickets oder neuen Features die so nie vorgesehen waren.

[Demirug]

[immy;11671184']Ich kann da einfach nicht verstehen wieso sich JavaScript grad so extrem durchsetzt wo es doch alle Fehler der Vergangenheit wiederholt.

Weil jeder gerne ein Full Stack Entwickler sein will.

[Mosher]

Refactoring funktioniert nur mit einer sehr guten Testabdeckung. Wenn man das nicht hat dann wird es u. U. eklig.
Aktuelles Beispiel:

Irgendein uralt-Projekt von vor über 15 Jahren. Recht schlampige Doku und von den damaligen Beteiligten ist die Hälfte nicht mehr da (Tod und Renteneintritt sind die häufigsten Ursachen, nur um mal ein Gefühl zu bekommen).

Was aber sau gut war, war die Testspezifikation.

Jetzt wollte der damalige Kunde das Projekt wiederbeleben, modernisieren, erweitern und ist etwas blauäugig davon ausgegangen, dass man "einfach so" am alten Stand anknüpfen könnte.

Ich wollte jedenfalls nicht gleich das Gegenteil behaupten und habe die Jungs mal paar Tage analysieren und Aufwände schätzen lassen.
Dabei kam im Grunde (eigentlich sarkastisch gemeint) raus, dass man ein Fußballfeld bräuchte, um in akzeptabler Größe ein State-Diagramm der Hauptschleife zu erstellen, ohne das man keine Chance hätte, das Gesamtsystem zu verstehen.

Ende vom Lied: Ich habe es machen lassen. Am Schluss war's kein Fußballfeld, sondern eher was Richtung DIN A1. Altmodisch ausgedruckt und mit Stiften daran herumgeschmiert haben die Jungs es geschafft, den Code (bzw. erstmal das Design) auf ein Drittel einzukochen und auf ein Level zu bringen, mit dem man weiterarbeiten kann.

Was ich damit sagen will: Manchmal ist die Kopf-Wand-Taktik einfach die beste. Fleißarbeit lässt sich gut abschätzen und fördert fast immer positive Überraschungen zu Tage, lässt sich also dem Kunden gut verkaufen.

Und Dank guter Testspezifikation konnte der erfolgreiche Umbau sehr effizient verifiziert werden.

Im Gegensatz zur Hardware bin ich bei Softwareprojekten immer mehr ein Fach davon geworden, einfach mal radikal durchfegen zu lassen. (y)

(Man muss dazu sagen, dass ich mich hier hauptsächlich auf nicht-FuSi-embedded-Kram beziehe)

[maximAL]

[immy;11671184']Durch TDD und Scrum kannst du in einem Komplexen System nicht wirklich schneller entwickeln, sie sorgen nur dafür das du während der Entwicklung ein wenig mehr Struktur rein bekommst und der Aufwand steigt ja sogar. Dafür hast du aber hinterher mit weniger Bugs zu kämpfen und dadurch weniger support. Schneller macht es die Entwicklung definitiv nicht.
Nur, wenn der Kunde ein unfertiges Produkt abnimmt. Bei uns hat der selbst eine große Testabteilung und irgendwelche gröberen Fehler gehen da einfach nicht durch. Unsere Entwicklungsgeschwindigkeit hat jetzt zum Ende des Projekts soweit abgenommen, das wir fast gar keine Fortschritte mehr machen. Fast jeder Bugfix und jedes Feature reißt irgendwo anders wieder 3 Sachen ein, sodass das Projekt einfach nicht konvergiert.

[Exxtreme]

Nur, wenn der Kunde ein unfertiges Produkt abnimmt. Bei uns hat der selbst eine große Testabteilung und irgendwelche gröberen Fehler gehen da einfach nicht durch. Unsere Entwicklungsgeschwindigkeit hat jetzt zum Ende des Projekts soweit abgenommen, das wir fast gar keine Fortschritte mehr machen. Fast jeder Bugfix und jedes Feature reißt irgendwo anders wieder 3 Sachen ein, sodass das Projekt einfach nicht konvergiert.
Das nennt man Pareto-Prinzip. :D Die ersten 80% des Projektes erreicht man in den ersten 20% der Zeit.

[RMC]

Update:

Ich hatte in den letzten Monaten Zeit, einen kleinen, neueren Teil des Frameworks zu refactoren und diesen Teil so auf einen guten Weg gebracht. Das Feedback von den Kollegen war durchaus positiv und da dieser Zweig des Codes ständig wächst, sind wir froh hier früh angesetzt zu haben.

Zum Zweiten gab es strategische Überlegungen für die Zukunft Teile des Codes in einer neuen Sprache zu entwickeln. Zu dem Anlass habe ich auch Architektur-Änderungen eines Kernmoduls vorgeschlagen, ein Prototyp wird dann folgen.

Was mich freudig stimmt ist, dass mein Chef der Sache sehr Positiv gegenüber steht und das auch aktiv vorantreibt. Ich hoffe wir können hier ähnlich gute Fortschritte machen =)

[Monger]

Wenn der Vertrauensvorschuss endet, brauchst du halt was belastbares, um zu zeigen dass sich die Investition wirklich lohnt.
Ich saß deshalb die letzten Tage da und hab Powershell Skripte geschrieben, die die Quellverwaltung und unsere Work Items durchstöbern, um statistische Aussagen zu machen: Wie viele File Changes wurden von uns eingecheckt, wieviel von anderen, wie viele Work items arbeiten wir ab, wie viele davon sind mit hoher Priorität, wie hat sich das über die Monate hinweg verändert...

Klingt albern, aber übers Jahresmittel hinweg sieht man da eben doch gewisse Veränderungen.

[Mosher]

Wenn genug Volumen da ist und weiterhin da sein wird, ist Statistik immer DAS Mittel der Wahl.

Finde deshalb nicht, dass das albern klingt.

Wobei ich mich gerade frage, wieso ihr kein Ticketsystem benutzt, was euch all diese Statistiken von Haus aus ausspuckt.

Wir verwenden sowas zB immer gerne, um dem Kunden zu zeigen, wie die Effizienz durch bestimmte Maßnahmen langsam, aber stetig gesteigert werden konnte.

[maximAL]

Wir verwenden sowas zB immer gerne, um dem Kunden zu zeigen, wie die Effizienz durch bestimmte Maßnahmen langsam, aber stetig gesteigert werden konnte.
Unsere Kunde verlangt auch immer Maßnahmen, ob sie tatsächlich was gebracht haben ist dann erstmal egal. Wenns nicht läuft, müssen eben noch mehr Maßnahmen ergriffen werden. Und wenn das immer noch nicht reicht noch mehr...

[Mosher]

Unsere Kunde verlangt auch immer Maßnahmen, ob sie tatsächlich was gebracht haben ist dann erstmal egal. Wenns nicht läuft, müssen eben noch mehr Maßnahmen ergriffen werden. Und wenn das immer noch nicht reicht noch mehr...

Ich rede vom umgekehrten Fall, dass wir dem Kunden vorschlagen, den initial kostspieligen Prozess XY einzuführen, um künftig bessere Ergebnisse zu erzielen. Ohne transparente Möglichkeit, den Erfolg zu messen, wird sich da kaum jmd. drauf einlassen.

[Monger]

Wobei ich mich gerade frage, wieso ihr kein Ticketsystem benutzt, was euch all diese Statistiken von Haus aus ausspuckt.
Ganz kurz gesagt: weil zu viele unterschiedliche Projekte hier das selbe Ticket System nutzen und sich nicht auf gemeinsame Ansprüche einigen können.

Außerdem: wir nutzen TFS. Der Reporting Server ist echt unnötig kompliziert gehalten. Man kann sich Reports selber machen, aber es ist echt würg. Aber dafür ist die REST API so schön simpel, dass man sich sehr leicht alle Daten zusammenziehen kann.