Wie können Sie bei der Entwicklung derselben App für mehrere Plattformen die Implementierung aufeinander abstimmen?

Aus PM-Sicht handelt es sich um zwei getrennte Projekte. Wenn dieselben Entwickler sowohl am Android- als auch am iOS-Client arbeiten, können Sie es jedoch als ein Projekt ausführen. Ein sinnvolles Feature-Alignment könnte man erreichen, indem man zwei Versionen der User Stories (iOS / Android) hat und diese nacheinander priorisiert.

Wenn es sich jedoch um zwei verschiedene Teams handelt, können und sollten Sie nicht versuchen, die Funktionsentwicklung über die beiden Projekte hinweg auszurichten. Sie können natürlich in beiden Versionen dieselbe User-Story-Priorisierung vergeben, machen aber keine Abhängigkeiten von einem Projekt zum anderen. Dies wird unweigerlich zu Verzögerungen in einem Team führen, da die gleiche Geschichte auf den beiden Plattformen in der benötigten Zeit stark variieren kann. In dieser Situation sind Sie besser dran, wenn Sie es als zwei verschiedene Entwicklungsprozesse mit separaten Kanban-Tafeln usw. ausführen.

Wenn Sie Scrum betreiben, würden Sie zwei verschiedene Scrum-Prozesse gleichzeitig ausführen und dann ein tägliches oder wöchentliches „Scrum of Scrums“ veranstalten, bei dem sich die Leads aus jedem Team treffen und den Fortschritt besprechen.

Es sollte keinen Unterschied in den User Stories oder Akzeptanzaufgaben/Tests geben, da beide Funktionen erklären, die für beide Apps gleich sind.

Allerdings wird empfohlen, Aufgaben für jede Plattform zu erstellen (auch wenn sie gleich sind), da es aus folgenden Gründen einfacher ist, den Fortschritt für jede Version zu verfolgen:

1.Zeitschätzung kann abweichen

2.Anderer Zessionar

3. Geben Sie jedem Team die Flexibilität, seine Aufgaben zu verwalten. Vielleicht möchte das iPhone-Team mit der Arbeit an Aufgabe Nr. 4 und dann an Nr. 3 beginnen, da es natürlich nicht von anderen Aufgaben abhängig ist, aber das Android-Team beginnt mit der Arbeit an Aufgabe Nr. 3 dann #4.

Sie können eine Farbcodierung verwenden (z. B. rote Post-its für Android, gelbe Post-its für iPhone).

Nehmen wir als Beispiel den Anmeldebildschirm.

User Story: Als Benutzer möchte ich meine Anmeldeinformationen eingeben, um mein Profil anzuzeigen.

Akzeptanztests:

• gültige Zugangsdaten verwenden, sollte sich der Benutzer bei seinem/ihrem Profil anmelden.
• Verwenden Sie ungültige Anmeldeinformationen, wird dem Benutzer die Meldung "Falscher Benutzername oder falsches Kennwort" angezeigt.
• Klicken Sie auf Senden, ohne Daten einzugeben, eine erforderliche Feldmeldung wird angezeigt.

Aufgaben (die Post-its)

1. Visuelles iPhone-Design
2. Visuelles Design für Android

usw.

Ich hoffe es hilft.

In der Reihenfolge deiner Fragen..

Wie halten Sie die iOS- und Android-Entwickler auf derselben Seite?

Sie bauen verschiedene Clients für dasselbe Produkt auf. Ich würde dies als ein einziges Projekt behandeln.

1. Dies ist ein Szenario, in dem Sie gleichzeitig ein bisschen Vereinigung und Trennung haben müssen
2. Sowohl iOS- als auch Android-Entwickler sollten einem Scrum-Team angehören (andernfalls sind Kommunikationslücken unvermeidlich, sie werden an denselben Scrum-Zeremonien teilnehmen, um die Kommunikation effektiv und nahtlos zu gestalten)
3. Auf diese Weise können Sie sowohl iOS- als auch Android-Teams in Bezug auf Produktvision, Erwartungen zum Zeitplan, Bedenken der Interessengruppen und allgemeine Mitteilungen auf dem gleichen Stand halten

Welche anderen Praktiken helfen Ihnen sicherzustellen, dass eine Funktion/User Story in beiden Apps auf die gleiche Weise implementiert wird? Was sind Standardpraktiken?

Das habe ich getan..

1. Entwicklungs-/QA-/Design-Aufgaben sind getrennt, da diese Aufgaben für jede Plattform separat ausgeführt werden müssen, also ja, Sie haben ein Produkt-Backlog, aber doppelte Aufgaben für jede Plattform
2. In Anbetracht der Implementierung von Feature A wird es ein Post-it für Android und ein weiteres Post-it für iOS mit höchstwahrscheinlich unterschiedlichen Schätzungen geben
3. In Ihrem Fall verpflichten sich verschiedene Entwickler zur Implementierung von Feature A in iOS und Android, sodass es sinnvoller ist, unterschiedliche Aufgaben zu haben
4. Sie könnten auch ein Burndown-Diagramm verwenden (weil die Product Owner in einer bestimmten Iteration ausgewählte Backlog-Elemente für iOS und Android zusammen veröffentlichen sollten ) .

