Klassifizierung: Bug oder change request

[Tr3x]

Hi,

als Software-Dienstleister haben wir für unsere eigene Platform auch einen Zugang für unsere Kunden.

Nun bekommen wir natürlich Anfragen von Kunden über das Verhalten der Platform und entsprechend hier immer alles als "bug" Klassifiziert. Oft sind viele dieser "Bugs" keine Bugs odern zum Teil schlecht definierte Anforderungen oder User Fehler. Unabhängig davon hat die Fehleingabe eines User auch nach hinten heraus Auswirkungen auf die Platform. Zum beispiel das gewisse Funktionen nicht mehr ausgeführt werden können (Exporte).

Mich würde hier interessieren wie Ihr aus der Praxis Folgepunkte klassifiziert bzw trennt. Gibt es hier Erfahrung oder sogar Lektüre?

 

[Merle]

ITIL? Service Request (Auftrag, Anfrage), Incident (Störung, Fehler, kann auch ein Bug sein), Change Requests/Changes für Standardänderungen (definierte Prozesse), Move (Service/HW umziehen, kann auch im Change abgebildet sein, je nach Prozess und Vereinbarung), Add (neue SW/HW, kann auch im Change abgebildet sein, je nach Prozess und Vereinbarung), Disposal (SW/HW kündigen, kann auch im Change...blabla).
ITIL ist eine Funktionsbibliothek an Begriffen, die man am Ende auf die eigenen Anforderungen strickt und gewisse best practices vorschlägt.
Habt ihr keine Ticketsystem?

*edit: Das war übrigens nur ein sehr kleiner Teil, den man aus ITIL machen/mitnehmen kann. Da gehört mehr dazu. Man MUSS das nicht alles machen, und geht auch kaum im kleinen Umfeld. Die nötigen Teile/sinnvollen Teile muss man selbst festlegen. Das geht auch nicht wirklich nebenbei. Die Dinge oben sind Dinge, mit denen ich beim Arbeitgeber als IT Betrieb konfrontiert bin. Das ist nicht absolut.

 

[Amplifier]

Habt ihr keine Test Instanz in der die Funktionen vor Live gang getestet werden?

Meine Definition
eines Bugs/Defects/Abweichung/Fehler:
Das Verhalten der Software entspricht nicht den Anforderungen.

eines Change Request:
Das Verhalten der Software entspricht den vorher definierten und abgenommenen Anforderung. Diese sollen aber nachträglich geändert werden.

Wie kann es passieren das der Endanwender eure Software benutzt und durch Fehleingaben massiv folgeprozesse gestört werden?
Normalerweise sollte sowas doch direkt im Frontend abgefangen werden. Sowas deckt man ja eigentlich durch einen vorherigen Test ab.

Habt ihr keinen Defectmanager der diese Request ggf. umklassifiziert und an die Entwickler oder Analysten weiter gibt? Vom Endanwender würde ich jetzt nicht erwarten das er mehr als einen Bug kennt.

Wie sieht grob euer Prozess aus, von der Anforderungskonzeption bis zum Livegang?

Ich kenn das grob so:
Anforderungsdefinition -> Entwicklung -> Test -> Livegang

Pauschal würde bei mir alles was nicht den Anforderungen entspricht ein Bug sein. Wenn Folgeprozesse dadurch schief laufen auch. Entweder unter dem selben Defect, oder als neuer Defect mit bezug zu den vorhergehenden.

 

[Madman1209]

Hi,

"Bug" - Fehler - eure Schuld
"User Fehler" - von euch nicht behandelter Fehler - eure Schuld
"Change Request" - Kunde möchte jetzt doch etwas anders, als es in der Spec stand oder eine erweiterte Funktion - Schuld des Kunden

Abgesehen davon: wieso definiert bei euch der Kunde, was ein Bug und was ein CR ist? Reichlich seltsam.

Und: Beiträg über mir, treffen den Nagel auf den Kopf!

VG,
Mad

 

[neofelis]

Der Auftraggeber sagt es ist ein Bug. Der Auftragnehmer sagt es ist kein Bug, sondern ein Feature.

Was ein Bug und was ein Feature ist, wird immer ausgehandelt, denn Anforderungen werden doch eigentlich nie ausreichend beschrieben, so dass es im Verlauf eines Projektes darüber keinen Streit gibt.

Bei Fehlern wird im allgemeinen mindestens zwischen folgenden Kategorien unterschieden:

• betriebsverhindernd (z.B. Programmabsturz)
• betriebsbehindernd (z.B. einzelne Funktionen gehen nicht)
• kosmetisch (z.B. Buttons oder Labels zu groß / zu klein)

Ob ein Fehler in die eine oder andere Kategorie fällt, ist aber oftmals wirklich Verhandlungssache.

Edit: Aktuelle Standard-Literatur zu dem Thema würde micht aber auch interessieren.
Vielleicht hat jemand dazu doch noch Tipps.

