Come organizzeresti un articolo del backlog che si prevede di cambiare nelle versioni future?
Ho un requisito che afferma che: Nella versione 1 gli utenti possono aprire il contenuto da macchine locali. Nelle versioni future gli utenti possono aprire contenuti da server remoti, FTP e web stream.
È tipico creare solo 2 elementi di backlog per descrivere questo requisito. Quindi assegna il miglioramento a una versione futura?
(Utilizzo di TFS per qualsiasi risposta contestuale)
Questo non è un requisito, ma 4 requisiti. Una delle caratteristiche di un buon requisito è che è coesa: si rivolge a una, e solo una, caratteristica funzionale o non funzionale del sistema. Io enumererei ciascuno di questi come requisiti o storie utente separati per promuovere la tracciabilità e la verifica:
- Users can open content from local machines.
- Users can open content from remote servers.
- Users can open content via FTP.
- Users can open content via web streams.
Ora che hai quattro storie utente, puoi trattarle come quattro entità separate, con le loro stime, le loro priorità e così via.
Un rilascio in cui distribuire la funzionalità non è un requisito del sistema, ma una misura di priorità, quindi la storia per essere in grado di aprire il contenuto da macchine locali è posta prima delle altre nel product backlog (probabilmente vicino la cima, quindi sarebbe in uno sprint iniziale). Gli altri possono avere la priorità in caso di caduta rispetto ad altre funzionalità.
La separazione promuove anche una migliore relazione dal requisito / la storia dell'utente ai casi di test che verificano la funzionalità e dà al cliente e all'utente la possibilità di dare la priorità alle quattro modalità operative nel caso in cui non è possibile consegnarle tutte nel stesso sprint.
Sì, sicuramente hanno diverse User Story per le due diverse funzionalità che hai descritto.
Le User Story sono più piccole e praticamente possibili, a patto che siano individualmente testabili, ognuna delle quali suona come è.
In effetti, anche se non stavi pianificando le 2 funzionalità che descrivi sopra per essere in versioni diverse, avrei comunque 2 User Story.
L'unica sfida che questo introduce è che né Scrum né TFS includono un modo efficace per gestire qualsiasi dipendenza che Story-2 abbia su Story-1 dopo averlo fatto per primo. Per gestirlo, quando si usa TFS, la mia squadra registra sull'articolo Story-2 che Story-1 deve essere fatto per primo. Creiamo anche un collegamento tra le due User Story in TFS, anche se è facile trascurarlo nell'interfaccia utente di Visual Studio TFS.
Le storie degli utenti non sono descrizioni del prodotto finale che viene creato. Descrivono le unità di lavoro. O, forse più esattamente, sono segnaposto per una conversazione su un'unità di lavoro. Una storia definisce ciò che vuoi costruire per l'iterazione corrente.
Se sai che stai costruendo una funzione nel tempo, la storia su cui lavori ora descriverà solo la funzione come desideri entro la fine di questa iterazione. Se la funzione evolverà nel tempo, avrai bisogno di una storia (o più) per ogni fase della sua evoluzione.
Leggi altre domande sui tag agile scrum team-foundation-server