come possono essere utilizzate le mappe delle storie degli utenti per i progetti con un pesante lavoro di backend e una piccola interfaccia utente

1

Sfondo

Sono un grande fan / sostenitore della mappa della storia utente di Jeff Patton. Attualmente sto leggendo il suo libro ..

Trovo che usare le mappe di storie sia un modo molto efficace per convincere i clienti a usare i principi di lean lean, costringendoli a riflettere a lungo su quali siano le funzionalità di mvp e quali dovrebbero essere rilasciate prima (cioè visualizzando le versioni e il backlog ecc.).

Problema

Il mio problema è che attualmente sto lavorando a una soluzione tecnica molto . Si tratta più di ottenere un'applicazione utente (B2C) (che ha un sacco di interfacce utente) e di crearne una versione cloud (B2B) che sarà gestita da una manciata di amministratori. Come parte della stima abbiamo capito che nella fase di MVP dovremmo usare principalmente la riga di comando e non preoccuparci troppo con l'interfaccia utente.

La mia domanda è: come possono essere utilizzate le mappe delle storie degli utenti per visualizzare un progetto come questo in cui non c'è troppa storia di un utente in corso. è per lo più roba in corso nel back-end per ridimensionare le operazioni di cui è già stata implementata un'interfaccia utente per il singolo consumatore.

Esempio

Quello che segue è un elenco di attività che vorrei mettere su una mappa utente e sto cercando di capire come definirle:

Backend/API-Basic-Setup
Backend/DB-Model/Setup
Backend/DB-Model/Credit-Cards
Backend/DB-Model/User-Data
Backend/DB-Model/Task
Backend/DB-Model/Task-Machine-Assignment
Backend/DB-Model/Cloud-State
Backend/DB-Migration
Backend/Pubsub-Setup
Backend/Provider/Abstraction
Backend/Provider/Abstraction-Min-Implementation
Backend/API/User-Data-CRUD
Backend/API/Task-CRUD
Backend/API/Task-Machine-Assignment
Backend/API/Bot-Facing-APIs
Backend/Coordination/Task-Scheduling
Dashboard/Login
Dashboard/User-CRUD
Dashboard/Task-List-Management
Dashboard/Task-Create-View
Dashboard/Task-Provisioning
Dashboard/Machines-Overview
Bot/Web-Server-Interface-Setup
Bot/Refactor-Existing-Tasks
Bot/Connect-API-To-Web-Routes
Bot/DB-State-Setup
Bot/Deploy-updates
Bot/Instance-image
    
posta abbood 23.01.2017 - 05:28
fonte

1 risposta

1

Se ho capito bene

  • hai già molte diverse implementazioni di gui per un backend-api e
  • exsting
  • si desidera modificare i dettagli di implementazione esistenti del back-end senza modificare l'API.
  • il tuo obiettivo: convertire il back-end in un'app cloud in modo che l'app sia più scalabile

La tua domanda è: In che ordine reimplementare "dettagli dell'implementazione"

La risposta è simile alla domanda: "quale codice modificare per ottimizzare le prestazioni (velocità)": misura / profilo quale codice rallenta il sistema.

Nel tuo caso, misura quale sotto-flusso di lavoro si sposta maggiormente da un servizio cloud scalabile.

Mentre le "storymap" sono un ottimo strumento per progetti agili secondo me non è adatto al tuo tipo di progetto.

nota: a mio parere una storymap è orientata al flusso di lavoro / alle funzionalità, i compiti di esempio sono orientati a componenti / moduli / architettura.

    
risposta data 23.01.2017 - 18:56
fonte

Leggi altre domande sui tag