Wie ich oben bereits erwähnt habe, müssen die Mitglieder des UI-Designteams, die auf beiden Plattformen arbeiten, für alle Mitteilungen in Bezug auf Funktionen, Anforderungen und Sprintplanung zusammenkommen, da sie ein gewisses Maß an Synchronisierung erfordern

Während der Implementierung haben die Mitglieder des QA & Release-Teams, die auf jeder Plattform arbeiten, plattformspezifische Aufgaben

Allgemein:

• Eine gut gestaltete App kann je nach Plattform eine andere Implementierung aufweisen. Ein Beispiel: Die iOS-App navigiert von einem Bildschirm zum anderen und der Zurück-Button befindet sich in der Navigationsleiste oben links. Die hintere Schaltfläche für die Android-App ist eine physische Taste unten am Telefon, nicht in der Anwendung.
• Eine gut gestaltete App folgt den Richtlinien, die von jedem Unternehmen (Apple oder Google) vorgeschlagen werden, versucht, die beste Benutzererfahrung zu bieten, und versucht, Dinge zu vermeiden, die auf einer Plattform nicht existieren.
• Daher kann die Implementierung der einzelnen Funktionen / User Stories je nach Plattform unterschiedlich sein.

Gedränge:

• Sie haben zwei parallele Scrum-Prozesse und die gesamte User Story wird dupliziert.
• Gemäß den Geschäftsregeln kann jede App die gleiche Anzahl an Features / User Stories haben oder nicht.

Daten:

• Für Anwendungen mit persistenten Daten ist es möglich, ein gemeinsam genutztes Datenrepository oder einen Webservice zu verwenden, um Datenmodelle gemeinsam zu nutzen.

Empfohlene Vorgehensweise:

• Um das Verhalten für jede Funktion zwischen den Apps sicherzustellen (trotz möglicher Unterschiede bei der Durchführung einer Aktion je nach Gerät), benötigen Sie ein Team aus QA und QC mit sehr klaren Testfällen und unabhängig von der Plattform.
• Wenn nach dem Ausführen (manuell oder automatisiert) aller Testfälle die Ergebnisse alle gültig sind, haben Sie 2 Anwendungen mit denselben Funktionalitäten und möglicherweise unterschiedlichen Implementierungen.

Bitte sehen Sie es als zwei verschiedene Projekte an, weil.

Die Probleme, die bei der Erstellung von Benutzeroberflächen für verschiedene Mobiltelefone oder Smartphones auftreten, beschränken sich nicht nur auf die Darstellung der gestalteten Inhalte auf dem Bildschirm. Beispielsweise unterscheidet sich das Entwerfen einer Benutzeroberfläche für Telefone ohne Touchscreen stark von dem Entwerfen für Touchscreen-Telefone. Ein Schnittstellentyp passt nicht zwangsläufig zu den technischen Anforderungen aller Geräte.

Ich denke, mehrere Leute haben gesagt, dass Sie es als zwei separate Projekte behandeln müssen.

Ich denke, Sie müssen es als Programm behandeln – eine Reihe von Projekten, die mit ähnlicher Methodik und mit einem kohärenten Ziel im Hinterkopf verwaltet werden.

Wie halten Sie die beiden Projekte aufeinander abgestimmt? Richten Sie die Projekte aus. Sicher gehen, dass:

• Die Scope-Anweisungen stimmen überein
• Der KPI-Match – wie Sie Leistung und Effektivität messen, muss übereinstimmen
• Risiken stimmen überein (oder zumindest wird jedes Risiko daraufhin untersucht, ob es Auswirkungen auf das andere Projekt hat).
• Änderungskontrolle/Änderungsmanagement sind aufeinander abgestimmt. Jede Änderung an einem der beiden Projekte sollte daraufhin untersucht werden, ob sie Auswirkungen auf das andere Projekt hat.
• Final Operational Acceptance Testing Matches.

Wenn die beiden nicht übereinstimmen, stellen Sie sicher, dass es einen Grund dafür gibt. Wenn Sie Ihren Teil dazu beitragen, dies einzurichten, werden Sie auch klar erkennen, welcher Teil der Arbeit der Kern Ihres Projekts ist und welche Teile plattformspezifisch sind.

Wenn Sie dies regelmäßig tun, kann es sinnvoll sein, dies als drei Projekte zu behandeln

• Ein Projekt zur Herstellung eines neuen Produkts – Schwerpunkt auf Architektur, Funktionalität usw. Sobald die Architektur und Funktionalität festgelegt sind, wird die gesamte Arbeit an eines der beiden anderen Teams ausgelagert, die als Subunternehmer behandelt werden.

  • Ein Projekt zur Implementierung des Produkts auf Android.

  • Ein Projekt zur Implementierung des Produkts auf Apple.

Obwohl es viel mehr Aufwand bedeutet, es so einzurichten, halte ich es für möglich, dass auf lange Sicht jeder im Team versteht, was er tut. "Ich entwickle die Architektur für Produkt X". "Ich implementiere die Benutzeroberfläche von Produkt X auf Apple." usw.