FPA è incompatibile con Agile?

2

Attualmente sto lavorando a un progetto basato su Agile + SCRUM. Lavoro su un modulo di livello inferiore. Questo porta a un problema particolare. Il lavoro che faccio non può essere associato direttamente a una storia di utenti molte volte. Dal momento che non posso riferire direttamente una storia di un utente al mio lavoro, spesso devo affrontare il problema che le mie esigenze non sono chiare. Inoltre tendo a "perdere" alcune cose che mi sono chiare solo in ritardo nello sprint. E i miei livelli funzionano non possono essere testati direttamente.

Su una nota simile, il nostro team della GUI stava generando molti bug a causa della mancanza di requisiti impliciti minori. Ad esempio, la larghezza del campo di testo era inferiore al previsto, ecc.

In precedenza avevo usato FPA in un altro progetto e penso che sia un buon modo per abbattere i requisiti per i piccoli dettagli atomici, chiarire i punti minori e quindi costruire il software usando i punti come checklist. Ho davvero pensato che sarebbe vantaggioso per il nostro progetto e in particolare per il mio livello. L'ho suggerito nel mio meeting team bit è stato rifiutato a causa della documentazione coinvolta. La logica del "saggio": l'FPA è pesante come documentazione e Agile disapprova la documentazione pesante. Ho sostenuto che Agile riguarda la produzione di buoni prodotti e se un processo Agile non può essere modellato per aggiungere un processo che riduca i difetti e produca un buon codice, semplicemente non è "agile". Alla fine la squadra ha votato la proposta affermando che non era "Agile". tuttavia sospetto che la ragione sia più probabile che sia la pigrizia.

FPA è davvero incompatibile con Agile a causa della quantità di documentazione coinvolta? E i nobili obiettivi del Manifesto Agile? È solo "codice funzionante" o "codice funzionante buono"?

    
posta DPD 08.06.2011 - 12:53
fonte

1 risposta

3

Questo è un caso classico di un'implementazione SCRUM fuorviante. Tu (e il tuo team) dovete seguire questo principio dal punto di rottura per tornare ai cambiamenti che devono essere fatti (ricordate: SCRUM è un processo adattivo, la seconda metà delle riunioni di revisione dovrebbe essere usata per capire fuori come farlo funzionare meglio nel prossimo sprint (s)!).

Il punto di rottura è chiaramente tutti i bug sollevati dal team della GUI. C'è un altro punto di rottura nel fatto che il tuo codice non può essere testato direttamente. Entrambe indicano una definizione della storia insufficiente. Questo livello di dettaglio (lunghezza dei campi di testo, ecc.) Non deve essere fatto in anticipo, può accadere durante lo sprint, ma richiede una stretta interazione tra i membri del team e i proprietari del prodotto (si DO hanno proprietari di prodotti, giusto?). Se questa interazione ha luogo, non è richiesta alcuna documentazione aggiuntiva. Nell'interazione non avviene, quindi hai un problema e il supervisore deve intervenire.

Inoltre, se il tuo lavoro non può essere associato a storie utente, i proprietari del prodotto non stanno facendo il loro lavoro correttamente.

Ho usato SCRUM per molti anni e sono un Master SCRUM certificato. Posso dirti dall'esperienza, se segui i principi di base, funziona magnificamente. Ma devi seguire TUTTI di loro, non solo quelli che ti si addicono (in questo contesto si intende l'intero team di Scrum, inclusi i proprietari dei prodotti).

Non hai bisogno di FPA, basta correggere il tuo processo SCRUM.

    
risposta data 08.06.2011 - 13:46
fonte

Leggi altre domande sui tag