Le storie degli utenti sono troppo alte e concettuali, la direzione si aspetta che gli sviluppatori riempiano gli spazi vuoti

Sono impiegato in un'azienda molto brillante con una vera intenzione di fare XP. La comunicazione è buona e la gestione è aperta a discussioni costruttive, ma a causa di pressanti vincoli temporali, alcune cose sono considerate troppo RUP per essere discusse.

Al momento sono un po 'turbato dal volume di cambiamento che diventa necessario durante l'implementazione delle storie. Credo che molte di queste scoperte (che richiedono tempo e fatica ovviamente) siano responsabilità degli autori di storie (clienti, utenti finali e proprietari di prodotti) e non degli sviluppatori. Per farla breve, le storie degli utenti sono troppo concettuali e trasmettono semplicemente l'intenzione di base ma mancano di dettagli sufficienti (specialmente pre-condizioni e post-condizioni, pertinenza con altre storie, dipendenze e simili). Lo sviluppatore dovrebbe riempire gli spazi vuoti a sua discrezione in virtù del fatto che gli sviluppatori XP sono designer e analisti allo stesso tempo. Il problema è che molti di questi spazi vuoti vengono scoperti dopo che alcune ipotesi errate si sono fatte strada nel tempo e nel codice di valutazione poiché si notano complessità aggiuntive rispetto a quanto inizialmente previsto. Anche in questo caso, trovare la cosa giusta da compilare richiede tempo che, a vari livelli, viene considerato come una deviazione dalle stime iniziali.

Sto cercando un modo costruttivo di trasmettere queste implicazioni al management in un modo che non mi ponga come qualcuno che sta cercando di complicare inutilmente le cose. Sono nuovo e non ho ancora stabilito molta credibilità.

I tuoi approfondimenti sono i benvenuti.

Strettamente correlato e in qualche modo dà una risposta: quanti dettagli su una user story può aspettarsi uno sviluppatore?

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

Hai ragione nel dire che, se gli sviluppatori fanno ipotesi, invariabilmente sbaglieranno e ciò costerà tempo a riqualificare il software in un secondo momento. Ma, allo stesso modo, se ci si aspetta che gli uomini d'affari facciano un progetto completo quando non sanno davvero cosa vogliono, accadrà la stessa cosa.

È una grande parte del lavoro di uno sviluppatore capire cosa vuole il cliente, quando spesso non lo sa davvero.

Innanzitutto, fai domande. Dove le risposte che ottieni sembrano insoddisfacenti, crea un prototipo. Mostra al cliente quello che sta chiedendo e lascia che ti dica come non è quello che vuole veramente. Inizia con un prototipo cartaceo, quindi passa a uno basato su HTML, senza codice. Quindi fai il minimo sviluppo necessario per produrre un prodotto quasi funzionante e dimostralo. Lasciare i bit più delicati il ​​più tardi possibile.

Ciò potrebbe richiedere molto tempo in sé ma, rispetto alla riqualificazione di un prodotto apparentemente finito, non lo è.

Inoltre, mantieni le storie il più piccolo possibile. Invariabilmente, ciò che l'azienda desidera è un'epopea, qualcosa che può essere suddiviso in molti risultati. Questo è meglio perché non ti sarai sviluppato troppo quando guarderanno il candidato alla versione finale e urleranno "Oh no, non è proprio quello che stavamo cercando."

Anche in questo caso, trovare la cosa giusta da compilare richiede tempo che, a vari livelli, viene considerato come una deviazione dalle stime iniziali.

Non mi sembra molto "XP".

Non sono in alcun modo un esperto di XP, ma l'idea di AFAIK XP è di adattare continuamente le vostre specifiche e le vostre stime ogni volta che ottenete feedback dal processo. E il processo è "analizzare un po '- progettare un po' - codificare un po '- testare un po' - e quindi ottenere il feedback degli utenti per correggere i presupposti sbagliati il ​​più presto possibile. Puoi anche provare a ottenere il feedback degli utenti 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 averne discusso con un utente o un cliente . Non credo che il "modo XP" vieti tale approccio solo perché " storie degli utenti ".

Ecco un bell'articolo su come ottenere feedback più presto usando le specifiche. Penso che questo tipo di pensiero sia indipendente dalla "metodologia" e gli argomenti presentati vi aiuteranno nel vostro dibattito con il management.

Per riassumere ci si trova nella seguente situazione:

1. Sei nuovo.
2. Il progetto (suppongo tu stia parlando di un progetto in corso) ha vincoli temporali urgenti.
3. Lo sviluppatore dovrebbe riempire gli spazi vuoti a sua discrezione.
4. La compagnia in cui lavori intende esercitare XP. Tuttavia, le storie degli utenti sembrano non essere applicate in un modo che si adatta alla metodologia XP. 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 / gruppo (non viceversa). Identifica dove l'azienda si attiene alla metodologia XP e dove si discosta. Questa è la base per un approccio costruttivo alle tue preoccupazioni.

A causa di 1 e 2 non sei attualmente in una buona posizione per chiederti se la società applica XP in modo ragionevole. Avvio di una discussione con il management molto probabilmente ti metterà come qualcuno che " complica le cose ". Tuttavia, puoi iniziare a discutere delle tue preoccupazioni con i tuoi colleghi sviluppatori. Forse troverai alcuni sviluppatori che la pensano come te. Forse c'è uno sviluppatore senior che poi trasmetterà le tue preoccupazioni alla direzione. Ma non aspettarti che le cose cambino rapidamente, soprattutto non nel progetto attuale. Tuttavia, il progetto ti darà una buona opportunità per raccogliere più dati che aggiungono più sostanza a un approccio costruttivo.

