Sfide dell'approccio Agile ai progetti governativi

Una precedente discussione Agile qui aveva buone risposte specificando ciò che è fondamentale per il successo dell'implementazione della metodologia Agile nello sviluppo del software. La maggior parte dei punti erano le tipiche sfide organizzative e gestionali, ma un punto mi preoccupa ed è che il cliente deve essere coinvolto durante tutto il processo.

Il cliente è l'unica cosa che non puoi controllare realisticamente, forse il tuo modello di business ti porta al lavoro con contratto governativo, ad esempio dove un contratto intensamente rigoroso obbliga la società a:

• Fornisci le funzioni X esattamente come richiesto

• Le richieste di funzionalità verranno gettate su un muro, non ci disturbare, non vogliamo ascoltarlo.

• Non esiste un concetto di priorità delle funzionalità nella mente del cliente, sono tutti importanti o non avremmo chiesto loro.

• Il progetto non costerà più e non meno di Y indipendentemente da sovraccarichi o scadenze.

• Scadenza assoluta, rigorosa, definitiva e non negoziabile per la consegna completa di tutto il lavoro.

Non abbiamo mai lavorato con un cliente del genere prima d'ora, ma i soldi per il progetto sono semplicemente troppo buoni per essere lasciati passare. Abbiamo bisogno di questo lavoro.

Sono venuto qui e ho lavorato duramente per cambiare i processi all'interno per passare allo sviluppo Agile e qui non so come conciliare il modo in cui questo progetto si adatta al nostro nuovo processo. Non ho mai avuto il lusso di una gestione a mani aperte di mentalità aperta che mi ha affidato la fiducia di guidare il team di sviluppo e i processi su questa strada e ora che siamo qui non posso onestamente dire a me stesso che questo progetto sarà veramente realizzato in un Modo agile. Sento che il management mi ha affidato la fiducia necessaria per guidare questo percorso e che li ho delusi perché questa situazione in cui ci troviamo ora richiede così chiaramente Waterfall. Temo che potrei perdere la loro fiducia se torno indietro ora.

Altre risposte come quella qui dicono che Agile è impossibile con questo tipo di cliente, sei d'accordo? Qualcuno di voi si è trovato in una situazione simile e l'ha fatto funzionare? Quali strategie hai implementato per far accadere con successo Agile?

Penso che la prima cosa da capire è che c'è una differenza tra l'essere Agile e l'essere Agile. Sviluppare lentamente tecniche e caratteristiche agili: team interfunzionali, pianificazione adattiva, consegna evolutiva / incrementale, iterazioni temporali e persino l'introduzione di concetti di Lean sono molto diversi dall'introduzione di Extreme Programming, Scrum o Crystal.

Citi esplicitamente il coinvolgimento dei clienti. Sì, molte delle metodologie Agile richiedono il coinvolgimento dei clienti, ma non è necessario che siano agili. In ogni programma relativo al governo / alla difesa, ho sempre avuto un programma o un project manager che era il punto di contatto con il cliente. Questa persona diventa la "voce del cliente". Potrebbe essere rallentato in quanto teleconferenza o e-mail o chiamata e chiarimento, ma è possibile avere una sola persona (o un gruppo, se si hanno anche vicepresidenti) che è il rappresentante del cliente del proprio team. Certo, non è proprio lo stesso. Ma non è agile l'essere flessibile e rispondere al cambiamento?

Si citano anche alcuni concetti chiave: requisiti predefiniti, con richieste di funzionalità "gettate oltre il muro", mancanza di priorità in quanto "sono tutti importanti" e progetti a costo fisso e / o a programma fisso. Ognuno di questi può essere affrontato in diversi modi.

Se pensi di avere tutte le tue esigenze in anticipo, è probabile che tu non lo faccia. I requisiti cambiano. Solo perché hai una specifica "completata e firmata" non significa che sia incastonata nella pietra. Dati i documenti di requisiti che hai, acquisiscili come ti senti a tuo agio e / o nel modo specificato dal contratto e fornisci i requisiti, il design e l'architettura. Inoltre, vedi se riesci a trattare questi documenti viventi (un documento di progettazione che ho visto oggi al lavoro è etichettato come Revisione G, il che significa che è sul suo ottavo aggiornamento). Chiedi quanto puoi lasciare come TBD in ogni data iterazione e quanto deve essere risolto ora - ci potrebbero essere alcuni dare e avere.

