Kategorisieren Sie Aufgaben / Fehler nach dem Risiko von Änderungen

Das Projekt, an dem ich gerade arbeite, hat ein Problem: Bugs und Aufgaben werden oft Leuten zugewiesen, die zu neu oder zu unerfahren sind, und ihre Arbeit führt später zu mehr Bugs. Das Problem ist, dass Teile unserer Software aufgrund von Problemen mit der Codequalität viel "gefährlicher" zu bearbeiten sind als andere. Ich habe versucht, dieses Problem zu bekämpfen, indem ich das mit Aufgaben verbundene Risiko abgeschätzt und genau darauf geachtet habe, welchen Entwicklern welche Aufgaben zugewiesen werden.

Wir verwenden JIRA, daher habe ich begonnen, Probleme zu kennzeichnen, um diese Schätzung zu verfolgen. Es ist mir aufgefallen, dass ich mehrere Metriken verwendet habe, um einen Fehler / eine Aufgabe zu kategorisieren:

• Wie klar / unkompliziert es ist. Zum Beispiel, ob es sich um etwas handelt, das viel Designarbeit oder nur eine einfache Fehlerbehebung für die Benutzeroberfläche erfordert.
• Wie wartbar der betroffene Bereich des Codes ist. Ist es ein gut gestalteter Bereich oder ein großer Schlammballen?
• Wie viel von dem Programm wird meiner Meinung nach von der erforderlichen Änderung betroffen sein.

Meine Labels sind etwas chaotisch, da ich keine klare Vorstellung hatte, wann ich mit den möglichen Kategorien angefangen habe und ich immer noch nicht. Ich denke darüber nach, ein neues Feld hinzuzufügen (so etwas wie "Risiko"), damit wir einen Kostenvoranschlag anfordern können, bevor wir die Arbeit jemandem zuweisen.

Hat sich schon jemand mit solchen Dingen beschäftigt?

Einer der Fehler der meisten Fehlerverfolgungsansätze besteht darin, dass sie sich nur mit einer Seite der Gleichung befassen - der Ansicht des Endbenutzers über das System. Dies ist ein kritischer Fehler, der behoben werden muss. Er kann eine Woche warten (Priorität). Dieser Fehler ist schmerzhaft, da es sich um seinen Pluralisierungsfehler handelt (Schweregrad).

In einem Blogeintrag, der die mehrdimensionale Fehlerverfolgung beschreibt, wird untersucht, wie dies behoben werden kann, einschließlich der Entwickleransicht: PEF und REV.

Die PEF-Werte sind die Ansicht des Benutzers:

• P ain - wie schmerzhaft ist der Fehler , wenn es auftritt?
• E ‍ Aufwand - wie viel Aufwand ist nötig, um dies zu umgehen?
• F requenz - wie oft kommt der Fehler auftreten?

Die REV-Seite ist aus Sicht des Entwicklers:

• R isk - wie riskant ist die Lösung?
• E ‍ Aufwand - wie viel Aufwand ist erforderlich, um den Fehler zu beheben?
• V erifiability - wie einfach ist es , zu überprüfen, ob der Fehler behoben ist?

Jedes von diesen wird auf einer Skala von 1 bis 9 gemessen, wobei 1 niedrig / leicht und 9 hoch / hart ist. Die Zahlen werden addiert, um eine Punktzahl für PEF und REV zu ergeben.

Der Teil, der die beschriebenen Bits anspricht:

• Wie klar / unkompliziert es ist. Zum Beispiel, ob es sich um etwas handelt, das viel Designarbeit oder nur eine einfache Fehlerbehebung für die Benutzeroberfläche erfordert.
• Wie wartbar der betroffene Bereich des Codes ist. Ist es ein gut gestalteter Bereich oder ein großer Schlammballen?
• Wie viel von dem Programm wird meiner Meinung nach von der erforderlichen Änderung betroffen sein.

Diese berücksichtigen den Aufwand und das Risiko, die in REV.

Ja, es ist etwas, mit dem man zuvor gekämpft hat. Ich habe (in der Vergangenheit) dieses Modell für benutzerdefinierte Felder in Redmine verwendet und es war einigermaßen erfolgreich.

Der große Vorteil ergibt sich beim Vergleich der PEF- und REV-Werte. Wenn Sie einen PEF von 21 und einen REV von 7 haben, kann dies ein großer Gewinn sein. Ein PEF von 7 und ein REV von 21 sollten für eine Weile vermieden werden, da die Risiko- und Aufwandseite wahrscheinlich den Nutzen überwiegt, der es regelt.

Man kann sich dann den REV-Score ansehen und den weniger erfahrenen Entwicklern Dinge mit geringem Risiko zuweisen (geringes Risiko, hoher Aufwand sind oft ideal für diese Situation).

Ich würde sagen, dass das, worauf Sie sich hier beziehen, besser als "Komplexität" bezeichnet werden könnte. Je komplexer eine Änderung ist, desto höher ist natürlich das Risiko, dass ein unerfahrener Programmierer einen neuen Fehler einführt. Es ist keine schlechte Idee, ein solches Feld einzuführen, wenn es sich um ein echtes Problem handelt.

Nach dem, was Sie geschrieben haben, scheinen Sie jedoch zwei Probleme zu haben:

1. Sie haben es mit neuen oder unerfahrenen Programmierern zu tun.
2. Die Qualität von (viel / etwas) Ihres Codes scheint fraglich zu sein.

Zusätzlich zur Einführung eines Komplexitätsbereichs (der Ihnen helfen würde, Ihre Arbeit zu verwalten und Prioritäten zu setzen) würde ich vorschlagen, dass Sie sich darauf konzentrieren, das Risiko der beiden oben genannten Probleme zu verringern.

Um das erste Problem anzugehen, würde ich einen Prozess erstellen, bei dem neue Programmierer zuerst alle neuen Fehler mit einem erfahrenen Programmierer besprechen, bevor sie an dem Fehler arbeiten. Außerdem werde ich auf jeden Fall Code-Reviews einführen, um das Risiko der Einführung neuer Fehler zu verringern und um den neuen Programmierern die Möglichkeit zu geben, schneller auf den neuesten Stand zu kommen.

In Bezug auf die Codequalität würde ich zwei Dinge tun. Stoppen Sie zunächst den Verrottungsprozess: Vereinbaren Sie Codierungsstandards und -praktiken, die verhindern, dass neuer minderwertiger Code eingeführt wird. Die vorgeschlagenen Code-Bewertungen würden auch hier helfen. Zweitens würde ich die schlimmsten Teile Ihres Codes identifizieren und damit beginnen, diese zu überarbeiten und zu bereinigen.

Ja, es ist eine gute Idee, unerfahrenen Entwicklern keine zu komplexen Probleme zu bereiten. Aber die Kehrseite ist, dass sie nichts lernen werden, wenn Sie sie nur die einfachen Dinge tun lassen.

Ich schlage vor, dass eine alternative Strategie darin besteht, ein Regelwerk für Codeüberprüfungen einzuführen. Lassen Sie die Neulinge an den kniffligen Dingen arbeiten (im Rahmen der Vernunft), aber überprüfen Sie ihre Arbeit gründlich.

Kurzfristig bedeutet dies mehr Arbeit für alle. Längerfristig werden Sie ein ganzes Team von Entwicklern haben, die mit den komplexen Dingen fertig werden UND in Bezug auf die Codequalität "auf der gleichen Seite" sind.