Optimierung Kunden-Feedback - Entwicklung

[openWB]

Da sind wir beim nachhalten das zu optimieren.
Punkte kommen ins Meeting und werden besprochen.
Das Feedback muss es dann auch zurück schaffen.

[aiole]

Im Ernst - ne komplexe SW hat ein höheres Bug-Risiko, was durch intensives Testing und Prüfprocedere reduziert wird. Oben verlinkt, gibt es eine Diskussion, wie das optimiert werden kann.

Ich glaub da haben wir andere Wahrnehmungen: Es geht in der verlinkten Diskussion nicht um Test- und Prüfprozedere sondern darum wie landet Feedback strukturiert bei der Entwicklung. Und der Eindruck der eben entsteht, dass eben keinerlei Tests und Prüfungen überhaupt stattfinden, wie können sonst so Basisfunktionalitäten wie Phasenumschaltung auf einmal nicht mehr funktionieren? Das ist der große Kritikpunkt.

Läuft bei mir gesamtheitlich unter Qualitätsmanagement. Also die Aufbereitung der Kunden-Themen zur Nutzung in der Entwicklung, welche dort natürlich auch die Prüfprozeduren erweitert.

Es kommt leider nur wenig feedback aus den alpha- und beta-Versionen. Die meisten sagen "Da warte ich besser bis zum release." Konsequenz - ergänzende praxisnahe Tests bleiben außen vor und die Qualität ist nicht so hoch wie sie real sein könnte.

Auch hier wieder andere Wahrnehmung - und der Grund warum wir diskutieren - es kommt Feedback, aber der wird eben selten auch bearbeitet. Und du bestätigst auch indirekt, was viele vermuten: Es gibt gar keine Tests, sondern es wird halt Bugfixing gemacht ohne Teststruktur und man ist auf Feedback angewiesen um Bugs und Fehler zu finden. Das dann die Qualität leidet ist völlig klar.

Keine Tests? Keine Teststruktur? - Wenn dem so wäre, dürfte wohl großes Chaos herrschen. Nein, da bist du auf dem Holzweg.
Dass die Tests verbessert werden können, steht dagegen außer Frage. Deshalb gibt's ja auch diese Diskussion.

[Elchkopp]

Es kommt leider nur wenig feedback aus den alpha- und beta-Versionen. Die meisten sagen "Da warte ich besser bis zum release." Konsequenz - ergänzende praxisnahe Tests bleiben außen vor und die Qualität ist nicht so hoch wie sie real sein könnte.

Ist nur eine Vermutung, aber das könnte indirekt ein Resultat aus der „Gesamtsituation“ sein und führt dann natürlich zu einem Teufelskreis:

Durch fehlerhafte Releases sind viele vermutlich eher abgeschreckt, auf eine Master oder Beta zu gehen, wenn (oder auch weil) man Angst haben muss, dass grundsätzliche Sachen auf einmal auch nicht mehr laufen, anstatt sich - so mein Verständnis von Alpha und Beta - auf die neuen Funktionen/Erweiterungen zu konzentrieren. Es ist ein Unterschied, ob ich das bewusste Risiko eingehe, dass nur eine neue Funktion nicht läuft (möchte aber helfen, sie zu testen, brauche sie aber eigentlich nicht) oder ich eben das Risiko habe, dass selbst die einfachste Funktion (Phasenumschaltung) (wieder) nicht läuft. Nicht jeder hat Zeit, Lust und/oder Know-how, ein Zweitsystem nur zum testen zu unterhalten. Somit ist nunmal die Produktivumgebungen gleichzeitig auch (heimische) Testumgebung.

Und dann wird man ja auch nicht müde zu erwähnen oder anzumahnen, dass Master/Beta eben nicht für Produktivumgebungen eingesetzt werden sollten.

Aber gleichzeitig soll ich bei angesprochenen Fehlern auf Master gehen, um zu testen. Also MUSS ich also Ottonormalanwender (im openWB-Sinne) ja mit meiner Produktivumgebung auf die Testschiene wechseln (Gründe siehe oben). Mit dem genannten Risiko. Also was denn nun?

Ich finde, das schreckt auch ab - und widerspricht sich auch grundlegend.

Und so führt das eine zum anderen.

Das ist ein Grund, warum ich aktuell mit anderer Software steuere. Ich hatte seit dem Wechsel noch nicht einmal ein grundlegendes Problem mit der Steuerung. Die Software mitsamt Pro läuft einfach. Und das, obwohl fast wöchentlich Updates eintrudeln.

[seaspotter]

