Le storie dovrebbero essere utilizzabili?

6

Sono nuovo di Agile come metodologia, anche se credo che abbia una conoscenza basilare dei suoi principi.

Il mio team sta attualmente costruendo un framework che supporterà l'applicazione del nostro cliente in futuro. Come input, abbiamo un sacco di requisiti e anche un suggerimento su come l'applicazione dovrebbe essere implementata, ad un livello MOLTO alto.

Come approccio, abbiamo deciso di utilizzare alcuni sprint per comprendere i requisiti prima di realizzare effettivamente il sistema. Il nostro output è più documenti che descrivono il sistema da costruire.

Dopo il primo sprint ho iniziato a chiedermi se questo non sta violando i principi Agile, dal momento che i nostri output (documenti) non sono testabili o un obiettivo del progetto in sé, solo sottoprodotti intermedi.

    
posta Bruno Brant 04.05.2016 - 01:19
fonte

4 risposte

2

Chi dice che l'output di uno sprint è solo codice?

Uno dei deliverable di sprint può essere la documentazione :

Once the team gets a business goal, it:

  • Figures out how to do the work
  • Does the work
  • Identifies what's getting in its way
  • Takes responsibility to resolve all the difficulties within its scope
  • Works with other parts of the organization to resolve concerns outside their control

L'enfasi sopra è mia.

Sebbene la documentazione non sia uno degli output preferiti, è un'opzione.

    
risposta data 04.05.2016 - 06:35
fonte
2

Il pericolo è ovviamente che una volta che i documenti sono completi, li si implementa a cascata.

Penso che il tuo approccio non sia probabilmente buono. Le metodologie di Aglie sono una risposta ai problemi generati pianificando tutto in anticipo e mi sembra che tu stia cercando di pianificare tutto in anticipo.

Invece di wtiting il documento che descrive il framework. Scrivi il quadro! Se non funziona come richiesto, fai un altro sprint con il requisito raffinato

    
risposta data 04.05.2016 - 14:40
fonte
2

Quando l'obiettivo del tuo progetto è quello di sviluppare un framework per sviluppare in seguito le applicazioni per gli utenti finali, non stai scrivendo l'applicazione per l'utente finale. I tuoi utenti non sono gli utenti finali. I tuoi utenti sono sviluppatori futuri e qualsiasi storia utente dovrebbe essere scritta dal loro punto di vista.

Tuttavia, i motivi per cui i tuoi utenti useranno il tuo framework sono perché loro stanno implementando una storia di un utente finale. Ciò significa che puoi avere una sorta di "storia in una storia" sotto forma di una storia di un utente finale che porta a uno sviluppatore che desidera utilizzare il framework per implementarlo.

The programmer receives a user-story which reads "the user clicks on a red button to close the window". However, in the current version that button still has the defalut color. So the programmer searches the sourcecode for a call to closeButton = new Button() and adds the line closeButton.SetColor( red ) after it.

Questa storia ti dice che tipo di requisiti i tuoi utenti (i programmatori) dovranno affrontare e come progetterai il tuo framework in modo tale che tali requisiti possano essere facilmente implementati.

    
risposta data 04.05.2016 - 14:50
fonte
1

Il punto principale di Agile è iterare invece di fare il grande design in primo piano. Tuttavia, devi ancora avere i requisiti per il prodotto minimamente fattibile che dovrebbe essere documentato in qualche formato: specifiche, storie degli utenti, qualsiasi cosa funzioni per il tuo team.

È molto più facile / veloce correggere i problemi nei requisiti piuttosto che rielaborare \ buttare fuori codice già implementato.

IMHO, se un cliente mi chiede di costruire un edificio, dovrei sapere se il cliente vuole un capannone, una casa, un edificio per uffici o un centro commerciale. Probabilmente dovrei anche sapere che tipo di fondazione vuole il cliente. Di che colore dovrebbe essere il tetto, e il colore delle pareti è un requisito che può essere inchiodato in un secondo momento.

    
risposta data 04.05.2016 - 17:51
fonte

Leggi altre domande sui tag