Le storie degli utenti sono troppo di alto livello e concettuali, la gestione si aspetta che gli sviluppatori riempiano gli spazi vuoti

Il trucco non è evitare che ci siano spazi vuoti. Il trucco consiste nel riempire quegli spazi il prima possibile nel processo di sviluppo.

Hai ragione nel dire che, se gli sviluppatori fanno ipotesi, saranno invariabilmente sbagliati e ciò richiederà tempo per riqualificare il software in un secondo momento. Ma, allo stesso modo, se ci si aspetta che gli uomini d'affari facciano un design completo, quando non sanno veramente cosa vogliono, succederà la stessa cosa.

È una grande parte del lavoro di uno sviluppatore capire quali sono le esigenze del cliente, quando spesso non lo sanno.

In primo luogo, fai domande. Dove le risposte che ottieni sembrano insoddisfacenti, crea un prototipo. Mostra al cliente quello che chiedono e lascia che ti dica come non è quello che vogliono veramente. Inizia con un prototipo di carta, quindi passa a uno basato su HTML, senza codice dietro di esso. Quindi esegui la minima quantità di sviluppo necessaria per produrre un prodotto quasi funzionante e mostraglielo. Lasciare i bit più complicati il più tardi possibile nel processo.

Potrebbe sembrare una perdita di tempo in sé, ma, rispetto alla riqualificazione di un prodotto apparentemente finito, non lo è.

Inoltre, mantieni le storie il più piccole possibile. Invariabilmente, ciò che l'azienda vuole è un'epopea, qualcosa che può essere suddiviso in molti risultati. Questo è meglio perché non ti sarai sviluppato troppo quando guardano il candidato al rilascio finale e urli "Oh no, non è proprio quello che stavamo cercando."

Even then finding the right thing to fill in takes time which is - to various degrees - considered as deviation from the initial estimations.

Questo non suona molto "XP" per me.

