Cosa fare dello "Sviluppo guidato dal fallimento"?

Nel nostro negozio, ci sforziamo di essere agili. E direi che stiamo facendo grandi passi avanti. Detto questo, alcuni di noi hanno individuato uno schema che abbiamo iniziato a chiamare "Failure Driven Development".

Lo sviluppo guidato da guasti può essere sostanzialmente descritto come un ciclo di rilascio / iterazione agile in cui i bug / funzionalità non sono guidati da attività e storie con criteri di accettazione, ma con difetti inseriti nel software di tracciamento dei difetti.

Il nostro team ha un ottimo Project Manager che si sforza di ottenere i criteri di accettazione dai clienti, ma non è sempre possibile. Dalla mia sedia di sviluppo, ciò è dovuto al fatto che il cliente non sa esattamente cosa vuole o (e questo è il kicker) due diversi "campi" nel conflitto dell'ufficio principale del cliente con come una storia dovrebbe essere implementata. Il campo A detterà vagamente che la funzione X funziona in questo modo , quindi il campo B fallirà perché non funziona in questo modo . Da qui il termine "FDD". Il processo è guidato da "guasti".

Questo porta alla mia domanda: qualcun altro ha riscontrato questo e, in caso affermativo, qualche suggerimento / suggerimento per affrontarlo?

Naturalmente, abbiamo cercato di far concordare prima i campi A e B, ma tutti sanno che non è sempre così.

Grazie

I requisiti selvaggiamente contrastanti non sono insoliti nel mondo aziendale. E questo è spesso il motivo per cui i progetti di automazione dei processi aziendali "falliscono". Può essere semplice come "il manuale delle politiche e delle procedure dice di fare X" mentre le persone che svolgono effettivamente il lavoro fanno Y. Far sì che il software faccia Y significa che le persone che pagano per il software insisteranno sul fatto che il software è difettoso dal loro prospettiva. Fare in modo che il software esegua X significa che le persone che svolgono effettivamente il lavoro non possono farlo.

Normalmente, la maggior parte delle società di sviluppo sceglierà ciò che i manager dicono su ciò che affermano i lavoratori perché è così che vengono pagate le bollette. Nel mondo ideale, non vi è alcuna discrepanza di impedenza tra le politiche scritte e quelle effettive; nel mondo reale gran parte del lavoro d'ufficio è suddiviso e non documentato in modo informale.

Il campo A detterà losamente che la funzione X funziona in questo modo, quindi il campo B fallirà perché non funziona così.

La discrepanza tra CampA e CampB è un problema politico e non un problema di software. Risolvere il problema implica parlare con le persone e ottenere un chiaro vincitore.

Uno dei motivi principali per utilizzare lo sviluppo iterativo è perché hai un gruppo di clienti che non ha una buona idea di ciò che vuole.

Questo non è un fallimento. Molti clienti semplicemente non hanno idea di esattamente ciò di cui hanno bisogno fino a quando non ottengono qualcosa nelle loro mani. Questo è il motivo per cui, per la prima volta, il cliente vede che il sistema non dovrebbe esserlo dopo che sono stati eseguiti tutti gli adattamenti e le finiture. Fagli vedere presto e spesso.

In altre parole, se questo era l'unico problema, non c'è bisogno di farti prendere dal panico a meno che tu non finisca in una situazione in cui hai solo infiniti tentativi.

Il problema del disaccordo tra il corpo del cliente è un problema del Product Manager che non dovrebbe interessarti. Il massimo che dovresti vedere è backlog / task / qualunque cosa. Certo, il PM spesso sfogerà nel campo dello sviluppo perché è l'unico posto che può, ma non dovrebbe interessarti.

Il modo in cui è gestito dipenderà in larga misura da chi sono il Campo A e il Campo B.

Se il campo A e il campo B rappresentano due livelli più alti, porta qualcuno che utilizzerà effettivamente il sistema per dirti di cosa hai bisogno. A volte si ottiene aria rarefatta nella terra di gestione causando una disconnessione con la realtà. Qualcuno che è pratico può spesso tagliare l'idealismo e sottolineare ciò che è veramente necessario.

D'altra parte, se A e B sono gruppi di utenti, si usa l'opposto opposto di ottenere qualcuno dalla direzione per stabilire la legge.

In tutti i casi, la perfezione è nemica del bene.

Quello che descrivi è una tipica implementazione errata di Agile. Non accetti il ​​cambiamento, sei il suo schiavo .

Hai un proprietario del prodotto? Puoi parlare con loro, se necessario? Stai facendo una recensione sprint con gli utenti? Gli utenti sono coinvolti nel processo (tramite il proprietario del prodotto) nella pianificazione dello sprint? Hai tester nella squadra principale?

Consiglio vivamente di assumere un allenatore Agile e / o inviare la tua squadra a un allenamento.

Un'altra soluzione è smettere di fare Agile.

Se stanno giocando a ping-pong (A dice do x, B rifiuta, dice y, poi A rifiuta e torna a x), allora i tuoi contatti (PO o qualunque cosa tu abbia) devono batterli su di loro per prendere una decisione .