Ergänzung (5. Juni 2019)

...
Abgesehen davon: wieso definiert bei euch der Kunde, was ein Bug und was ein CR ist? Reichlich seltsam.
...

Wieso seltsam? Der AN wird schon quieken, wenn ihm die Einsortierung in die gewählte Kategorie durch den AG nicht passt.
Dann wird wieder fröhlich verhandelt. Der Projektmanager muss ja für irgendwas sein Geld bekommen.

 

[Femigaming]

Deswegen gibt es Pflichten und Lastenhefte, Kundenabnahmen, SLA Verträge, etc. Um genau zu Differenzieren was ist ein Feature,Bug,Change Request, Service Request, etc. Wie oben schon erwähnt ITIL kann man heranziehen aber auch div. ISOS heranziehen https://de.wikipedia.org/wiki/ISO/IEC_9126 bzw https://de.wikipedia.org/wiki/ISO/IEC-27000-Reihe

 

[PHuV]

Der Auftraggeber sagt es ist ein Bug. Der Auftragnehmer sagt es ist kein Bug, sondern ein Feature.

Was ein Bug und was ein Feature ist, wird immer ausgehandelt, denn Anforderungen werden doch eigentlich nie ausreichend beschrieben, so dass es im Verlauf eines Projektes darüber keinen Streit gibt.
:
Ob ein Fehler in die eine oder andere Kategorie fällt, ist aber oftmals wirklich Verhandlungssache.

Wenn es eine klare Beschreibung und Dokumentation gibt, was die Software können soll oder was Standardfeatures sind (z.B. Menübedienung usw.), dann gibt es sehr wohl anhand dessen eine klare Definition, was ein Fehler ist. Wenn jemand das erst beim Auftreten des Problems "definieren" will, hat IMHO schon vorher etwas falsch gemacht.

 

[Merle]

Leider erlebe ich sehr oft, dass die „Anforderungen leben“ und sich im Projekt verändern. Das ist aber jedes einzelne Mal, wenn es nicht von der Fachkraft im Betrieb durch Kenntnis oder Mehrleistung abgefangen wird, eine Katastrophe. Oft verzögern sich große Infrastrukturprojekte dadurch um Quartale oder sogar Jahre. Der AN will das ja am Ende vergütet wissen.
Darum Lasten- und Pflichtenheft. Wichtig!!! Sonst verschenkt ihr Kohle am Ende. Oder wenigstens detaillierte, schriftliche Anforderungen oder einen exakten Vertrag. Dann passiert das wenigstens nicht unvergütet.
Ansonsten sind hier viele Anregungen.
Eure Betriebsgröße und Kundenzahl (grob) wäre noch interessant.
Wenn ihr 2-3 Leute seid ist das alles evtl oversized. Aber dann muss man dieselben Anliegen eben anders abfangen. Und der exakt vereinbart und dokumentiert-Teil ist non-optional.

 

[Tr3x]

Hi,

schon jede menge interessantes Zeug dabei

Wir haben durchaus JIRA im Einsatz bei der die Kunden die Möglichkeiten haben das Ticket als Bug, CR, Frage, Vorschläge einbringen können. Wie oft wird gern einfach der Bug für jedes Ticket verwendet, weshalb hier im einzelen geprüft werden muss ob es tatsächlich ein Bug ist oder nicht. Oft führt ein Fehler an einer Stelle zu einem Rattenschwanz.

An sich verwenden wir auch Spezifikationen und legen diese offen. In dem kürzlichen Vofall bei uns wurde die Datenanbindung bzw. der Export bei dem Kunden geschrottet weshalb wir nicht mehr versorgt worden sind und als Schwanz die Daten nicht verarbeiten und beispielsweise im Web auch nicht mehr ausgegeben haben.

Das ist oft schwer hier einen erstmal vermeintlichen Fehler richtig einzustufen. Meißt heißts wer fixt hats verbockt. Aber das wäre hier interessant wo die Schwelle zwischen Bug und CR wäre, weshalb ich hier einfach gern die Erfahrung bzw. Prüfmechanismen aus der Praxis anderer interessiert das ich ggfs übernehmen kann.

 

[Maviapril2]

Um es kurz zu machen...
Bug: etwas ist kaputt/fehlerhaft
CR: etwas (funktionierendes) soll geaendert werden

 

[Merle]

Ich kann morgen mal im JIRA von einem meiner Dienstleister schauen, wie die das haben. Fängt dein AG mit Pl.... an? 😅

 

[Madman1209]

Hi,

Wieso seltsam? Der AN wird schon quieken, wenn ihm die Einsortierung in die gewählte Kategorie durch den AG nicht passt.

wenn es für den TE so einfach wäre gäbe es ja vermutlich diesen Thread nicht.

