Wir arbeiten an einem Projekt, das (grob) aus folgenden Teilen besteht:
Unser „Team“ hingegen besteht aus mehreren Ein-Mann-Teams, die jeweils an einem anderen Teil des Projekts arbeiten.
Wir verwenden JIRA+Agile. Wir haben ein einzelnes Projekt in JIRA erstellt, und für jeden oben genannten Teil wird eine Komponente erstellt. Jedes Problem wird der/den richtigen Komponente(n) zugeordnet. Dies gilt hauptsächlich für Epics- und Story-Ausgabetypen, wo es tatsächlich Sinn macht.
Wir schreiben Benutzergeschichten so, dass PO klar sehen kann, was durch das Vervollständigen dieser Geschichte gewonnen wird (dh dem Benutzer erlauben, seinen Posteingang zu sehen). Wir neigen dazu, Geschichten zu erstellen, die so granular sind, dass sie innerhalb eines Sprints vernünftig abgeschlossen werden können. Tatsächliche Entwicklungsaufgaben werden als Unteraufgaben des Hauptthemas der Story erstellt. Wir schätzen unsere Geschichten, indem wir Planning Poker spielen, auch wenn verschiedene Leute wirklich unterschiedlich viel Arbeit in jede Geschichte stecken, und es macht Sinn für uns.
Dieser Ansatz ermöglicht es uns auch, den Fortschritt der Implementierung komplexer, neuer Funktionen über alle Komponenten hinweg (Epics) zu verfolgen, indem wir sie in einzelne Stories aufteilen und dann Unteraufgaben für jede Aufgabe erstellen, die ausgeführt werden muss. Wenn Aufgaben gelöst sind, vervollständigen sich die Geschichten automatisch, was alles schön und süß ist, und wir sind im Allgemeinen damit zufrieden, wie alles funktioniert.
Allerdings ... Wir werden eine weitere Client-Anwendung für eine andere Plattform erstellen (Teil desselben Projekts). Die Arbeit, die wir durchführen müssen, ist in bestehenden Stories bereits gut definiert, da der Großteil dieser Arbeit in anderen Client-Anwendungen für andere Plattformen abgeschlossen wurde. Das Problem ist, dass all diese Geschichten bereits fertig sind! Und außerdem ist die Anzahl der Story-Punkte für jede Story vor langer Zeit geschätzt ...
Eine Möglichkeit besteht darin, alle User Storys in Bezug auf vorhandene Client-Apps zu duplizieren, sie ein wenig neu zu definieren, um deutlich zu machen, auf welche Plattform sie abzielen, und sie für diese Plattform neu zu schätzen. Eine andere Möglichkeit besteht darin, im Grunde eine User Story für jedes Stück davon zu erstellen Arbeit, die auf jeder Plattform erledigt werden muss, ABER dieser Ansatz wird den gesamten Prozess aus Sicht der Bestellung unterbrechen und somit die gewünschte Funktionalität in mehrere (wahrscheinlich nicht gleich lesbare) Geschichten aufteilen ... Vielleicht war es ein Fehler, eine zu erstellen ein Projekt für alle Komponenten? Aber es wurde von der Tatsache angetrieben, dass Client-Apps für jede Plattform sich im Grunde zu mindestens 90 % gegenseitig replizieren würden, sodass es viele Überschneidungen und doppelte Probleme geben würde ...
Frage: Was wäre ein guter Weg, um ein solches Projekt mit JIRA und Agile zu organisieren, das es uns ermöglichen würde, auf ähnliche Weise zu arbeiten, wie wir es bereits tun, aber das würde uns auch eine größere Flexibilität beim Hinzufügen neuer Komponenten ermöglichen, die im Grunde repliziert werden müssten? Funktionalität bereits in anderen Client-Apps implementiert?
Danke fürs Lesen ;)
Erstellen Sie wiederverwendbare Komponenten und organisatorische Prozessressourcen
Eine Möglichkeit besteht darin, alle User Stories in Bezug auf vorhandene Client-Apps zu duplizieren, sie ein wenig neu zu definieren, um deutlich zu machen, auf welche Plattform sie abzielen, und sie für diese Plattform neu zu schätzen.
Erstens das Gesetz von CodeGnome; Machen Sie sich keine Gedanken über Technologie (Jira), bis Sie entschieden haben, was Sie tun möchten und wie Sie es tun möchten.
Zweitens: Wenn Sie Client-Anwendungen für mehrere Plattformen schreiben müssen, machen Sie sich keine Gedanken über die Technologie, bis Sie entschieden haben, was Sie tun und wie Sie es tun. Entwerfen Sie die Client-Server-Architektur, entwerfen Sie dann die Client-Fähigkeiten und zerlegen Sie diese dann in funktionale und nicht-funktionale Anforderungen. Planen Sie dann, wie Sie diese Anforderungen für jede Plattform erfüllen können.
Beachten Sie, wie Sie automatisch eine Referenzklasse für die Schätzung erstellt haben? Beginnen Sie mit der Arbeit auf Plattform 1; Wenn Sie Plattform 2 schätzen, bestimmen Sie, wie viel der Differenz zwischen Schätzung und Ist-Wert Ihre Schätzung für Plattform 2 beeinflusst. Wiederholen Sie dies für Plattform N.
Wenn Sie damit beginnen, für jede Arbeit User Stories zu erstellen, untergraben Sie den Wert der Wiederverwendung.
Wie @Mark C. Wallace betonte, entscheiden Sie zuerst, was Sie tun möchten und wie Sie es tun möchten. Beim Erstellen der ersten Clientanwendung hat Ihr Product Owner beispielsweise möglicherweise darüber nachgedacht, wie die Designs/Flows verbessert werden können. Ihr Entwicklungsteam hat möglicherweise einige Dinge darüber gelernt, was nicht zu tun ist. Durch das einfache Kopieren der Geschichten verliert das Team die Möglichkeit, im Lichte der Erfahrungen neu zu denken und Dinge zu verbessern.
Wenn Sie jedoch nach reiflicher Überlegung des oben Genannten Geschichten in großen Mengen kopieren möchten, sieht es so aus, als gäbe es einige Möglichkeiten. Wir haben Agile Boards so eingerichtet, dass wir Geschichten aus mehreren Projekten ziehen können. Obwohl ich es nicht verwendet habe, verstehe ich, dass ich in diesem Setup ein gesamtes JIRA-Projekt mit der Jira-Befehlszeilenschnittstelle (JCLI) klonen/kopieren kann .
Chintan Patel