Gibt es einen klaren Vorteil, Problem und Aufgabe zu trennen, wenn man in größeren Teams arbeitet?
Bei der Arbeit mit beträchtlichen Teams von Entwicklern zusätzlich zu einer Reihe von externen Kunden, QA und jeder anderen Form von Testern für die Entwicklung einer Softwareanwendung ist es nur logisch, dass ein zugängliches Problemverfolgungssystem verwendet wird.
Traditionell werden alle Probleme genau als das in ein Tracking-System eingegeben - ein "Problem". Diese "Ausgaben" würden dann hauptsächlich durch ein TypeFeld für die Ausgabe unterteilt, das definiert, ob es sich um eine Bug, Feature, Taskoder etwas anderes handelt. Die dafür verwendete Terminologie ist in der Regel durch das verwendete Trackingsystem vorgegeben und konnte daher beispielsweise nicht von „Issue“ auf „Task“ geändert werden.
Dadurch arbeiten Entwickler, Projektmanager, externe Benutzer und QA alle an derselben Warteschlange von "Issues", wobei sie alle in dieselbe Warteschlange eintreten und nur durch ein Feld zu diesem Problem getrennt sind.
Was ich hier vorzustellen versuche, ist ein System, das auf einer Kernebene zwischen dem Konzept eines „Problems“ und einer „Aufgabe“ trennt. Das heißt, die Verwendung dieser Begriffe in der Projektmanagement-Software neu zu definieren.
Issue- Ein außerplanmäßiger Artikel / eine Frage / ein Kommentar zu einem Projekt, das über einen Dritten eingegeben wurde, sei es ein Tester der QA oder ein Kunde, der ein Problem hat.
Task- Ein verifiziertes Element, das vom Projektmanager geplant oder einfach von einem Entwickler übernommen wurde. Dies kann als ein Werk angesehen werden Work Item, an dem gearbeitet werden soll. Es kann verifiziert sein oder nicht Issue.
Die Idee ist, dass die meisten Abfragen/Anfragen von Drittanbietern als . eingegeben Issueund dann in . migriert Taskund anschließend vom Projektmanager geplant und zugewiesen werden, bevor die Arbeit abgeschlossen ist. Dies ermöglicht eine klare Trennung von Aufgaben, Entwickler können sich nur an eine TaskWarteschlange halten, um ihre Arbeit zu finden und abzuschließen, und Projektmanager / Supportassistenten (als Beispiel) können die IssueWarteschlange verwenden, um sie zu klären Probleme vollständig, bevor Sie sie in festgeschriebene Tasks umwandeln.
Bevor Sie sich mit einem System befassen, das die Trennung zwischen einer Aufgabe und einem Problem bietet, möchten Sie sicherstellen, dass die Benutzer mit der Terminologie und insbesondere mit der Verwendung der einen oder anderen sehr vertraut sind.
Wie Sie gesagt haben, verwenden Systeme normalerweise dieselbe Nomenklatur, um etwas Ausstehendes zu identifizieren. Ich glaube, das liegt hauptsächlich daran, dass es den Benutzern egal ist, wie die IT es nennen wird. Solange die Benutzer des Systems also eindeutig wissen, wann sie etwas als Aufgabe oder Problem identifizieren, werden Sie später Probleme haben.
Ein weiteres mögliches Szenario ist, dass Tickets meist von Personen eingereicht werden, die den Unterschied genau kennen. Warum in diesem Fall nicht eine Information verwenden, um Tickets zu unterscheiden? In unserem Fall haben wir uns darauf geeinigt, dass das Ausfüllen des Felds „Fälligkeitsdatum“ bedeutet, dass es sich um eine Aufgabe handelt, die in Produktion geht, um sie von anderen noch nicht priorisierten Tickets zu trennen.
Möglicherweise zahlen sich die Bemühungen, das vorhandene System durch ein anderes System zu ersetzen, das die Trennung von Aufgaben und Problemen bietet, nicht aus. Denken Sie daran, dass es für neue Systeme immer eine Lernkurve gibt, und wenn Sie Ihren Kunden Tickets eingeben lassen, ist es möglicherweise nicht schön, ihn in ein neues System zu belasten, „nur um es der IT zu erleichtern“.
In Ihrem Fall könnten Sie jedes Feld auswählen, an dessen Verwendung Ihr Team nicht sehr gewöhnt ist, und zustimmen, dass dieses Feld die „Aufgabenkennung“ ist (ein Feld, das vorzugsweise nur von der IT gesehen werden kann).
Zurück zur Systemfrage: Jira könnte Ihre Anforderungen erfüllen. Aber denken Sie daran, dass eine solche Differenzierung eher kulturell als systematisch ist.
Ich denke, wir versuchen dasselbe Problem zu lösen, nämlich die Herausforderung, verschiedene Arten von Arbeit zu priorisieren, indem wir sie in der Eintrittsphase oder zumindest sehr bald nach dem Eintritt kategorisieren.
Ich habe mit Systemen gearbeitet, die einen einzigen Problemtyp ("Bug") bis zu einer aktuellen Jira-Implementierung mit drei ("lieferbar", "Aufgabe" und "Bug") hatten. Das Ein-Typ-System führte zu vielen seltsamen Bezeichnungen und Dokumentationsstandards, um "Bugs" (ungeplante Arbeit, außer im allgemeinen Sinne) und "geplante Arbeit" zu unterscheiden. Das System mit drei Problemtypen hat sich über fünf Jahre entwickelt und entspricht den Anforderungen meiner Organisation.
Ergebnis: Formelle Projektarbeit, geschätzt, detailliert, mit Abschlusstests und einem formellen Überprüfungs-/Abnahmeschritt. In der Regel auf irgendeine Art von vertraglicher Verpflichtung aufgerollt.
Aufgabe: Weniger formal, kein Überprüfungsschritt. Grundsätzlich "to do"-Elemente, die oft von Entwicklern selbst eingegeben werden. Existiert aufgrund des Wunsches, ansonsten unbekannte Arbeiten in Form von Notizblocklisten, Outlook-Aufgaben usw. zu erfassen.
Fehler: Wird normalerweise von QA-Testern eingegeben. Überprüft (wir nennen es Triage) und priorisiert für Maßnahmen in Bezug auf den Schweregrad. Ein schwerwiegender Fehler kann Vorrang vor einer Lieferung haben, ein sehr kleiner Fehler kann lange im Rückstand warten. Eine Fehlerbehebung wird vom Melder verifiziert.
Beachten Sie, dass sowohl Ergebnisse als auch Fehler Überprüfungs-/Verifizierungsschritte haben. Der Unterschied zwischen einem Liefergegenstand und einem Fehler besteht darin, dass Liefergegenstände noch nicht defekt sind.
Die Idee ist, dass die meisten Anfragen/Anfragen von Drittanbietern als Problem eingegeben und dann in eine Aufgabe migriert und anschließend vom Projektmanager geplant und zugewiesen werden
Was Sie hier meinen, ist eine Zustandsänderung, kein separates Element. Sie benötigen eine Möglichkeit, den Anfangsstatus des Elements als Problem zu erfassen, und dann eine Möglichkeit, diesen Status zu ändern, um anzugeben, dass es von den PMs angesehen und genehmigt wurde und bereit (oder geplant) ist.
In TFS ist dies einfach, wenn neue Arbeitselemente vom Basistyp (Name variiert je nach Vorlage) der Status so etwas wie "vorgeschlagen" oder "ausstehend" ist. Sobald es genehmigt wurde, ändert sich der Status in "genehmigt".
Diese Methode sorgt für ein transparentes Reporting und auch dafür, dass Workitems nicht verloren gehen. Wenn Sie zwei völlig separate Arbeitselemente verwendet haben, könnten Sie leicht auf Probleme stoßen, bei denen das Element nicht ordnungsgemäß migriert werden konnte. Jeder Status hat seine eigene Abschlussmethode, sodass ein Arbeitselement, das nicht genehmigt wurde, abgelehnt werden kann, aber ein Arbeitselement, das genehmigt wurde, abgeschlossen oder abgebrochen werden kann.
Ich denke, das ist eine großartige Frage, und ich schätze den detaillierten Kontext. Ich stimme @aclear16 zu, dass dies eher eine Zustandsänderung als zwei getrennte nachverfolgbare Entitäten sind. Ich denke, womit Sie es wirklich zu tun haben, ist grundlegende Änderungskontrolle.
Sie haben „Problem“ als eine Eingabe von einem Dritten definiert, die auf den Wunsch nach Änderung hinweist. Logischerweise sollte diese Änderungsanforderung analysiert werden, um herauszufinden, welche Auswirkungen sie auf Umfang/Zeitplan/Kosten/Qualität usw. hat. Basierend auf dieser Analyse entwickelt der PM ein Arbeitspaket, um das Problem anzugehen – was Sie eine „Aufgabe“ nennen.
Aufgaben sollten den relevanten Stakeholdern (Change Control Board) zur Priorisierung und Ressourcenzuweisung vorgelegt werden. (Manchmal führt das CCB die Validierung durch und eine separate Einheit übernimmt die Priorisierung und Ressourcenbeschaffung). An diesem Punkt wird der Zeitplan geändert, um die Aufgabe aufzunehmen.
Verwechseln Sie Projekteingaben nicht mit Verpflichtungen für Leistungen. Dies scheint das zugrunde liegende X / Y-Problem zu sein, das von der Frage angesprochen wird.
Traditionell werden alle Probleme genau als das in ein Tracking-System eingegeben - ein "Problem".
Das Problem besteht meines Erachtens darin, dass Ihre Tools den Arbeitsablauf diktieren und Sie versuchen, zwischen unkontrollierten Prozesseingaben (Issues) und kontrollierten, geordneten Prozessergebnissen (Tasks) zu unterscheiden.
Soweit Sie bereits eine Unterscheidung zwischen den beiden definiert haben, gibt es kein wirkliches Problem. Das Problem als solches besteht darin, dass Sie Ihren Arbeitsablauf nicht entsprechend geändert haben und dass Sie Ihren Arbeitsablauf in gewissem Maße auf der Grundlage Ihrer vorhandenen Toolkette einschränken.
Es scheint auch einen fehlenden Prozessschritt zu geben. Insbesondere der Prozess, bei dem Probleme gesichtet und zugewiesen, priorisiert und geplant werden – oder auch nicht, je nach Bedarf der Organisation.
Es hat keinen inhärenten Wert, zwischen „Problemen“ und „Aufgaben“ zu unterscheiden. Was Sie wirklich tun müssen, ist Ihren Prozess so anzupassen, dass er zwischen „Zeug, für das wir Zeit und Geld ausgeben wollen“ und „Zeug, das uns egal ist“ unterscheidet.
Zu diesem Zweck müssen Sie Ihren Sichtungsprozess überprüfen oder einen erstellen, falls er noch nicht vorhanden ist. Jemand sollte Probleme prüfen, sobald sie eingehen, die Auswirkungen auf das Geschäft (falls vorhanden) bewerten und es als Ergebnis identifizieren, wenn es den Aufwand und die Ressourcen verdient.
In Scrum wäre das die Aufgabe des Product Owners. Die PO priorisiert das Product Backlog, indem sie den Geschäftswert identifiziert, und platziert den Job im Backlog in einem Slot, der sowohl durch die eigentliche Wichtigkeit als auch durch die Abhängigkeiten anderer Backlog-Elemente bestimmt wird.
Wenn Sie darauf bestehen, durch Ihre aktuelle Toolkette eingeschränkt zu bleiben, haben Sie immer noch ein paar Optionen.
Verwenden Sie einen anderen Bucket für Arbeit, die nicht triagiert wurde.
Dies ist im Wesentlichen ein Slop-Stapel, aus dem der Product Owner (oder ein Äquivalent) Arbeit auswählen kann, die in einen anderen Bucket übertragen werden soll, aus dem die Arbeit tatsächlich zugewiesen wird. Mit Ausnahme der Triage werden keine Arbeiten direkt aus dem nicht triagierten Eingabe-Bucket ausgeführt.
Verwenden Sie denselben Bucket, aber arbeiten Sie nur an triagierten und entsprechend gekennzeichneten Problemen.
Die meisten Bug-Tracking-Systeme ermöglichen Labels, Priorisierung und Planung. Wenn Ihr Bug-Tracking-System wirklich der Bucket für zu liefernde Ergebnisse Ihres Projekts ist, stellen Sie sicher, dass Ihre Triage-Prozesskennzeichnungen so funktionieren, dass sie als „Wontfix“ oder ähnliches ignoriert werden, oder weisen Sie den auszuführenden Arbeiten Schweregrade, Fälligkeitsdaten und Meilensteine zu.
Wie auch immer, die Lösung ist letztendlich dieselbe: Hören Sie auf, Probleme oder Fehleranfragen als Verpflichtung für bestimmte Ergebnisse zu behandeln. Ungeachtet des Formats oder der Nomenklatur liefert Ihr Problemsystem lediglich Eingaben für Ihren Prozess. Es liegt an der Organisation, den Wert zu bewerten, und an der Verantwortung des Projektteams, den Aufwand zu schätzen und sich auf bestimmte Aufgaben und Meilensteine festzulegen.
Eine Aufgabe ist die Ausführung eines Arbeitspakets. Es ergibt sich aus einer vorsätzlichen Projektplanungsaktivität (sei es eine User Story oder ein Wasserfall-Projektplan). Eine Aufgabe ist eine geplante Aktivität.
Ein Problem ist ein Fehler, Risiko oder eine Herausforderung, die während der Ausführung auftritt. Es fließt aus der laufenden Arbeit. Ein Problem ist eine ungeplante Aktivität.
Ob ein Problem zu einer Aufgabe wird, hängt von Ihrem Änderungskontroll- und/oder Risikomanagementprozess ab. In diesem Prozess entscheiden Sie, wann ein Fehler zu einer Aufgabe wird oder ob beispielsweise ein positives Risiko (eine Chance) zu einem Feature wird. Von dort würden Sie es zurück zu einer geplanten Aktivität leiten (wie das Erstellen des Features oder das Angehen des Risikos).
Wenn der Fehler während des Testens/QA auftaucht, dh während der Entwicklung des Produkts, müssen Sie entscheiden, wann die Software "fertig" ist, und davon ausgehend Entscheidungen zur Fehlerbeseitigung treffen.
Rudi Visser
Task(lieferbar) und anIssueoderTicket, was einfach die "Triage" -Liste ist.