Wie geht man mit Handouts von einem Jira-Projekt zum anderen um?

Dort! Erstbenutzer hier!

Da wir drei Jira-Projekte haben:

  • USERS, die Benutzer verwenden, um Probleme einzugeben;
  • BACKEND, das für unser Backend-Team intern ist;
  • FRONTEND, das für unser Frontend-Team intern ist

Unser Ablauf ist heute wie folgt:

  • Der Benutzer gibt ein Ticket in das USERS-Projekt ein
  • Der PM erstellt zwei verknüpfte Vorgänge: einen für das BACKEND-Projekt und einen für das FRONTEND-Projekt.
  • Das PM verknüpft das BACKEND-Ticket als "blockiert" das FRONTEND-Ticket.
  • Sowohl die BACKEND- als auch die FRONTEND-Tickets gehen in den üblichen Backlog/Sprint-Prozess

Mein Problem liegt heute im Handout-Prozess. Das FRONTEND-Team muss warten, bis das BACKEND-Team seine Arbeit an seinem Ticket abgeschlossen hat. Wenn das erste Team fertig ist, teilen sie es dem FRONTEND-Team mit, und das Frontend-Team beginnt mit der Arbeit an seinem Teil des Jobs. Dies ist natürlich nicht optimal, da das erste Team oft vergisst, es dem anderen Team mitzuteilen, nachdem sie fertig sind. Es liegt an mir, ihre Tickets im Auge zu behalten, um zu sehen, was als RESOLVED markiert ist, und dann den Beginn der Arbeit am Frontend-Gericht auszulösen.

Wie können wir dies besser machen (ohne die gesamte Organisation und die Art und Weise, wie unsere Teams organisiert sind, umzugestalten)? Gibt es eine Möglichkeit, dieses Handout mit Jira zu automatisieren?

Vielen Dank!

Einige Anmerkungen: 1. Beide Teams sind bereits groß genug, um getrennt zu werden. Ein großes Team wäre zu groß, um richtig geführt zu werden. 2. Ich werde weitere Bemerkungen hinzufügen, wenn sie mir einfallen ;)

Wenn die Teams zu groß sind, um sie zu kombinieren, bilden Sie zwei Teams, die das gesamte Problem angehen können.

Antworten (1)

TLDR

  • Fassen Sie die Teams zu einem zusammen.
  • Kombiniere die Geschichten zu einer.
  • Verwenden Sie SubTasks, um die Arbeit zu trennen.
  • Haben Sie ein einziges Board, das alle Arbeiten zeigt.
  • Arbeiten Sie nach Möglichkeit im Tandem.

Es gibt hier vieles, was ich als problematisch ansehe, also lassen Sie mich ein paar wichtige Punkte ansprechen:

Teams sollten funktionsübergreifend sein.

Warum die Entwicklung in zwei Teams aufteilen? Genau aus diesem Grund ist das eine schlechte Idee – es schafft Abhängigkeiten und Übergaben, was zu Verschwendung führt. Kombinieren Sie die beiden Teams zu einem Team.

Beide Teams sind bereits groß genug, um getrennt zu werden. Ein großes Team wäre zu groß, um richtig gemanagt zu werden.

Okay. Nehmen Sie dann die Hälfte von Team A und tauschen Sie sie mit der Hälfte von Team B aus. Jetzt haben Sie zwei funktionsübergreifende Teams, die keine Abhängigkeiten zwischen ihnen haben.

Geschichten sollten für sich genommen einen Geschäftswert bieten.

Siehe INVEST-Mnemonik . Geschichten sollten unabhängig sein. Andernfalls erhalten Sie viele fertige Geschichten als Teil halbfertiger Anforderungen. Sie können SubTasks verwenden, um die Front-/Back-End-Arbeit zu trennen, falls gewünscht. Im Idealfall sollten Ihre Entwickler im Laufe der Zeit zusammenarbeiten und T-förmig werden, sodass eine Person einige Geschichten vollständig fertigstellen kann.

Es gibt keinen Gesamtüberblick über die Arbeit des Projekts

Nun, das sollte kein Problem sein, wenn Sie die obigen Ratschläge beachten, aber wenn Sie aus irgendeinem Grund nicht können / wollen, dann müssen Sie entweder ein einzelnes Jira-Projekt erstellen (ggf. durch Epics trennen) oder ein einzelnes Board das zeigt beide Jira-Projekte. Auf diese Weise gibt es eine konsolidierte Sicht auf den Status des Projekts.

Warum ein Block?

Warum sollten Sie hier überhaupt einen Block haben? Alles, was Sie brauchen, ist eine vereinbarte API, wonach die beiden Teams gleichzeitig an dem Feature arbeiten können sollten. Welchen Vorteil haben Sie, wenn Sie einen Roadblock hinzufügen?

@Daniel Mehr wie "hämmere ich diesen Nagel mit einem Schuh oder einer Glasflasche ein?" Siehe meta.stackoverflow.com/questions/308807/… und weblogs.asp.net/alex_papadimoulis/408925
@Daniel Ich habe bearbeitet, um Ihre Bearbeitung zu adressieren.