Agile può essere realizzato senza il coinvolgimento del cliente?


23

Non riuscivo a scrivere un libro su Agile. Ho lavorato in diversi negozi che chiamano il loro processo Agile. Uno dei punti principali dello sviluppo Agile è il coinvolgimento regolare dei clienti. Dopo uno sprint, il lavoro può essere sottoposto a demo per il cliente per ottenere il loro feedback. Risciacqua e ripeti.

Il problema che ho riscontrato è che molti clienti non vogliono essere così coinvolti. Preferirebbero di gran lunga un approccio a cascata. Raccogli i requisiti in anticipo, poi torna quando hai finito. Nella mia esperienza, la cascata non funziona. I clienti non sanno cosa vogliono fino a quando non lo vedono. Il dilemma della cascata è ulteriormente propagato da una grande comunità di sviluppatori che vogliono avere tutti i requisiti in anticipo. In questo modo sanno cosa stanno costruendo, possono progettare di conseguenza e il cliente è responsabile perché hanno "firmato" tali requisiti.

Sono errato? Agile può funzionare senza il coinvolgimento del cliente? In tal caso, come e come superare i problemi di cui ho discusso?


12
Non lasciare che "agile" diventi il ​​tuo martello in modo che tutto il resto appaia come un chiodo che deve essere martellato.
Patrick Hughes,

1
Nella mia esperienza, la preferenza verso gli approcci a cascata è generalmente dovuta alla mancanza di comprensione del funzionamento del software o del design. La buona notizia è che significa che Agile non è il grosso problema, è l'atteggiamento / comprensione del cliente. La cattiva notizia è l'atteggiamento del cliente.
Ben Brocka,

@BenBrocka: Non è terribilmente sorprendente, considerando che è stato appositamente progettato Waterfall. L'autore voleva scrivere un articolo su come potrebbe apparire un processo di sviluppo creato da qualcuno che non capisce lo sviluppo del software e perché un tale processo non può funzionare. Quindi, ha specificamente inventato Waterfall come esempio di un processo progettato da qualcuno che non capisce lo sviluppo del software e che non può funzionare. Ovviamente, non è una sorpresa che piaccia a chi non capisce lo sviluppo del software, né è una sorpresa ...
Jörg W Mittag

@BenBrocka: ... che non funziona. Ciò che sorprende è il motivo per cui qualcuno dovrebbe anche voler utilizzare un processo che è specificamente progettato per non lavorare. Immagino che nessuno si preoccupi di leggere davvero il giornale.
Jörg W Mittag,

1
@ JörgWMittag L'adozione effettiva di Waterfall (che si rendano conto che è la cascata o no) è principalmente solo perché è un modello standard di decisioni aziendali; il capo vuole qualcosa, sottotitolo, il cliente è felice, giusto? Ovviamente non funziona ma è un bel modello semplice per belle menti semplici :)
Ben Brocka,

Risposte:


17

Come potrebbe? La natura stessa della tecnica impone una sorta di circuito di feedback tra il cliente e lo sviluppatore.

Parti del tuo team possono, tuttavia, agire come clienti "proxy" (un processo simile a "mangiare il tuo cibo per cani") in modo che tu possa "fingere" di essere agile, anche se non sarà soddisfacente come ottenere un cliente reale risposta.

Piaccia o no, il cliente sarà coinvolto nel processo di progettazione; è solo una questione di quanto vogliono che le rilavorazioni costino (più è lungo il ritardo, più è costoso).

Dal momento che il cliente desidera "Big Design Up Front", aiutalo a capire che ci vorrà più tempo e impegno da parte sua per ottenere il design giusto la prima volta.


5
Parti del tuo team possono, tuttavia, fungere da clienti "proxy" - nella mia esperienza, i tester hanno reso "proxy" piuttosto efficaci del tipo che menzioni. Quando ero anch'io un tester, a volte facevo anche finta di indossare una tuta da cliente per così dire. Tuttavia, un simile proxy ha delle limitazioni - ad esempio, un addetto al controllo qualità che si lamenta di quanto tempo impiega a installare il prodotto potrebbe sentirsi così perché lo fa quotidianamente mentre il cliente lo fa una volta all'anno o due
moscerino

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Per chi è davvero più costoso? La maggior parte dei clienti non vede pagare per il proprio tempo per mettere in atto la propria visione attuale di una soluzione. A volte hanno solo un problema e non hanno modo di sapere quale dovrebbe essere la soluzione fino a quando non dici loro quale sarà. A quel punto se ciò che hai detto loro in realtà non risolve il loro problema, allora è IL TUO GUASTO non il loro. Come è colpa loro se hai frainteso i loro veri problemi in primo luogo? cont ...
maple_shaft

