Dieses Material wurde von unserem Partner Equio vorbereitet .
Beim Kauf eines IT-Produkts zur Lösung verschiedener Unternehmensprobleme denken Geschäftskunden häufig über Kosten, Funktionalität, Komfort, Integrationsmöglichkeiten usw. nach. Dies sind keine so offensichtlichen Probleme wie die Qualität und das Niveau des technischen Supports, sie denken bereits an zweiter Stelle.
Die Qualität des Endprodukts hängt jedoch in hohem Maße davon ab, wie der Entwickler den Prozess des Testens, Identifizierens und Behebens von Fehlern organisiert hat, die unter Entwicklern als "Bugs" bekannt sind (vom englischen Bug - ein Bug, ein beliebiges Insekt, ein Virus oder ein umgangssprachliches Wort, das normalerweise einen Fehler bedeutet) im Programm). Diese Frage wird von sehr wenigen einzelnen Geschäftskunden gestellt.
Wir möchten Ihnen erzählen, wie Entwickler Fehler identifizieren und beheben, die sich zum Testen eignen. Ein Ansatz basiert auf der Zero Bug Policy.
Spoiler! Wir werden Ihnen sagen, wofür die Entwickler tatsächlich Zeit aufwenden und warum sie nicht alle Fehler beheben. 
Sieben Kindermädchen
Es gibt einen bekannten Witz über die Ankündigung der neuen Version "Optimierte Anwendungsleistung, Fehlerkorrekturen, neue hinzugefügt". In der Tat ist das Beheben und Hinzufügen neuer Fehler ein ewiger Prozess, alte Fehler werden behoben, aber nicht weniger neue treten auf.
Dies macht sich insbesondere dann bemerkbar, wenn eine große Anzahl von Entwicklern oder sogar mehrere Projektteams an einem Softwareprodukt auf einer einzigen Codebasis arbeiten. Es ist sehr schwierig, ihre Bemühungen zu synchronisieren und den vollständig fehlerfreien Code für die Ausgabe zu erhalten. Beispielsweise hat ein Team die Änderungen im Hauptzweig, dh in der Hauptversion des Codes, im Repository (Repository) gespeichert. Das andere Team ist wiederum mit einer Vielzahl von Konflikten konfrontiert und versucht, diese zu beheben. Dies alles geht in die Veröffentlichung, das heißt in die endgültige Version des Produkts, die für normale Benutzer geeignet ist, und hier taucht eine unglaubliche Menge von Fehlern auf. Dies ist mit Geld- und Kundenverlusten behaftet und gefährdet vor allem den Ruf des Entwicklers.
Was tun in dieser Situation? Sie können all Ihre Kräfte und Ressourcen einsetzen, um Fehler zu beheben. Wie können Sie sich dann an der Produktentwicklung beteiligen, vorhandene verbessern und neue Funktionen hinzufügen?
Aus den Augen, Rückstand
Ein großes IT-Unternehmen hatte gerade ein ähnliches Problem. Dank der Empfehlung eines der Spezialisten, die im Unternehmen tätig waren, wurde beschlossen, den
Zero Bug Policy- Ansatz anzuwenden. Über ihn ist leider noch wenig in russischer Sprache geschrieben worden.
Sein Wesen ist wie folgt. Wenn Tester oder Benutzer einen Fehler im Produkt finden und die Entwickler darüber informieren, entscheidet letztere, ob dieser Fehler behoben wird oder die Leistung des Produkts nicht beeinträchtigt wird. Daher kann seine Korrektur verzögert oder vollständig ausgeschlossen werden aus Rückstand (Aufgabenliste). Diesem Fehler wird der Status "Nicht repariert" zugewiesen, wonach er für immer aus dem Blickfeld der Entwickler verschwindet. In einigen Fällen werden Fehler mit diesem Status ganz am Ende des Backlogs platziert. Dies bedeutet, dass die Entwickler nur dann „in die Hände bekommen“, wenn alle anderen Aufgaben gelöst sind.
Zurück zum bereits erwähnten IT-Unternehmen. Die Mitarbeiter analysierten die gesamte Liste der entdeckten Fehler und sortierten die gefundenen Probleme. Fast die Hälfte der Fehler sollte in naher Zukunft behoben werden, und mehr als die Hälfte erhielt den Status "Won't Fix". All diese Arbeiten dauerten ungefähr zwei Monate. Danach beschloss das Unternehmen, die
Null-Fehler-Richtlinie fortlaufend zu übernehmen. Bisher hat dieses Unternehmen nicht mehr als 10 offene Aufgaben im Rückstand. So können Sie sich auf die Implementierung neuer Funktionen konzentrieren.
Bug-Experten
Wie werden Bugs sortiert? Wer trifft die Entscheidung, dass ein Fehler kritisch ist und behoben werden muss, und auf der anderen Seite können Sie weiterhin in Frieden leben oder die Korrektur auf einen späteren Zeitpunkt verschieben?
Wir zeigen Ihnen, wie dieser Prozess mit dem Konzept des flexiblen Projektmanagements (Agile) organisiert ist. Jeder weiß, dass Agile mehrere Techniken beinhaltet. Wir werden eines davon als Beispiel nehmen, nämlich SCRUM, da es in der Welt der Softwareentwicklung am häufigsten verwendet wird.
Der Product Owner oder Scrum Product Owner ist eines der wichtigsten Mitglieder des Projektteams. Er ist es, der die Interessen der Endverbraucher vertritt und alles unternimmt, um den Wert des Produkts zu maximieren. Er ist auch von Anfang bis Ende für den Produktbestand verantwortlich. Das gesamte Entwicklungsteam ist am Sortieren von Fehlern beteiligt, aber das letzte Wort ist immer für den Product Owner. Hiermit wird festgelegt, welcher Fehler behoben wird und welcher als "Nicht behoben" markiert ist.
In der Tat ist alles Geld. Wenn beispielsweise die Behebung eines Fehlers keine finanzielle Rendite für das Unternehmen bedeutet, aber gleichzeitig viel Zeit und Ressourcen in Anspruch nimmt, ist es besser, einem solchen Fehler den Status "Nicht repariert" zuzuweisen und die Behebung auf bessere Zeiten zu verschieben. In der Tat ist der "Eigentümer des Produkts" für die Priorisierung und den Status der gefundenen Fehler verantwortlich.
Mit anderen Worten, jeder hat „Skelette im Schrank“. Wenn sie sich jedoch nicht auf die Leistung des Produkts auswirken, die Benutzeraktionen nicht behindern oder den Integrationsprozess behindern, können sie vollständig ignoriert werden.
Auswahlkriterien
Solche "kleinen" Fehler sind in den Produkten eines Entwicklers enthalten.
In der Administrationsoberfläche des Content-Management-Systems ist es beispielsweise nicht möglich, einen zu langen Titel für einen Abschnitt, Artikel usw. einzugeben. Die Entwickler beschließen, diesen Fehler nicht zu beheben. Schließlich kostet die Korrektur Zeit und Ressourcen, und Sie können den Namen einfach nehmen und auf eine bestimmte Anzahl von Zeichen reduzieren. Es reicht aus, den Benutzer lediglich zu warnen, dass Namen mit mehr als 30 Zeichen nicht unterstützt werden.
Die Schaltfläche ist ein wenig in der falschen Farbe, die Oberflächenelemente befinden sich zwei Pixel links von dem, was benötigt wird. All dies sind Fehler, die weder die Benutzerfreundlichkeit noch die Leistung der Anwendung beeinträchtigen. Daher können sie möglicherweise Won't Fix zugeordnet werden.
Kritische Fehler sind in erster Linie solche, die von vielen Kunden behoben werden, die dazu führen oder führen können, dass Kunden aufgrund von Fehlern in Programmierern Geld verlieren. All dies definiert den Product Owner, der verpflichtet ist, das Produkt wie seine Westentasche zu kennen und nicht nur seine Funktionalität zu verstehen, sondern auch zu verstehen, wie Geschäftskunden es verwenden, welche Anwendungsszenarien in einem bestimmten Unternehmen existieren.
Kollektiver Verstand
Die Null-Fehler-Richtlinie ist häufig mit einem Service Level Agreement (SLA) verbunden. In der Regel verfügen Entwickler über mehrere technische Supportanfragen.
Der erste empfängt eine Fehlermeldung vom Benutzer, sammelt alle für die Reproduktion und Analyse erforderlichen Daten und überträgt dann alle diese Informationen in die zweite Zeile. Die Spezialisten der zweiten Zeile reproduzieren diesen Fehler auf Workstations oder Servern, auf denen dieselbe Produktversion wie der Benutzer installiert ist. Wenn der Fehler reproduziert wird, wie der Benutzer behauptet, fallen Informationen darüber in den aktiven Sprint, dh eine Liste von Aufgaben für Entwickler.
Der erste und der zweite technische Support sowie die Entwickler verfügen über SLAs. Je kritischer der Fehler ist, desto strenger sind die SLA-Standards für die Fehlerbehebung. Es gibt auch eine allgemeine SLA für die Fehlerbehebung: vom Kundenkontakt bis zum Erhalt des korrigierten Codes in der Produktion. Die Entscheidung, ob Won't Fix einen Bug-Status zugewiesen wird oder nicht, trifft der technische Support in der zweiten Zeile. Ihr Urteil ist jedoch nicht endgültig. Die Mitarbeiter orientieren sich zunächst an den Grundsätzen und Regeln des aktuellen Sprints. Darüber hinaus gibt es eine Reihe von Erwartungen von Entwicklern, Kunden und der Abteilung für Geschäftsentwicklung.
Wenn sich unter Berücksichtigung all dieser Faktoren eine kontroverse Situation ergibt, steht das letzte Wort genau hinter der zweiten Supportlinie und natürlich dem Product Owner.
Zufrieden bedeutet produktiv
Warum braucht ein Entwicklungsunternehmen das alles? Ein Grund ist die erhöhte Motivation der Entwickler. Das Beheben von Fehlern ist eine routinemäßige und unangenehme Aufgabe, die nicht jeder gerne erledigt. Das Implementieren neuer Funktionen ist viel interessanter als das Beheben der Fehler Ihrer Kollegen. Dies erhöht die Produktivität und Produktivität. Auf diese Weise kann man ohne Qualitätseinbußen ernsthaft die Wartung der Tester einsparen und statt einer ganzen Abteilung ein oder zwei Spezialisten im Unternehmen lassen.
Warum brauchen Anwender und Geschäftskunden das? Das Geschäft entwickelt sich, es sieht sich ständig neuen Herausforderungen gegenüber, die mithilfe von IT-Produkten angegangen werden müssen. Und wenn Entwickler die meiste Zeit damit verbringen, unwesentliche Fehler zu beseitigen, anstatt die Funktionalität ihrer Kreationen zu verbessern, besteht die Gefahr, dass sie weit hinter den Wettbewerbern zurückbleiben. Das Geschäft wird diejenigen auswählen, die sich weiterentwickeln, während die Qualitätslatte auf einem hohen Niveau bleibt.
Das ist alles. Weitere Informationen über die
Firma "Equio" finden Sie auf ihrer offiziellen Website.
Auf
der Otus-Website können Sie sich mit unseren Kursen vertraut machen und an den
kostenlosen Webinaren teilnehmen, die Sie interessieren.