Ich habe ein Team von 8 Entwicklern, die an verschiedenen Technologien arbeiten (Backend, iOS, Android und Web). Wir verwenden Scrum.
Am Anfang habe ich für jede Technologie ein Board verwendet, aber es war so chaotisch, weil es in den verschiedenen Projekten doppelte User Stories gab.
Also habe ich ein klassisches Scrum-Board erstellt, um alle Storys, Bugs, Tasks und Subtasks zu verwalten. Auch wenn ich alles versucht und gelesen habe, bin ich mir immer noch nicht sicher, ob meine Lösung die richtige ist.
Mit dieser neuen Lösung habe ich jetzt eine Geschichte für jedes Feature, sodass das Team eine Implementierung an einem einzigen Ort besprechen kann. Während der Sprint-Planung zerlegen wir diese Geschichte in verschiedene Teilaufgaben, die wir jeweils einer Komponente (Backend, iOS, Android und Web) zuweisen.
Mein Problem ist, dass ich einer Geschichte keine Story Points geben kann, weil sie sich nicht auf eine einzelne Technologie bezieht. Ich kann einer Unteraufgabe auch keine Story Points geben. Sollte ich dann für jede Technologie eine Geschichte haben? Jede Lösung hat ihre Vor- und Nachteile und ich weiß nicht, welche die beste ist.
Also schlägt jemand eine gute Lösung vor? Ich bin neugierig, wie ich das am besten in Jira organisieren kann, und ich würde mich über Ihren Beitrag und Ihre Erfahrungen freuen.
In jedem Fall werden Sie auf Probleme stoßen.
Basierend auf meinen Erfahrungen mit Jira sollte jedes Produkt ein separates Jira-Projekt sein. Das bedeutet, dass Ihre iOS-Anwendung, Ihre Android-Anwendung und Ihre Webanwendung alle separate Jira-Projekte sind. Ich bin mir nicht sicher, was Sie mit „Backend“ meinen, aber wenn Sie APIs pflegen, die von all diesen Produkten gemeinsam genutzt werden, dann wäre das auch ein eigenes Jira-Projekt. Diese Struktur ermöglicht es Ihnen, unter anderem die Funktionen von Jira rund um Versionen, Releases und Komponenten zu nutzen.
Sie können bei Bedarf Boards erstellen, die Issues aus all diesen Jira-Projekten abrufen. Die Boards geben Ihnen Zugriff auf die Anzeige des Arbeitsstatus oder einfachen Zugriff auf Sprint-basierte Metriken.
Dieser Ansatz wird es auch ermöglichen, dass jedes Problem darstellt, was wirklich passieren muss. Ihre Backend-Datenbanken und APIs würden beispielsweise wahrscheinlich verhindern, dass neue Funktionen in einer der Anwendungen veröffentlicht werden. Wenn Sie Mockups und Designdetails an jedes Jira-Problem anhängen, hilft diese Isolierung auch sicherzustellen, dass sich die iOS-Arbeit von der Android-Arbeit unterscheidet.
Das Klonen des ursprünglichen Problems in das andere Projekt kann ein guter Ausgangspunkt sein, um die Arbeit zu verwalten. Es gibt auch neue Funktionen in Jira rund um die Vorgangsautomatisierung, die automatisch Vorgänge in verschiedenen Projekten basierend auf Auslösern erstellen können (einschließlich der Erstellung eines Vorgangs, der verschiedene Kriterien erfüllt). Es gibt Tools, die das Erstellen eines Stub-Issues vereinfachen können.
Mein Problem ist, dass ich einer Geschichte keine Story Points geben kann, weil sie sich nicht auf eine einzelne Technologie bezieht.
Warum? Das Team kann eine Schätzung für das gesamte Feature abgeben, es muss es nicht nach Technologie aufschlüsseln. Wenn der Aufwand je nach Technologie unterschiedlich ist, sollte das Team einen Kompromisswert für die Schätzung verwenden.
Dies ähnelt der Frage, wie Tester und Entwickler dieselbe Geschichte einschätzen.
Wenn Sie beispielsweise eine neue Suchfunktion hinzufügen, könnten Sie eine Unterhaltung wie die folgende führen:
"Aus Web-Sicht ist das ziemlich schnell, so etwas wie eine 2"
"Auf iOS ist es schwierig, weil es keine Such-API gibt, es ist eher wie eine 5"
"Android ist hier ähnlich wie iOS"
"Nicht viel Arbeit am Backend, vielleicht eine 1?"
„Okay, also insgesamt, sollen wir uns für eine 3 entscheiden?“
Da Ihr Team aus Spezialisten besteht, kann es auch ratsam sein, eine Plausibilitätsprüfung durchzuführen . Nachdem Sie beispielsweise die gewünschten Storys zum Sprint hinzugefügt und Unteraufgaben erstellt haben, könnten Sie schnell überprüfen, ob keine Disziplin über- oder unterlastet ist.