È possibile eseguire Agile senza il coinvolgimento del cliente?

Come potrebbe? La natura stessa della tecnica determina una sorta di anello 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 da poter "fingere" di essere agili, anche se ciò non sarà così soddisfacente come ottenere un feedback effettivo da parte dei clienti.

Piaccia o no, il cliente sarà coinvolto nel processo di progettazione; è solo una questione di quanto vogliono che la rilavorazione abbia un costo (più a lungo viene ritardata, più è costosa).

Poiché il cliente desidera "Big Design Up Front", aiuta loro a capire che ci vorrà più tempo e sforzi da parte loro per ottenere il design giusto la prima volta.

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

In my experience, waterfall does not work.

Waterfall è una metodologia valida per fornire sistemi di varia complessità. È un peccato che non sia ben presentato o capito. Una delle ragioni è che non fa abbastanza soldi per competere 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 utilizzando solo l'approccio Waterfall e molti di questi sono ancora in produzione oggi. È triste che l'industria del software sia basata su hype più che sulla scienza.

Clients do not know what they want until they see it.

Questo è un mito. Un grande anche. Questo potrebbe 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 questi utenti usano ancora gli schermi AS / 400 e i monitor 3270 CICS con RGB e possono fare il loro lavoro con quegli strumenti. Inoltre, quegli stessi utenti accettano i sistemi ERP SAP e ORACLE senza avere alcuna 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 capiscono come fanno il loro lavoro molto bene il 90% delle volte.

The waterfall dilemma is further propagated by a large community of developers that want to have all the requirements up front. This way they know what they are building, they can architect accordingly, and the client is to blame because they "signed off" on said requirements.

Non puoi incolpare gli sviluppatori di voler sapere cosa stanno costruendo perché quegli sviluppatori vogliono andare a casa a cucinare la cena e premere le camicie per un'altra esercitazione dopo aver trascorso 3 ore circa imparando la prossima tecnologia. questo sostituirà il loro attuale set di abilità! Il gioco della colpa non rende nessuno un 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 sostituiscono gli analisti di business che dovrebbero sapere come raccogliere i requisiti dagli utenti, indipendentemente dalla metodologia.

Non vogliono mettere il tempo e se hanno una scelta preferiscono avere software gratis, ma li addebiterà comunque, giusto? Ciò si offusca 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 il massimo da voi il più possibile.

Puoi essere potenzialmente agile. Ottieni tutte le specifiche e inizia a programmare. Una volta che il client interrompe il lavoro perché pensava solo a qualcosa e devi apportare modifiche e rielaborazioni, sei diventato un po 'più agile. Potresti anche fare le approvazioni all'interno del tuo team. Chiedi a una delle tue squadre di indossare giacca e cravatta e fingere di essere il cliente.

Impegnarsi molto in anticipo potrebbe spaventarli. Suggerisci di fare uno sprint per provarlo. Quindi offri loro la possibilità di ritirarti. Puoi sempre passare a una cascata per il resto del progetto. Suggerire inoltre che persone diverse nella propria squadra possano fare la revisione e approvare se il tempo è un vincolo per la persona che scrive il assegno.

Ad un certo punto, devi dire loro che non pensate che la cascata funzionerà. Chiedi loro se sono 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 un accordo sui requisiti può essere privo di senso come ho visto nei progetti a cui ho partecipato. Il tuo problema va oltre la possibilità 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 possibilità di ottenere requisiti più dettagliati per ogni funzionalità complessiva. Quando il cliente asseconda tutte le sue esigenze in anticipo, ciascuna caratteristica tende a essere un'idea vaga, con un po 'di funzionalità definite. Agile costringe il cliente a rivisitare ogni funzione e a concentrarsi su esattamente su ciò che desidera e su come la funzione si adatta all'immagine più grande. Per ottenere la stessa quantità di dettagli (abbastanza dettagli per implementare le funzionalità) nelle specifiche, waterfall richiede davvero di fare una delle due cose:

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

2. Dare molta più importanza al design in anticipo. In sostanza, quando il cliente lancia le sue specifiche semi-elaborate al primo giorno, pensa di esaminare tutti i minimi dettagli prima di implementare qualsiasi cosa. Chiedi al cliente di chiarire tutto fino alla nausea fino al punto in cui conosci tutti i dettagli dell'implementazione per l'intero progetto. Anche se non è perfetto, è meglio dell'opzione 1. Potresti ancora imbatterti in dettagli che non avevi previsto, e potrebbe persino inviare il client in esecuzione per le colline, ma se davvero non vogliono essere in comunicazione durante lo sviluppo e tu non sono psichici, questa è una necessità. Fondamentalmente è cascata e include tutti gli aspetti negativi associati, tra cui l'estrema difficoltà di esecuzione.

3. Prendi le specifiche semi-cotte, ma chiedi dei chiarimenti mentre vai comunque. Lavora finché non raggiungi una parte vaga delle specifiche, quindi chiedi al cliente di chiarire. Naturalmente, questo non è ciò che il cliente ha chiesto, ma se non vogliono un'applicazione un'applicazione torbida come le specifiche e si rifiutano di definire le specifiche in anticipo, questa è l'unica opzione rimanente. Non ha tutti i vantaggi di Agile (come l'approvazione regolare del cliente per assicurarsi che tutti siano sulla stessa pagina), tuttavia, ti permette di ottenere le informazioni che ti servono per sviluppare. Dato che l'opzione 1 ti lascerà probabilmente un prodotto secondario, l'opzione 2 è dispendiosa e frustrante per il cliente (probabilmente dovrai dedicare almeno il doppio del tempo al design e alla raccolta delle specifiche in generale se lo fai interamente in anticipo), questa non è davvero una cattiva opzione. La chiave qui è quella di essere diligenti nel modificare le scadenze e il prezzo con ogni cambiamento che si presenta. Se lo fai bene, potresti scoprire che la maggior parte delle pratiche Agile sono compatibili con questo accordo, anche se il cliente non lo sa. IMHO, questo è davvero in linea con lo spirito di Agile, in quanto dovresti adattare le metodologie al tuo particolare arrangiamento.

