Welche Prozessänderungen kann ich vornehmen, um sowohl kollaborative Geschichten als auch individuelle Zeit in Jira genauer zu verfolgen?

Ich arbeite derzeit mit einer Organisation zusammen, die das Jira Tempo Timesheets -Plug-in verwendet, um die Entwicklerzeit zu verfolgen, aber die Art und Weise, wie Jira-Storys und -Aufgaben verwendet werden, kann den Overhead ohne viele manuelle Optimierungen nicht genau erfassen.

Wenn das Team beispielsweise eine User Story mit zwei Aufgaben hat:

  1. Zwei Personen könnten an einer der Aufgaben zusammenarbeiten. Wenn beide Personen die Arbeit an der Aufgabe protokollieren, verdoppelt sich die Zeit, die Jira für die Aufgabe annimmt.
  2. Eine Person kann zwei 30-Minuten-Blöcke damit verbringen, an einer Aufgabe zu arbeiten, aber zwei Stunden sind blockiert.
    • Der Entsperrungsprozess (z. B. Anrufe tätigen, Ressourcen jagen, Besprechungen abhalten) könnte theoretisch der blockierten Aufgabe zugeordnet werden, aber dann sieht das Dashboard (insbesondere die Agile-Ansicht) wirklich verzerrt aus.
    • Wenn Sie diese Zeit nicht der blockierten Aufgabe zuweisen, werden Details zur Vorlaufzeit ausgeblendet, und der Aufwand wird geringer aussehen, als er war.
  3. Manchmal kann eine Aktivität mit mehreren Aufgaben/Unteraufgaben verrechnet werden, aber wenn Sie sie in beide eingeben, werden die Rollup-Werte lächerlich groß und letztendlich irreführend.
  4. Andererseits lässt die Aufteilung der Zeit zwischen getrennten Aktivitäten, die zufällig eine gemeinsame Abhängigkeit aufweisen, den Anschein erwecken, als hätten die Ausführenden der Aufgabe die Hälfte der Zeit, die sie tatsächlich aufgewendet haben, damit verbracht, etwas zu erledigen.

Kurz gesagt, ich bin mir nicht sicher, wie ich Jira als Epic/Story- oder Task/Subtask-Tool (insbesondere für kollaborative User Stories) mit seiner organisatorischen Rolle als „Quelle der Wahrheit“ für individuelle Stundenzettel in Einklang bringen soll.

Obwohl ich persönlich denke, dass Jira nicht das richtige Werkzeug für einen wirklich agilen Prozess ist, insbesondere für Projekte, die Scrum oder XP folgen, ist das nicht meine Entscheidung. Ich brauche nur einen besseren Prozess zum Nachverfolgen von Arbeit, abrechenbaren Stunden und Zykluszeit in Jira.

Welche Prozessänderungen kann ich vornehmen, damit die Zeitzuweisungen für Stories/Aufgaben auf der Führungsebene sinnvoll sind, ohne dass es so aussieht, als würde jede Kalenderwoche 300 Arbeitsstunden der Zeit jeder Person verbrauchen? Und wie bringe ich Jira dazu, den Prozessaufwand zu berücksichtigen, sodass die für bestimmte Aktivitäten zugewiesene Zeit (die oft kleiner ist als die tatsächlich verstrichene Zeit zum Erreichen der Definition of Done) die tatsächlichen Kosten für die Fertigstellung der Storys nicht außer Acht lässt?

Antworten (1)

Mein Ansatz wäre:

  1. Lassen Sie beide Entwickler die Arbeit an dem Problem protokollieren, an dem sie gemeinsam gearbeitet haben. Es ist die einfache Wahrheit, dass, wenn 2 Entwickler eine Stunde lang gearbeitet haben, dann 2 Stunden aufgewendet werden. Die protokollierte Arbeit ist nicht Zeit, sondern Aufwand.
  2. Für alles, was die Entwickler tun, was nicht direkt mit Geschichten zu tun hat, würde ich "Aufgaben bündeln" empfehlen, zB eine Aufgabe "Meetings April", bei der jeder Teilnehmer eines Meetings die Arbeit an diesem Thema protokolliert. Wenn Sie diese auf monatlicher Basis haben, erhalten Sie einen schönen Bericht, wie viel Zeit für "alles andere" aufgewendet wurde. Etwas, das eine großartige Eröffnung in einer Retrospektive ist, wenn Sie dem Team zeigen, wie viel Zeit sie tatsächlich mit Dingen verbracht haben, die nicht mit der Geschichte zu tun haben.
  3. Ich würde empfehlen, die Arbeit nur an Storys und nicht an Aufgaben zu protokollieren. Wenn etwas auf mehrere Geschichten abzielt, würde ich die protokollierte Arbeit zwischen ihnen aufteilen.
  4. Dies ist nur dann ein Problem, wenn Sie tief in die Arbeit eintauchen möchten, die für eine bestimmte Geschichte geleistet wurde. Für Metriken wie Durchlaufzeit und Durchlaufzeit sollte es keinen Unterschied machen.

Mein Rat für eine Prozessänderung wäre, die Zeiterfassung insgesamt zu hinterfragen. Die Zeiterfassung ist eine Methode aus dem Command & Control-Weg des Projektmanagements. Ich würde empfehlen, Scrum zu verwenden, wo Sie Sprints als feste Zeitfenster haben. Mit einfachen Schritten bekommt man ein ziemlich gutes Verständnis von der Arbeitskapazität eines Teams.

Das Management sollte sich auf die Strategie konzentrieren und den Teams vertrauen, dass sie ihre Prozesse kontinuierlich verbessern.