Come faccio a convincere un proprietario del progetto a partecipare ai test di accettazione?

3

Ho iniziato a utilizzare Tracker pivotal per un progetto su cui sto lavorando. Concettualmente, questo sembra davvero interessante e mi interessa usare il modello agile. Tuttavia, ho un problema con tutto ciò di cui si parla nel video.

Alle 4:19 nel video collegato parlano di accettazione della storia e di come dovrebbe essere fatto dal proprietario del progetto. Questo concetto suona molto bene sulla carta, ma non sono sicuro di poter effettivamente convincere il proprietario del progetto a sedersi e provare anche la metà delle nuove funzionalità che creo, per non parlare di tutte.

La mia domanda è: come ti avvicini al proprietario di un prodotto sul lavoro che questo sapore del modello Agile richiede loro? Cosa fai se si rifiutano di partecipare ai test di accettazione?

    
posta AlexLordThorsen 05.02.2014 - 00:42
fonte

1 risposta

9

Quello che stai citando è un classico problema che molte aziende hanno introdotto uno sviluppo agile.

Sfortunatamente, non esiste una soluzione facile.

  1. Per il problema specifico dell'accettazione, la soluzione "standard" consiste nel fatto che qualcuno del team agisce come proxy per il proprietario del prodotto. Questo non è un granché, ma può funzionare fintanto che questa persona si prende cura di dimostrare regolarmente al proprietario in modo da mantenere la stessa percezione di ciò che è accurato.

  2. I proprietari dei prodotti dovrebbero collaborare quotidianamente con il team. Questo perché in genere le unità di lavoro (cioè le storie) sono negoziate durante lo sviluppo. Per esempio. un'interfaccia utente per una storia non è stata progettata in anticipo. Il suo design viene negoziato durante lo sviluppo, quindi le decisioni di progettazione vengono convalidate su una soluzione di lavoro anziché su un foglio di carta. Non c'è una soluzione facile qui. Se tutto è deciso in anticipo, ci saranno problemi di qualità o inefficienze, perché è davvero difficile progettare tutto in anticipo.

  3. Spesso manca la chiarezza su cosa sono i test di accettazione di una user story. Un proprietario di un prodotto assente spesso non fornirà test di accettazione sufficienti o nessuno per chiarire quali sono gli obiettivi finali "in bianco e nero" di una storia. Sfortunatamente, questo significa che qualcuno nel team, possibilmente una persona di controllo qualità, sostituirà gradualmente il PO su questo argomento e questa non è una buona soluzione, dal momento che molti di questi test sono abbastanza arbitrari e spesso i team finiscono per dissentire quando un la storia è completa.

  4. Probabilmente il problema più grande, tuttavia, è la mancanza di agilità. Avere una serie di storie e un'idea "perfetta" di un prodotto non è una buona implementazione di agile. Se tutto ciò che devi fare è noto in anticipo, probabilmente non hai bisogno di questa metodologia. Il punto di forza dell'agile è che massimizza il valore offerto cambiando lo scopo e la direzione del progetto in volo per sfruttare l'aumento della conoscenza del prodotto acquisita durante lo sviluppo. Se non c'è nessuno che guidi questo processo, non c'è praticamente alcuno sviluppo con una metodologia solo "teoricamente" agile.

risposta data 05.02.2014 - 01:24
fonte