Läuft bei mir gesamtheitlich unter Qualitätsmanagement. Also die Aufbereitung der Kunden-Themen zur Nutzung in der Entwicklung, welche dort natürlich auch die Prüfprozeduren erweitert.
Keine Tests? Keine Teststruktur? - Wenn dem so wäre, dürfte wohl großes Chaos herrschen. Nein, da bist du auf dem Holzweg.
Dass die Tests verbessert werden können, steht dagegen außer Frage. Deshalb gibt's ja auch diese Diskussion.

Sorry für die direkten Worte: Aber ganz viel heiße Luft, wenig konkrete Antworten und auf Fragen nicht antworten. So bringt eine Diskussion in der du dich beteiligst wirklich gar nichts. Da diskutiere ich mit dir auch nicht weiter.
Offizielle Antworten seitens openWB gibts nur von Kevin oder den Entwicklern.

[aiole]

Da diskutiere ich mit dir auch nicht weiter.

Na, ob das zielführend ist, da habe ich so meine Zweifel. Wenn gegenseitiger Respekt abhanden kommt, fehlt die Basis und es wird für das eigentliche Ziel sicher nicht besser. Sieht man ja auch im "Großen" . Die Art der Kommunikation spielt eine gewichtige Rolle - auch in einem echten Fachforum.

[seaspotter]

Na, ob das zielführend ist, da habe ich so meine Zweifel. Wenn gegenseitiger Respekt abhanden kommt, fehlt die Basis und es wird für das eigentliche Ziel sicher nicht besser. Sieht man ja auch im "Großen" . Die Art der Kommunikation spielt eine gewichtige Rolle - auch in einem echten Fachforum.

Kannst ja mal in dich gehen wie das mit der Transparenz und der Kommunikation und so aussieht, ob das so wirklich zielführend ist.

[therobbot]

Ich denke, es würde eine Menge helfen, wenn mal konsequent Bugs in der Release Version gefixt würden.

Bin ich bei dir. Am besten alle .
Im Ernst - ne komplexe SW hat ein höheres Bug-Risiko, was durch intensives Testing und Prüfprocedere reduziert wird. Oben verlinkt, gibt es eine Diskussion, wie das optimiert werden kann.

ps
Es kommt leider nur wenig feedback aus den alpha- und beta-Versionen. Die meisten sagen "Da warte ich besser bis zum release." Konsequenz - ergänzende praxisnahe Tests bleiben außen vor und die Qualität ist nicht so hoch wie sie real sein könnte.

Ich bin nicht ganz sicher, ob mein Anliegen wirklich deutlich geworden ist. Aus meiner Sicht sollte viel aktiver bei einer Release Version Bugfixing betrieben werden, bis die Bugs wirklich gefixt sind. Es sollte eigentlich nie vorkommen müssen, dass ein Bug in einer Release Version (zb in 2.1.9) dann nur in 2.2.0 gefixt wird. Man sollte nicht gezwungen werden, aufgrund von Bugs auf die nächste Release Version gehen zu müssen. Genau das ist mir aber halt erst kürzlich passiert. Ich erwarte eigentlich, dass ich auf eine neue Release Version nur gehen muss, wenn ich neue Features will und dass echte Bugs auch auf vergangenen Releases gefixt werden.

[openWB]

Im regulären Zyklus würde backporten auch wieder aufwand verursachen.
Ich werfe mal eine LTS Variante in dem Raum.
Aber da ist dann auch die Frage, was ist Bug und was ist Feature?
Gerade auch im Hinblick auf die aktive Speichersteuerung gibt es durchaus manchmal Anpassungsbedarf aufgrund von Speicher Updates.

[Andi03]

Hallo in die Runde. Ich würd auch vorschlagen, gerade im Bereich Mieterstrom, Lastmanagement, HEMS und Gewerblich betriebenen LP's wäre eine LTS Version, die Stabil läuft und keine bekannten Fehler hat sehr praktisch. Vielleicht schaut man sich jetzt die 2.2.0 an und macht hier aus einer eventuellen Patch 2 Variante dann eine LTS? Also würde da mal an sich mal 4-6 Monate warten und ne stabile LTS daraus machen und diese dann 1-2 Jahre unterstützten ( natürlich ohne neue Features, die es in neuere Versionen schaffen). Nur als Idee. Gerade aus der Sicht eines Anwenders (die es zu Haufe gibt) welche nur Plug und Play nach erstmaliger Einrichtung das System nutzen wollen, ist eine LTS Version praktisch. So hat man dann zumindest 1-2 Jahre Zeit bis man sich mit einem Update und den Neuerungen ( auch auf bedienebene) auseinander setzen muss.

[aiole]

Eine LTS-Version würde dem zuletzt stark gewachsenen Bedarf an WEG- und Ladepark-Installationen entgegen kommen. Das gab's früher nicht in der Anzahl.