{"id":650,"date":"2016-06-08T11:17:37","date_gmt":"2016-06-08T09:17:37","guid":{"rendered":"http:\/\/usersnap.com\/de\/blog\/?p=650"},"modified":"2016-08-09T17:30:57","modified_gmt":"2016-08-09T15:30:57","slug":"defect-management-basics","status":"publish","type":"post","link":"https:\/\/usersnap.com\/de\/blog\/defect-management-basics\/","title":{"rendered":"Bugs priorisieren: So geht’s!"},"content":{"rendered":"

Bug Tracking ist ein Thema, das von Anfang an in den Software Entwicklungs-Workflow eingebettet ist. Oder zumindest sein sollte. Ein effizientes Zeitmanagement ist hier oft der Schl\u00fcssel zum Erfolg. Man denke an all die Bug Reports, \u00c4nderungsw\u00fcnsche und Ideen.<\/p>\n

Schnell tritt hier die Frage der Priorisierung auf. Wie\u00a0kann ich die auftretenden Bugs priorisieren?<\/p>\n

<\/p>\n

Defect Management Prozesse<\/h2>\n

Ich will an dieser Stelle nicht zu sehr ins Detail gehen, aber um die Frage nach der Priorisierung von Bugs zu verstehen, lohnt es sich die Basics von Defect Management zu erkl\u00e4ren.<\/p>\n

Defect Management<\/strong><\/em> besteht aus folgenden Schritten:<\/p>\n

    \n
  1. Bugs finden<\/li>\n
  2. Bugs dokumentieren<\/li>\n
  3. Bugs reproduzieren<\/li>\n
  4. Bugs beheben<\/li>\n<\/ol>\n

    \"bugs<\/p>\n

    Klingt einfach, oder?<\/p>\n

    Eine der ersten Fragen ist: Ok, aber wie und wann priorisiere ich meine Bugs?<\/p>\n

    \"bugs<\/p>\n

    Bugs vs Feature Requests<\/h2>\n

    Wenn man sich \u00fcberlegt, wie man Bugs priorisieren kann, muss man sich auch \u00fcberlegen, wie man Bugs im Gegensatz zu Feature Requests handhaben will.<\/p>\n

    \"bugs<\/p>\n

    Balance ist hier ganz entscheidend. Und um Bugs zu balancieren, lohnt es sich, einen Blick auf das Konzept von technischer Schuld zu werfen.<\/p>\n

    Was ist technische Schuld? <\/b><\/p>\n

    Technische Schuld (auch als “Technische Schulden<\/em>” bekannt) ist, \u201cist eine in der Informatik<\/a> gebr\u00e4uchliche Metapher f\u00fcr die m\u00f6glichen Konsequenzen schlechter technischer Umsetzung von Software. Unter der technischen Schuld versteht man den zus\u00e4tzlichen Aufwand, den man f\u00fcr \u00c4nderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.\u201d<\/p>\n

    Technische Schuld bildet sich nat\u00fcrlich mit der Zeit. Bugs treten auf, wenn man versucht Abk\u00fcrzungen bei der Entwicklung zu nehmen. Anstatt die bestm\u00f6gliche L\u00f6sung zu verwenden, nimmt man eine Abk\u00fcrzung.<\/p>\n

    Was sollten Sie tun?<\/h2>\n

    Wenn man sich mit der Balance von Bugs vs. Feature Requests besch\u00e4ftigt, ist es wichtig sich die \u00fcbergeordneten Business-Ziele ins Ged\u00e4chtnis zu rufen. Das sollte helfen, Bugs und Feature Request in einem ersten Schritt zu priorisieren.<\/p>\n

    \"bugs<\/p>\n

    Wenn Ihr Erfolg als Entwickler f\u00fcr ein Unternehmen entscheidend ist, dass kann das bedeuten, dass die Behebung eines Bugs Vorrang hat und zuerst erledigt werden muss, bevor Sie an neuen Features arbeiten k\u00f6nnen.<\/p>\n

    Wie k\u00f6nnen Sie Bugs also priorisieren?<\/h2>\n

    Wie k\u00f6nnen Sie Bugs also nun priorisieren? Im folgenden geben wir Ihnen einen Einblick, wie wir das Thema bei Usersnap handhaben.<\/p>\n

    Schritt 1: Sammeln Sie Informationen (Bugs & Feature Requests) \u00a0<\/i><\/b><\/p>\n

    Je mehr Informationen Sie haben, desto bessere Entscheidungen k\u00f6nnen Sie treffen, wenn es darum geht, welche Bugs und Feature Requests dringend sind.<\/p>\n

    Sammeln Sie alle Bugs an einem Ort. Ein Issue Management Tool<\/a> oder ein einfaches Spreadsheet kann Ihnen dabei helfen. Bei Unsicherheiten sprechen Sie mit Ihren Kunden, Website-Besuchern, Kollegen und fragen Sie diese nach deren Bed\u00fcrfnissen.<\/p>\n

    Der erste Schritt klingt ziemlich einfach, es ist aber der Schritt, der die meiste Zeit braucht. Sie m\u00fcssen hier Antworten auf ganz vielf\u00e4ltige Fragen finden. Wenn Sie Bugs sammeln, denken Sie an die folgenden Fragen:<\/p>\n