Che cosa fare riguardo a "Failure Driven Development"?

Requisiti estremamente conflittuali 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 effettivamente fanno il lavoro fanno Y. Fare il software Y significa che le persone che pagano il software insisteranno che il software è difettoso dal loro prospettiva. Rendere il software X significa che le persone che ottengono effettivamente il lavoro non possono portare a termine il lavoro.

Normalmente, la maggior parte delle società di sviluppo sceglierà cosa direbbero i dirigenti rispetto a ciò che dichiarano i lavoratori perché è così che le fatture vengono pagate. Nel mondo ideale, non vi è alcun disallineamento di impedenza tra politiche scritte e politiche attuali; nel mondo reale molto lavoro d'ufficio è suddiviso informalmente e non documentato.

Camp A will losely dictate that Feature X works like this, then Camp B will fail it due not functioning like that.

La discrepanza tra CampA e CampB è un problema politico e non un problema di software. Risolvere il problema implicherà 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 un'idea di esattamente ciò di cui hanno bisogno fino a quando non ottengono qualcosa nelle loro mani. Questo è il motivo per cui la prima volta che il cliente vede il sistema non dovrebbe essere dopo che tutto è stato fatto e finito. Lascia che lo vedano presto e spesso.

In altre parole, se quello era l'unico problema, non c'è bisogno di andare in panico a meno che non si finisca in una situazione in cui si hanno solo ripetuti tentativi.

Il problema del disaccordo tra il corpo del cliente è un problema di Product Manager che non dovrebbe trapelare su di te. Il massimo che dovresti vedere è backlog / tasks / whatever. Ovviamente, il PM sfogherà spesso nel raggio di sviluppo perché è l'unico posto dove possono, ma non dovrebbe influire su di te.

Il modo in cui viene gestito dipenderà molto da chi sono il Campo A e il Campo B.

Se il Campo A e il Campo B rappresentano due rialzi più alti, allora porta qualcuno che effettivamente userà 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 sta lavorando spesso può tagliare l'idealismo e indicare ciò che è veramente necessario.

D'altra parte, se A e B sono gruppi di utenti, si usa la mossa opposta per far sì che qualcuno della direzione imponga la legge.

In tutti i casi, la perfezione è il nemico di abbastanza buono.

Quello che descrivi è un'implementazione tipica sbagliata di Agile. Non abbracci 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 (attraverso il proprietario del prodotto) nella pianificazione dello sprint? Hai dei tester nella squadra principale?

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

Un'altra soluzione è smettere di fare Agile.

Se sono ping-pong (A dice do x, B rifiuta, dice y, quindi A rifiuta e torna a x), quindi i tuoi lead (PO o qualunque cosa tu abbia) devono batterli per fare in mente.

Va bene se il primo go finisce per non soddisfare i loro bisogni (il punto centrale di questo è di dare loro qualcosa da guardare) ma se si siedono lì e oscillano avanti e indietro nelle iterazioni successive non lo farai mai.

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 in competizione all'interno del tuo cliente. Idealmente i campi A e B otterrebbero una visione condivisa negoziata che potrebbero presentarti.

Forse potrebbero essere costretti al tavolo da te a spiegare quanto costano loro i combattimenti mentre ripeti di nuovo ciò che A ha chiesto per B (o viceversa).

Mantenere note dettagliate sulla spesa del tuo tempo potrebbe aiutarti. (Il mio lavoro ha scritto un'applicazione per timetracking leggera: facile da usare e facile da riportare e riporta il tempo in blocchi di 15 minuti. Rende facile dire "Ho trascorso n ore su X".)

Significa che sei a rischio di rovesciare il cliente o di sembrare cattivo, qualunque cosa tu faccia, dal momento che ciò che fai per B potrebbe turbare A (o, ancora, vice versa).

Spero che tu possa trovare un campione presso il cliente che possa prendersi cura delle lotte intestine per te.

Per come la vedo io, il problema può essere risolto efficacemente in un unico posto, presso il cliente, che sarà difficile.

Stai dicendo che ti stai sforzando di essere agile, quindi lo prenderò dal punto di vista della mischia, che è il processo agile che conosco meglio.

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

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

Quindi credo che sia necessaria una persona con la responsabilità di coordinare le esigenze tra i diversi team presso il cliente, assicurando che i requisiti / le storie degli utenti consegnate agli sviluppatori siano state verificate da entrambi i team presso il cliente. Perseguire questo ruolo può facilmente essere un lavoro a tempo pieno, soprattutto con il cliente che hai.

Ciò che sarebbe davvero l'ideale è spostare questa responsabilità verso il cliente, per avere il ruolo di proprietario di un dipendente di uno dei tuoi clienti. Finché il cliente non ha questo ruolo, il cliente non si impegna a risolvere i propri disaccordi interni e lascia a te la responsabilità di risolverlo, cosa che molto probabilmente non sarà in grado di fare. Ed è per questo che credo che l'unica soluzione efficace sia quella di dare al cliente questa responsabilità.

Tuttavia, dato che hai già avviato una collaborazione, credo che avrai difficoltà a implementare tale modifica.

Affinché il tuo software venga accettato dal cliente, deve soddisfare tutti i requisiti stabiliti dal cliente in base ai criteri di accettazione.

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

Puoi uscire da questa situazione descrivendo il design funzionale e le regole di bussiness implementate e ottenendo questi firmati dal cliente. Questi saranno quindi ciò che viene testato contro durante l'accettazione. Questo deve essere concordato preventivamente 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, sei ancora nella fase di analisi dei requisiti del progetto.

Il tuo project manager potrebbe / dovrebbe offrire consulenza a pagamento come parte del progetto per risolvere l'ambiguità dei requisiti funzionali.

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

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