cont ... perché dovrebbero pagare per questo? Solo per salvare la faccia con il cliente e non rovinare del tutto ogni possibilità di affari ripetuti, allora devi voltarti e fare le rilavorazioni gratuitamente perché hanno richiesto il contratto a prezzo fisso in primo luogo. Questo è l'atteggiamento più diffuso ed è esattamente ciò che sta vivendo P.Brian.Mackey. I clienti rafforzano queste trattative e quando sei solo una delle 100 startup che cercano di ottenere il contratto, il ragazzo con il contratto realistico ed equo basato su Agile dovrà attendere in fondo alla fila. È DURO là fuori adesso.
maple_shaft

@maple_shaft: Chiaramente sei stato bruciato da questo. Ma, come in tutte le cose, si tratta di scelte. Agile esiste perché la cascata ha i suoi problemi e le persone non sono perfette. Se il cliente è stato informato dei rischi e desidera comunque la cascata, questa è la sua scelta. È anche una scelta del negozio di software decidere se valga la pena rischiare o meno un client che non comprende i rischi o nega la validità di tali rischi.
Robert Harvey,

@RobertHarvey Anche un cattivo cliente in una cattiva economia è ancora un cliente e mantiene ancora le luci accese per qualche altro mese. I rischi per il cliente nel caso che ho citato sono minimi e contenuti per sapere se hanno ricevuto la soluzione promessa in tempo. Il rischio per il negozio di software in questo caso è se questo client doloroso nella parte posteriore ci risucchia.
maple_shaft

7

La risposta breve alla tua domanda è "no". Ecco alcuni commenti su alcune parti della tua domanda. Per essere precisi, la maggior parte delle risposte si basa sulla mia esperienza personale e osservazione.

Nella mia esperienza, la cascata non funziona.

Waterfall è una solida metodologia per fornire sistemi di varia complessità. È un peccato che non sia ben presentato o compreso. Uno dei motivi è che non fa abbastanza soldi in competizione con la metodologia del giorno che continua a spuntare. Potresti essere sorpreso di sapere che molti dei sistemi bancari, assicurativi e produttivi sono stati costruiti solo con l'approccio Waterfall e molti di questi sono ancora in produzione oggi. È triste che l'industria del software sia basata sulla campagna pubblicitaria più che sulla scienza.

I clienti non sanno cosa vogliono fino a quando non lo vedono.

Questo è un mito Anche uno grande. Questo può essere il caso del design / layout della pagina Web, ma per l'elaborazione dei dati aziendali, la maggior parte degli utenti desidera qualcosa che funzioni. Alcuni di quegli utenti usano ancora schermi AS / 400 e monitor 3270 CICS con RGB e possono svolgere la propria attività con quegli strumenti. Inoltre, quegli stessi utenti accettano i sistemi SAP e ORACLE ERP senza avere voce in capitolo nella progettazione dell'interfaccia (e alcune volte nella funzionalità). La maggior parte degli utenti aziendali adatterà anche le proprie abitudini e flussi di lavoro se il sistema sta producendo la funzione corretta. Lo stress qui è sulla funzione non sembra. Gli uomini d'affari comprendono come svolgono il proprio lavoro molto bene il 90% delle volte.

Il dilemma della cascata è ulteriormente propagato da una grande comunità di sviluppatori che vogliono avere tutti i requisiti in anticipo. In questo modo sanno cosa stanno costruendo, possono progettare di conseguenza, e il cliente è responsabile perché hanno "firmato" tali requisiti.

Non puoi incolpare gli sviluppatori di voler sapere cosa stanno costruendo perché quegli sviluppatori vogliono andare a casa cucinare la cena e premere le magliette per un altro trapano dopo aver trascorso circa 3 ore a imparare la prossima tecnologia. che sostituirà la loro attuale serie di abilità! Il gioco della colpa rende nessuno vincitore. Pensa in termini di ruoli e responsabilità di ciascuna parte e il quadro sarà molto chiaro.

In conclusione, i project manager, i programmatori e i web designer non possono sostituire gli analisti aziendali che dovrebbero sapere come raccogliere i requisiti dagli utenti finali indipendentemente dalla metodologia.


