Agile può essere realizzato senza il coinvolgimento del cliente?

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?

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.

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.

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?

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.

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.

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" ...

È 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.

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.

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. SÌ 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 è Sì , 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.