Va bene se il primo passo finisce per non soddisfare i loro bisogni (il punto è quello di dare loro qualcosa da guardare) ma se si siedono lì e oscillano avanti e indietro nelle iterazioni successive, non avrai mai finito.

Il problema qui non sembra essere "Lo saprò quando lo vedrò". I wireframe possono aiutare (fino a un certo punto) con quel particolare problema.

Il problema qui è, mi sembra, le due fazioni concorrenti all'interno del tuo cliente. Idealmente, i campi A e B avrebbero avuto una visione condivisa negoziata che potevano presentarti.

Forse potrebbero essere costretti al tavolo da te spiegando quanto costano i combattimenti mentre rifai di nuovo ciò che A ha chiesto di B (o viceversa).

Tenere note dettagliate sulla spesa in termini di tempo sarebbe utile qui. (Il mio lavoro ha scritto un'applicazione di timetracking leggera: facile da usare e facile da riferire e riporta il tempo in blocchi di 15 minuti. Rende facile dire "Ho trascorso n ore sulla funzione X.")

Significa che sei un po 'a rischio di sconvolgere il cliente o di apparire male, qualunque cosa tu faccia, dal momento che ciò che fai per B potrebbe sconvolgere A (o, ancora, viceversa).

Spero che tu possa trovare un campione presso il cliente che possa prendersi cura dei combattimenti per te.

A mio avviso, il problema può essere risolto efficacemente in un solo posto, presso il cliente, il che sarà difficile.

Stai menzionando che stai lottando per l'agile, quindi lo prenderò dal punto di vista della mischia, che è il processo agile che conosco meglio.

Secondo la mischia, hai un ruolo specifico, il proprietario del prodotto, che è responsabile della definizione delle priorità delle storie / bug / versioni degli utenti, ecc. Questo dovrebbe idealmente essere solo una persona. Se ci sono molte parti interessate con opinioni diverse sullo stesso software, è responsabilità del proprietario del prodotto che il prodotto soddisfa tutte le parti interessate.

Mi sembra che il tuo project manager abbia questo ruolo. Ma dal momento che viene chiamato project manager e non proprietario di un prodotto, sono portato a credere che sia gravato anche da altre attività (attività tradizionali, non agili, di gestione?) E non abbia abbastanza tempo per perseguire ruolo del proprietario del prodotto.

Quindi credo che tu abbia bisogno di una persona con la responsabilità di coordinare le esigenze tra i diversi team del cliente, assicurando che i requisiti / le storie degli utenti forniti agli sviluppatori siano stati verificati da entrambi i team del cliente. Perseguire questo ruolo può facilmente essere un lavoro a tempo pieno, specialmente con il cliente che hai.

Quello che sarebbe davvero l'ideale è spostare questa responsabilità verso il cliente, per avere uno dei dipendenti del cliente che ricopre il ruolo di proprietario del prodotto. Finché il cliente non ha questo ruolo, il cliente non si impegna a risolvere i propri disaccordi interni e lascia a te la risoluzione di ciò che molto probabilmente non sarai in grado di fare. Ed è per questo che credo che l'unica soluzione efficace sia quella di dare al cliente questa responsabilità.

Ma dato che hai già avviato una collaborazione, credo che avrai difficoltà a implementare quel cambiamento.

Al fine di ottenere l'accettazione del software da parte del cliente, è necessario soddisfare i requisiti stabiliti dal cliente in base ai criteri di accettazione.

Hai una serie di requisiti dell'utente sotto forma di storie e criteri di accettazione, ma parti dell'organizzazione del cliente hanno interpretazioni diverse delle storie degli utenti, il che porta all'ambiguità.

È possibile uscire da questa situazione descrivendo il design funzionale e le regole di business implementate e ottenendo queste firmate dal cliente. Questi saranno quindi gli elementi che verranno testati durante l'accettazione. Questo deve essere concordato in anticipo dal cliente per evitare discussioni sul significato di tutta la documentazione in seguito.

Finché il tuo gruppo non può descrivere il software che stai costruendo in modo tale che entrambi i gruppi siano d'accordo su di esso, sei ancora nella fase di analisi dei requisiti del progetto.

Il project manager potrebbe / dovrebbe offrire una consulenza retribuita nell'ambito del progetto per risolvere l'ambiguità dei requisiti funzionali.

Penso che tutti abbiamo visto il caso in cui otteniamo requisiti dettagliati dall'utente, li implementiamo, quindi sentiamo l'utente "Aspetta, non funzionerà per me" una volta implementato.

Una cosa che potrebbe aiutare è fare una forma di QA sui requisiti fornendo all'utente esempi dettagliati con il comportamento del sistema previsto. Ad esempio, potresti dire: "Ecco un esempio. Se implementiamo X, allora Y sarà il risultato e Z una delle conseguenze." In questo modo, puoi arrivare a "Aspetta, non funzionerà" prima di scrivere il codice anziché dopo.