Passiamo ora al punto 3: penso che le storie di buoni utenti siano scritte in collaborazione da clienti / utenti finali / proprietari di prodotti e sviluppatori. Mostra qualche iniziativa: cerca qualche opportunità per chiedere direttamente agli autori le storie degli utenti. Se ciò non è possibile, chiedere ad alcuni sviluppatori senior o al management come affrontare le domande aperte a cui devono rispondere gli autori delle storie degli utenti. Forse puoi almeno avere una corrispondenza scritta. Poiché è necessario compilare gli spazi vuoti a propria discrezione, la scelta dovrebbe essere quella di coinvolgere attivamente i clienti / utenti finali / proprietari dei 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 cervo. Forse il tuo coinvolgimento attivo con il cliente ha mostrato alcuni effetti positivi. Forse il prossimo progetto sta già iniziando. Forse hai anche un po 'di backup da altri sviluppatori. Forse scoprirai che il modo in cui funziona non è affatto male. Il punto è che poi avrai abbastanza idee per trasmettere le tue preoccupazioni al management, sulla base di esperienze e dati reali all'interno della tua azienda.

Francamente, le storie degli utenti non dovrebbero avere molti dettagli. "Voglio che il software esegua X, per soddisfare le esigenze aziendali di Y" dovrebbe essere sufficiente. Dopotutto, non vuoi che gli uomini d'affari dettino come farlo: sei l'esperto del software e delle migliori pratiche in esso.

Detto questo, gli sviluppatori devono anche chiedere : "come ti aspetti che funzioni?", "Cosa succede quando questo interagisce con la funzione Z?". Gli sviluppatori non impongono requisiti, ma implementano.

Sembra anche che ci sia troppo spazio tra implementazione e valutazione. Le parti interessate dovrebbero guardare i prototipi, il codice mezzo fatto ogni pochi giorni. Ciò ti consente di ricevere feedback prima di andare troppo lontano nelle erbacce.

Se ti viene chiesto di stimare una storia che ti sembra incompleta, fai sapere che hai delle domande sulla storia e che non puoi fornire una stima adeguata prima di rispondere a tali domande.

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

Se sei costretto a fornire una stima anche quando le tue domande non ricevono (tutte) una risposta, puoi scegliere di rifiutare di fornire una stima o di indicare chiaramente che stai assumendo i risultati peggiori possibili per gli spazi vuoti rimanenti nella stima (che probabilmente renderà la tua stima un valore più alto).

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, modificarli in seguito. Quindi dividi il tuo lavoro in parti e implementalo in iterazioni. Dopo ogni iterazione, hai finito qualcosa.

La differenza con lo sviluppo delle cascate è nello sviluppo delle cascate, tutto viene 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 leggerle come una specifica dettagliata e costruirla nel modo giusto la prima volta? Se potessi farlo, non avresti bisogno di XP o di qualsiasi altra metodologia agile.

Qualcuno dovrebbe porre domande se la storia è troppo vaga. Dove si verifica il test di accettazione ?

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

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

Hanno lavorato su prodotti nuovi ed esistenti e con entrambi hanno avuto casi in cui i requisiti erano solo 5 righe e ci si aspettava che riempissero gli spazi vuoti e facessimo un documento "comprensivo" o più elaborato.

I progetti si sono mossi molto meglio quindi abbiamo avuto il nostro personale di servizi professionali che ci ha aiutato (o in un caso un vicepresidente che è saltato dentro perché non c'era nessun altro disponibile). In entrambi i casi è una perdita di tempo per lo sviluppo (a meno che non ci sia feedback e la scadenza non sia cambiata). quindi il mio suggerimento: chiedi maggiori dettagli, fornisci di più, chiedi feedback a tempo determinato ai tuoi presupposti e documentazione e dichiari che è un rischio che ci siano rilavorazioni e ritardi se non ricevi queste informazioni entro la x data.

Indipendentemente dalla metodologia di sviluppo, se qualunque cosa tu stia utilizzando per definire i requisiti induce lo sviluppatore a fare ipotesi, deve essere respinto dal lato aziendale. Ho spesso una buona idea di quale risposta preferirei, quindi rilasso le cose in questo modo:

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

Ci vuole molto meno tempo per chiarire le cose prima di fare ipotesi sbagliate che rifare. Gli sviluppatori che fanno congetture sui requisiti senza ottenere la conferma che la loro ipotesi è giusta tendono ad essere cattivi sviluppatori e costano molto alla loro azienda. Se un cattivo manager non ti consente di respingere le cose, allora spiegagli quanto è più costoso in termini di tempo e denaro farlo nel modo sbagliato. Se insiste ancora, allora fai quello che dice e quando fallisce l'UAT, la prossima volta che vuoi calciare qualcosa, ricordagli quanto è stato costoso il tempo che non ti avrebbe lasciato. Se ancora non ascolta, trova un capo migliore.

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

Come sviluppatore,

Ho bisogno di comprendere appieno le specifiche di una user story,

in modo da poterlo stimare e implementare con sicurezza.

In altre parole, è necessario porre domande fino a quando non si comprendono i dettagli della storia. Questo viene fatto nella pianificazione dell'iterazione e funge da punto di decisione: se non è possibile stimarlo, non è possibile crearlo.