Sii agile con la tua documentazione. Non duplicare gli sforzi tra "ciò che il tuo team vuole" e "ciò che il cliente desidera". Ad esempio, se il tuo cliente desidera una specifica dei requisiti software tradizionali e il tuo team desidera utilizzare le storie utente, prova ad adattarti a un SRS tradizionale e usa gli oggetti azione e un elenco di articoli azione a rotazione anziché le storie utente in modo da non perdere tempo formulando sia "il sistema deve ..." che "deve essere in grado di perché". Ciò richiede disciplina da parte del team, tuttavia, per adattarsi alle differenze tra i progetti. Cattura i problemi nelle riflessioni.

Una volta arrivato allo sviluppo, potresti eseguire 5 o 6 iterazioni e quindi invitare il tuo cliente alla tua struttura per vedere un sottoinsieme dell'implementazione. Risciacquare e ripetere questo processo. Non è il costante coinvolgimento richiesto da alcune metodologie, ma si ha il vantaggio di un'alta visibilità. Se il tuo cliente dice di no, almeno ci hai provato. Se dicono di sì, puoi illuminarli per essere agili. In un progetto in cui ero presente, il cliente visitava il sito ogni pochi mesi (3-5 mesi, di solito). Ci guarderebbero durante i test di controllo qualità, discuterebbero delle preoccupazioni con gli ingegneri e fare affari con l'ufficio programmi / progetti. È stata un'opportunità per tutti di accedere alla stessa pagina.

I test e la manutenzione avvengono come quelli di altri progetti agili. Crea le tue procedure di test e documenta i difetti nel modo appropriato, monitora le metriche per gli obblighi contrattuali e documenta i risultati dei test. Se vuoi seguire TDD, provaci. L'integrazione continua è un'altra buona idea. Durante le riunioni sullo stato del progetto, il responsabile del progetto può utilizzare queste informazioni per dire "abbiamo implementato N requisiti, disponiamo di test M, test X passati" e aggiorna la salute e lo stato del progetto alle persone con i soldi.

A proposito di denaro, abbiamo il problema del costo fisso e / o del programma fisso.

Trattare con un programma fisso è abbastanza semplice. Dati i tuoi requisiti, sai quante iterazioni puoi completare. Il carico di lavoro per ogni iterazione è praticamente improntato alla pietra in termini di funzionalità da implementare, testare e integrare. Potrebbe essere difficile, ma non è impossibile rompere le funzionalità e assegnarle in anticipo alle iterazioni. Questo risale al mio punto sull'invito al cliente: se hai un anno e stai usando iterazioni di 2 settimane, forse invita il cliente trimestralmente (e invitalo ogni trimestre) e mostra loro i risultati del lavoro precedente. Consenti loro di vedere la tua priorità dei requisiti, i tuoi piani futuri e come stai pianificando.

Trattare con un budget fisso è simile. Sai quanto tempo hai, quante risorse hai per il progetto, quanto costano e quindi quante ore tutti possono lavorare per iterazione. Si tratta solo di garantire che tutti ne tengano traccia con attenzione. Se la tua azienda può sostenere i costi degli straordinari, provaci. Altrimenti, assicurati che tutti lavorino per il periodo di tempo appropriato e usa le buone capacità di gestione del tempo e il time-boxing per mantenere tutti produttivi. Maggiori ore produttive sono ciò di cui hai bisogno per contenere i costi: fornire più documenti e software a valore aggiunto senza i costi delle riunioni e delle spese generali.

In definitiva, non si tratta necessariamente di essere Agili, ma di applicare le cose che rendono Agile buono ed essere agile. Essere in grado di rispondere ai cambiamenti nei requisiti, essere in grado di fornire software frequente anche se il cliente non lo desidera, produrre solo documentazione a valore aggiunto (insieme a tutto ciò che si è obbligati a produrre contrattualmente) e così via.

