I bug di correzione possono portare a feedback ritardati [chiuso]

Question

I bug di correzione possono portare a feedback ritardati [chiuso]

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)

0

Ho lavorato in un gruppo di Microsoft che ha sviluppato l'aggiornamento all'antivirus di Microsoft Security Essentials. Per un anno abbiamo lavorato alla prossima versione del prodotto. Abbiamo avuto 6 traguardi (pietra miliare ogni due mesi). La maggior parte delle funzionalità sono state sviluppate nelle prime pietre miliari e per la seconda parte dell'anno queste caratteristiche sono state perfezionate e sono stati corretti errori. Ogni pietra miliare di una porzione più ampia di utenti (abbonati ai vari programmi alpha / beta) otterrebbe il prodotto e fornirà un feedback.

I responsabili del programma mi hanno detto che il vantaggio di questo approccio è che c'è più tempo per i potenziali utenti di dare un feedback sulle funzionalità, quindi è preferibile spedire tutte le funzionalità il prima possibile.

Tuttavia Scrum non difende questo approccio. In Scrum si consiglia di fornire un software software completamente testato e funzionante e non funzioni scadenti e fragili. Questo approccio ha vari vantaggi, ma presenta anche alcuni inconvenienti. Uno di questi è che il feedback è in ritardo.

Quindi quale approccio preferisci e perché?

bug scrum

posta Eugene 14.02.2014 - 12:25

fonte

3 risposte

Leggi altre domande sui tag bug scrum

Rendere un algoritmo più efficiente Trova tutte le intersezioni dei segmenti di linea

score 5 · Answer 1

"In Scrum ti viene consigliato di consegnare un pezzo di software completamente testato e funzionante e non di funzionalità semisvenute e fragili"

Sembra che tu stia confondendo il feedback degli utenti - a loro piacciono le funzionalità che sono state consegnate, trovano utile, soddisfa un bisogno, ha degli errori arcani quando (male) utilizzati in modi che gli sviluppatori non hanno anticipare - con prestazioni di base, stabilità e correttezza funzionale. Scrum fa eco all'agile manifesto che pretende di valutare il software di lavoro, con l'accento sul WORKING nel senso che fa ciò che il product owner ha chiesto a voi. Il feedback degli utenti è quindi prezioso solo perché allinea la visione del proprietario del prodotto con il mercato. Se spedisci software non funzionante, il feedback dell'utente sarà prevedibilmente "WTF?".

score 1 · Answer 2

Sembra che per loro questo sia il driver principale.

L'utente fornisce funzionalità di "vita reale" e informazioni sull'usabilità.

Quindi ottengono la caratteristica di base e migliorano il risultato inserendo input su di essa, al contrario del primo approccio corretto che forse presuppone che siano state messe in primo piano ulteriori analisi dei requisiti.

score 1 · Answer 3

Potresti fare una discussione per sovra-ingegnerizzare questo progetto basandoti sui tuoi commenti alla risposta di Julia Hayward. (Penso che molto dovrebbe essere nella domanda.)

Well, when I said "ship" I meant ship to alpha/beta users or not even ship at all but simply deliver the software for usability tests.

In questo caso, sembra che il gestore del programma sia più il proprietario del prodotto e che sia autorizzato ad accettare funzioni semi-elaborate.

So yes, it will be only partially functional, not pretty, with some bugs, but at least an important feedback can be generated so the team will know if its in the right direction.

Quindi ora puoi prendere quella "caratteristica A" appena sfornata e trasformarla in un'altra richiesta che richiede: controllo degli input, test degli errori, uso del nuovo design della GUI, ecc.

Quando passi attraverso questa rotta alpha / beta, non è il tuo codice che è cotto a metà, sono le storie degli utenti. Soddisfa solo la storia dell'utente in modo che superi l'approvazione del proprietario del progetto.