Nein, ein Bug ist kein Feature!
Während des Sprint 5 Planning Meetings hat sich erneut herausgestellt, dass das Verständnis über die Frage was ein Bug ist und was ein Feature, zwischen Team und Product Owner stark abweicht.
Für den Product Owner ist alles ein Bug, was betriebsstörend ist - alles was er als Input von Dritten bekommt, ist ein Bug. Aha! Das ist so nicht richtig, obwohl dies aus Kundensicht durchaus richtig erscheinen mag. Dazu kommt die Tatsache, dass der Product Owner in der Vergangenheit gelernt hat, dass ein Bug mit "fix asap" immer gleich vom Team realisiert wird, während Features immer im Sprint geplant werden und daher länger brauchen, bis sie wirksam werden.
Ein Bug aus Sicht des Team ist, wenn etwas nicht so funktioniert, wie es implementiert sein sollte und dadurch Fehler/Fehlverhalten auftreten, z.B. "Wenn man die AGB's anklickt bekommt man eine Fehlerseite".
Kein Bug ist etwas, was wie gewünscht realisiert wurde, aber für Endbenutzer so nicht brauchbar ist (das sollte eigentlich nie vorkommen!), z.B. "Im Email wird der Name und Vorname nicht angezeigt". Wie auch, wurde so nie implementiert! Das ist nach der Defintion vom Team ein Change Request und damit wird es als User Story im kommenden Sprint geplant und priorisiert.
Eine nicht unwichtige Überlegung, die man in diesem Zusammenhang anstellen muss, ist das Release Management. Wenn das Team auf der Release Branch ein Feature realisiert, der als Bug gekennzeichnet ist, hat das teure Konsequenzen. Auf dem Release entwickelte Dinge müssen in den Trunk gemerged werden. Dieser ist aber nach der Release Freigabe bereits fortgeschritten und die Code Basis hat sich unter Umständen bereits markant verändert. Der Merge vom Release Branch in den Trunk kann sehr teuer werden. Wenn dann noch eine Datenbankänderung dazu kommt, ist die Auslieferung des kommenden Releases vom Trunk aus sehr aufwendig.
Keine Kommentare:
Kommentar veröffentlichen