Eliminare la vera agilità dalla parola d'ordine agile in un'intervista [chiuso]

Recentemente ho intervistato per cooperazioni (stage retribuiti) e un gran numero di aziende con cui ho intervistato hanno affermato di utilizzare Scrum o qualche altra metodologia agile (la mischia è la più popolare). So che ci sono veri negozi agili e ci sono posti che dicono che usano una metodologia agile ma stanno davvero facendo qualcos'altro e usano agile come parola d'ordine.

La mia domanda è: quali sono alcune domande che posso porre in un'intervista che separerebbe questi negozi?

EDIT: Mentre sto cercando uno stage, sento che queste domande sono rilevanti per tutti. La parte dello stage è contestuale.

Comincio sempre ponendo questa domanda:

Qual è la durata delle iterazioni?

Valuta la loro risposta:

1 settimana è fantastica, 2 settimane sono fantastiche, 3 è ok e 4 mediocre. Più di questo indica che stanno lottando e più di 8 settimane è solo strano. Se la risposta dipende , sai che non ne hanno idea.

Seguire con:

Quanto spesso rilasci?

Questo per verificare la prima domanda. La risposta giusta è giornaliera o alla fine di ogni sprint . Un agilista saprebbe che non dovrebbe esserci alcuna differenza tecnica tra un rilascio interno ed esterno.

Chiedi loro di difendere metodologie agili. E poi chiedi loro di confutare sottolineandone le debolezze. Punti bonus se possono navigare in questo corso senza sporcarlo con parole d'ordine insignificanti.

Chiedi loro perché lo usano .

Lo saprai immediatamente.

Chiederei loro di descrivere il ciclo di vita dello sviluppo del software quando si utilizza la metodologia Agile. Se ne hanno familiarità, dovrebbero essere in grado di descrivere accuratamente ogni fase dell'SDLC.

EDIT : Ho appena capito che stavi chiedendo dal punto di vista dell'intervistato, non dell'intervistatore. In tal caso probabilmente chiederei loro riguardo al loro SDLC e vedere se i passi che dicono che fanno corrispondano a ciò che è realmente Agile.

