Indipendenza e stima delle storie degli utenti che si basano sul predecessore condiviso

La soluzione corretta è il numero 2.

La stima Agile è di progettazione molto meno precisa di waterfall:

• le storie sono "promemoria per avere una conversazione" e sono incomplete e negoziabili per definizione
• l'unico scopo di stimare le storie è determinare, più o meno, cosa può essere realizzato in una iterazione, se stai usando iterazioni
Le stime
• sono fondamentalmente inutili in metodologie agili come Kanban, purché le storie siano abbastanza piccole.
• non ha senso stimare quando una serie di storie è precisamente andrà fatta: le storie cambieranno, quindi le stime dettagliate devono essere evitate per obiettivi a lungo termine.

In particolare, la creazione del database è un compito , un dettaglio di implementazione, nella prima storia che si sta per riprodurre. I compiti verranno stimati (se lo si desidera) in ore , non in punti e saranno stimati durante lo sprint e non durante la pianificazione sprint.

I punti misurano la complessità di una storia - non la quantità di lavoro, o ancor meno il tempo necessario - e nella mia esperienza sono visti come un "premio" che la squadra vince quando completano la storia. L'aggiunta di una tabella di database non aumenta la complessità complessiva. L'aggiunta di una tabella di database è un dettaglio che appare a causa del momento specifico in cui viene riprodotta la storia.

Chiede "dove vanno i 2 punti?" non ha senso Non ci sono "2 punti" per andare ovunque. La storia è sempre la stessa se è necessario creare il tavolo o no, ed è perfettamente normale e inevitabile non sapere quali sono tutti i compiti che devono essere eseguiti per completare la storia.

Quando stimolo, non so quando verrà riprodotta una storia e quale bit del database sarà sul posto quando lo suonerò, quindi non c'è modo di uscire da questa mancanza di precisione. Ancora una volta, vorrei sottolineare che questo è normale e inevitabile.

Per essere più specifici, dite:

• As an administrator I can add/modify/delete catalog items (one or more user story, doesn't matter here)
• As a customer I can search product catalog
• As a customer I can view product details

Each of this stories rely on predecessor: design and create database to store product information.

Ma questo non è vero in generale. Non hai bisogno di un database. Potresti usare, diciamo, un servizio. È possibile installare un componente open source che si prende cura di esso. Potresti decidere di utilizzare un database di documenti che non richiede la creazione di tabelle. Potresti utilizzare un servizio di ricerca preconfezionato, ecc. Ecc.

Quello che stai facendo è confondere i dettagli di implementazione con le storie. Le storie non sono requisiti. Devono essere più di alto livello! Un cliente trarrà vantaggio dalla ricerca nel catalogo prodotti e ci si aspetta che il team fornisca la soluzione più semplice che soddisfi la storia (e la definizione di fatto che hai impostato), che può o meno includere un database del prodotto.

L'impostazione del database non ha valore per il cliente da solo, quindi preferibilmente non è una storia a parte. L'implementazione del database dovrebbe essere parte della prima storia che ne ha bisogno. O, idealmente, il database viene implementato in fasi: con Ogni storia si implementa la parte necessaria per far funzionare quella storia.

(Ciò non significa che non puoi fare il design in anticipo. Probabilmente dovresti)

In generale: le dipendenze tra le storie degli utenti sono molto comuni. Il team valuterà una certa storia nell'ipotesi che qualche altra storia sia già stata fatta. (È meglio prendere nota di questo tipo di prerequisiti). Questo succede sempre. Se la pianificazione cambia e i prerequisiti di una storia non si applicano più, il team dovrebbe avere l'opportunità di riconsiderare.

Ho incontrato questo problema un numero di volte e non ho mai trovato una soluzione perfetta.

Ma ho trovato che la soluzione meno imperfetta è quella di avere una storia separata. La difficoltà sta nel modo in cui esprimerla. Devi farlo in collaborazione con l'utente, in modo che sappiano che questa storia non produce nulla di visibile, ma ti permette, il programmatore, di fornire altre storie utili per loro.

"Come proprietario di un negozio, voglio memorizzare le informazioni sui prodotti che vendo" non trasmette molto bene quel punto. Implica che l'utente finale sarà in grado di memorizzare quei dettagli.

Se i tuoi stakeholder sono bravi a capire che gli sviluppatori sono anche parti interessate nel prodotto, puoi dire loro che "come programmatore, voglio archiviare e recuperare informazioni sui prodotti che il mio cliente vende, quindi che posso completare le attività # 132, # 133, # 134. "

Quando un utente lo vede nell'iterazione corrente ma non nelle attività 132, 133 o 134, sapranno che questo non è qualcosa che puoi dimostrare a loro alla fine del iterazione, ma saranno soddisfatti del fatto che, in seguito, saranno in grado di portare a termine tali compiti, a basso costo. Questo di solito è sufficiente.

Dovresti, come ovvio, dimostrare tali compiti l'uno con l'altro, alla fine di un'iterazione, dato che sei il principale stakeholder per il compito.

Come bonus, questa mentalità porta bene alle conversazioni su storie di debito tecnico come "Come programmatore, ho bisogno di un'API migliorata per i servizi XYZ, in modo che possa svilupparmi contro di loro più rapidamente."

Nota che ho aggiunto una clausola "così" a ciascuno dei miei esempi di storie. Questa è una buona pratica per le storie, anche quando sono più chiare rispetto all'esempio di cui stiamo discutendo. Il valore aziendale di un'attività è almeno altrettanto importante di quello che l'utente deve essere in grado di fare per ottenere quel valore. Ciò diventa esponenzialmente vero quando il numero di stakeholder cresce.

Eviterei di usare le dipendenze della trama, porta a una pendenza scivolosa. Come è stato detto prima, come si sapere hai bisogno di un database. Forse un file flat o qualcosa di simile potrebbe funzionare per la tua situazione.

Creare il database in anticipo / in anticipo non è davvero una buona opzione in quanto ciò limiterà strongmente le opzioni per il codice.

Vorrei andare avanti usando Mocks, XML o qualche altro meccanismo di input dati leggero per lo sviluppo. Quindi, man mano che la progettazione generale del codice inizia ad evolversi, è possibile utilizzare Mocks / XML come base per la progettazione del database. I mock non sono gettati via, in quanto possono essere utilizzati in seguito per la convalida automatica delle modifiche al codice. Anche la creazione del database deve essere eseguita in una iterazione? È possibile rivedere la struttura di Mock con qualcuno che potrebbe creare il database basato sui mock e fornirlo in un punto concordato in futuro?

Per quanto riguarda la trama, potresti voler pensare di analizzare "Come cliente posso cercare il catalogo dei prodotti" anche oltre? Come fanno a cercare nel catalogo prodotti, per ID prodotto, Descrizione, Colore, Dimensione, Prezzo? Come scritto, direi che la storia ha un'alta probabilità di prendere più di una singola iterazione da completare.

Infine suggerirei di leggere alcuni dei materiali di Scott Ambler su [http://www.ambysoft.com/scottAmbler.html] [1]

[1]: link Scott ha lavorato molto sui database e su come si relazionano con l'agile.

Cheers!