3
+1 - Per contendere "i clienti non lo sanno". È una questione di domini diversi che hanno diversi tipi di client. Ecco perché gli agilisti non riescono a capire le persone a cascata. Credono che tu possa dire quello che vuoi solo quando lo vedi. Non è vero, ma è tutto ciò che vedono dai loro clienti. Mentre i sostenitori della cascata non riescono a capire perché non si riesca a comprendere la stragrande maggioranza dei requisiti in modo che il progetto possa tenere conto di tutti i problemi. Probabilmente è perché le persone a cascata non trattano molto con i clienti volenti o cattivi.
Dunk il

1
@Dunk, grazie per il tuo commento. Mi piace la tua frase "" clienti volenti o nolenti!
NoChance,

2

Non vogliono perdere tempo e se gli viene data la possibilità preferiscono ottenere software gratuitamente, ma li ricaricherai comunque, giusto? Questo diventa sfocato se stai sviluppando software internamente per la tua azienda. Pensano che il dipartimento IT sia stato acquistato e pagato (dipendenti stipendiati), quindi potrebbero anche ottenere più lavoro possibile da te.

Puoi essere potenzialmente agile. Ottieni tutte le specifiche e inizia a scrivere codice. Una volta che il cliente interrompe il lavoro perché hanno appena pensato a qualcosa e devi apportare modifiche e rilavorazioni, sei diventato un po 'più agile. Potresti anche fare le approvazioni all'interno del tuo team. Chiedi a un membro della tua squadra di indossare giacca e cravatta e fingere di essere il cliente.

Fare un grande impegno in anticipo può spaventarli. Suggerisci di fare uno sprint per provarlo. Quindi dai loro la possibilità di rinunciare. Puoi sempre passare a una cascata per il resto del progetto. Inoltre, suggerisce che diverse persone del loro team possano fare la revisione e approvare se il tempo è un vincolo per la persona che scrive l'assegno.

Ad un certo punto, devi dire loro che non pensi che la cascata funzionerà. Chiedi loro se erano soddisfatti di questo approccio e, in tal caso, perché non hanno l'ultimo ragazzo a fare questo progetto?


2

Nessuna metodologia può funzionare senza il coinvolgimento del cliente. Avere la firma sui requisiti può essere insignificante come ho visto in progetti a cui ho partecipato. Il tuo problema va oltre la capacità di fare Agile, devi educare il tuo cliente e assicurarti che capiscano quanto sia importante per loro partecipare.


2
Non è una questione di importo e frequenza di partecipazione da parte del cliente e non è una questione di tutto o niente?
JeffO,

3
Un cliente che rifiuta di partecipare spesso è a mio avviso un cliente bisognoso di educazione. Non è insolito che gli esperti del business del cliente mettano in una posizione in cui devono interagire con la società di sviluppo software e svolgere comunque le loro attività quotidiane e che devono essere affrontate parlando con i loro superiori.
Otávio Décio,

2

