Implementazione della mischia, ma per la prima volta: come gestire i prerequisiti tecnici?

Naturalmente è necessario disporre di alcuni prerequisiti tecnici prima di poter avviare un progetto. Ad esempio, è necessario un ambiente di lavoro solido, una decisione sulla tecnologia da utilizzare (linguaggio di programmazione, framework ecc.). Decisioni errate all'inizio del progetto potrebbero rallentare o addirittura causare il fallimento del progetto, quindi si dovrebbe essere molto intelligenti su di loro. È responsabilità del team prendere la decisione migliore lì.

Non spendere troppo tempo su di esso però. Il vero lavoro è finire le cose per il cliente. E questo si ottiene solo creando funzionalità rivolte al cliente, non progettando alcuni dettagli dell'applicazione o creando l'infrastruttura di cui il progetto ha bisogno per essere eseguito.

troverai sempre qualcosa da modificare nello schema DB che non è ancora perfetto. O semplicemente non c'è abbastanza infrastruttura di test, ancora. Questo è non un particolare "inizio del problema del progetto" . Lo stesso vale per l'architettura. Scegli come target ridimensionare l'architettura anziché progettare molto in anticipo . Ci sono un bel discorso di Mich Lacey su esattamente questo argomento che consiglierei di vedere. Illustra come potresti avvicinarti a questo.

Crea una mentalità in cui ti concentri sulla rifinitura e non sulla lucidatura e pensa a ogni dettaglio tecnico esattamente come quello che è: un dettaglio tecnico. Non interessa il cliente (e non dovrebbe interessare il cliente) un solo bit.

Tratta come qualsiasi altra storia. Avere un design stabile avvantaggia il cliente. Avere schema design avvantaggia il cliente. Descrivi cosa hai bisogno di fare e quali sono i risultati finali. Assegna loro la priorità tra lo staff tecnico e i proprietari del prodotto, quindi estraili e completali.

Un'altra cosa da considerare è che queste storie tecniche sono simili ai problemi tecnici del debito che probabilmente hanno più commenti / ricerche su di loro.

Sono preoccupato che tu abbia separato il progetto / API dalle storie degli utenti - è una buona idea considerare come le cose si evolveranno, ma ritengo che questo lavoro dovrebbe essere incorporato nelle storie, non segregato da esso.

Mi sembra che tu abbia paura delle parole "potenzialmente spedibili". Questo NON significa che ciò che costruisci possa essere spedito al cliente da utilizzare, ma semplicemente che il risultato dello sprint è in realtà 'Fatto' - cioè testato e qualità di produzione.

Può essere il caso in progetti più grandi che il primo sprint / s il risultato non ha assolutamente alcun significato per il cliente, ma se puoi almeno dire 'Questo database è stato costruito in modo che possiamo fare X' o qualcosa di simile , o addirittura eseguire test unitari che mostrano 100 piccole luci verdi, dovrebbero capire che l'utilità seguirà presto.

Se stai lavorando su qualcosa come la scelta e l'impostazione del controllo del codice sorgente, direi che non sei ancora operativo. Un'analogia sarebbe che un ristorante deve preparare la sua cucina prima di servire i clienti. Potresti ancora utilizzare il processo di scrum, ma l'attenzione si preparerebbe a iniziare invece di soddisfare le esigenze dei clienti.

"Abbiamo alcuni prerequisiti per il codice prima di poter iniziare a lavorare sulle storie." La frase precedente taglia al centro del problema. Stai pianificando di lavorare su qualcosa per il cliente, ma quello su cui stai lavorando non è una storia.

È importante lavorare su ciò di cui il cliente ha bisogno.

Ti suggerisco di convalidare con il proprietario del prodotto che hai ragione nel ritenere che non si aspettano qualcosa in due settimane. Che si dica si o no, l'importante è che tu sia in linea con il cliente.

In base a ciò che dice il proprietario del prodotto, suggerisco una delle due opzioni

1. Se il progetto ha bisogno di fare qualcosa in fretta o è probabile che cambi i requisiti in futuro, suggerirei di fare solo un design sufficiente per soddisfare la storia corrente dell'iterazione.

2. Se il progetto ha una quantità di storie abbastanza alta (3 mesi di lavoro o più) utile o non è probabile che cambi i requisiti in futuro, considera la struttura del database come un picco. Il rischio per il cliente è che si possa progettare qualcosa che il cliente decide di non implementare.