Se il cliente non può davvero vivere con le conseguenze di una di queste tre opzioni o di una vera e propria Agile, ho difficoltà a immaginare come potrebbe valere davvero il tuo cliente.

Penso che sia difficile ma ancora possibile. Penso che l'idea del proxy di Robert funzioni, ma è necessario che il proxy spenda il maggior tempo possibile con il client 'reale' in modo che possano vedere le cose dal loro punto di vista. In questo modo il proxy può accertare quali caratteristiche sono veramente importanti e avere un'idea dell'esperienza utente che il cliente si aspetta / desidera.

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

È possibile evitare i 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 il cliente.

Agile richiede il loop ristretto per sostituire il grande design up-front che è Hard - Abbastanza difficile ma in realtà può essere fatto, l'agile non è l'unico modo.

Potresti voler trovare una delle modifiche di Agile - ce ne sono molte e uno probabilmente affronta questo problema specifico, ma se non lo fai da solo se pensi di poterlo fare.

Tutti questi processi sono stati creati da persone intelligenti - e le persone intelligenti possono far funzionare qualsiasi processo. Non credi che Cascata sia stata inventata perché non ha mai funzionato per nessuno? Si è evoluto perché alcune persone potevano farlo funzionare, e altri guardavano e dicevano "Devo perfezionarlo e darlo al mio team che non sembra produrre altrettanto efficacemente" - a quel punto probabilmente ha funzionato meglio di quello che hanno stavamo facendo, ma se non riconosci che non tutti i programmatori possono risolvere ogni problema, possono davvero sconcertarti perché due team che utilizzano lo stesso processo possono avere risultati diversi.

Il problema è che molti processi richiedono talento per implementarli - stiamo parlando di talenti rari come i giocatori sportivi professionisti da un gruppo di persone che hanno mai praticato uno sport - è probabile che molti di noi non abbiano mai incontrato qualcuno capace di far funzionare i processi di crack come la cascata 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 avere il cliente a guardare costantemente ciò che stai facendo in modo che gli errori non possano propagarsi, e cose come il refactoring senza scrupoli in modo che tu non possa " t costruire un debito tecnico che la squadra non può disfare pochi mesi dopo la linea.

Definisci il cliente.

È un'altra società? Un altro individuo?

È un'altra squadra nella tua azienda?

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

Sei tu?

Tutti i precedenti sono possibili e abbastanza ragionevoli a seconda delle circostanze. Non vuoi dare una sola visione del tunnel su cosa vuol dire essere Agile, per cui un NO definitivo non sarebbe corretto. SÌ d'altra parte richiede un piccolo pensiero laterale.

Pensa alla parola Agile per un momento. Il gruppo di persone molto intelligenti che hanno 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 una flotta di piedi? Veloce per reagire forse? Veloce per adattarsi?

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

Sono il cliente a tutti gli effetti per i miei progetti solisti. Indosso persino un vero cappello a volte, quando voglio davvero apportare un cambiamento mentale distintivo al mio ruolo di cliente . Questo non mi rende meno agile di quando sono al lavoro. Per quel che mi riguarda, il mio gatto può essere il manager . Si assicura che prenda una pausa ogni tanto, e mi ricorda di evitare di essere troppo ossessionato da un singolo compito. Forse preferisci usare la tua fantasia "Pomadoro Technique", ma preferisco il timer "Rascal" !! Il fatto è che io lavoro in un processo rigorosamente agile ogni volta che scrivo codice per me stesso. Non sono il tipo hacker-come-cowboy, che vive una vita di infiniti picchi di sviluppo e che 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 lavorassi per un vero cliente. Quando le cose interrompono il mio programma, aggiusto e do la priorità al mio progetto di conseguenza. Uso tutte le pratiche e le tecniche Agile standard che posso applicare da solo e "consegno" codice di lavoro a me stesso (oa un amico o collega per testare) tutte le volte che posso. Se tutto questo non è agile, ti chiedo che 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 gestore. Puoi lavorare su un progetto tutto da solo e indossare cappelli multipli. Tuttavia, potrebbe non essere Ideale fare a meno di questi altri ruoli, poiché è molto utile collaborare con gli altri per raggiungere un obiettivo. Agiscono come una cassa di risonanza per le tue idee e ti danno i requisiti che altrimenti potresti trovare difficili da generare in modo sensato da soli. L'altro ruolo molto importante che il cliente e il manager soddisfano è quello di mantenerti concentrato sui tuoi obiettivi, senza aggiungere continuamente funzioni e perfezionare il tuo codice oltre a quello che potrebbe essere strettamente necessario.

Tuttavia, se lavori in modo disciplinato, attenendosi rigorosamente alla tua metodologia di scelta e applica pratiche Agili, e se quando ti trovi di fianco, o cambi idea (quando indossi il cappello del tuo cliente) e il tuo prodotto la progettazione o la direzione prende una svolta, se è possibile adattare il programma e regolare le priorità proprio come si immagina il cliente si aspetterebbe che tu lo faccia, allora sei agile.