Come faccio a creare un potenziale prodotto (PSP) alla fine di uno sprint?

Naviga le tue risposte
3

Gestisco un team di 4 sviluppatori e 2 tester e cerco di rispettare il principio Scrum di creare una PSP con ogni sprint. Ciò significa che ho bisogno di creare una versione potenziale con tutte le storie degli utenti che sono state completate e archiviate su alcuni server di pubblicazione affinché l'ordine di acquisto faccia ciò che desiderano.

Il mio problema è come creare tecnicamente la build quando alcune storie non sono completate alla fine dello sprint? Il codice è archiviato, ma non ha completamente superato il test.

Se faccio solo il codice di check-in che è Fatto, cioè codice sottoposto a revisione completa, mi imbatto nella possibilità di divergere basi di codice e fusioni che potrebbero essere disastrose. Ad esempio, gli sviluppatori A e B lavorano su diverse funzionalità che modificano l'assembly X. Dev A termina la codifica, spinge l'assembly X a testare. Il giorno dopo Dev B termina la codifica e spinge l'assemblaggio X a testare. La caratteristica A ritorna con errori, la caratteristica B è perfetta. Oops, lo sprint è finito. Ora, come posso creare una PSP con la funzione B, ma non A?

    
posta Ninjarabbi 20.12.2011 - 10:12
fonte

4 risposte

2

La chiave è:

  • codice pulito e ben organizzato
  • buon controllo del codice sorgente (probabilmente distribuito) che supporta la ramificazione e l'unione automatizzata
  • suite di test automatizzata
  • integrazione continua che può crescere fino alla consegna continua

Puoi:

  • Crea tutto nel bagagliaio e ripristina tutte le storie incomplete (dopo la ramificazione) dal bagagliaio. Questo può avere un impatto significativo sulla base del codice, specialmente se le storie richiedevano grandi cambiamenti al codice condiviso.
  • Utilizza il ramo per ogni nuova storia e uniscilo solo quando la storia è terminata. Ha un problema significativo. La storia è testata in modo isolato e il feedback viene raccolto lentamente ma ciò è la pratica più semplice. I grandi aiutanti sono buoni strumenti e buoni codici / test.
  • Sviluppa tutte le storie degli utenti nel bagagliaio e mantieni il prodotto spedibile nella filiale. Risolve il problema con l'isolamento, ma ha elevate esigenze sulla strategia di fusione che può essere molto difficile in caso di modifiche al codice condiviso.
  • Combinazione. Tenere il prodotto spedibile nel bagagliaio e lo sviluppo delle storie nei rami. Unisci tutti i commit tra rami e trunk (ogni ramo deve sempre avere l'ultimo codice commit dagli altri). Assicurati che le nuove funzionalità nel trunk siano disponibili per l'utente finale solo dopo aver completato l'intera storia.

Nell'ultima opzione spedirai storie incomplete ma non saranno disponibili per l'utente - solo il loro codice esisterà nella tua base di codice. Il requisito è che tutte le storie degli altri utenti debbano funzionare.

Ho anche usato una soluzione molto più semplice (ma non simile a Scrum). Non abbiamo rimosso le storie incomplete se non hanno infranto le storie completate. Nella riunione di revisione abbiamo appena detto che non siamo stati in grado di completare queste storie e che non dovrebbero essere utilizzate perché non funzionano. Questa opzione è possibile solo in caso di rilasci interni in cui l'utente finale convalida solo storie completate e non utilizzerà il prodotto per il lavoro reale subito dopo lo sprint.

    
risposta data 20.12.2011 - 12:21
fonte
4

Il problema principale qui è storie non fatte alla fine dello sprint. Questo è il problema che dovresti provare a risolvere.

In altre parole, chiedi al team "come possiamo finire tutte le mie storie entro la fine dello sprint?" non "come possiamo adattare il nostro processo per gestire le mie storie a metà completate".

    
risposta data 20.12.2011 - 14:54
fonte
3

La chiave è di non permettere al codice di "rompere la build". In altre parole, non controllare il codice che non supera il test. Se esegui un ciclo di build / test automatico notturno, tutto dovrebbe essere automatizzato per te.

Il codice che fallisce verrebbe comunque memorizzato nel repository come un ramo, non sarebbe solo parte della PSP.

In particolare, dovresti utilizzare le pratiche di integrazione continua e un sistema di controllo del codice sorgente come Mercurial ( KILN ) progettato per supportare questo.

    
risposta data 20.12.2011 - 11:26
fonte
0

Dev A finishes coding, pushes assembly X to test. The next day Dev B finishes coding and pushes assembly X to test. Feature A comes back with bugs,

Presupposti Caratteristica Le storie hanno test di unità / accettazione / integrazione.

Lo sviluppatore B controlla il suo codice in un'area di staging ... se tutti i test passano, incluso quello per la caratteristica A, il codice della caratteristica B viene automaticamente unito alla produzione ..

puoi fare sopra con Distributed Version Control

    
risposta data 13.02.2012 - 18:16
fonte

Leggi altre domande sui tag

Disegno Ellisse da un riquadro di delimitazione? Perché mantenere la chiusura del wrapping in ogni js-file se può essere aggiunto dopo la concatenazione?