Sì, l'agile non è appropriato per un simile progetto, perché sembra che i requisiti siano già stati fatti e fissati nella pietra, probabilmente il risultato di anni di analisi di costosi consulenti, riunioni di commissioni e compromessi politici. Waterfall funziona bene se il cliente è così disciplinato da poterti dire per iscritto esattamente ciò che desidera. Potrebbero essere sbagliati, ma almeno ce l'hai per iscritto e verrai pagato se lo consegnerai. (Questo non dice nulla di soddisfazione del cliente, ovviamente. È probabile che consegnerai qualcosa di cui in realtà non hanno bisogno.)

Agile è stato creato per risolvere un problema che non hai: rischio a causa dell'incertezza nei requisiti.

È vero che il cliente potrebbe richiedere richieste di modifica, ma si segue uno dei due percorsi seguenti:

1. I soldi erano così buoni che sai che puoi assorbire una quantità X di nuove funzionalità in varie fasi del progetto e ancora uscire senza perdere la maglietta, o
2. Si chiarisce al cliente all'inizio che, a causa della negoziazione di un prezzo ridotto, ogni nuova richiesta di funzionalità genererà un ordine di modifica con un prezzo che dovrà essere approvato da loro, con un ordine di acquisto di accompagnamento (o modifica a l'ordine d'acquisto originale) affinché tu possa implementarlo. L'ordine di modifica spiegherà eventuali impatti sulla funzionalità o sulla pianificazione. Se dicono che la scadenza non può essere spostata, gli ordini di modifica diventano esponenzialmente più costosi man mano che il progetto avanza perché è più costoso cambiare le cose in seguito.

La relazione sembra molto più amichevole nella situazione n. 1, ma il fatto è piuttosto raro trovare reparti acquisti che non ti spremano sul prezzo, quindi la maggior parte delle volte ti trovi nella situazione n. 2. Ciò significa che la relazione è conflittuale, ma se vuoi sopravvivere negli affari, devi essere bravo a gestire la relazione mantenendo la tua posizione. Questa è una grande parte del lavoro del project manager.

Sembra che potresti trovarti nella situazione n. 1, il che è positivo. Immagino che i contratti governativi siano l'unico posto in cui non si preoccupano dei soldi, perché, dopo tutto, non stanno spendendo i loro soldi, stanno spendendo i tuoi soldi.

... lavori appaltati dal governo, ad esempio quando un contratto intensamente rigoroso obbliga la società a:

Primo. È severo. Ma non è inflessibile. Richiede semplicemente attenzione ai dettagli e una lunga, lunga serie di ordini di modifica.

Le agenzie governative in realtà sono agili in modo lento e inefficiente. Devi sempre scrivere (e negoziare) ordini di modifica formali e dettagliati.

Fornisci le funzioni X esattamente come richiesto

Fino a quando non viene modificato da un ordine di modifica.

Le richieste di funzionalità verranno gettate su un muro, non ci disturbare, non vogliamo ascoltarlo.

Il canale di comunicazione è l'ordine di cambiamento. Impatto sul budget e sulla pianificazione.

Non esiste un concetto di priorità delle funzionalità nella mente del cliente, sono tutti importanti o non avremmo chiesto loro.

È difficile aggirare questo problema. Anche le imprese non governative che spendono un sacco di soldi per "analisi dei requisiti" non vogliono sentirsi dire che una pila grande, piatta e fumante di requisiti non gravati da informazioni prioritarie e di compromesso è incompleta. Hanno pagato buoni soldi per ottenere tutti i requisiti. Come puoi richiedere maggiori informazioni?

Questo è un problema difficile

Il progetto non costerà più e non meno di Y indipendentemente da sovraccarichi o scadenze.

Tranne gli ordini di modifica. Che modificano Y e la scadenza.

Scadenza assoluta, rigorosa, definitiva e non negoziabile per la consegna completa di tutto il lavoro.

"non negoziabile" non è generalmente vero. È negoziabile. È solo doloroso negoziare.

La parte importante della negoziazione con le agenzie governative è il fatto che sono necessarie "prove a livello di avvocato" per le modifiche ai costi e ai programmi. Alcune presentazioni tecniche accurate con una bella diapositiva power-point non sono "prove". Hai bisogno di molta documentazione per presentare il tuo caso.

La gente del governo deve fornire prove impareggiabili di aver fatto tutto il possibile per renderlo il più economico ed efficace possibile. Sanno che ogni decisione viene riesaminata dalla stampa pubblica e controllata con il senno di poi.