Penso che uno dei principali vantaggi di Agile sia la capacità di ottenere requisiti più dettagliati per ogni funzione in generale. Quando il cliente fornisce in anticipo tutti i suoi requisiti, ogni caratteristica tende ad essere un'idea vaga, con un po 'di funzionalità definita. Agile costringe il cliente a rivisitare ogni funzione e concentrarsi esattamente su ciò che desidera e su come la funzione si adatterà al quadro generale. Per ottenere la stessa quantità di dettagli (dettagli sufficienti per implementare le funzionalità) nelle specifiche, cascata richiede davvero di fare una delle due cose:

  1. Indovina. Implementa fino a quando non ti imbatti in qualcosa di vago, quindi dai un giudizio su come ritieni che la funzionalità sarebbe meglio implementata. Questo ovviamente non è l'ideale, dal momento che porta alla "Aspetta, non è quello che ho chiesto!" scenario.

  2. Metti molta più enfasi sul design in anticipo. Fondamentalmente, quando il cliente ti lancia le specifiche appena sfornate il primo giorno, pianifica di esaminare ogni dettaglio prima di implementare qualsiasi cosa. Chiedi al cliente di chiarire tutto fino alla nausea al punto in cui conosci tutti i dettagli di implementazione per l'intero progetto. Sebbene non sia perfetto, questo è meglio dell'opzione 1. Potresti ancora imbatterti in dettagli che non avevi previsto, e potrebbe persino inviare il client in corsa per le colline, ma se davvero non volessero essere in comunicazione durante lo sviluppo e tu non sono sensitivi, questa è una necessità. Questo è fondamentalmente a cascata, e viene fornito con tutti i lati negativi associati, incluso essere estremamente difficile da eseguire correttamente.

  3. Prendi le specifiche semicotte, ma chiedi chiarimenti man mano che vai avanti. Lavora finché non raggiungi una parte vaga delle specifiche, quindi chiedi al cliente di chiarire. Naturalmente, questo non è ciò che il cliente ha richiesto, ma se non vogliono un'applicazione torbida come la specifica e rifiutano di definire la specifica in anticipo, questa è l'unica opzione rimasta. Non ha tutti i vantaggi di Agile (come l'approvazione regolare del cliente per assicurarsi che tutti siano sulla stessa pagina), tuttavia, ti consente di ottenere le informazioni che devi sviluppare. Poiché l'opzione 1 probabilmente ti lascerà con un prodotto secondario, l'opzione 2 è dispendiosa e frustrante per il cliente (probabilmente dovrai dedicare almeno il doppio del tempo alla progettazione e alla raccolta di specifiche complessive se lo fai completamente in anticipo), questa non è davvero una cattiva opzione. La chiave qui deve essere diligente nel modificare le linee temporali e il prezzo ad ogni cambiamento che si presenta. Se lo fai nel modo giusto, potresti scoprire che la maggior parte delle pratiche Agili sono compatibili con questo accordo, anche se il cliente non lo conosce. IMHO, questo è davvero in linea con lo spirito di Agile, in quanto si suppone che si adattino le metodologie alla propria disposizione particolare.

Se il cliente non riesce davvero a convivere con le conseguenze di nessuna di queste tre opzioni o Agile in piena regola, faccio fatica a immaginare come questo cliente possa davvero valere la pena.


Hai lasciato fuori l'opzione 4. Prendi le specifiche con la stragrande maggioranza dei requisiti. Fai il design (probabilmente iterativo) con le recensioni dei clienti. Implementare e testare il codice (probabilmente iterativo). Tenere periodiche revisioni del programma che informano il cliente dello stato di avanzamento e delle decisioni. Danno feedback, tu incorpori i loro commenti e vai avanti.
Dunk il

Le situazioni che descrivi sopra si verificherebbero solo con squadre che non sanno come fare la cascata. Sì, è difficile eseguire correttamente. Anche Agile è difficile da eseguire correttamente. Ogni volta che qualcuno fallisce in modo agile, qualche agilista lancia una nuova regola che non è stata seguita e afferma che questa è la ragione del fallimento. Non è mai colpa di Agile. Almeno i sostenitori della cascata ammettono che ci vogliono brave persone con buone capacità per far funzionare la cascata.
Dunk il

La tua opzione 4 è esattamente ciò che intendevo descrivere nell'opzione 3.
Morgan Herlocker,

Come potrei migliorare la mia risposta? Non so dire se sei d'accordo o in disaccordo con quello che sto dicendo.
Morgan Herlocker,

Puoi migliorarlo forse togliendo la parola cotta a metà per cominciare. Rimuovere la parte su questo non è ciò che il cliente voleva. Rimuovere la parte oscura delle specifiche, ecc. In cascata, la parte importante della cattura dei requisiti è quella di ottenere quelli architettonici significativi e quelli che il sistema deve assolutamente fare per essere utile in anticipo. Successivamente, i cambiamenti di solito non sono un grosso problema. Che ci crediate o no, ci sono e sono sempre state iterazioni, sia formali che informali nello sviluppo delle cascate. Molto prima che arrivasse l'agile.
Dunk,

1

Penso che sia difficile ma ancora possibile. Penso che l'idea del proxy di Robert funzioni ma è necessario che il proxy passi il più tempo possibile con il client "reale" in modo che possano vedere le cose dal loro punto di vista. In questo modo il proxy può verificare quali funzionalità sono davvero importanti e farsi un'idea dell'esperienza dell'utente che il cliente si aspetta / desidera.

Ma a un certo punto dovrai mostrare il software al client "reale" ...


0

È possibile evitare clienti reali, infatti a volte è necessario per la regolamentazione. Di solito i clienti del software medico non sono coinvolti. In questi casi, altre entità possono sostituire il ruolo del cliente, ad esempio il team di marketing può essere considerato cliente.


0

Agile richiede l'anello stretto per sostituire il grande design frontale che è difficile - Abbastanza difficile ma in realtà può essere fatto, agile non è l'unico modo.

Potresti voler trovare una delle modifiche di Agile: ce ne sono molte e una probabilmente risolve questo problema specifico, ma se non riesci a risolverle se pensi di poterlo fare.

Tutti questi processi sono stati creati da persone intelligenti e le persone intelligenti possono far funzionare qualsiasi processo. Non pensi che la cascata sia stata inventata perché non ha mai funzionato per nessuno, vero? Si è evoluto perché alcune persone potevano farlo funzionare, e altri hanno guardato e detto "Devo perfezionarlo e dargli da mangiare al MIO team che non sembra produrre nel modo più efficace" - a quel punto probabilmente ha funzionato meglio di quello che loro stavamo facendo, ma se non riconosci che non tutti i programmatori possono risolvere ogni problema, puoi davvero sconcertarti perché due team che usano lo stesso processo possono avere risultati diversi.

Il problema è che molti processi richiedono talento per implementarli - stiamo parlando di talenti rari come i professionisti dello sport da un pool di tutti coloro che hanno mai praticato uno sport - è probabile che la maggior parte di noi non abbia mai incontrato qualcuno in grado di creare i processi scadenti come la cascata funzionano ed è per questo che così tante persone pensano che non possa avere successo - non l'hanno mai visto funzionare.

Ci vuole molto meno talento per far funzionare Agile, ma richiede alcuni investimenti molto specifici come far controllare costantemente al cliente ciò che si sta facendo in modo che gli errori non possano propagarsi e cose come il refactoring spietato in modo da non accumulare un debito tecnico che la squadra non può svelare qualche mese dopo.


0

Definire il cliente.

È un'altra compagnia? Un altro individuo?

È un'altra squadra all'interno della tua azienda?

È un campione di prodotto all'interno della tua azienda?

Sei tu?

Tutto quanto sopra è possibile e abbastanza ragionevole a seconda delle circostanze. Non vuoi dare una sola visione in fondo al tunnel su cosa debba essere Agile, quindi dire che un NO definitivo sarebbe errato. d'altra parte richiede un po 'di pensiero laterale.

Pensa alla parola Agile per un momento. Il gruppo di persone molto intelligente che ha coniato il termine non avrebbe potuto scegliere una metafora migliore per il concetto che stavano cercando di descrivere. Quando dici Agilità , cosa ti viene in mente? Essere flotta di piede? Veloce a reagire forse? Veloce da adattare?

Ora pensa a tutte le pratiche Agile comunemente accettate e chiediti cosa portano realmente ai metodi di sviluppo del software che sono considerati Agili .

Sono il cliente a tutti gli effetti per i miei progetti da solista. Indosso persino un vero cappello a volte, quando voglio davvero fare un cambiamento mentale distintivo nel mio ruolo di cliente . Questo non mi rende meno agile di quando sono al lavoro. Per quanto mi riguarda, il mio gatto può essere il manager. Si assicura che io faccia una pausa di tanto in tanto ogni tanto, e mi ricorda di evitare di essere troppo ossessionato da ogni singolo compito. Puoi preferire usare la tua "tecnica Pomadoro", ma preferisco il timer "Rascal" !! Il fatto è che lavoro in un processo strettamente Agile ogni volta che scrivo codice per me stesso. Non sono il tipo hacker-come-cowboy, che vive una vita di picchi di sviluppo senza fine e non realizza nulla. Mi piace creare il mio software, pianificare lo sviluppo del mio lavoro e delle mie vite personali e completarlo in un modo che mi aspetterei di fare se stessi lavorando per un vero cliente. Quando le cose interrompono il mio programma, adeguo e stabilisco le priorità del mio progetto di conseguenza. Uso tutte le pratiche e le tecniche Agile standard che posso applicare da solo e "consegno" codice di lavoro per me stesso (o un amico o un collega da testare) il più spesso possibile. Se tutto ciò non è Agile, ti chiedo cos'è?

Quindi la mia risposta è , puoi essere uno sviluppatore di software Agile e puoi applicare una metodologia Agile e non hai necessariamente bisogno del cliente o del manager. Puoi lavorare su un progetto da solo e indossare più cappelli. Tuttavia, potrebbe non essere necessariamente ideale eliminare questi altri ruoli, poiché è molto utile cooperare con gli altri per raggiungere un obiettivo. Agiscono come una cassa di risonanza per le tue idee e ti soddisfano requisiti che potresti trovare difficili da generare in modo sensato da solo. L'altro ruolo molto importante che il cliente e il manager soddisfano è quello di tenervi concentrati sui vostri obiettivi, senza aggiungere infinite funzionalità e perfezionare il codice oltre ciò che potrebbe essere strettamente necessario.

Tuttavia, se lavori in modo disciplinato, aderendo rigorosamente alla tua metodologia di scelta e applichi le pratiche Agile, e se quando verrai indirizzato o cambi idea (quando indossi il cappello del cliente) e il design o la direzione del tuo prodotto fa una svolta, se puoi adattare il tuo programma e adattare le tue priorità proprio come immagineresti che il tuo cliente si aspetterebbe da te, allora sei Agile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.