Das beste Feature aus Quake 3 (strafe jumping) war original Mal ein Bug. Wurde aber drin gelassen, weil man das als coole Spielmechanik identifiziert hat. 😎
Also Anforderungen sollten keine Fehlerquelle sein. Wenn die Anforderungen unklar sind, muss man dafür sorgen, dass diese klar werden. Alles andere ist imho unprofessionell.
Genau das ist der Punkt. Und wenn's eine Fehlerquelle ist, muss das geändert werden. Hatte mal ein Projekt, das da wirklich hervor stach - im negativen Sinne. Wir haben konzernweit Daten über Hard- und Software, Konfigurationen, Routen, LBs, etc zusammen gesammelt und nach SPoFs gesucht, unter den Abteilungen abgeglichen, dem Ticketsystem zur Verfügung gestellt, um z.B. Impacts von Änderungen zu dokumentieren, VMs nach Rechenzentrum vorzuschlagen, sowas. Anforderungstickets (nach Gedächtnis, aber ungekürzt): "Schnittstelle für xy einbinden." Keine Spec, keine Details, keine Planung, wie das ins Datenmodell passen soll, wie das weiter verarbeitet wird, wie Inkonsistenzen behandelt werden sollen, etc. In der Regel nicht mal eine genaue Datenquelle, manchmal keine exakten Bezeichner für die Quelle. Also xy = "VMs". Von den Vmware-Leuten? Von Ops? Netzwerk? Waren teils redundante Daten, teils unvollständig, deshalb haben wir ja alles integriert. War aber der einzige anscheinend, der damit ein Problem hatte. "Wenn das nicht klar ist, dann frag halt nach." - "Für jedes Ticket? Lasst uns das doch einfach mit rein schreiben." - "Also mir ist das klar." - "Mir nicht wenn ich nach zwei Monaten endlich dazu komme und den neuen Entwicklern bestimmt auch nicht." - "Was soll denn dann da mit rein deiner Meinung nach?" - "Ansprechpartner, Dokumentationen, Beispieldaten, Modelle, ... vielleicht zumindest eine Definition der Felder. (Waren meist Excel-Dateien als CSV exportiert. Eine arme Socke in den Abteilungen hat das dann von Hand wöchentlich exportiert und hochgeladen. Tippfehler inklusive.) Definition of Done, ..." - "Dann werden das ja Riesentickets!" - "Wohl definierte würde ich sagen." Führte dann auch zu Duplikaten natürlich. Manche einfach erkennbar, manche gewollt (weil Daten aus mehreren Quellen kommen sollten), manche weil die Schnittstelle schon existierte, aber einfach im Betrieb nicht benutzt wurde. °oO( Wäre schön, wenn wir das-und-das abladen könnten. ) => Ticket. TL;DR: ja, sollte nicht sein. Wenn doch: Ursache beheben. (Plus längliches Rumgeheule. Sorry dafür.)
Da habe ich komplett andere Erfahrungen, ich denke die falschen oder ungenauen Anforderungen sind mit abstand das Top-Problem :) Und JA, vollkommen richtig - dafür muss man sorgen, genau darum geht es ja u.a. hier. Gruß David
Mal Klartext aus 24 Jahren Entwicklung: Anforderungen sind IMMER unklar und undurchdacht. Bin jetzt bei der 9then Firma. Es gibt keine perfektes Umfeld
@@peters3710 Das stimmt. Ich habe zwar noch nicht soviel Erfahrung, arbeite aber nun schon seit fast 10 Jahren im selben Betrieb und habe einige Kundenprojekte im Alleingang gestemmt. Da gab es auch oft schwammige Formulierungen. Dann habe ich meinen Ansprechpartner beim Aufzraggeber per Mail oder Telefon kontaktiert und habe die Anforderung so weit verbessert, bis es mir klar war, wohin die Reise gehen sollte. Das Projekt ist erfolgreich im tagtäglichen Einsatz und der Kunde äußerst zufrieden.
Mit wie vielen Bugs Pro Team & Zeiteinheit ist der Kunde denn gestartet? Habt ihr das wirklich mit allen Bugs gemacht? Warum ich frage: Ich kenne Umgebungen da sind es einfach 5 bis 10 Bugs alle zwei Wochen. Hängt auch damit zusammen, dass manchmal Bugs reinkommen die internen Testern aufgefallen sind, in die kein Endanwender je reinlaufen würde. Sowas wie "Wenn ich jetzt hier drücke, sofort schließe, in einer Stunde zurück komme und dann die Zeitzone gewechselt habe, dann stimmt die Hintergrundfarbe nicht mehr" (ich übertreibe offensichtlich) Nimmt man sich dann eher einfach alle Bugs und kategorisiert die durch? Macht man eine Triage und sagt "Wir fangen mal mit Bug X und Y an. Zum Rest kommen wir später."?
Hey, +3/-3 waren es zu Beginn, also 3 kamen im Schnitt pro Sprint (3 Wochen dazu), 3 wurden gefixt, kenne auch viele Situationen wo es mehr sind, die Frage ist dann halt warum. Das kategorisieren machst Du ja eh erst später in der Retro, wenn Sie "bearbeitet" wurden... Gruß David
Macht mal einen Test: Eine Tasse Kaffee mit Keks kostet 1,10€. Der Kaffee kostet 1 € mehr. Was kostet der Keks? Die Anzahl der fehlerhaften Antworten (10 ct) ist immer wieder erschreckend. Das die Ursache wohl durch die 'Lernfähigkeit' unseres Gehirns verursacht wird, gibt mir immer wieder denken.
Ok. Fehler verstanden. Es geht darum, die Aufgabenstellung GENAU und KOMPLETT zu lesen und den Text der Formulierung genau zu zerlegen. DANN fällt das Wort M E H R auf. Wenn man dies überließt fällt man in die Grube, welche der PO/Marketing/Vertrieb einem Geschaufelt hat. Der härteste Gegner hat immer den gleichen Arbeitgeber wie man selbst.
"Don't make me think" Es sollte aber vielleicht eher darum gehen, die Aufgabenstellung so anzupassen, dass die nicht wie so oft schon zu einem Rätselraten und einer Interpretation des Geschriebenen verkommt. Wenn die Akzeptanzkriterien nicht klar und einfach beschrieben werden werden können, ist die Aufgabe meist zu groß geschnitten oder zu unklar spezifiziert.
@@carsten_Das wäre die konsequente Lösung des Problems. Fehler vermeiden, statt sich für die Lösung vermeidbarer Fehler feiern zu lassen. Eine klare Definition aller Kriterien vermeidet unnötige Iterationen.
@@carsten_ und jetzt die Frage: How to stop thinking? Ich muss für mich eingestehen, der Fehler ist immer da. Man kann viel Energie ins Requirements Engineering stecken. Am Ende kommt doch die missverstanden Spezifikation. 737max oder Challenger Unglück.
Also hatte bis jetzt keine Bugs die in Stunden auf gelöst werden können. Sind meist Wochen haben aber halt auch keine Debugging option außer halt logs.
@@alxk3995 also ich verstehe einen richtigen bug als einnen problematischen fehler wie dass in einer variable encoding fehler existieren (wie auch immer das passiert) also dass deswegen die ausführung verhindert wird oder dass statt einem komma ein punkt genutzt wird (statt 1 euro... 1.000 euro) ein glitch ist ein witziger nicht problematischer bug.... also dass in zb einem gui zbencoding fehler zu sehen sind obwohl die variable keine hat.... solche glitsches sind witzig und machen an sich keinen schaden
Gliches hängen oft mit Spielphysik zusammen und sind nicht immer auf Fehler im Code zurückzuführen, sondern eher ein Zeichen, dass man an den Grenzen der Gamephysik keine Sperre eingebaut hat. Also eher das „fehlen von Code“, und nicht so sehr „Fehler im Code“. Aber Spielern ist diese Spitzfindigkeit egal, wenn sie auf der Treppe durch den Boden fallen…
Verstehe die Message, aber: Analyse der Grundursache kann nicht Teil des Postmortems sein. Es ist wichtig und sinnvoll über gefundene Probleme zu sprechen, gerade wenn das größere Änderungen in Prozessen, Architektur usw bedeutet. Die Analyse kommt aber davor, bevor der Bug gefixed wird und bevor es ein dazugehöriges Deployment gibt. Ein Fix soll im Normalfall keine Symptome bekämpfen, sondern die Ursache beheben. Eine Quick/Hackfix kann ik Einzelfall zwar der Entscheid sein, aber dieser wird gefällt auf Basis einer genauen Analyse (wie kritisch, großes Refactoring notwendig usw). Debugging ist die Analyse der Ursache. Hier habe ich auch die Erfahrung gemacht, dass dieser Prozess, aus welchen Gründen auch immer, oft als "wir stellen Mutmaßungen an und unterdrücken das Symptom" interpretiert wird. Das allerdings ist ausdrücklich professionelles Vorgehen.
Es geht bei dem hier beschriebenen Vorgehen um mögliche übergeordnete Probleme, bzw. Verbesserungsmöglichkeiten, die weder mit der Architektur noch dem Code zwingend zu tun haben müssen. Debugging alleine kann eben nicht diese Probleme erkennen. Darum war wohl die Firma von Davids Vorgehen so begeistert, weil er darüber hinaus geht und uns andere Probleme oder Lösungsmöglichkeiten sehen lässt. Ein Bug ist erst so nicht nur lästig, sondern auch eine Chance gezielt als gesamtes besser zu werden. Hier noch meinen Dank für die Videos an David!
Wenn es keine Anforderung verletzt, ist es kein Bug. In einer idealen Welt sollte es auch quantifizierte Anforderungen an die Performance geben. Ohne die entscheidet ja letztendlich Willkür darüber, welche Performance so gerade noch okay, ergo kein Bug oder nicht mehr akzeptabel, also doch ein Bug ist.
@@sauerland_fellaWenn ich wesentlich langsamer als die Konkurrenz seit, habt ihr wahrscheinlich kein sauberen Code. Sollte immer ein Grund den Code zu reviewen. Und auf KISS zu achten.
man lernt mehr, man kann das Feature nochmal oder teurer verkaufen. Also nur gut für den Dienstleister, nicht den Abnehmer🤣 bei In House Software dann nur gut fürs eigene Know-How , nicht fürs Budget 🤪
wer hat denn zeit dafür sich das nochmal anzuschauen? Man ist froh wenn man den bug gefixt bekommt und dabei nichts anderes umfällt. PO bekommt nen Anfall wenn wir noch zeit dafür aufwenden wollten.
Kommt nat. immer auf die konkrete Situation an. Teamgröße, wie wartungsfreundlich ist die Software, Budget, Motivation des Teams,... Aber überhaupt keinen Aufwand in KVP stecken hört sich falsch an. So gibt man sich ja gar keine Chance Dinge langfristig zu verbessern.
![Scrum - Von A bis Z [Mit Profi-Tipps]](/img/1.gif)
99 bugs in the code,
99 bugs.
Take one down, patch it around,
127 bugs in the code.
Thats it :)
Aufstehen & hinfallen würde ich sagen David :)
Nur wer liegen bleibt wird es nicht schaffen
Krone richten nicht vergessen 😊
Das wollte ich gerade auch schreibe... :D
Die Gaming-Industrie liest nur den Titel und freut sich 🤣🤣
Aus Bugs kann man Features machen^^
Das beste Feature aus Quake 3 (strafe jumping) war original Mal ein Bug. Wurde aber drin gelassen, weil man das als coole Spielmechanik identifiziert hat. 😎
Neues Feld in der Jira-Ticket-Vorlage wurde erstellt: „Schuld ist“ 😂
😂
Wichtig ist eine gute Fehlerkultur zu schaffen.
this
Also Anforderungen sollten keine Fehlerquelle sein. Wenn die Anforderungen unklar sind, muss man dafür sorgen, dass diese klar werden. Alles andere ist imho unprofessionell.
Genau das ist der Punkt. Und wenn's eine Fehlerquelle ist, muss das geändert werden.
Hatte mal ein Projekt, das da wirklich hervor stach - im negativen Sinne. Wir haben konzernweit Daten über Hard- und Software, Konfigurationen, Routen, LBs, etc zusammen gesammelt und nach SPoFs gesucht, unter den Abteilungen abgeglichen, dem Ticketsystem zur Verfügung gestellt, um z.B. Impacts von Änderungen zu dokumentieren, VMs nach Rechenzentrum vorzuschlagen, sowas.
Anforderungstickets (nach Gedächtnis, aber ungekürzt): "Schnittstelle für xy einbinden."
Keine Spec, keine Details, keine Planung, wie das ins Datenmodell passen soll, wie das weiter verarbeitet wird, wie Inkonsistenzen behandelt werden sollen, etc. In der Regel nicht mal eine genaue Datenquelle, manchmal keine exakten Bezeichner für die Quelle. Also xy = "VMs". Von den Vmware-Leuten? Von Ops? Netzwerk? Waren teils redundante Daten, teils unvollständig, deshalb haben wir ja alles integriert.
War aber der einzige anscheinend, der damit ein Problem hatte. "Wenn das nicht klar ist, dann frag halt nach." - "Für jedes Ticket? Lasst uns das doch einfach mit rein schreiben." - "Also mir ist das klar." - "Mir nicht wenn ich nach zwei Monaten endlich dazu komme und den neuen Entwicklern bestimmt auch nicht." - "Was soll denn dann da mit rein deiner Meinung nach?" - "Ansprechpartner, Dokumentationen, Beispieldaten, Modelle, ... vielleicht zumindest eine Definition der Felder. (Waren meist Excel-Dateien als CSV exportiert. Eine arme Socke in den Abteilungen hat das dann von Hand wöchentlich exportiert und hochgeladen. Tippfehler inklusive.) Definition of Done, ..." - "Dann werden das ja Riesentickets!" - "Wohl definierte würde ich sagen."
Führte dann auch zu Duplikaten natürlich. Manche einfach erkennbar, manche gewollt (weil Daten aus mehreren Quellen kommen sollten), manche weil die Schnittstelle schon existierte, aber einfach im Betrieb nicht benutzt wurde. °oO( Wäre schön, wenn wir das-und-das abladen könnten. ) => Ticket.
TL;DR: ja, sollte nicht sein. Wenn doch: Ursache beheben. (Plus längliches Rumgeheule. Sorry dafür.)
Da habe ich komplett andere Erfahrungen, ich denke die falschen oder ungenauen Anforderungen sind mit abstand das Top-Problem :) Und JA, vollkommen richtig - dafür muss man sorgen, genau darum geht es ja u.a. hier.
Gruß David
Dann ist es aber kein Bug, sondern ein Feature wenn die falschen Anforderungen umgesetzt worden sind.
Mal Klartext aus 24 Jahren Entwicklung: Anforderungen sind IMMER unklar und undurchdacht. Bin jetzt bei der 9then Firma. Es gibt keine perfektes Umfeld
@@peters3710 Das stimmt.
Ich habe zwar noch nicht soviel Erfahrung, arbeite aber nun schon seit fast 10 Jahren im selben Betrieb und habe einige Kundenprojekte im Alleingang gestemmt.
Da gab es auch oft schwammige Formulierungen.
Dann habe ich meinen Ansprechpartner beim Aufzraggeber per Mail oder Telefon kontaktiert und habe die Anforderung so weit verbessert, bis es mir klar war, wohin die Reise gehen sollte.
Das Projekt ist erfolgreich im tagtäglichen Einsatz und der Kunde äußerst zufrieden.
Mit wie vielen Bugs Pro Team & Zeiteinheit ist der Kunde denn gestartet? Habt ihr das wirklich mit allen Bugs gemacht?
Warum ich frage: Ich kenne Umgebungen da sind es einfach 5 bis 10 Bugs alle zwei Wochen. Hängt auch damit zusammen, dass manchmal Bugs reinkommen die internen Testern aufgefallen sind, in die kein Endanwender je reinlaufen würde. Sowas wie "Wenn ich jetzt hier drücke, sofort schließe, in einer Stunde zurück komme und dann die Zeitzone gewechselt habe, dann stimmt die Hintergrundfarbe nicht mehr" (ich übertreibe offensichtlich)
Nimmt man sich dann eher einfach alle Bugs und kategorisiert die durch? Macht man eine Triage und sagt "Wir fangen mal mit Bug X und Y an. Zum Rest kommen wir später."?
Hey,
+3/-3 waren es zu Beginn, also 3 kamen im Schnitt pro Sprint (3 Wochen dazu), 3 wurden gefixt, kenne auch viele Situationen wo es mehr sind, die Frage ist dann halt warum.
Das kategorisieren machst Du ja eh erst später in der Retro, wenn Sie "bearbeitet" wurden...
Gruß David
den Bug-Report schreib ich morgen in unser Ticketsystem, mal sehen wer reagiert 😂
It‘s not a bug… it‘s a feature!
Jaja, kennen wir alle!
Gruß David
Macht mal einen Test: Eine Tasse Kaffee mit Keks kostet 1,10€. Der Kaffee kostet 1 € mehr. Was kostet der Keks?
Die Anzahl der fehlerhaften Antworten (10 ct) ist immer wieder erschreckend. Das die Ursache wohl durch die 'Lernfähigkeit' unseres Gehirns verursacht wird, gibt mir immer wieder denken.
5ct ^^ Frag den Admin 😂😂
Ok. Fehler verstanden. Es geht darum, die Aufgabenstellung GENAU und KOMPLETT zu lesen und den Text der Formulierung genau zu zerlegen. DANN fällt das Wort M E H R auf. Wenn man dies überließt fällt man in die Grube, welche der PO/Marketing/Vertrieb einem Geschaufelt hat. Der härteste Gegner hat immer den gleichen Arbeitgeber wie man selbst.
"Don't make me think"
Es sollte aber vielleicht eher darum gehen, die Aufgabenstellung so anzupassen, dass die nicht wie so oft schon zu einem Rätselraten und einer Interpretation des Geschriebenen verkommt. Wenn die Akzeptanzkriterien nicht klar und einfach beschrieben werden werden können, ist die Aufgabe meist zu groß geschnitten oder zu unklar spezifiziert.
@@carsten_Das wäre die konsequente Lösung des Problems. Fehler vermeiden, statt sich für die Lösung vermeidbarer Fehler feiern zu lassen. Eine klare Definition aller Kriterien vermeidet unnötige Iterationen.
@@carsten_ und jetzt die Frage: How to stop thinking? Ich muss für mich eingestehen, der Fehler ist immer da. Man kann viel Energie ins Requirements Engineering stecken. Am Ende kommt doch die missverstanden Spezifikation. 737max oder Challenger Unglück.
Also hatte bis jetzt keine Bugs die in Stunden auf gelöst werden können. Sind meist Wochen haben aber halt auch keine Debugging option außer halt logs.
mal eine frage....
denkst du David es gibt einen unterschied zwichen bugs und glitches?
Glitch ist eig. nur ein speziellerer Begriff für Bug in einem Videospiel.
@@alxk3995 also ich verstehe einen richtigen bug als einnen problematischen fehler
wie dass in einer variable encoding fehler existieren (wie auch immer das passiert)
also dass deswegen die ausführung verhindert wird oder dass statt einem komma ein punkt genutzt wird (statt 1 euro... 1.000 euro)
ein glitch ist ein witziger nicht problematischer bug....
also dass in zb einem gui zbencoding fehler zu sehen sind obwohl die variable keine hat....
solche glitsches sind witzig und machen an sich keinen schaden
Gliches hängen oft mit Spielphysik zusammen und sind nicht immer auf Fehler im Code zurückzuführen, sondern eher ein Zeichen, dass man an den Grenzen der Gamephysik keine Sperre eingebaut hat.
Also eher das „fehlen von Code“, und nicht so sehr „Fehler im Code“.
Aber Spielern ist diese Spitzfindigkeit egal, wenn sie auf der Treppe durch den Boden fallen…
Verstehe die Message, aber: Analyse der Grundursache kann nicht Teil des Postmortems sein. Es ist wichtig und sinnvoll über gefundene Probleme zu sprechen, gerade wenn das größere Änderungen in Prozessen, Architektur usw bedeutet. Die Analyse kommt aber davor, bevor der Bug gefixed wird und bevor es ein dazugehöriges Deployment gibt. Ein Fix soll im Normalfall keine Symptome bekämpfen, sondern die Ursache beheben. Eine Quick/Hackfix kann ik Einzelfall zwar der Entscheid sein, aber dieser wird gefällt auf Basis einer genauen Analyse (wie kritisch, großes Refactoring notwendig usw). Debugging ist die Analyse der Ursache. Hier habe ich auch die Erfahrung gemacht, dass dieser Prozess, aus welchen Gründen auch immer, oft als "wir stellen Mutmaßungen an und unterdrücken das Symptom" interpretiert wird. Das allerdings ist ausdrücklich professionelles Vorgehen.
Es geht bei dem hier beschriebenen Vorgehen um mögliche übergeordnete Probleme, bzw. Verbesserungsmöglichkeiten, die weder mit der Architektur noch dem Code zwingend zu tun haben müssen. Debugging alleine kann eben nicht diese Probleme erkennen.
Darum war wohl die Firma von Davids Vorgehen so begeistert, weil er darüber hinaus geht und uns andere Probleme oder Lösungsmöglichkeiten sehen lässt. Ein Bug ist erst so nicht nur lästig, sondern auch eine Chance gezielt als gesamtes besser zu werden. Hier noch meinen Dank für die Videos an David!
megageiler Thumbnail :D
Endlich würdigt es mal jemand :D
Chuck Norris' Software ist bug-frei. Immer.
Bitte die Hintergrundmusik im Intro etwas leiser machen. Wenn man selbst noch Geräusche um sicher herum hat, ist deine Stimme nur schwer zu verstehen
Frage: Sollte man Performance Probleme als Bugs einstufen?
Wenn es keine Anforderung verletzt, ist es kein Bug. In einer idealen Welt sollte es auch quantifizierte Anforderungen an die Performance geben. Ohne die entscheidet ja letztendlich Willkür darüber, welche Performance so gerade noch okay, ergo kein Bug oder nicht mehr akzeptabel, also doch ein Bug ist.
@@sauerland_fellaWenn ich wesentlich langsamer als die Konkurrenz seit, habt ihr wahrscheinlich kein sauberen Code.
Sollte immer ein Grund den Code zu reviewen. Und auf KISS zu achten.
man lernt mehr, man kann das Feature nochmal oder teurer verkaufen. Also nur gut für den Dienstleister, nicht den Abnehmer🤣 bei In House Software dann nur gut fürs eigene Know-How , nicht fürs Budget 🤪
Hey,
die Aussage habe ich so in der Tat schon in einem Projekt bekommen... :D Kann also nur bedingt darüber lachen... ;)
Gruß David
@@DavidTielke 😄🤫
👍👍
wer hat denn zeit dafür sich das nochmal anzuschauen? Man ist froh wenn man den bug gefixt bekommt und dabei nichts anderes umfällt. PO bekommt nen Anfall wenn wir noch zeit dafür aufwenden wollten.
Kommt nat. immer auf die konkrete Situation an. Teamgröße, wie wartungsfreundlich ist die Software, Budget, Motivation des Teams,...
Aber überhaupt keinen Aufwand in KVP stecken hört sich falsch an. So gibt man sich ja gar keine Chance Dinge langfristig zu verbessern.
Bucks.
Right
Make bucks from bugs.
JIRA zu nutzen ist schon der erste Bug…