La complessità dello sviluppo del software e l'aspetto "posticipato del lunedì mattina" del lavoro del governo li rendono riluttanti a apportare modifiche al contratto senza prove schiaccianti.

Rende difficile un approccio adeguatamente agile.

"Individui e interazioni su processi e strumenti" è difficile. Non stai lavorando con un individuo, ma un rappresentante del governo il cui lavoro è vincolato dal processo.

In un progetto come questo, hanno legato le mani su portata, risorse e tempo. L'unica cosa che ti resta da gestire è la qualità. Così...

Non trarrai il massimo beneficio da un approccio agile che potresti altrimenti, ma puoi fare del tuo meglio per mitigare i rischi di qualità ed essere in grado di informare il cliente dei problemi prima piuttosto che dopo.

Quindi sii il più agile possibile:

1. Esamina i requisiti e stabilisci le priorità in base al rischio tecnico. Impostare i requisiti prioritari come backlog.
2. Elaborare il backlog negli sprint: progettare, testare e codificare le funzionalità per lo sprint. Manca l'interazione con il cliente, quindi il documento sui requisiti deve rappresentare il client per questa attività.
3. Invita il cliente ad ogni recensione dello sprint: possono dire di no, ma potrebbero dire di sì. E riceverai feedback prima piuttosto che dopo.

Se inizi a correre contro la scadenza, sarai in grado di mostrare cosa è stato fatto, e forse a quel punto il cliente, sapendo che non otterrà tutto, avrà la priorità sufficiente per dirti ciò che vuole. Dovresti anche fare le cose più rischiose, il che significa che i compiti alla scadenza sono i più facili da stipare nelle ore extra lavorative.

Penso che questo tipo di cliente non sia la norma. Hai a che fare con un gruppo che ha richiesto progetti simili in precedenza, quindi sanno esattamente cosa vogliono. Non hai mai detto che le loro specifiche cambieranno.

Fornisci le funzioni X esattamente come richiesto

Sono fortunato se offro vagamente la funzione X come suggerito ed essere pronto a cambiarla in un attimo.

Le richieste di funzionalità verranno gettate su un muro, non ci disturbare, non vogliamo ascoltarlo.

Se sai cosa vogliono, vai e costruiscilo.

Non esiste un concetto di priorità delle funzionalità nella mente del cliente, sono tutti importanti o non avremmo chiesto loro.

Non puoi perdere su questo. Costruiscili come meglio credi.

Il progetto non costerà più e non meno di Y indipendentemente da sovraccarichi o scadenze. Scadenza assoluta, rigorosa, definitiva e non negoziabile per la consegna completa di tutto il lavoro.

È difficile se non hai mai realizzato un progetto per il governo. Se hai un po 'di storia, potresti essere in grado di determinare se puoi consegnare. Ciò non significa che non paghino bene (sono noti per pagare $ 50 per un martello da $ 10) o hanno aspettative irragionevoli. Con queste specifiche, qualcuno nel tuo team dovrebbe agire come cliente e approvare il lavoro rispetto alle specifiche. Anche se hai trovato un difetto e lo hai implorato di cambiare i requisiti, probabilmente non lo farebbero.

Purtroppo quello che hai descritto è la tipica visione da parte del cliente di come un progetto software dovrebbe essere affrontato. Questo non significa che il cliente sia irragionevole; dopo tutto, non è così che si potrebbe eseguire la costruzione di qualsiasi altra cosa (una casa, per esempio?). Detto questo, però, non sto offrendo niente di più di quello che già sappiamo tutti. Quello che stai chiedendo è ... è possibile applicare pratiche agili in questa situazione?

Ho il vantaggio di aver appena finito un progetto che è simile per molti aspetti alla situazione che descrivi, cioè

1. Scadenza fissa (in pietra, come hell-or-high-water).
2. Documento sui requisiti funzionali ("la Bibbia"). Non sorprendentemente inadeguato.
3. Ruoli tradizionali: Project Manager, Business Analyst.
4. Utenti aziendali debolmente coinvolti (puoi dire "nessuno sponsor del prodotto"?).

... e, naturalmente, il team di sviluppo lungimirante sta cercando di lavorare in modo agile, nonostante quanto sopra:

