Sviluppo agile e modello di requisiti standard

4

So che c'è una netta differenza tra una specifica del requisito e una user story. Tuttavia, nella nostra azienda, molti dei requisiti possono essere definiti in un modello standard. Questo vale per le applicazioni aziendali di piccole e medie dimensioni basate su un singolo sito di SharePoint. Ho scoperto che è molto più semplice utilizzare un documento Excel standard con fogli per:

  • Gruppi di autorizzazioni
  • Gestione degli accessi
  • Elenchi + più definizione (colonne, impostazioni, ecc.)
  • Librerie (colonne, impostazioni, permessi, ecc.)
  • Flussi di lavoro.

Quindi fondamentalmente in un documento Excel standard, posso descrivere tutti i requisiti per una determinata soluzione.

  • È più semplice definire e ottenere l'accettazione da parte dell'utente.
  • È più facile da sviluppare
  • È più facile testare

La domanda è come questo si trasferirà nelle User story? Penso che sia troppo grande per tenere in una storia utente, ma dall'altra parte, non voglio rompere il foglio di Excel in più sezioni. Quindi, come si dovrebbe lavorare con i modelli di requisiti standard, mentre si attacca al manifesto di Agile?

    
posta CADmageren 14.06.2017 - 15:18
fonte

2 risposte

4

Lavora con gli sviluppatori

La soluzione migliore qui è avere una conversazione con i tuoi sviluppatori. Scopri i motivi per cui vogliono storie e condividi con loro i motivi per cui non vuoi darli a loro. Siate pronti a scendere a compromessi, e siate consapevoli che come parte di una squadra agile avete un solo voto.

Penso che il tuo obiettivo, soprattutto perché sembra che tu stia appena imparando lo sviluppo agile, sia ottimizzare per la squadra e non solo per te stesso. Fa schifo che potrebbe significare più lavoro per te, ma il team esiste per costruire prodotti, e se il modo più efficiente per farlo è con le storie, allora dovresti dare loro delle storie.

Le storie sono un modo molto efficace per descrivere piccole unità di lavoro. Come proprietario del prodotto, puoi certamente utilizzare un foglio di calcolo per gestire il tuo lavoro, ma il lavoro che il team di sviluppo deve basarsi su storie se stai facendo uno sviluppo agile 1

Penso che sia necessario continuare a creare le story card per il team, ma forse è possibile aggiungere alla story card le righe del foglio di calcolo che la carta rappresenta, in modo da poter tenere traccia di quali storie sono per quali requisiti.

Le storie sono maggiori della somma delle loro parti

Le story card sono molto più di un lavoro impegnativo richiesto da una metodologia. Forniscono un valore reale al team costringendo il team a definire o riconoscere a chi è destinata una funzione e qual è il valore aziendale. Anche se i dati vengono ripetuti su 20 carte, aiuta a rafforzare il motivo per cui la storia è importante. Aiuta a mantenere il cliente sempre presente nelle menti degli sviluppatori.

Oltre a ciò, le story card sono un eccellente punto focale per gli stand-up quotidiani. Invece di guardare una riga in un foglio di calcolo, puoi avere un oggetto reale, tangibile da tenere in mano e da interagire. Che ci crediate o no, c'è una vera spinta psicologica dall'essere in grado di spostare fisicamente una carta storia in una colonna "fatta" - qualcosa che semplicemente non si ottiene digitando una stringa in una colonna su un foglio di calcolo.

1 Ok, se sei veramente agile, il team può fare tutto ciò che funziona meglio per loro. In tal caso, si tratta di una decisione del team, non di una decisione del proprietario del prodotto, né di una decisione di persone su Internet. Lascia che il team ti dica cosa funziona meglio per loro, poi dai loro quello e resta fuori dai piedi: -)

    
risposta data 14.06.2017 - 22:40
fonte
5

Il manifesto per lo sviluppo di software agile non dice nulla sui metodi. Questo, insieme ai principi su cui si basa , parla di cose come persone e interazioni favorite da processi e strumenti, collaborazione sulla negoziazione del contratto, rispondere al cambiamento dopo aver seguito un piano.

È assolutamente soddisfacente seguire un modello di sviluppo agile e utilizzare i tuoi strumenti e formati attuali per acquisire i requisiti. Tuttavia, guarda come ti adatti alle istanze quando cambiano tali requisiti e come trasmetti le informazioni tra i membri del team o tra il team e gli altri stakeholder.

    
risposta data 14.06.2017 - 15:26
fonte

Leggi altre domande sui tag