L'approccio che ho davvero non ha molto a che fare con le parole d'ordine agili, ma ha a che fare con le pratiche agili. Uno dei punti in comune in tutti i team agili è la breve iterazione, la maggior parte delle persone ottiene quella parte (è uno dei 12 principi alla base dell'agile sul sito http://agilemanifesto.org ). Lo scopo della breve iterazione è di ottenere un feedback tempestivo sulla qualità del software sviluppato. Questo è dove inizio.

1. Chiedi informazioni sui test unitari. Incredibilmente la risposta che ottengo qui è stata "uh, l'abbiamo eliminata perché non avevamo abbastanza tempo" (nota: primi 2 flag di avvertimento - nessun tempo e nessun test unitario)
2. Chiedere quando è stato testato il software e con quale frequenza. Le risposte possono essere creative qui. Soprattutto se il team usa "Agile" come scusa per buttare via tutto il processo. Se la risposta è verso la fine del progetto, o qualcosa di diverso da ogni iterazione, non sanno cosa sia agile.

Finora, non ho dovuto andare oltre per sapere che la persona non sa cosa sia agile. Ho anche partecipato a un'intervista con un'azienda che aveva già avviato processi agili ben consolidati.

C'è più di un modo di fare agile, e io mi preoccupo più dei principi di agile che di qualsiasi particolare marchio o parola d'ordine.

Esistono diverse cose che separano coloro che "agiscono" agili da quelli che sono agili:

• Chiedere l'integrazione continua se non utilizzano CI dedurre un punto. Aggiungi un punto se lo sono. Punti extra:
  1. Aggiungi 1 se utilizzano commit in due fasi (il codice deve essere compilato correttamente prima che lo sviluppatore possa effettuare il check-in).
  2. Aggiungi 1 se lo script di build include l'esecuzione di una suite di test
  3. Aggiungi 1 se la compilazione fallisce se la copertura del codice scende al di sotto di una determinata soglia
  4. Aggiungi 2 se è possibile distribuire l'applicazione in modo che sia pronto per essere eseguito con un clic
• Chiedi informazioni su TDD (test-driven development) sottraendo 2 punti se non usano TDD aggiungi 1 se lo fanno.
• Chiedi informazioni sulle iterazioni, per quanto tempo (sottrai 2 punti se non eseguono uno sviluppo iterativo, sottrai 1 se l'iterazione dura più di un mese o meno di due settimane, aggiungi 1 se sono le sue 2 settimane)
• Chiedi come viene fatta la stima, aggiungi 1 se usano i punti storia, aggiungi 2 se pianificano il poker o qualcosa di simile, sottrai uno se usano stime di tempo assolute, sottrai 2 se gli sviluppatori non sono coinvolti nel processo di stima.
• Chiedi come sono costruite le funzionalità aggiungi 1 se uno sviluppatore è responsabile della funzionalità dall'alto verso il basso (sezione verticale) sottrai 1 se gli sviluppatori sono responsabili di un livello specifico (sezione orizzontale)

Ci sono un certo numero di altri indicatori, ma quelli da soli dovrebbero darti una buona idea se il team è effettivamente agile. Una squadra con almeno 5 punti si qualifica. Qualsiasi altra cosa significa che stanno "facendo" agili. Agile non si tratta solo di iterazioni, ma di consentire al team di adattarsi ai cambiamenti facilmente. Se stai scrivendo in modo iterativo codice non testato, confuso, scritto sotto pressioni esterne, beh, stai solo scrivendo codice di merda nelle iterazioni. Si noti che è possibile ottenere molti punti solo dal proiettile di integrazione continua. Ma questo da solo non è abbastanza per portarti oltre 5 se non stai seguendo le altre pratiche.

Come per tutte queste cose, chiedi esempi del mondo reale dai progetti su cui hanno lavorato , non dalla teoria. Accettare le risposte teoriche è il modo più semplice per essere ingannato da qualcuno che non è stato effettivamente lì.

Quindi chiedi di parlare con gli sviluppatori reali e chiedi cose come:

• Quindi parlami del tuo attuale progetto. Qual era l'obiettivo finale iniziale? Cosa conteneva il primo sprint e cosa poteva fare il software alla fine?
• Puoi darmi esempi di funzionalità o design sul tuo ultimo progetto che ritieni abbia funzionato diversamente da come l'hai fatto come un progetto a cascata?
• Mi fai un esempio di come una grande funzionalità è stata suddivisa su più sprint? A quali inefficienze / rilavorazioni ha portato questo? E quali miglioramenti o cambiamenti rispetto a quanto inizialmente previsto.
• Quando hai iniziato a lavorare con l'agile, quali cose che stavi facendo durante i primi sprint hai cambiato durante gli sprint (o i progetti) successivi mentre hai imparato la metodologia?

Continuate a riportarli ai progetti reali : cosa stavano cercando di ottenere, esempi di ciò che era presente in ogni sprint, esempi del genere di cose emerse durante le riunioni, esempi di interazioni con gli utenti.

Non accettare la teoria, non accettare i progetti di altre persone, solo le cose su cui loro stessi hanno lavorato e di cui possono parlare per esperienza diretta.

Dovrebbero essere incredibilmente bravi a mentire per riuscire a recuperare 10-15 minuti di cose che ti supererebbero se conoscessi le tue cose.

Se non vuoi renderli difensivi, ho scoperto che la seguente domanda avvierà una conversazione che ti dirà tutto ciò che devi sapere sul fatto che stanno effettivamente utilizzando un approccio Agile o semplicemente pagando il servizio labbra:

Chi è responsabile della redazione dei requisiti / specifiche per i tuoi progetti software?

Ho visto numerose aziende che affermavano di essere agili e volevano persino una certificazione Scrum Master per descrivere un classico processo di progettazione iniziale quando chiedi del loro processo di raccolta dei requisiti.

La cosa che mi distingue è che stai cercando uno stage, il che mi porta a chiedermi quale sia il tuo scopo nel porre queste domande. Stai cercando di porre una domanda su agile per far andare bene l'intervista o rifiuteresti effettivamente un'offerta da una società che usa una parola d'ordine agile? Se stai davvero cercando un ambiente agile, scegli una domanda (perché usi agile, a che ora sono i tuoi stand-up, per quanto tempo sono le iterazioni, qualunque cosa) e chiedilo al telefono o in un'e-mail senza perdere tempo su un colloquio. Se stai cercando entrate, attendi il colloquio e poni domande che dimostrino la tua conoscenza / entusiasmo riguardo alle metodologie agili (parlami del tuo ciclo di vita di sviluppo del software) senza mettere in imbarazzo l'intervistatore se usano un abominio semi-agile.

Chiedo loro di descrivere una richiesta tipica, dall'inizio alla consegna finale al cliente.

Chiedo anche se in genere gestiscono il supporto a lungo termine per il prodotto che forniscono al cliente (perché i team che lo fanno generalmente costruiranno un prodotto migliore, sapendo che saranno quelli che lo ripareranno all'una di domenica durante il weekend del Labor Day).

Chiedo anche come il management vede il suo ruolo durante il processo. È abbastanza facile vedere se hanno l'atteggiamento di fuoco e dimentica (lanciamo, voli, ti chiediamo se colpisci il bersaglio) o l'atteggiamento "ti aiutiamo a remare la barca sul fiume".

Questi ti mostreranno in genere come fanno veramente le cose, non come sono tenuti a farle, o come sostengono di farle.

Il modo migliore che ho trovato per vedere se qualcuno sa cosa stanno facendo da una prospettiva SDLC è chiedere loro dove hanno sbagliato in passato e come lo farebbero diversamente. Le persone che hanno superato il processo alcune volte e ammetteranno completamente dove hanno sbagliato, e in genere sono piuttosto dettagliate. La loro apertura a discuterne mostra un livello di fiducia, perché ammettono di non essere perfetti. Evitare la domanda dicendo "Lo fanno praticamente sempre OK" è un vero segnale di avvertimento.

Quanto spesso rilasciano in produzione. Più lungo è il tempo, meno agili sono. Quante volte hanno seminari di riflessione. Se sanno di cosa stai parlando, allora bene. Con quale frequenza organizzano riunioni di gruppo. Il quotidiano è fantastico, il mensile è negativo. Hanno un server di integrazione continua? Questo non è un must, ma ti darà un'idea del loro uso degli strumenti. Con quale frequenza gli utenti finali siedono con gli sviluppatori. Non significa mai che non sono Agili.

• Dai loro una situazione e chiedi loro di risolverlo in modo agile;
• Chiedi loro le loro pratiche agili preferite (pianificazione del poker, programmazione delle coppie, bdd / tdd, kanban);
• Chiedi loro perché non hanno scelto o spostato da altre metodologie (cascata, rup, ecc.)
• Quali sono le persone più conosciute nel mondo della metodologia agile, che hanno coniato il termine e quali libri più popolari sono scritti al riguardo.

Se stanno usando Scrum, potresti chiedere se puoi guardare il prossimo stand-up. Se non li hanno, chiedi perché no, perché di solito sarebbe parte della metodologia.

Ci sono alcuni aspetti di Agile che potrebbero essere degni di nota. Chiedi di vedere lo storyboard, quanto è grande il registro posteriore o quali sono stati alcuni dei momenti salienti dell'ultima retrospettiva, per qualche altra idea. La chiave qui è quella di arrivare a qualcosa di tangibile che mostra ciò che sta accadendo rispetto a parole soffici che non significano molto.

Chiedi loro come gestiscono il design. Se ti dicono che non esiste un design agile, non lo stanno ottenendo.

Chiedi loro come gestiscono le mutevoli esigenze. Se sembra che il cambiamento dei requisiti abbia un suo processo, probabilmente non lo stanno ottenendo.

Se affermano di usare Scrum, guarda come lo scrivono. I negozi che fanno Scrum tendono a sapere abbastanza bene come scriverlo. Suggerimento: non è SCRUM.

Potrebbe sembrare una pedanteria, ma sono fermamente convinto che per applicare con successo un modello di processo come Scrum, RUP, XP o qualsiasi altra cosa, devi capire la filosofia e il "perché", così sai come adattarti il "cosa" per la tua organizzazione. In Scrum, la maggior parte delle persone che stanno facendo i compiti troveranno quel po 'di informazioni. Le persone che sono alla ricerca di ricette di libri di cucina per la gestione dei progetti di solito non hanno questo dettaglio.

Ciò che ha senso per me è chiedere loro di descrivere come gestiscono parte del processo Agile. In questo momento il mio preferito è l'inizio di un'iterazione, ma potresti sviluppare il tuo preferito.

Chiedi: "dato una pila di biglietti all'inizio dello sprint, descrivi il tuo flusso di lavoro da qui"

Punti chiave da ascoltare qui:

• Gli sviluppatori stimano i biglietti?
• Tieni traccia della velocità?
• Cosa succede quando le tue stime superano la tua velocità?
• Cosa succede quando le tue stime superano la tua velocità quando hai una scadenza? (Guarda qui per lo spin: riducono la complessità, o ridistribuiscono, o semplicemente fanno morire il team di sviluppo?)

Nessuno di questi è un affare da solo, ma se le loro risposte a abbastanza di queste domande ti fanno meravigliare, allora forse sono interessati a rituali agili , non allo sviluppo agile reale .