Bei uns ist es - und so kenne ich es in vielen Firmen - so, dass das Kundenfeedback generell erstmal als "Issue" aufläuft, quasi eine "unklassifizierte Kundenrückmeldung".
Klassifiziert wird dann nicht vom Kunden, sondern je nach Art und Gestaltung des Projekts von einem PO, Projektleiter oder einer anderen Person, die die genauen Vorgaben und vertraglichen Absprachen kennt.

Von daher: ja, ich finde die Klassifizierung rein durch den Kunden seltsam.

VG,
Mad

 

[Amplifier]

Erläuter mal Bitte eure Abläufe und wie viel leute ihr seit. Habt ihr Anforderungsdokumente oder User Storys anhand derer ihr die Software umsetzt? Gibt es Sinnvollen intepretationsspielraum?
Ich habe schon Projekte Erlebt in denen man Stur nach User Story umgesetzt hat, auch wenn man da bereits Verbesserungen entdeckt hat. Diese Wurden dann nachträglich als CR Umgesetzt anstatt es gleich vernünftig zu machen... Dann kann man denke ich bessere mpfehlungen geben.

Jira kann man sich ja so anpassen wie man es haben möchte. Cherwell könnte man genauso benutzen. Gibt da sicher noch zich andere....

Es muss klar Definiert sein was welche Kategorisierung im Jira bedeutet damit der Kunde das korrekt ausfüllen kann. Prüfen ob die Klassifizierung korrekt ist muss dann sowieso ein "Experte" oder der der das Ticket bearbeitet. Hier auch nochmal die Frage. Wie läuft das ab? Bekommt beim Bug der Entwickler das Ticket und beim CR der Projektmanager?

Usere Kunden sind die "Fachbereiche" im Unternehmen. Diese nutzen die Software als Arbeitsmittel. Die Wissen wie man was Klassifiziert. Bei uns kommt sowas z.B. recht selten vor.

Auch hier nochmal die Frage. Wie läuft eure Entwicklung? War das Beispiel von dir ein "krasser" Sonderfall den keine hätte erahnen können? Für mich klingt das nach einem Versagen im bereicht Test und Entwicklung.
Oder Aber eure Anforderungen sind schlecht...

Das mit dem "Wer fixt hats verbockt" Stimmt sicher in den meißten fällen. In deinem Beispiel hats der verbockt der die fehleingabe ermöglicht hat. Das die Exporte dann nciht klappen ist ja ein Logischer Folgefehler. Auch hier gäbe es sicher Mechanismen um sowas abzufangen oder ein Alerting einzubauen damit man wenigstens gleich eine Meldung bekommt wenn was nicht klappt.

Die Sache mit dem Issue von Madman1209 ist auch nicht schlecht. So muss man dem kunden nix beibringen :-) Deine Klassifizierungsbeispiele sind ja aber auch nicht so schwer zu verstehen für einen Normal denkenden Menschen ^^

 

[Tr3x]

Hey,

ja vll ungünstig ausgedrückt. Über das JIRA Portal haben die Kunden die Möglichkeit ein Ticket in einer der Kategorien unter anderem Bug, Frage und CR anzulegen. In der ersten Runde gehen unsere supportler ran und prüfen inwiefern die Kategorie richtig ist, welche Informationen fehlen und leiten diese entsprechend an die Abteilung and die PMs weiter. Also eine reine Klassifizierung von Kunden haben wir somit nicht. Erst bei der Umsetzung geht es an die Entwickler und am Ende über zwei Testphasen (Entwickler, PM/Kunden) auf Live.

Bei neuen Features oder Projekten werden erstmal Anforderungen gemeinsam mit dem Kunden erstellt und abgesegnet Von Kunden natürlich ob Ihre Wünsche erfüllt werden auf unserer Seite sofern technisch machbar und ob das auch Hand und Fuß hat.

In meinem Beispiel ist das schon eher ein krasser Fehler. Bisher lief das Jahrelang ohne Probleme erst durch diesen Vorfall deren Dienstleister kam das überhaupt auf. Natürlich müsste das auch von unserer Seite auch irgendwie abgefangen werden zumindest überwacht. Das wäre durchaus ein improvment bei uns. Ohne die Krux wäre das vermutlich nie aufgekommen. Natürlich hängt da vieles zusammen und durch die Zeit ist das auch kein zwei Zeiler. Daher gibt es auch bestimmt später wieder Tickets die bei uns aufkommen und historisch bedingt vll wieder die Frage aufwirft Fehler oder CR. Die interessante Frage für mich ist wie ist hier die beste Vorgehensweise ein etwas komplexeres Problem die Punkte einzeln richtig zu zerlegen und zu klassifizieren. So ein Rattenschwanz wird so auch nicht komplett umgesetzt das der letzte Part auch Fehler vom aller ersten Part/Prozess abfängt sondern eher den vor und nach ihm