Non sono un esperto di XP, ma l'idea di AFAIK XP è di adattare continuamente le tue specifiche e la tua stima ogni volta che ricevi un feedback dal processo. E il processo è "analizza un po '- progetta un po' - codifica un po '- prova un po' - e poi ottieni feedback degli utenti per correggere le tue assunzioni sbagliate il prima possibile. Puoi anche provare a ottenere l'utente feedback ancora più presto , ad esempio, dopo aver progettato alcune parti del software (come l'interfaccia utente), su un foglio di carta o una lavagna e discuterne con un utente o un cliente . Non penso che il "modo XP" proibisca questo approccio solo perché abbiamo "storie degli utenti".

Ecco un bell'articolo su come ottenere un feedback più precoce utilizzando le specifiche. Penso che questo tipo di pensiero sia "metodologico" -indipendente, e gli argomenti presentati in questo articolo ti aiuteranno nel tuo dibattito con la gestione.

Per riassumere ci si trova nella seguente situazione:

1. Sei nuovo.
2. Il progetto (presumo che tu stia parlando di un progetto in corso) ha dei vincoli temporali precisi.
3. Lo sviluppatore deve compilare gli spazi vuoti a sua discrezione.
4. La società a cui stai lavorando intende praticare XP. però le storie degli utenti sembrano non essere applicate in un modo che si adatta alla XP metodologia. D'altra parte " lo sviluppatore dovrebbe riempire gli spazi vuoti a sua discrezione ".

Pensa al punto 4: La mia opinione è che le pratiche agili dovrebbero essere adattate ai bisogni e alla cultura di un'azienda / squadra (non viceversa). Identifica dove la società si attiene alla metodologia XP e dove devia. Questo è il fondamento per un approccio costruttivo alle tue preoccupazioni.

A causa dell'1 e del 2 non sei attualmente in una buona posizione per mettere in discussione se l'azienda applica XP in modo ragionevole. Iniziare una discussione con la direzione molto probabilmente ti porrà come qualcuno che " complica le cose ". Tuttavia puoi iniziare a discutere le tue preoccupazioni con i tuoi colleghi sviluppatori. Forse troverai alcuni sviluppatori che pensano come te. Forse c'è uno sviluppatore senior che trasmetterà quindi le tue preoccupazioni alla direzione. Ma non aspettarti che le cose cambieranno velocemente, specialmente non nel progetto attuale. Tuttavia, il progetto ti darà una buona opportunità di raccogliere più dati che aggiungono più sostanza a un approccio costruttivo.

Ora al punto 3: penso che buone storie utente siano scritte in modo collaborativo dagli sviluppatori di utenti finali / proprietari di prodotti e . Mostra qualche iniziativa: cerca qualche opportunità per chiedere direttamente agli autori le storie degli utenti. Se ciò non è possibile, chiedere a uno sviluppatore senior o alla direzione come affrontare le domande aperte a cui gli autori devono fornire una risposta. Forse puoi almeno avere una corrispondenza scritta. Dal momento che è necessario compilare gli spazi vuoti a propria discrezione, la scelta dovrebbe essere quella di coinvolgere attivamente i clienti / utenti finali / proprietari di prodotti.

Ad un certo punto hai fatto abbastanza pensieri e osservazioni su come la tua azienda applica XP (o pratiche agili in generale). Forse è già passato del tempo e non sei più percepito come un greenhorn. Forse il tuo coinvolgimento attivo con il cliente ha mostrato alcuni effetti positivi. Forse il prossimo progetto sta già iniziando. Forse hai già qualche backup da altri sviluppatori. Forse scopri che il modo in cui funziona non è affatto male. Il punto è che allora avrai abbastanza idee per trasmettere le tue preoccupazioni alla direzione, basandoti su esperienze e dati reali all'interno della tua azienda.

Francamente, le storie degli utenti non dovrebbero avere un sacco di dettagli. "Voglio che il software faccia X, per soddisfare le esigenze aziendali di Y" dovrebbe essere sufficiente. Dopotutto, non vuoi che gli uomini d'affari diano come per farlo - sei l'esperto del software e delle migliori pratiche al suo interno.

Detto questo, gli sviluppatori devono anche chiedere : "come ti aspetti che funzioni?", "cosa succede quando interagisce con la funzione Z?". Gli sviluppatori non fanno requisiti, fanno implementazione.

Sembra anche che ci sia troppo spazio tra implementazione e valutazione. Le parti interessate dovrebbero esaminare i prototipi, a metà del codice ogni pochi giorni. Ciò ti consente di ottenere un feedback prima di arrivare troppo lontano alle alghe.

Se ti viene chiesto di stimare una storia che ti sembra incompleta, fai sapere che hai domande sulla storia e che non puoi dare una stima adeguata prima che le domande abbiano una risposta.

Quindi, fai le tue domande e assicurati che le risposte diventino parte della storia.

Se sei costretto a dare una stima anche quando le tue domande non sono (tutte) risposte, puoi scegliere di rifiutare di dare una stima o di indicare chiaramente che stai assumendo i peggiori risultati possibili per gli spazi vuoti rimanenti nella tua stima (che probabilmente renderà la stima molto alta)

Quello che fai non è un modo agile di sviluppo. Invece, stai lavorando con requisiti di bassa qualità. È falso che un modo agile di sviluppo non è quello di specificare i requisiti.

Invece, devono inizialmente specificare il più possibile e, se necessario, cambiarlo più tardi. Quindi dividi il tuo lavoro in parti e implementalo nelle iterazioni. Dopo ogni iterazione, hai qualcosa finito.

La differenza rispetto allo sviluppo a cascata, è nello sviluppo a cascata, tutto è implementato con i requisiti iniziali e modificato alla fine.

Sembra che gli sviluppatori siano completamente rimossi dalla creazione delle storie degli utenti. Ti aspetti di essere in grado di leggerli come una specifica dettagliata e costruirla correttamente la prima volta? Se potessi farlo, non avresti bisogno di XP o di qualsiasi altra metodologia agile.

Qualcuno dovrebbe fare domande se la storia è troppo vaga. Dove si verifica Test di accettazione ?

Le storie degli utenti sono destinate a cambiare. Devi occupartene.

Sebbene uno sviluppatore possa scrivere una storia / requisiti dettagliati, non ho visto molti che sono bravi a farlo. siamo bravi a segnalare problemi, suggerendo flussi migliori ma come input per un caso già ben scritto.

Abbiamo lavorato su prodotti nuovi ed esistenti e con entrambi abbiamo avuto casi in cui i requisiti erano solo di 5 righe e ci aspettavamo di riempire gli spazi vuoti e fare una "comprensione" o un documento più elaborato.

I progetti si sono mossi molto meglio di quando abbiamo avuto la nostra persona di servizi professionali che ha aiutato con questo (o in un caso un VP che è intervenuto in quanto non c'era nessun altro disponibile). In entrambi i casi è una perdita di tempo da sviluppare (a meno che non ci sia un riscontro e la scadenza non sia cambiata). quindi il mio suggerimento: chiedi maggiori dettagli, fornisci altro, richiedi un feedback legato al tempo alle tue ipotesi e documentazione e dichiari che è un rischio che ci saranno rilavorazioni e ritardi se non ottieni queste informazioni entro la data x.

Indipendentemente dalla metodologia di sviluppo, se qualunque cosa si sta usando per definire i requisiti fa presupporre lo sviluppatore, deve essere rimandato al lato aziendale. Spesso ho una buona idea di quale risposta preferirei quindi riprendo le cose in questo modo:

XYZ non è chiaro per me. Significa ABC? Oppure mi sfugge qualcosa? (Supponiamo che XYZ sia il requisito, supponiamo che ABC sia l'assunto che vorrei fare come sviluppatore)

Ci vuole molto meno tempo per chiarire le cose prima di fare ipotesi sbagliate piuttosto che rifare. Gli sviluppatori che fanno supposizioni sui requisiti senza ottenere conferma che la loro ipotesi è giusta tendono ad essere sviluppatori cattivi e costano alla loro azienda un sacco di soldi. Se un cattivo manager non ti lascerà scacciare le cose, allora spiegagli quanto è più costoso in termini di tempo e denaro è farlo male. Se insiste ancora, allora fa quello che dice e quando fallisce UAT, la prossima volta che vuoi dare un calcio indietro, ricordagli quanto è stato costoso il momento in cui non ti avrebbe permesso. Se continua a non ascoltare, trova un capo migliore.

L'altro valore del respingere le cose è che, gradualmente, l'azienda apprenderà ciò di cui hai bisogno e ti fornirà requisiti migliori.

As a developer,

I need to fully understand the specifics of a user story,

so that I can confidently estimate and implement it.

In altre parole, devi porre domande finché non comprendi le specifiche della storia. Questo viene fatto nella pianificazione delle iterazioni e agisce come un punto di decisione: se non puoi stimarlo, non puoi costruirlo.