1. Iterazioni di 2 settimane;
2. Stand-up;
3. retrospettive;
4. Coppia di programmazione;
5. TDD;
6. Integrazione continua.

Qualcosa di tutto questo è comunque significativo per l'azienda? No. A due mesi dalla scadenza, le iterazioni fino a quel momento osservate attentamente e le riunioni di pianificazione sono state abbandonate in una frenesia di pollo senza testa.

Le risposte che altri hanno fornito sopra sono compromessi maggiori o minori. Secondo me, l'agile (sia "Agile" che "agile") viene "fatto in" in modo pernicioso quando scendiamo a compromessi. Secondo me:

Non c'è compromesso o non c'è agilità.

Lo stesso spirito di agilità consiste nel tagliare all'inseguimento, nel rimuovere gli sprechi, nell'essere brutalmente onesti con se stessi. È un fatto ormai ben documentato e innegabile che la stima del software su grandi progetti è una scommessa al massimo. Non è nostro dovere come professionisti del software educare i potenziali clienti di questo? Se i clienti non sono disposti ad accettare che siamo gli esperti, allora non è nostro dovere professionale andare via?

Quando ho iniziato a lavorare dove sono ora, mi sono ritrovato a porre la stessa domanda che mi hai fatto parecchio. C'è qualcosa da dire a cascata con i contratti del governo. Ironia della sorte, ora l'agile è diventato una parola d'ordine con i clienti del governo (che lavorano realisticamente in maniera a cascata), quindi ora ci rimane ancora più da fare per implementare un processo agile con un cliente sostanzialmente non flessibile.

Abbiamo un sistema che è stato descritto come "Scrummerfall" "Agilefall" o "A pasticcio", ma per molti aspetti siamo riusciti lentamente ad adottare un processo sempre più agile poiché questo progetto (gigantesco) è andato avanti nel corso degli anni . Uno dei modi in cui lo abbiamo fatto è fondamentalmente trovare canali di comunicazione con gli UTENTI del nostro sistema, al contrario dei nostri CLIENTI. I nostri clienti sono un reparto chiuso guidato da funzionari nominati che non toccheranno mai il nostro software durante la loro vita lavorativa e non vogliono capirlo. I nostri utenti sono regolari funzionari governativi sul campo che tentano di svolgere un compito importante. Per noi, la chiave per stabilire un circuito di feedback sulla comunicazione che ci ha permesso di essere agili come noi era la necessità di UAT (User Acceptance Testing).

A un certo punto del nostro progetto, è stato deciso che un gruppo rappresentativo di UTENTI EFFETTIVI di vari uffici del nostro vasto cliente governativo sarebbe stato raccolto QUI e avremmo avuto un paio di settimane di tempo con loro mentre correvano attraverso una serie di script di test per testare il nostro software. Molto più che una cosa informale, il team dei requisiti ha trasformato questa volta in un modo inestimabile per ottenere feedback dagli utenti finali reali. Nel frattempo, il team di test UAT all'interno del governo ha lavorato attraverso la loro burocrazia per avere sempre più influenza sul processo di requisiti formali da parte loro, compresi gli ordini di modifica. Il risultato finale è che BA come me agiscono come proprietari stand-in di prodotti incorporati nei team di scrum e sono in grado di ottenere un prezioso tempo a faccia con clienti reali che ci consentono di funzionare in modo molto agile.

Ovviamente, ci sono molti problemi e non siamo ancora molto agili, ma siamo abbastanza agili da essere stati sostenuti come esempio di un grande progetto agile che utilizza effettivamente quella metodologia nel settore dei contratti pubblici.

Per riassumere: usa la tua esperienza di agile evangelista all'interno della tua organizzazione per infiltrarti nel cliente. Segui un processo di apprendimento con loro, stabilisci un partenariato basato sulla fiducia con le persone chiave dalla loro parte e lavora attorno al processo formale e ossessivo dei requisiti che inevitabilmente hanno messo in atto. Sarai ringraziato dai ragazzi sul campo che devono effettivamente utilizzare ciò che stai sviluppando!

Stai assumendo che i requisiti siano ben scritti e pensi che significhino ciò che pensano di voler dire. L'andamento avanti e indietro del processo agile contribuirà a garantire che ottengano ciò che intendevano oltre a ciò che chiedevano.